ಒಂದು ವಿಡಿಯೋ-ಹೋಸ್ಟಿಂಗ್ ಸೇವೆಯ ಹಿಂದಿರುವ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ತನ್ನ SQLite FTS5 ಇಂಡೆಕ್ಸ್ ಅನ್ನು OpenSearch ಕ್ಲಸ್ಟರ್ಗೆ ಬದಲಾಯಿಸಿತು, ಇದರಿಂದ ಶೂನ್ಯ-ಫಲಿತಾಂಶದ (zero-result) ಕ್ವೆರಿಗಳು 12% ರಿಂದ 1.4% ಕ್ಕೆ ಇಳಿದವು ಮತ್ತು ಲ್ಯಾಟೆನ್ಸಿ (latency) 28 ms ಗಿಂತ ಕಡಿಮೆ ಇರಿಸಿಕೊಳ್ಳುವಾಗೆಯೇ ಸರ್ಚ್-ಟು-ಕ್ಲಿಕ್ ದರವು 9% ಹೆಚ್ಚಾಯಿತು.
ಈ ಬದಲಾವಣೆ ಏಕೆ ತುರ್ತಾಗಿ ಬೇಕಾಯಿತು
SQLite ನ ಫುಲ್-ಟೆಕ್ಸ್ಟ್ ಸರ್ಚ್ ಎಕ್ಸ್ಟೆನ್ಶನ್ (FTS5) ಆಕರ್ಷಕವಾಗಿದೆ: ಇದು ಉಳಿದ ಡೇಟಾದಂತೆಯೇ ಒಂದೇ ಫೈಲ್ನಲ್ಲಿ ಇರುತ್ತದೆ, ಯಾವುದೇ ಲೈಸೆನ್ಸಿ ವೆಚ್ಚವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಮತ್ತು ನಿಖರವಾದ ಟೋಕನ್ ಹೊಂದಾಣಿಕೆಗಳಿಗೆ ತಕ್ಷಣವೇ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ. ಆದರೆ, ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ಲಾಗ್ಗಳು ಬಳಕೆದಾರರ ಸರ್ಚ್ಗಳಲ್ಲಿ ಸುಮಾರು ಹನ್ನೆರಡು ಪ್ರತಿಶತವು ಯಾವುದೇ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತಿಲ್ಲ ಎಂದು ತೋರಿಸಿದವು. ಮೊಬೈಲ್ ಕೀಬೋರ್ಡ್ಗಳಲ್ಲಿ ಜನರು ಮಾಡುವ “intersteller” ಅಥವಾ “avengrs endgame” ನಂತಹ ಕಾಗುಣಿತ ದೋಷಗಳು (misspellings) ಇದಕ್ಕೆ ಮುಖ್ಯ ಕಾರಣಗಳಾಗಿದ್ದವು.
ಟ್ರಿಗ್ರಾಮ್ಗಳನ್ನು (trigrams - ಮೂರು ಅಕ್ಷರಗಳ ತುಣುಕುಗಳು) ಬಳಸುವ ಮೂಲಕ ಮಾಡಿದ ಒಂದು ಸಣ್ಣ ತಂತ್ರವು ಶೂನ್ಯ-ಸರ್ಚ್ ದರವನ್ನು 7% ಕ್ಕೆ ಇಳಿಸಿತು, ಆದರೆ ಇದು ಎರಡು ಸಮಸ್ಯೆಗಳನ್ನು ತಂದಿತು. ಮೊದಲನೆಯದಾಗಿ, ಇಂಡೆಕ್ಸ್ ತನ್ನ ಮೂಲ ಗಾತ್ರಕ್ಕಿಂತ ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚು ದೊಡ್ಡದಾಯಿತು, ಇದರಿಂದ ಸ್ಟೋರೇಜ್ ವೆಚ್ಚಗಳು ಹೆಚ್ಚಾದವು ಮತ್ತು ಅಪ್ಡೇಟ್ಗಳು ನಿಧಾನವಾದವು. ಎರಡನೆಯದಾಗಿ, ಪ್ರಸ್ತುತತೆ (relevance) ಕುಂದಿತು; ಫಸ್ಸಿ ಮ್ಯಾಚಿಂಗ್ (fuzzy matching) ಸಂಬಂಧವಿಲ್ಲದ ವಿಡಿಯೋಗಳ ಮಿಶ್ರಣವನ್ನು ನೀಡುವ ಮೂಲಕ ಬಳಕೆದಾರರಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡುವ ಬದಲು ಗೊಂದಲಕ್ಕೀಡು ಮಾಡಿತು.
ನೈಸರ್ಗಿಕವಾಗಿ ಕಾಗುಣಿತ ದೋಷಗಳನ್ನು ಸಹಿಸಿಕೊಳ್ಳುವ (typo-tolerance) ಮತ್ತು ಅತ್ಯಾಧುನಿಕ ಪ್ರಸ್ತುತತೆ ಸ್ಕೋರಿಂಗ್ (relevance scoring) ಹೊಂದಿರುವ, ವಿಶೇಷವಾಗಿ ನಿರ್ಮಿಸಲಾದ ಸರ್ಚ್ ಇಂಜಿನ್ ಅಗತ್ಯವಿದೆ ಎಂದು ತಂಡವು ತೀರ್ಮಾನಿಸಿತು.
OpenSearch ಪೈಪ್ಲೈನ್ ನಿರ್ಮಿಸುವುದು
SQLite ಅನ್ನು ಮೂಲ ಸತ್ಯದ ಮೂಲವಾಗಿ (source of truth) ಇರಿಸಿಕೊಳ್ಳಿ
OpenSearch ಒಂದು ಬಿಸಾಡಬಹುದಾದ (disposable), ಕೇವಲ ಓದುವಿಕೆಗೆ ಮಾತ್ರ ಸೀಮಿತವಾದ (read-only) ರೆಪ್ಲಿಕಾ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು. ಎಲ್ಲಾ ವಿಡಿಯೋ ಮೆಟಾಡೇಟಾವು SQLite ನಲ್ಲಿಯೇ ಇತ್ತು; ಡೇಟಾ ನಷ್ಟದ ಅಪಾಯವಿಲ್ಲದೆ ಸರ್ಚ್ ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಮರುನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಿತ್ತು. OpenSearch ಕ್ಲಸ್ಟರ್ ಸ್ಥಗಿತಗೊಂಡಾಗ, ಅಪ್ಲಿಕೇಶನ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮೂಲ FTS5 ಇಂಜಿನ್ ಅನ್ನು ಬಳಸತೊಡಗಿತು.
“should” ಕ್ವೆರಿಯೊಂದಿಗೆ ಪದರವಾದ ಪ್ರಸ್ತುತತೆ (Layered relevance)
ಕೇವಲ ಫಸ್ಸಿ ಮ್ಯಾಚಿಂಗ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವ ಬದಲು, ಕ್ವೆರಿಯು ಮೂರು ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು:
- Exact phrase match – ಅತಿ ಹೆಚ್ಚು ಬೂಸ್ಟ್, ಶೀರ್ಷಿಕೆಯನ್ನು ಸರಿಯಾಗಿ ಟೈಪ್ ಮಾಡಿದ ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ.
- All terms present – ಮಧ್ಯಮ ಬೂಸ್ಟ್, ಪ್ರತಿಯೊಂದು ಪದವೂ ಕಂಡುಬರುವ ಆದರೆ ಅನಿವಾರ್ಯವಾಗಿ ಕ್ರಮದಲ್ಲಿಲ್ಲದ ಕ್ವೆರಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ.
- Fuzzy match – ಕಡಿಮೆ ಬೂಸ್ಟ್, ಕಾಗುಣಿತ ದೋಷವಿರುವ ಟೋಕನ್ಗಳಿಗೆ ಸುರಕ್ಷತಾ ಜಾಲವಾಗಿ (safety net) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಈ ಶ್ರೇಣಿ ವ್ಯವಸ್ಥೆಯು ನಿಖರವಾದ ಕ್ವೆರಿಗಳಿಗೆ ನಿಖರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವ ಜೊತೆಗೆ, ಕಾಗುಣಿತ ದೋಷಗಳಿಗಾಗಿ ಸರಳವಾದ ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು ಒದಗಿಸಿತು.
ಫಸ್ಸಿ ಸೆಟ್ಟಿಂಗ್ಗಳ ಟ್ಯೂನಿಂಗ್ (Tuning fuzzy settings)
ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದ (prefix length) 1 ಇರಿಸುವ ಮೂಲಕ, ಫಸ್ಸಿ ಲಾಜಿಕ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೊದಲು ಪ್ರತಿಯೊಂದು ಪದದ ಮೊದಲ ಅಕ್ಷರವು ಹೊಂದಿಕೆಯಾಗುವಂತೆ ಮಾಡಲಾಯಿತು. ಈ ನಿಯಮವು ಸರ್ಚ್ ಅನ್ನು ವೇಗವಾಗಿರಿಸಿತು ಮತ್ತು ಮೆಮೊರಿಯನ್ನು ಅತಿಯಾಗಿ ಬಳಸಬಹುದಾದ ಪದಗಳ ಸಂಖ್ಯೆಯನ್ನು ತಡೆಗಟ್ಟಿತು. ಸಂಪನ್ಮೂಲಗಳ ಅತಿಯಾದ ಬಳಕೆಯನ್ನು ತಡೆಯಲು ತಂಡವು ಪದಗಳ ವಿಸ್ತರಣೆಯ (term expansions) ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯನ್ನು ಸಹ ಮಿತಿಗೊಳಿಸಿತು.
ಸಿಂಕ್ರೊನೈಸೇಶನ್ ತಂತ್ರ (Synchronisation strategy)
ಮೂರು ಪೂರಕ ಪ್ರಕ್ರಿಯೆಗಳು OpenSearch ಇಂಡೆಕ್ಸ್ ಅನ್ನು SQLite ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯಲ್ಲಿಡುತ್ತವೆ:
- ಹೊಸ ಡೇಟಾವನ್ನು ಸಿಂಕ್ ಮಾಡಲು ಕ್ರೋನ್ ಜಾಬ್ (cron job).
- ರಾತ್ರಿಗೊಂದು ಡಿಫ್ ಪಾಸ್ (Nightly diff pass) – ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಅಪ್ಡೇಟ್ಗಳಲ್ಲಿ ತಪ್ಪಿದ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ.
- ವಾರಕ್ಕೊಮ್ಮೆ ಪೂರ್ಣ ಮರುನಿರ್ಮಾಣ (Weekly full rebuild) – ಇದು ಇಂಡೆಕ್ಸ್ ಏಲಿಯಾಸ್ (index alias) ಹಿಂದೆ ಚಲಿಸುತ್ತದೆ, ನಂತರ ಏಲಿಯಾಸ್ ಅನ್ನು ಒಂದೇ ಹಂತದಲ್ಲಿ ಬದಲಾಯಿಸುತ್ತದೆ, ಇದರಿಂದ ಯಾವುದೇ ಡೌನ್ಟೈಮ್ ಇಲ್ಲದಿರುವುದು ಖಚಿತವಾಗುತ್ತದೆ.
ಎರಡು ವಾರಗಳ ನಂತರದ ಅಳೆಯಬಹುದಾದ ಪರಿಣಾಮಗಳು
- ಶೂನ್ಯ-ಫಲಿತಾಂಶದ ಕ್ವೆರಿಗಳು 12% ರಿಂದ 1.4% ಕ್ಕೆ ಇಳಿದವು.
- ಸರ್ಚ್-ಟು-ಕ್ಲಿಕ್ ಕನ್ವರ್ಷನ್ 9% ಹೆಚ್ಚಾಯಿತು.
- ಮೀಡಿಯನ್ ಲ್ಯಾಟೆನ್ಸಿ (Median latency) 28 ms ಗಿಂತ ಕಡಿಮೆ ಇತ್ತು, ಇದು ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ಬಳಕೆದಾರ ಅನುಭವದ ಗುರಿಯೊಳಗೆ ಇತ್ತು.
ಎಚ್ಚರಿಕೆಗಳು ಮತ್ತು ವಿರೋಧಾಭಾಸಗಳು
ಈ ಮೈಗ್ರೇಷನ್ ಸುಲಭವಾದ 'ಪ್ಲಗ್-ಅಂಡ್-ಪ್ಲೇ' ಅಪ್ಗ್ರೇಡ್ ಅಲ್ಲ. ಪ್ರಾಥಮಿಕ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಎಂದಿಗೂ ಸರ್ಚ್ ಇಂಜಿನ್ನಿಂದ ಬದಲಾಯಿಸಬಾರದು ಎಂದು ತಂಡವು ಒತ್ತಿ ಹೇಳುತ್ತದೆ; ಎಲ್ಲಾ ವಿಡಿಯೋ ಮೆಟಾಡೇಟಾಗಳ ಅಧಿಕೃತ ಸಂಗ್ರಹವಾಗಿ SQLite ಇರುತ್ತದೆ.
ಸಾರಾಂಶ
ವಿಶೇಷವಾಗಿ ನಿರ್ಮಿಸಲಾದ ಸರ್ಚ್ ಇಂಜಿನ್ ಮೂಲಕ ಕಾಗುಣಿತ ದೋಷಗಳನ್ನು ಸಹಿಸಿಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸೇರಿಸುವುದರಿಂದ, ಬಳಕೆದಾರರ ಪ್ರಯಾಣದಲ್ಲಿನ ಒಂದು ದೊಡ್ಡ ಅಡೆತಡೆಯನ್ನು ಸುಗಮ ಮತ್ತು ವೇಗದ ಅನುಭವವನ್ನಾಗಿ ಬದಲಾಯಿಸಲಾಯಿತು. ಒಂದು ಶಿಸ್ತುಬದ್ಧ ಆರ್ಕಿಟೆಕ್ಚರ್ – ಅಂದರೆ ರಿಲೇಶನಲ್ ಸ್ಟೋರ್ ಅನ್ನು ಮೂಲ ಸತ್ಯದ ಮೂಲವಾಗಿ ಇರಿಸಿಕೊಳ್ಳುವುದು, ಪ್ರಸ್ತುತತೆಯನ್ನು ಪದರಗಳಾಗಿ ವಿಂಗಡಿಸುವುದು ಮತ್ತು ಫಸ್ಸಿ ಲಾಜಿಕ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿಡುವುದು – ಸ್ಥಿರತೆಯನ್ನು ಬಲಿ ನೀಡದೆ ಅಳೆಯಬಹುದಾದ ಲಾಭಗಳನ್ನು ನೀಡಬಲ್ಲದು ಎಂದು ಈ ಕೇಸ್ ಸ್ಟಡಿ ತೋರಿಸುತ್ತದೆ.