एक उत्पादन बेंचमार्क समर्पित वेक्टर डेटाबेस के साथ pgvector की तुलना करता है।
pgvectorscale के साथ पीजीवेक्टर ने थ्रूपुट में Qdrant से बेहतर प्रदर्शन किया, लेकिन टेल लैटेन्सी पर हार गए; स्थानीय परीक्षण उत्पादन फिट नहीं बल्कि बेंचमार्किंग सिखाते हैं।
मुख्य बिंदुओं का सारांश
- 50 मिलियन-वेक्टर उत्पादन बेंचमार्क ने दिखाया कि पीजी वेक्टर और पीजीवेक्टर्सकेल के साथ पोस्टग्रेज़ 99% रिकॉल पर क्यूड्रेंट की तुलना में 11.4 गुना अधिक क्वेरी थ्रूपुट प्राप्त कर रहा है।
- Qdrant ने कम पूंछ विलंबता प्रदान की, p99 को 48% से काट दिया और पोस्टग्रेस सेटअप की तुलना में लगभग 3.4 गुना तेजी से अपना सूचकांक बनाया।
- बेंचमार्क ने पीजी वेक्टर प्लस पीजीवेक्टर्स स्केल की तुलना की, न कि केवल वैनिला पीजीवी के साथ, जो परिणामों की व्याख्या करते समय महत्वपूर्ण है।
- एक 100,000-वेक्टर स्थानीय बेंचमार्क सेटअप वर्कफ़्लो सीखने के लिए उपयोगी है, लेकिन वास्तविक उत्पादन निर्णयों का समर्थन करने के लिए बहुत छोटा है।
- pgvector Postgres के भीतर वेक्टर खोज रखकर वास्तुकला को सरल करता है, जबकि समर्पित वेक्टर डेटाबेस परिचालन जटिलता जोड़ते हैं लेकिन विलंबता और अनुक्रमण का बेहतर अनुकूलन कर सकते हैं।
मेटा विवरणः pgvector और Qdrant की एक बेंचमार्क तुलना में स्थानीय परीक्षण, Tiger Data उत्पादन परिणाम, थ्रूपुट, विलंबता और जब प्रत्येक वेक्टर खोज सेटअप फिट होता है।
टैगः pgvector, Qdrant, वेक्टर डेटाबेस, पोस्टग्रेस, बेंचमार्किंग
विशेष रुप से प्रदर्शित छवि: (अंग्रेज़ी में) ">"</string> दो डेटाबेस इंजनों का अमूर्त चित्रण जो विलंबता और थ्रूपुट को संतुलित करता है, मैत्रीपूर्ण शैली, कोई वास्तविक लोग, लोगो या पाठ नहीं।
यह तय करने वाली टीमों के लिए कि क्या pgvector और Qdrant बेंचमार्क एक माइग्रेशन को सही ठहराते हैं, मापा गया उत्तर विभाजित हैः 50 मिलियन-वेक्टर Tiger Data परीक्षण से पता चला है कि पीजी वेक्टर और पीजीवेक्टर्सकेल के साथ पोस्टग्रेस 99% में क्यूड्रेंट की तुलना में प्रति सेकंड 11.4 गुना अधिक प्रश्न वितरित कर रहा था, जबकि क्यूड्रांट ने 48% द्वारा पी 99 विलंबता में कटौती की। एक आम परिदृश्य एक मंगलवार दोपहर पर Postgres में पीजीवी जोड़ने वाली टीम है, फिर छह महीने बाद विक्रेता पिच प्राप्त करना कि किसी भी दिशा में संख्याओं के बिना समर्पित वैक्टर डेटाबेस की आवश्यकता होती है।
उत्पादन की संख्या जो सबसे अधिक मायने रखती है
स्रोत के अनुसार, प्रकाशित बेंचमार्क पीजीवेक्टर के खिलाफ उपलब्ध सबसे विस्तृत, पद्धतिगत रूप से पारदर्शी सार्वजनिक तुलना है। इसने मिलान किए गए AWS r6id.4xlarge हार्डवेयर पर 768 आयामों में 50 मिलियन वास्तविक Cohere एम्बेडिंग का परीक्षण किया, प्रत्येक मशीन 16 वर्चुअल सीपीयू और 128 जीबी RAM के साथ कॉन्फ़िगर की गई थी, जो उद्योग-मानक ANN-Benchmarks टूल के संशोधित कांटा का उपयोग कर रही थी।
एक बारीकियों आवश्यक हैः परीक्षण इस्तेमाल किया Postgres साथ pgvector प्लस पीजीवेक्टरस्केल, Timescale के अपने अतिरिक्त एक्सटेंशन है कि जोड़ता है एक अलग सूचकांक प्रकार कहा जाता StreamingDiskANN नहीं वेनिला पीजी वेक्टर अकेले. कई दूसरे सारांश संक्षेप में धुंधला उस बिंदु, तो आंकड़े संयुक्त सेटअप का वर्णन करते हैं।
99% रिकॉल पर, Postgres कॉन्फ़िगरेशन ने Qdrant के लिए प्रति सेकंड 471.57 क्वेरी हासिल कीं, 11.4-गुना थ्रूपुट लाभ। क्यूड्रांट का काउंटरपॉइंट टेल लैटेन्सी था: इसका p99 38.71ms 74.60ms की तुलना में एक 48% सुधार था, और इसने अपने सूचकांक को लगभग 3.4 गुना तेजी से बनाया। दोनों प्रणालियों ने 50 मिलियन वेक्टर डेटासेट पर 100ms के नीचे हर मापा प्रतिशत रखा, सीधे धारणा को कम करते हुए कि एक सामान्य प्रयोजन डेटाबेस वास्तविक पैमाने पर नहीं रख सकता है।
स्थानीय pgvector और Qdrant बेंचमार्क कैसे चलाएं
स्रोत एक लैपटॉप आकार का बेंचमार्क प्रदान करता है जिसमें 100,000 वेक्टर होते हैं। यह कार्यप्रवाह सीखने के लिए उपयोगी होता है, उत्पादन चयन के लिए नहीं।
पूर्व शर्तें: डॉकर, Docker Compose, पायथन 3.10 या बाद में, लगभग 8 जीबी मुफ्त RAM, और संरचनात्मक क्वेरी भाषा (एसक्यूएल) और पायथन को पढ़ने के लिए बुनियादी आराम।
- पीजीवेक्टर को एक Docker Compose फ़ाइल के साथ शुरू करें, जो कि आधिकारिक डॉकर छवि है जो एक्सटेंशन को पोस्टग्रेस 17 के साथ बंडल करती है। डॉकर की रचना करने के बाद -d, कनेक्ट और चलाएं CREATE EXTENSION IF NOT EXISTS वेक्टर, उस डेटाबेस में वेक्टर प्रकार और सूचकांक विधियों का पंजीकरण करने वाला एक बार चरण।
- Start Qdrant इसके एकल डॉकर कमांड के साथ। फिर वेक्टरपैराम्स ((size=1536, distance=Distance.COSINE) के साथ एक संग्रह बनाएं, जो pgvector तालिका में उपयोग की जाने वाली आयाम और कोसिन दूरी से मेल खाता है। उचित तुलना के लिए दोनों प्रणालियों को समान मापने की आवश्यकता होती है।
- सिंथेटिक वेक्टर जनरेट करें और प्रत्येक सिस्टम में पंक्तियों को लोड करें। pgvector के लिए, psycopg2 के साथ पीजीवेक्टर-पायथन s एडेप्टर का उपयोग करें; register_vector (((conn) साइकोपी 2 को सिखाता है कि कैसे NumPy सरणियों को परिवर्तित किया जाए ताकि execute_values मैन्युअल स्ट्रिंग फॉर्मेटिंग के बिना कच्चे सरणियां सम्मिलित कर सकें। Qdrant के लिए 1,000 वैक्टरों के बैचों में अप्सर्ट का प्रयोग करें, क्योंकि एक विशाल अनुरोध या एकल-वेक्टर लिखते हैं की तुलना में बल्क डालने से तेज़ होते हैं।
- तुलनीय Hierarchical Navigable Small World (HNSW) सूचकांक बनाएँ. pgvector में, अपने स्वयं के अनुक्रमण प्रलेखन का पालन करें. Qdrant में, एक ही अंतर्निहित एल्गोरिथ्म और सेटिंग्स लागू करें: m=16 और ef_construction=64, pg vector17]s डिफ़ॉल्ट। यदि इंडेक्स पैरामीटर भिन्न होते हैं, तो बेंचमार्क परिणाम तुलनात्मक नहीं होते हैं।
- पहले से ही लोड किए गए वेक्टरों के बजाय 200 ताजा होल्ड-आउट वैक्टर्स के साथ क्वेरी। एक वेक्टर को पूछना जो पहले से इंडेक्स में है, शून्य दूरी पर खुद को लौटा सकता है और परिणाम को विकृत कर सकता है Set SET hnsw.ef_search = 64 पुनरुत्पादित pgvector व्यवहार के लिए; बेहतर याद दिलाने के लिए उच्च मान व्यापार गति का उपयोग करें। <=> %s और Qdrant के client.query_points), वर्तमान अनुशंसित खोज विधि पुराने search () कॉल की जगह लेती है।
- दोनों प्रणालियों के लिए समान सारांश तर्क का उपयोग करते हुए, औसत p50, 95 वें प्रतिशत p95, और 99 वें percentile p99 विलंबता प्लस प्रश्न प्रति सेकंड की रिपोर्ट करें ताकि आउटपुट सीधे लाइन-दर-लाइन तुलनीय हों।
एक विशिष्ट लैपटॉप पर, दोनों सिस्टम अक्सर कम एकल-अंकीय से लेकर दसियों मिलीसेकंड की सीमा में विलंबता की रिपोर्ट करते हैं। सटीक संख्या भारी रूप से CPU, उपलब्ध RAM, और जो कुछ भी चल रहा है उस पर निर्भर करती है। वह परिवर्तनशीलता ईमानदार सबक हैः 100,000 वेक्टर सेटअप यांत्रिकी की पुष्टि करने का एक अच्छा तरीका है, लेकिन यह वास्तविक उत्पादन निष्कर्ष निकालने के लिए बहुत छोटा पैमाना है।
आर्किटेक्चर और वर्कलोड फिट
pgvector एक ओपन-सोर्स पोस्टग्रेस एक्सटेंशन है, वर्तमान में संस्करण 0.8.6 और इसके आधिकारिक GitHub रिपॉजिटरी के अनुसार Postgres 13 और बाद का समर्थन करता है। यह सीधे डेटाबेस के अंदर सटीक और अनुमानित निकटतम पड़ोसी खोज के साथ, पोस्टग्रेस को एक देशी वेक्टर कॉलम प्रकार जोड़ता है। एक वेक्टर एम्बेडिंग उसी तालिका में रह सकता है जैसा कि वह रिकॉर्ड बताता है, पहले से ही ज्ञात एसक्यूएल के साथ क्वेरी किया जाता है। खड़े होने के लिए कोई अलग सेवा नहीं है, सिंक रखने के लिए किसी दूसरे सिस्टम की आवश्यकता नहीं है और संबंधपरक डेटा और वैक्टर डेटा के बीच कोई नेटवर्क हॉप नहीं है।
एक समर्पित वेक्टर डेटाबेस एक अलग, उद्देश्य-निर्मित सेवा है, जो अपने स्वयं के स्टोरेज इंजन के साथ अपनी प्रक्रिया के रूप में चलती है, जिसे सामान्य प्रयोजन डेटाबेस पर जोड़ने की बजाय वेक्टर खोज के आसपास डिज़ाइन किया गया है। यह एक अलग वास्तुशिल्प विकल्प हैः इसका मतलब सच्चाई के स्रोत के साथ तैनात करने, निगरानी करने, बैकअप लेने और सिंक्रनाइज़ रखने के लिए एक अन्य प्रणाली का अर्थ है। स्रोत इस श्रेणी को पांच सबसे अधिक पहुंच वाले विकल्पों के चारों ओर फ्रेम करता है, और इसकी विस्तृत तुलना Qdrant का उपयोग करती है क्योंकि वह सिस्टम pgvector उपलब्ध के खिलाफ सबसे पारदर्शी सार्वजनिक बेंचमार्क का विषय है। इसमें विशिष्ट शक्तियों के साथ मिल्वस और पाइनकोन भी नाम हैं।
निर्णय रेखा ठोस है। लगभग 5 से 10 मिलियन वेक्टरों के तहत स्केल उचित हार्डवेयर पर pgvector की सीमा के भीतर आरामदायक रूप से है। रिलेशनल डेटा और एम्बेडमेंट्स के बीच लेनदेन संबंधी स्थिरता की एक वास्तविक आवश्यकता, जैसे कि उसी परमाणु लेन-देन में एक दस्तावेज़ और इसके वैक्टर को अपडेट करना, एक संरचनात्मक लाभ है जो पीजीवेक्टर का एक अलग डेटाबेस प्रदान नहीं कर सकता है। एक मौजूदा पोस्टग्रेस निवेश, और एक टीम जो पहले से ही यह जानती है कि इसे कैसे संचालित किया जाए, मॉनिटर किया जाए और इसका बैकअप लिया जाए, इसका मतलब है कि वेक्टर खोज लागत जोड़ना विस्तार और सूचकांक, न कि एक नई प्रणाली। प्रति सेकंड हजारों समवर्ती प्रश्नों के बजाय मध्यम क्वेरी समकालिकता, कार्यभार को उस हद तक रखता है जिसे अच्छी तरह से ट्यून किए गए पोस्टग्रेश उदाहरण आसानी से संभाल सकते हैं।
दूसरी ओर, वास्तव में बड़े पैमाने पर, सैकड़ों मिलियन से अरबों वेक्टर हैं जहां उद्देश्य-निर्मित वितरित आर्किटेक्चर अपनी परिचालन लागत अर्जित कर सकते हैं। भारी समवर्ती फ़िल्टर्ड खोज के तहत एक कठिन पूंछ विलंबता एसएलए, जिस तरह की आवश्यकता है जिसमें 25 से 40 मिलीसेकंड से ऊपर का p99 एक वास्तविक समस्या है, Qdrant99s ने पूंछा-विलंबता लाभ प्रदर्शित किया है। जीपीयू त्वरित अनुक्रमण Milvus की ओर इशारा करता है, जिसे जमीनी स्तर से उस विकल्प के आसपास बनाया गया है। टीम में कोई डेटाबेस विशेषज्ञता और किसी भी चीज़ को चलाने या ट्यून करने के लिए कोई भूख नहीं होने वाले शून्य संचालन प्रबंधित बुनियादी ढांचे की वरीयता आपके प्लेट से हटाने के लिए पिनकोन जैसी पूरी तरह से प्रबंधित सेवा मौजूद है।
सामान्य त्रुटियाँ: किसे इसका उपयोग करना चाहिए और किसको इसे छोड़ना चाहिए
सबसे आम गलती एक लैपटॉप बेंचमार्क को प्रमाण के रूप में व्यवहार करना है। दूसरा अलग-अलग सूचकांक सेटिंग्स वाले सिस्टम की तुलना कर रहा है, जैसे कि केवल एक तरफ m या ef_construction बदलना। टीमें पहले से ही इंडेक्स में लोड किए गए वैक्टरों को क्वेरी करके परीक्षण को कमजोर करती हैं, जब पुनरुत्पादकता मायने रखती है तो डिफ़ॉल्ट खोज सेटिंग पर भरोसा करते हैं, या यह अनदेखा करते हुए कि उत्पादन बेंच मार्क ने सादा पीजीवेक्टर के बजाय pgvectorscale का उपयोग किया था। अंत में, मापी गई कार्यभार आवश्यकताओं के बजाय स्लोगन द्वारा चयन करने से टीम जटिलता के लिए अधिक भुगतान या पैमाने के लिए कम प्रावधान छोड़ देती है।
pgvector का उपयोग तब करें जब डेटासेट मामूली हो, लेन-देन की स्थिरता मायने रखती है, पोस्टग्रेस पहले से ही अच्छी तरह से संचालित होता है, और कार्यभार प्रति सेकंड हजारों एक साथ क्वेरी नहीं होते हैं। इसे छोड़ दें जब डाटासेट सैकड़ों मिलियन से अरबों वेक्टर तक पहुंच जाता है, जब कठोर पूंछ-विलंब एसएलए गैर-वार्तालाप योग्य हो, जब जीपीयू त्वरित अनुक्रमण आवश्यक हो, या जब टीम पूरी तरह से प्रबंधित बुनियादी ढांचे को बिना डेटाबेस ट्यूनिंग के चाहती हो।
Use Qdrant जब इसकी पूंछ-विलंबता लाभ भारी समवर्ती फ़िल्टर्ड खोज के तहत मायने रखता है, खासकर जब 25 से 40 मिलीसेकंड से ऊपर p99 अस्वीकार्य होता है। इसे छोड़ दें जब कार्यभार 5 से 10 मिलियन वैक्टरों के भीतर आराम से हो और टीम तैनाती, निगरानी, बैकअप और सिंक्रनाइज़ करने के लिए किसी अन्य सिस्टम से बचना चाहेगी।
बेंचमार्क डेटा या तो साफ कहानी का समर्थन नहीं करता हैः पीजीवेक्टर हमेशा ठीक नहीं होता है, और समर्पित डेटाबेस हमेशा जीतते नहीं हैं। यह दो प्रणालियों को दिखाता है जो वास्तव में अलग-अलग ट्रेडऑफ के साथ मेल खाते हुए पारदर्शी परिस्थितियों में मापा जाता है। एक परीक्षण किए गए पोस्टग्रेस प्लस pgvectorscale सेटअप में थ्रूपुट पर निर्णायक रूप से जीतता है, दूसरा पूंछ विलंबता पर दृढ़ता से जीतेगा, और दोनों आराम से सबसे वास्तविक अनुप्रयोगों की आवश्यकता वाले पट्टी को साफ़ करते हैं। इसका उत्तर उस व्यापार के किस पक्ष पर वास्तविक कार्यभार बैठा है, न कि कौन सी प्रणाली पहले विक्रेता पिच करती है।

Comments (0)