वेक्टर डेटाबेस
एक प्रबंधित वेक्टर डेटाबेस जो केवल PostgreSQL है
एम्बेडिंग्स स्टोर करें और अर्थ के आधार पर उनकी खोज करें, pgvector पर जिसे हम आपके लिए संचालित और बैकअप करते हैं। सीखने के लिए कोई नया डेटास्टोर नहीं, आकार देने के लिए कोई क्लस्टर नहीं — एक इंडेक्स बनाएं, अपने वैक्टर लिखें, और अपने पास मौजूद API कुंजी के साथ उस पर क्वेरी करें।
जिस डेटाबेस पर आप पहले से भरोसा करते हैं, उसमें एक अतिरिक्त कॉलम प्रकार के साथ
वेक्टर डेटाबेस आमतौर पर पहले डेटाबेस के साथ चलाने के लिए एक दूसरा सिस्टम होता है: एक और क्लस्टर, एक और बैकअप कहानी, और जागते रहने की एक और वजह। यह PostgreSQL के भीतर pgvector है — वही इंजन, वही ड्यूरेबिलिटी, वही रात का बेस बैकअप और लगातार राइट-अहेड लॉग आकाइविंग जो यहाँ बाकी सभी चीज़ों को मिलती है। आपका इंडेक्स इस पर एक HNSW इंडेक्स वाली एक सामान्य टेबल है, इसलिए यह अनुमानित निकटतम-पड़ोसी खोज (approximate nearest-neighbour search) के लिए तेज़ है और बाकी हर मामले में सामान्य है, जो कि रात के तीन बजे आप जो खूबी चाहते हैं वही है।
आपके मॉडल की चौड़ाई, हमारी चुनी हुई चौड़ाई नहीं
अधिकांश प्रबंधित वेक्टर सेवाएँ आपको आयामों की एक छोटी सूची में से चुनने के लिए मजबूर करती हैं। आपका वेक्टर गोल संख्या का होना आवश्यक नहीं है: 1 से 3072 तक कुछ भी स्वीकार किया जाता है और बिल्कुल वैसे ही रखा जाता है, क्योंकि एक संकीर्ण वेक्टर को अगली भौतिक चौड़ाई में शून्य के साथ पैड किया जाता है — जिससे कोसाइन, यूक्लिडियन और आंतरिक-उत्पाद दूरी में बिल्कुल कोई बदलाव नहीं होता है। 1408-आयाम वाला मॉडल इसके लिए मूल रूप से आकार दिए गए मॉडल की तरह ही रैंक करता है, और रीड्स आपको आपके संग्रहीत 1408 मान वापस देते हैं, पैडिंग कभी नहीं।
हर वेक्टर प्लान में शामिल
- 3072 तक की कोई भी एम्बेडिंग चौड़ाई, और कोसाइन, यूक्लिडियन या इनर-प्रोडक्ट दूरी
- प्रत्येक वेक्टर के साथ मेटाडेटा संग्रहीत किया जाता है, और क्वेरी के समय फ़िल्टर किया जाता है
- 30 दिनों के रिज़ेंशन और पॉइंट-इन-टाइम रिकवरी के साथ रात के समय के बैकअप
- पंक्ति-स्तर की सुरक्षा, ताकि एक संगठन के वेक्टर दूसरे संगठन के लिए पहुंच से बाहर रहें
योजनाएँ और मूल्य निर्धारण
तीन स्तर, जिनकी कीमत उन दो चीज़ों पर आधारित है जो वास्तव में हमारे लिए खर्च लाती हैं: आप कितना स्टोर करते हैं और आप कितना खोजते हैं।
आपके कॉन्फ़िगरेशन के आधार पर मूल्य निर्धारित
लागत आपके द्वारा चुने गए क्षेत्र, मशीन के आकार, बैंडविड्थ और स्टोरेज पर निर्भर करती है, इसलिए यहाँ कोई एक निश्चित मासिक आंकड़ा छाप पाना संभव नहीं है। हमें अपना वर्कलोड बताएं और हम इसके लिए आपको कोटेशन देंगे।
100% अक्षय ऊर्जा द्वारा संचालित
हमारे हर उत्पाद के लिए, हमारे द्वारा चलाया जाने वाला हर सर्वर, नवीकरणीय बिजली से संचालित होता है। बाद में उसकी भरपाई नहीं की जाती — शुरुआत से ही वैसे प्राप्त किया जाता है।
- हमारे सभी होस्टिंग पर 100% नवीकरणीय बिजली
- 1.1 से 1.2 के PUE पर चलने वाले डेटा सेंटर
- हमारे साझा प्लेटफ़ॉर्म पर मौजूद साइटें ग्रीन वेब फाउंडेशन की जाँच में खरी उतरती हैं — एक ऐसा तीसरा पक्ष जिसकी पुष्टि आप स्वयं कर सकते हैं
खरीदने से पहले लोग जो सवाल पूछते हैं
यह किन एम्बेडिंग मॉडल के साथ काम करता है?
इनमें से कोई भी। आप हमें वे नंबर भेजते हैं जो आपके मॉडल ने तैयार किए हैं, इसलिए OpenAI, Cohere, Voyage, आपकी अपनी मशीन पर मौजूद Sentence-Transformers मॉडल और अन्य सभी हमारे लिए एक समान हैं। जब आप इंडेक्स बनाते हैं तो आप हमें चौड़ाई बताते हैं — 384, 768, 1024, 1536 और 3072 सभी आम हैं, और उनके बीच की कोई भी संख्या भी आम है।
क्या मैं बाद में किसी इंडेक्स की चौड़ाई या दूरी का फ़ंक्शन बदल सकता हूँ?
नहीं, और हम इसे घुमा-फिराकर कहने के बजाय सीधे तौर पर बताना पसंद करेंगे कि आपके वेक्टर भौतिक रूप से कहाँ संग्रहीत हैं और उन्हें कैसे रैंक किया जाता है, इन दोनों का निर्णय यही करते हैं, इसलिए इनमें से किसी को भी बदलने से इंडेक्स में पहले से मौजूद सब कुछ चुपचाप अमान्य हो जाएगा। यदि आप किसी भिन्न एम्बेडिंग मॉडल पर स्विच करते हैं, तो दूसरा इंडेक्स बनाएं और उसमें डेटा लिखें — वही बात जो हर वेक्टर डेटाबेस आपसे कहता है, और उसी कारण से।
क्या बहुत चौड़े वैक्टर के बारे में कुछ अलग है?
हाँ, और यह बात जानना ज़रूरी है। 2,000 आयामों से अधिक मानों को आधे प्रिसिजन पर संग्रहीत किया जाता है, क्योंकि PostgreSQL का HNSW इंडेक्स उससे चौड़े पूर्ण-प्रिसिजन कॉलम को स्वीकार नहीं करता है। 3072-आयाम वाले मॉडलों के लिए यह वही तरीका है जिसकी सिफ़ारिश pgvector खुद करता है और रैंकिंग पर इसका प्रभाव नगण्य है — लेकिन यह एक वास्तविक ट्रेड-ऑफ़ है और इसके बारे में आपको खुद अनुमान लगाने के बजाय हमारे द्वारा पता चलना चाहिए।
क्या मुझे डेटाबेस कनेक्शन स्ट्रिंग मिलती है?
आज नहीं। आप अपनी Zinn® API कुंजी के साथ HTTPS पर अपना इंडेक्स एक्सेस करते हैं, जो इस प्रकार सीमित होती है कि खोज करने वाली कुंजी आपके खाते में और कुछ नहीं कर सकती। यही वह चीज़ है जिससे हम ईमानदारी से अनुरोधों की माप कर सकते हैं और एक टेनेंट की पंक्तियों को दूसरे की पहुँच से दूर रख सकते हैं। यदि आपको सीधे कनेक्शन की आवश्यकता है, तो हमें बताएं — हम किसी के पूछने पर इसे बनाना पसंद करेंगे, न कि अंदाज़ा लगाना।
इसकी माप कैसे की जाती है, और क्या मैं खुद आँकड़ों की जाँच कर सकता हूँ?
दो पैमानों पर: एक कैलेंडर महीने में आप कितना स्टोर करते हैं और कितनी खोजें चलाते हैं। दोनों आपके डैशबोर्ड पर वास्तविक समय में दिखते हैं। स्टोरेज भौतिक टेबल आकार के बजाय एक प्रकाशित फॉर्मूला है — पंक्ति ओवरहेड, साथ ही संग्रहीत चौड़ाई, साथ ही आपकी अपनी आईडी और मेटाडेटा की लंबाई — ठीक इसलिए ताकि आप हमारे शब्द पर भरोसा करने के बजाय उस आंकड़े को स्वयं पुनरुत्पादित कर सकें जिसके लिए हम आपको बिल भेज रहे हैं।