LanceDB, pgvector ಗಿಂತ 22 ಪಟ್ಟು ವೇಗವಾಗಿ 100k OpenAI embeddings ಅನ್ನು ಲೋಡ್ ಮಾಡಿತು, ಆದರೆ ಎಂಟು ಏಕಕಾಲಿಕ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಬಂದ ಅದೇ ಕೆಲಸದ ಹೊರೆಯನ್ನು (workload) pgvector 1.8 ಪಟ್ಟು ವೇಗವಾಗಿ ನಿರ್ವಹಿಸಿತು. ಸಿಂಗಲ್-ಥ್ರೆಡ್ ಲೇಟೆನ್ಸಿ (single-thread latency) ಮತ್ತು ಸ್ಟೋರೇಜ್ ದಕ್ಷತೆಯಲ್ಲಿನ ವ್ಯತ್ಯಾಸವು ಕೂಡ LanceDB ಪರವಾಗಿತ್ತು, ಇದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ವೆಕ್ಟರ್ ಸ್ಟೋರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ದತ್ತಾಂಶ ಆಧಾರಿತ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ.

ಈಗ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಏಕೆ ಮುಖ್ಯವಾಗಿದೆ

ವೆಕ್ಟರ್ ಸರ್ಚ್ (Vector search) ಸಂಶೋಧನಾ ಪ್ರಯೋಗಾಲಯಗಳಿಂದ ಶಿಫಾರಸು ಇಂಜಿನ್‌ಗಳು (recommendation engines) ಮತ್ತು ರಿಟ್ರಿೀವಲ್-ಆಗ್ಮೆಂಟೆಡ್ ಜನರೇಷನ್ (RAG) ನಂತಹ ಪ್ರೊಡಕ್ಷನ್ ಸೇವೆಗಳಿಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದೆ. ಹೆಚ್ಚಿನ ತಂಡಗಳು ಈಗಾಗಲೇ PostgreSQL ಅನ್ನು ಬಳಸುತ್ತಿವೆ, ಆದ್ದರಿಂದ pgvector ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ಹೊಸ ಮೂಲಸೌಕರ್ಯವಿಲ್ಲದೆ ಸಿಮಿಲಾರಿಟಿ ಸರ್ಚ್ ಅನ್ನು ಭರವಸೆ ನೀಡುತ್ತದೆ. ಆದರೆ, LanceDB ನಂತಹ ಮೀಸಲಾದ ಸ್ಟೋರ್‌ಗಳು ಕಡಿಮೆ ಲೇಟೆನ್ಸಿ ಮತ್ತು ಅಗ್ಗದ ಸ್ಟೋರೇಜ್ ಅನ್ನು ಹೊಂದಿವೆ ಎಂದು ಪ್ರತಿಪಾದಿಸುತ್ತವೆ. ಡೇಟಾ ಸೆಟ್‌ಗಳು ಬೆಳೆದಂತೆ ಮತ್ತು ರಿಕ್ವೆಸ್ಟ್ ದರಗಳು ಹೆಚ್ಚಾದಂತೆ, ವೆಚ್ಚ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ "ನಮ್ಮ ಬಳಿ ಇರುವುದಕ್ಕೆ ಇದನ್ನು ಸೇರಿಸಿ" ಮತ್ತು "ನಿರ್ದಿಷ್ಟ ಉದ್ದೇಶಕ್ಕಾಗಿ ನಿರ್ಮಿಸಲಾದ ಇಂಜಿನ್ ಅನ್ನು ಬಳಸಿ" ಎಂಬ ಎರಡರಲ್ಲಿ ತಂಡಗಳು ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಿಕೊಳ್ಳಬೇಕು.

ಪರೀಕ್ಷೆಯನ್ನು ಹೇಗೆ ಸಿದ್ಧಪಡಿಸಲಾಯಿತು

ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳು OpenAI ನ ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್‌ನಿಂದ ರಚಿತವಾದ ತಲಾ 1536 ಡೈಮೆನ್ಷನ್‌ಗಳಿರುವ ಒಂದೇ ರೀತಿಯ 100k ವೆಕ್ಟರ್‌ಗಳನ್ನು ಇಂಡೆಕ್ಸ್ ಮಾಡಿದವು. ನಾವು ಇಂಜೆಸ್ಟಿನ್ ವೇಗ (ingestion speed), ಡಿಸ್ಕ್ ಬಳಕೆ, ಸಿಂಗಲ್-ಥ್ರೆಡ್ ಕ್ವೆರಿ ಲೇಟೆನ್ಸಿ ಮತ್ತು ಎಂಟು ಏಕಕಾಲಿಕ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ಥ್ರೂಪುಟ್ ಅನ್ನು ಅಳೆದವು.

