Laravel Vector Search ಈಗ MariaDB ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ

Laravel 13 ಅಭಿವರ್ಧಕರಿಗೆ MariaDB ವಿರುದ್ಧ ನೇರ vector-search ಪ್ರಶ್ನೆಗಳನ್ನು (queries) ನಡೆಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಇದು PostgreSQL ಗೆ ಬದಲಾಗುವ ಒತ್ತಡವಿಲ್ಲದೆ Laravel ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ semantic-search ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಈ ಹೊಸ ಬೆಂಬಲವು ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ ಹಿಂದಿನ PostgreSQL-ಮಾತ್ರದ ಅನುಷ್ಠಾನವನ್ನು (implementation) ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪರಿಚಿತ whereVectorSimilarTo ವಿಧಾನವು ಈಗ MariaDB ಸಂಪರ್ಕದೊಂದಿಗೆ ನೇರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನೀವು ಶಿಫಾರಸು ಇಂಜಿನ್‌ಗಳು (recommendation engines), ದಾಖಲೆ-ಸಮಾನತೆಯ ಸಾಧನಗಳು (document-similarity tools), ಅಥವಾ "nearest-neighbor" ತರ್ಕವನ್ನು ಅವಲಂಬಿಸಿರುವ ಯಾವುದೇ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಈ ಬದಲಾವಣೆಯು ಒಂದು ಪ್ರಮುಖ ಅಡಚಣೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ.

ಈ ಬದಲಾವಣೆ ಏಕೆ ಮುಖ್ಯ

Laravel ನ query builder ಈ ಮೊದಲು ಕೇವಲ PostgreSQL ಸಂಪರ್ಕಗಳನ್ನು ಗುರುತಿಸುವ instanceof ಪರೀಕ್ಷೆಯ ಮೂಲಕ vector-search ಅಗತ್ಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತಿತ್ತು. ಆ ವಿಧಾನವು ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಕೇವಲ ಒಂದು ಡ್ರೈವರ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿತ್ತು ಮತ್ತು ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ಡೇಟಾಬೇಸ್-ನಿರ್ದಿಷ್ಟ ಕಂಡೀಷನಲ್‌ಗಳನ್ನು (conditionals) ಹೆಚ್ಚಿಸಿತ್ತು.

13 ನೇ ಬಿಡುಗಡೆಯು ಈ ತರ್ಕವನ್ನು (logic) grammar layer ಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ ಮತ್ತು ಎರಡು ಡ್ರೈವರ್-ನಿರ್ದಿಷ್ಟ ವಿಧಾನಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ:

  • supportsVectorDistance() – ಪ್ರಸ್ತುತ ಸಂಪರ್ಕವು vector ಅಂತರಗಳನ್ನು ಲೆಕ್ಕಹಾಕಬಲ್ಲದೇ ಎಂದು Laravel ಗೆ ತಿಳಿಸುತ್ತದೆ.
  • compileVectorDistanceExpression() – ಲೆಕ್ಕಾಚಾರವನ್ನು ಮಾಡುವ SQL ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ.

ಈ ಜವಾಬ್ದಾರಿಗಳನ್ನು ಪ್ರತಿಯೊಂದು ಡ್ರೈವರ್‌ಗೆ ನಿಯೋಜಿಸುವ ಮೂಲಕ, ಫ್ರೇಮ್‌ವರ್ಕ್ "type-checking" ಹ್ಯಾಕ್ ಅನ್ನು ಕೈಬಿಡುತ್ತದೆ ಮತ್ತು ಭವಿಷ್ಯದ ವಿಸ್ತರಣೆಗಳಿಗೆ ದಾರಿ ಮಾಡಿಕೊಡುತ್ತದೆ. ಈಗ ಮತ್ತೊಂದು ಡೇಟಾಬೇಸ್‌ಗೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸುವುದು ಎಂದರೆ ಕಂಡೀಷನಲ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಚದುರಿಸುವ ಬದಲು ಕೆಲವು ಡ್ರೈವರ್ ವಿಧಾನಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು ಎಂದರ್ಥ.

MariaDB ನ ನೇರ ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ, ಆದರೆ MySQL ಪಡೆಯುವುದಿಲ್ಲ

MariaDB ನ ನೇರ vector ಫಂಕ್ಷನ್‌ಗಳೊಂದಿಗೆ ಬರುತ್ತದೆ. ನೀವು AI ಎಕ್ಸ್‌ಟೆನ್ಶನ್‌ಗಳನ್ನು ಸೇರಿಸುವ ವಿಶೇಷ ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ಬಳಸದ ಹೊರತು, ಸ್ಟ್ಯಾಂಡರ್ಡ್ MySQL ನಲ್ಲಿ ಇವುಗಳ ಕೊರತೆಯಿದೆ.

Laravel ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ PHP-ಬದಿಯ ಸಾಮ್ಯತಾ ಲೆಕ್ಕಾಚಾರವನ್ನು (similarity calculation) ತಪ್ಪಿಸುತ್ತದೆ. PHP ನಲ್ಲಿ vector ಗಳನ್ನು ಲೆಕ್ಕಹಾಕುವುದರಿಂದ ಪೇಜಿನೇಶನ್ (pagination) ತಪ್ಪಾಗಬಹುದು ಮತ್ತು ಎಚ್ಚರಿಕೆಯಿಲ್ಲದೆ ಅಪ್ಲಿಕೇಶನ್ ನಿಧಾನವಾಗಬಹುದು. ಡ್ರೈವರ್ ಈ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ದೋಷವನ್ನು (error) ತೋರಿಸುವುದು ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಾದ ವಿಧಾನವಾಗಿದೆ.

