LanceDB ने pgvector की तुलना में 100k OpenAI embeddings को 22 गुना तेज़ी से लोड किया, जबकि pgvector ने आठ एक साथ (simultaneous) क्लाइंट्स से आने वाले समान वर्कलोड का जवाब 1.8 गुना तेज़ी से दिया। सिंगल-थ्रेड लेटेंसी (latency) और स्टोरेज दक्षता (efficiency) के मामले में भी बढ़त LanceDB के पक्ष में रही, जिससे डेवलपर्स को वेक्टर स्टोर चुनने के लिए डेटा-आधारित तरीका मिला।
अब बेंचमार्क क्यों महत्वपूर्ण है
वेक्टर सर्च अब रिसर्च लैब्स से निकलकर प्रोडक्शन सर्विसेज जैसे कि रिकमेंडेशन इंजन और रिट्रीवल-ऑगमेंटेड जनरेशन (RAG) तक पहुँच गई है। अधिकांश टीमें पहले से ही PostgreSQL का उपयोग कर रही हैं, इसलिए pgvector एक्सटेंशन बिना किसी नए इंफ्रास्ट्रक्चर के सिमिलरिटी सर्च (similarity search) का वादा करता है। हालाँकि, LanceDB जैसे समर्पित (dedicated) स्टोर्स कम लेटेंसी और सस्ते स्टोरेज का दावा करते हैं। टीमों को "जो हमारे पास है उसमें इसे जोड़ें" और "एक उद्देश्य-निर्मित (purpose-built) इंजन चलाएं" के बीच चुनाव करना होगा, एक ऐसा निर्णय जो डेटासेट बढ़ने और रिक्वेस्ट रेट बढ़ने के साथ लागत और प्रदर्शन को प्रभावित करता है।
टेस्ट कैसे सेटअप किया गया था
दोनों सिस्टम्स ने OpenAI के एम्बेडिंग मॉडल द्वारा जनरेट किए गए समान 100k वेक्टर्स को इंडेक्स किया, जिनमें से प्रत्येक के 1536 डायमेंशन (dimensions) थे। हमने इनजेशन स्पीड (ingestion speed), डिस्क यूसेज, सिंगल-थ्रेड क्वेरी लेटेंसी और आठ कॉन्करेंट (concurrent) क्लाइंट्स के साथ थ्रूपुट (throughput) को मापा।
आमने-सामने के परिणाम
- इनजेशन स्पीड – LanceDB ने 22× का लाभ दर्ज किया।
- डिस्क फुटप्रिंट – LanceDB ने वेक्टर्स को pgvector द्वारा उपयोग किए गए स्थान के लगभग एक-तिहाई हिस्से में स्टोर किया।
- सिंगल-थ्रेड लेटेंसी – LanceDB पर क्वेरीज़ लगभग दोगुनी तेज़ी से चलीं।
- कन्करेंसी स्केलिंग – आठ पैरेलल क्लाइंट्स के साथ, pgvector ने LanceDB की तुलना में 1.8× अधिक थ्रूपुट दिया।
अंतरों की आर्किटेक्चरल जड़ें
LanceDB एक एम्बेडेड लाइब्रेरी है जो उस Python प्रोसेस के अंदर चलती है जो एप्लिकेशन को होस्ट करती है। सभी ऑपरेशन्स इन-प्रोसेस (in-process) रहते हैं, इसलिए डेटा कभी भी नेटवर्क बाउंड्री को पार नहीं करता और इंडेक्स न्यूनतम ओवरहेड के साथ अपडेट होता है। यह डिज़ाइन सिंगल-टास्क वर्कलोड के लिए बेहतरीन है, लेकिन जब कई Python थ्रेड्स ग्लोबल इंटरप्रेटर लॉक (GIL) के लिए प्रतिस्पर्धा करते हैं, तो यह एक सीमा (ceiling) पर पहुँच जाता है, जो Python बाइटकोड के वास्तविक पैरेलल निष्पादन (parallel execution) को रोकता है।
pgvector सर्वर साइड पर PostgreSQL का विस्तार करता है। प्रत्येक क्लाइंट कनेक्शन एक अलग सर्वर प्रोसेस शुरू करता है, जिससे GIL पूरी तरह से बच जाता है। PostgreSQL प्लानर यह तय करता है कि सिमिलरिटी सर्च को कैसे पूरा किया जाए, और सर्वर कॉन्करेंट रिक्वेस्ट को सेवा देने के लिए कई प्रोसेस शुरू कर सकता है। यह आइसोलेशन (isolation) लोड के तहत बेहतर स्केलिंग की व्याख्या करता है।
फ़िल्टरिंग और क्वेरी प्लानिंग की बारीकियां
वास्तविक दुनिया के RAG पाइपलाइन्स अक्सर वेक्टर सिमिलरिटी को पारंपरिक फ़िल्टर्स (जैसे, WHERE user_id = 42) के साथ जोड़ते हैं। LanceDB एक प्रीफ़िल्टर (prefilter) लागू करता है जो सभी रन में अनुमानित (predictable) व्यवहार करता है। pgvector PostgreSQL के क्वेरी प्लानर पर निर्भर करता है, जो सांख्यिकी (statistics) के आधार पर एक तेज़ इंडेक्स स्कैन चुन सकता है या धीमे सटीक स्कैन (exact scan) पर वापस जा सकता है। pgvector टेबल में बल्क लोडिंग के बाद ANALYZE चलाने से वे सांख्यिकी रिफ्रेश हो जाती हैं; इसके बिना, रिकॉल (recall) लगभग शून्य तक गिर सकता है, जिससे सर्च प्रभावी रूप से टूट सकती है।
कब कौन सा विकल्प सही है
pgvector चुनें यदि
- आपके स्टैक में पहले से ही PostgreSQL शामिल है और आप एक और सर्विस जोड़ने से बचना चाहते हैं।
- आप कई एक साथ (simultaneous) उपयोगकर्ताओं या API कॉल्स की अपेक्षा करते हैं।
- ACID गारंटी और परिचित DBA टूल्स महत्वपूर्ण हैं।
LanceDB चुनें यदि
- आपका वर्कफ़्लो एक ML पाइपलाइन है जो बार-बार नए एम्बेडिंग्स को इनजेस्ट करती है।
- आपको सिंगल-रिक्वेस्ट एजेंटों (जैसे, चैट बॉट्स) के लिए सबसे तेज़ राइट पाथ और कम लेटेंसी की आवश्यकता है।
- डिस्क लागत एक चिंता का विषय है और आप सिंगल-थ्रेड परफॉरमेंस की सीमा को सहन कर सकते हैं।
निष्कर्ष: यदि रॉ इनजेशन स्पीड, न्यूनतम स्टोरेज और सिंगल-रिक्वेस्ट लेटेंसी सबसे महत्वपूर्ण हैं, तो LanceDB जीतता है। यदि आपको एक साथ कई उपयोगकर्ताओं को सेवा देनी है और आप मौजूदा PostgreSQL डिप्लॉयमेंट पर भरोसा करते हैं, तो pgvector की कन्करेंसी में बढ़त इसे एक सुरक्षित विकल्प बनाती है। अपने प्रोडक्ट के सबसे महत्वपूर्ण मेट्रिक के साथ स्टोर का मिलान करने के लिए इस बेंचमार्क के नंबरों का उपयोग करें।
