LanceDB ने 100k OpenAI embeddings pgvector पेक्षा 22 पट वेगाने लोड केले, तर pgvector ने आठ एकाच वेळी काम करणाऱ्या (simultaneous) क्लायंट्सकडून आलेला तोच वर्कलोड 1.8 पट वेगाने हाताळला. सिंगल-थ्रेड लॅटन्सी (latency) आणि स्टोरेज कार्यक्षमतेमधील (efficiency) फरक देखील LanceDB च्या बाजूने झुकलेला होता, ज्यामुळे डेव्हलपर्सना वेक्टर स्टोअर निवडण्यासाठी डेटा-आधारित मार्ग मिळाला.

आता बेंचमार्क का महत्त्वाचा आहे

वेक्टर सर्च आता रिसर्च लॅब्समधून रेकमेंडेशन इंजिन्स आणि रिट्रिव्हल-ऑगमेंटेड जनरेशन (RAG) सारख्या प्रोडक्शन सर्व्हिसेसमध्ये पोहोचले आहे. बहुतेक टीम्स आधीच PostgreSQL वापरत असतात, त्यामुळे pgvector एक्सटेंशन नवीन इन्फ्रास्ट्रक्चरशिवाय सिमिलॅरिटी सर्च करण्याचे आश्वासन देते. तथापि, LanceDB सारखी समर्पित स्टोअर्स कमी लॅटन्सी आणि स्वस्त स्टोरेजचा दावा करतात. डेटासेट वाढत असताना आणि रिक्वेस्ट रेट्स वाढताना, टीम्सना "आपल्याकडे जे आहे त्यात ते जोडा" किंवा "एक खास बनवलेले इंजिन चालवा" यापैकी एकाची निवड करावी लागते; हा निर्णय खर्च आणि कामगिरीवर परिणाम करतो.

चाचणी कशी आयोजित केली होती

दोन्ही सिस्टम्सनी OpenAI च्या एम्बेडिंग मॉडेलद्वारे तयार केलेले, प्रत्येकी 1536 डायमेंशन्स असलेले तेच 100k वेक्टर्स इंडेक्स केले. आम्ही इन्जेशन स्पीड (ingestion speed), डिस्क वापर, सिंगल-थ्रेड क्वेरी लॅटन्सी आणि आठ कॉनकरंट क्लायंट्ससह थ्रूपुट (throughput) मोजला.

आमनेसामने निकाल

  • इंजेशन स्पीड – LanceDB ने 22× अधिक फायदा नोंदवला.
  • डिस्क फूटप्रिंट – LanceDB ने वेक्टर्स pgvector वापरत असलेल्या जागेच्या साधारण एक तृतीयांश भागात स्टोअर केले.
  • सिंगल-थ्रेड लॅटन्सी – LanceDB वर क्वेरीज साधारण दुप्पट वेगाने चालल्या.
  • कॉनकरन्सी स्केलिंग – आठ पॅरलल क्लायंट्ससह, pgvector ने LanceDB पेक्षा 1.8× जास्त थ्रूपुट दिला.

फरकाची आर्किटेक्चरल कारणे

LanceDB ही एक एम्बेडेड लायब्ररी आहे जी ॲप्लिकेशन होस्ट करणाऱ्या Python प्रोसेसमध्ये चालते. सर्व ऑपरेशन्स इन-प्रोसेस (in-process) राहतात, त्यामुळे डेटा कधीही नेटवर्क बाउंड्री ओलांडत नाही आणि इंडेक्स किमान ओव्हरहेडसह अपडेट होतो. हे डिझाइन सिंगल-टास्क वर्कलोडसाठी उत्तम आहे, परंतु जेव्हा अनेक Python थ्रेड्स Global Interpreter Lock (GIL) साठी स्पर्धा करतात, तेव्हा ते एका मर्यादेपर्यंत पोहोचते, जे Python बाइटकोडच्या खऱ्या समांतर अंमलबजावणीला (parallel execution) अडथळा आणते.