MySQL ಬಳಕೆದಾರರು ಈಗ ಏನು ಮಾಡಬಹುದು

ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ ಸಾಮಾನ್ಯ MySQL ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಮುಂದೆ ಮೂರು ವಾಸ್ತವಿಕ ಮಾರ್ಗಗಳಿವೆ:

  1. MariaDB ಗೆ Migrate ಮಾಡಿ – ಹೆಚ್ಚಿನ MySQL ಕೆಲಸಗಳಿಗೆ ಇದು ನೇರ ಪರ್ಯಾಯವಾಗಿದೆ, ಇದು ಒಂದೇ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತಲೇ ನಿಮಗೆ ನೇರ vector ಬೆಂಬಲವನ್ನು ನೀಡುತ್ತದೆ.
  2. ಪ್ರತ್ಯೇಕ ಸರ್ಚ್ ಸೇವೆಯನ್ನು ಸೇರಿಸಿ – ಕೇವಲ ಸಾಮ್ಯತಾ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ (similarity queries) MySQL ಜೊತೆಗೆ ಒಂದು ಲೈಟ್‌ವೇಟ್ PostgreSQL ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಚಲಾಯಿಸಿ.
  3. ಇದಿಲ್ಲದೆಯೇ ಮುಂದುವರಿಯಿರಿ – ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ semantic search ಐಚ್ಛಿಕವಾಗಿದೆ; ಇದರ ಪ್ರಯೋಜನವು ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚಕ್ಕಿಂತ ಹೆಚ್ಚಿಲ್ಲದಿದ್ದರೆ, MySQL ನಲ್ಲೇ ಇರುವುದು ಪ್ರಾಯೋಗಿಕ ನಿರ್ಧಾರವಾಗಬಹುದು.

ಪ್ರತಿಯೊಂದು ಆಯ್ಕೆಯೂ ಕಾರ್ಯಾಚರಣೆಯ ಸಂಕೀರ್ಣತೆ, ವಿಳಂಬ (latency) ಮತ್ತು ನಿರ್ವಹಣಾ ವೆಚ್ಚದಲ್ಲಿ ಹೊಂದಾಣಿಕೆಗಳನ್ನು (trade-offs) ಒಳಗೊಂಡಿದೆ. ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಮೌಲ್ಯದ ಮೇಲೆ vector search ಎಷ್ಟು ಮುಖ್ಯವಾಗಿದೆ ಎಂಬುದರ ಮೇಲೆ ಈ ನಿರ್ಧಾರ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.

API ವಿನ್ಯಾಸಕ್ಕಾಗಿ ಪಾಠಗಳು

Laravel ಬದಲಾವಣೆಯು ಒಂದು ವಿಶಾಲವಾದ ವಿನ್ಯಾಸ ತತ್ವವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಕೋರ್ ಲಾಜಿಕ್‌ನಾದ್ಯಂತ ಡೇಟಾಬೇಸ್-ನಿರ್ದಿಷ್ಟ ಪರಿಶೀಲನೆಗಳನ್ನು ಚದುರಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ. ಒಂದು ವೈಶಿಷ್ಟ್ಯವು ನಿರ್ದಿಷ್ಟ ಇಂಜಿನ್‌ನ ಸಾಮರ್ಥ್ಯಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದಾಗ, ಆ ಅವಲಂಬನೆಯನ್ನು ಡ್ರೈವರ್ ಇಂಟರ್ಫೇಸ್‌ನ ಹಿಂದೆ ಸಂಯೋಜಿಸಿ (encapsulate). ಹೊಸ grammar-ಆಧಾರಿತ ವಿಧಾನವು ಇದನ್ನೇ ಮಾಡುತ್ತದೆ, ಇದು ಕೋರ್ query builder ಅನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸದೆ ಭವಿಷ್ಯದ ವಿಸ್ತರಣೆಗಳಿಗಾಗಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ.

ತಮ್ಮದೇ ಆದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿರುವ ಅಭಿವರ್ಧಕರು ಇದನ್ನು ಗಮನಿಸಬೇಕು. ನಿಮ್ಮ ಸರ್ವಿಸ್ ಲೇಯರ್‌ನೊಳಗೆ ಡೇಟಾಬೇಸ್ ಪ್ರಕಾರಕ್ಕಾಗಿ instanceof ಪರಿಶೀಲನೆಗಳನ್ನು ಕಂಡರೆ, ಆ ಜವಾಬ್ದಾರಿಯನ್ನು ಡ್ರೈವರ್ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಅಡಾಪ್ಟರ್‌ಗೆ ವರ್ಗಾಯಿಸಿ. ಇದು ಪಬ್ಲಿಕ್ API ಅನ್ನು ಸ್ವಚ್ಛವಾಗಿಡುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಭವಿಷ್ಯಕ್ಕೆ ಸಿದ್ಧಪಡಿಸುತ್ತದೆ.