ಮುಖಾಮುಖಿ ಫಲಿತಾಂಶಗಳು

  • ಇಂಜೆಸ್ಟಿನ್ ವೇಗ (Ingestion speed) – LanceDB 22× ಹೆಚ್ಚಿನ ಅನುಕೂಲವನ್ನು ದಾಖಲಿಸಿತು.
  • ಡಿಸ್ಕ್ ಬಳಕೆ (Disk footprint) – LanceDB, pgvector ಬಳಸಿದ ಜಾಗದ ಅಂದಾಜು ಮೂರನೇ ಒಂದು ಭಾಗದಷ್ಟು ಜಾಗದಲ್ಲಿ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿತು.
  • ಸಿಂಗಲ್-ಥ್ರೆಡ್ ಲೇಟೆನ್ಸಿ (Single-thread latency) – LanceDB ನಲ್ಲಿ ಕ್ವೆರಿಗಳು ಸುಮಾರು ಎರಡು ಪಟ್ಟು ವೇಗವಾಗಿ ನಡೆದವು.
  • ಕನ್ಕರನ್ಸಿ ಸ್ಕೇಲಿಂಗ್ (Concurrency scaling) – ಎಂಟು ಸಮಾಂತರ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ, pgvector LanceDB ಗಿಂತ 1.8× ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಅನ್ನು ನೀಡಿತು.

ವ್ಯತ್ಯಾಸಗಳ ವಾಸ್ತುಶಿಲ್ಪದ ಮೂಲಗಳು

LanceDB ಎಂಬುದು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ Python ಪ್ರಕ್ರಿಯೆಯ ಒಳಗೇ ಚಲಿಸುವ ಎಂಬೆಡೆಡ್ ಲೈಬ್ರರಿಯಾಗಿದೆ. ಎಲ್ಲಾ ಕಾರ್ಯಾಚರಣೆಗಳು ಇನ್-ಪ್ರೊಸೆಸ್ (in-process) ಆಗಿರುತ್ತವೆ, ಆದ್ದರಿಂದ ಡೇಟಾ ಎಂದಿಗೂ ನೆಟ್‌ವರ್ಕ್ ಗಡಿಯನ್ನು ದಾಟುವುದಿಲ್ಲ ಮತ್ತು ಇಂಡೆಕ್ಸ್ ಅತಿ ಕಡಿಮೆ ಓವರ್‌ಹೆಡ್‌ನೊಂದಿಗೆ ಅಪ್‌ಡೇಟ್ ಆಗುತ್ತದೆ. ಈ ವಿನ್ಯಾಸವು ಸಿಂಗಲ್-ಟಾಸ್ಕ್ ಕೆಲಸಗಳಿಗೆ ಅತ್ಯುತ್ತಮವಾಗಿದೆ, ಆದರೆ ಮಲ್ಟಿಪಲ್ Python ಥ್ರೆಡ್‌ಗಳು Global Interpreter Lock (GIL) ಗಾಗಿ ಸ್ಪರ್ಧಿಸಿದಾಗ ಇದು ಮಿತಿ ತಲುಪುತ್ತದೆ, ಇದು Python ಬೈಟ್‌ಕೋಡ್‌ನ ನಿಜವಾದ ಸಮಾಂತರ ಚಾಲನೆಯನ್ನು ತಡೆಯುತ್ತದೆ.

pgvector ಸರ್ವರ್ ಕಡೆಯಲ್ಲೇ PostgreSQL ಅನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ. ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಕನೆಕ್ಷನ್ ಒಂದು ಪ್ರತ್ಯೇಕ ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಇದು GIL ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸುತ್ತದೆ. PostgreSQL ಪ್ಲಾನರ್ ಸಿಮಿಲಾರಿಟಿ ಸರ್ಚ್ ಅನ್ನು ಹೇಗೆ ಪೂರೈಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ಏಕಕಾಲಿಕ ರಿಕ್ವೆಸ್ಟ್‌ಗಳನ್ನು ಪೂರೈಸಲು ಅನೇಕ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು. ಈ ಪ್ರತ್ಯೇಕತೆಯು (isolation) ಹೆಚ್ಚಿನ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಉತ್ತಮ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಫಿಲ್ಟರಿಂಗ್