pgvector सर्व्हर साईडवर PostgreSQL ला विस्तारते. प्रत्येक क्लायंट कनेक्शन एक वेगळी सर्व्हर प्रोसेस सुरू करते, ज्यामुळे GIL पूर्णपणे टाळता येते. PostgreSQL प्लॅनर सिमिलॅरिटी सर्च कसा पूर्ण करायचा हे ठरवतो आणि सर्व्हर एकाच वेळी येणाऱ्या रिक्वेस्ट्स पूर्ण करण्यासाठी अनेक प्रोसेसेस सुरू करू शकतो. हे आयसोलेशन लोड असताना चांगले स्केलिंग का मिळते याचे स्पष्टीकरण देते.

फिल्टरिंग आणि क्वेरी प्लॅनिंगमधील बारकावे

रिअल-वर्ल्ड RAG पाइपलाईन्समध्ये अनेकदा वेक्टर सिमिलॅरिटीसोबत पारंपारिक फिल्टर्स (उदा. WHERE user_id = 42) वापरले जातात. LanceDB एक प्रीफिल्टर लागू करते जो प्रत्येक वेळी अंदाजितपणे (predictably) काम करतो. pgvector हे PostgreSQL च्या क्वेरी प्लॅनरवर अवलंबून असते, जो सांख्यिकीनुसार (statistics) जलद इंडेक्स स्कॅन निवडू शकतो किंवा संथ एक्झॅक्ट स्कॅनवर अवलंबून राहू शकतो. pgvector टेबलमध्ये बल्क लोडिंग केल्यानंतर ANALYZE चालवल्यास ती सांख्यिकी रिफ्रेश होते; त्याशिवाय, रिकॉल (recall) शून्याच्या जवळ जाऊ शकतो, ज्यामुळे सर्च प्रभावीपणे निकामी होऊ शकतो.

प्रत्येक पर्याय कधी योग्य ठरतो

pgvector निवडा जर

  • तुमच्या स्टॅक मध्ये आधीच PostgreSQL समाविष्ट आहे आणि तुम्हाला आणखी एक सर्व्हिस जोडणे टाळायचे आहे.
  • तुम्हाला अनेक एकाच वेळी येणारे युजर्स किंवा API कॉल्स अपेक्षित आहेत.
  • ACID गॅरंटी आणि परिचित DBA टूल्स महत्त्वाचे आहेत.

LanceDB निवडा जर

  • तुमचा वर्कफ्लो एक ML पाइपलाइन आहे जी वारंवार नवीन एम्बेडिंग्स इन्जेस्ट करते.
  • तुम्हाला सिंगल-रिक्वेस्ट एजंट्ससाठी (उदा. चॅट बॉट्स) सर्वात वेगवान राईट पाथ आणि कमी लॅटन्सी हवी आहे.
  • डिस्क खर्च ही चिंता आहे आणि तुम्ही सिंगल-थ्रेड परफॉर्मन्सची मर्यादा सहन करू शकता.

थोडक्यात सांगायचे तर: जर रॉ इन्जेशन स्पीड, किमान स्टोरेज आणि सिंगल-रिक्वेस्ट लॅटन्सी सर्वात महत्त्वाचे असेल, तर LanceDB जिंकते. जर तुम्हाला एकाच वेळी अनेक युजर्सना सर्व्ह करायचे असेल आणि विद्यमान PostgreSQL डिप्लॉयमेंटवर अवलंबून राहायचे असेल, तर pgvector चा कॉनकरन्सी फायदा त्याला अधिक सुरक्षित पर्याय बनवतो. तुमच्या उत्पादनाच्या सर्वात महत्त्वाच्या मेट्रिकनुसार योग्य स्टोअर निवडण्यासाठी या बेंचमार्कमधील आकडेवारीचा वापर करा.