5 हार्ड वेक्टर खोज समस्याएं और हमने अपाचे कैसेंड्रा में उन्हें कैसे हल किया

वेक्टर खोज जेनरेटिव एआई टूलींग का एक महत्वपूर्ण घटक है क्योंकि पुनर्प्राप्ति संवर्धित पीढ़ी (आरएजी) कैसी है चमक मतिभ्रम से बचते हुए एलएलएम को अद्यतन, अनुकूलित जानकारी शामिल करने में मदद करता है . साथ ही, वेक्टर खोज एक सुविधा है, उत्पाद नहीं - आपको वैक्टर से पूछताछ करने की आवश्यकता है क्योंकि वे आपके बाकी डेटा से संबंधित हैं, अलगाव में नहीं, और आपको अपने बाकी डेटा को सिंक करने के लिए एक पाइपलाइन बनाने की आवश्यकता नहीं होनी चाहिए ऐसा करने के लिए एक वेक्टर स्टोर के साथ डेटा।

2023 में वेक्टर खोज उत्पादों और परियोजनाओं में विस्फोट देखा गया है, जिससे उनमें से चयन करना एक गंभीर प्रयास बन गया है। जैसे ही आप विकल्पों पर शोध करते हैं, आपको निम्नलिखित कठिन समस्याओं और उन्हें हल करने के विभिन्न तरीकों पर विचार करने की आवश्यकता होगी। यहां, मैं आपको इन चुनौतियों के बारे में बताऊंगा और बताऊंगा कि डेटास्टैक्स एस्ट्रा डीबी और अपाचे कैसेंड्रा के लिए वेक्टर खोज के हमारे कार्यान्वयन के लिए डेटास्टैक्स ने उनसे कैसे निपटा।

सामग्री अवलोकन

• आयामीता का अभिशाप
• समस्या 1: स्केल-आउट
• समस्या 2: कुशल कचरा संग्रहण
• साइडबार: क्लाउड एप्लिकेशन कार्यभार
• समस्या 3: समवर्तीता
• समस्या 4: डिस्क का प्रभावी उपयोग
• समस्या 5: रचनाशीलता
• लपेटें

आयामीता का अभिशाप

इन कठिन समस्याओं के मूल में वही है जिसे शोधकर्ता कहते हैं " आयामीता का अभिशाप ।” व्यवहार में इसका मतलब यह है कि एल्गोरिदम जो 2-डी या 3-डी स्थानों में सटीक वेक्टर खोज के लिए काम करते हैं, जैसे केडी पेड़ , जब आप अपने वैक्टर में 10 या 100 या 1000 आयाम प्राप्त करते हैं तो अलग हो जाते हैं। इसका परिणाम यह है कि उच्च-आयामी वैक्टर के साथ सटीक समानता खोज के लिए कोई शॉर्टकट नहीं है; लघुगणक-समय परिणाम प्राप्त करने के लिए, हमें अनुमानित निकटतम पड़ोसी (एएनएन) एल्गोरिदम का उपयोग करने की आवश्यकता है, जो अपने साथ निम्नलिखित क्षेत्रों में चुनौतियाँ लाते हैं।

समस्या 1: स्केल-आउट

कई वेक्टर खोज एल्गोरिदम उन डेटासेट के लिए डिज़ाइन किए गए थे जो एक ही मशीन पर मेमोरी में फिट होते हैं, और यह अभी भी परीक्षण किया गया एकमात्र परिदृश्य है ऐन-बेंचमार्क . (एन-बेंचमार्क इसके परीक्षण को एक ही कोर तक सीमित कर देता है!) यह दस लाख दस्तावेज़ों या पंक्तियों के अकादमिक कार्य के लिए ठीक हो सकता है, लेकिन इसे वास्तविक दुनिया के कार्यभार का प्रतिनिधि माने जाने में कई साल लग गए हैं।

किसी भी अन्य डोमेन की तरह, स्केल-आउट के लिए प्रतिकृति और विभाजन दोनों की आवश्यकता होती है, साथ ही मृत प्रतिकृतियों को बदलने, नेटवर्क विभाजन के बाद उनकी मरम्मत करने आदि के लिए सबसिस्टम की आवश्यकता होती है।

यह हमारे लिए आसान था: स्केल-आउट प्रतिकृति कैसेंड्रा की ब्रेड और बटर है, और इसे नए-इन-कैसंड्रा-5.0 SAI (स्टोरेज-अटैच्ड इंडेक्सिंग - देखें) के साथ जोड़ना सीईपी-7 यह कैसे काम करता है, और SAI दस्तावेज़ इसका उपयोग कैसे करें के लिए) ने हमारे वेक्टर खोज कार्यान्वयन को प्रभावी ढंग से मुफ्त में शक्तिशाली स्केल-आउट क्षमताएं प्रदान कीं।

समस्या 2: कुशल कचरा संग्रहण

"कचरा संग्रहण" से मेरा मतलब सूचकांक से अप्रचलित जानकारी को हटाना है - हटाई गई पंक्तियों को साफ करना, और उन पंक्तियों से निपटना जिनके अनुक्रमित वेक्टर मान बदल गए हैं। यह उल्लेख करने लायक नहीं लग सकता है - यह रिलेशनल डेटाबेस की दुनिया में चालीस वर्षों से कमोबेश हल की गई समस्या रही है - लेकिन वेक्टर इंडेक्स अद्वितीय हैं।

मुख्य समस्या यह है कि हम जिन सभी एल्गोरिदम के बारे में जानते हैं, जो कम-विलंबता खोज और उच्च-रिकॉल परिणाम दोनों प्रदान करते हैं, वे ग्राफ़-आधारित हैं। बहुत सारे अन्य वेक्टर इंडेक्सिंग एल्गोरिदम उपलब्ध हैं - FAISS उनमें से कई को लागू करता है - लेकिन उनमें से सभी या तो निर्माण करने में बहुत धीमे हैं, खोज करने में बहुत धीमे हैं, या सामान्य-उद्देश्य समाधान होने के लिए बहुत कम (और कभी-कभी तीनों!) याद दिलाते हैं। यही कारण है कि प्रत्येक उत्पादन वेक्टर डेटाबेस, जिसके बारे में मैं जानता हूं, एक ग्राफ़-आधारित सूचकांक का उपयोग करता है, जिनमें से सबसे सरल HNSW है। पदानुक्रमित नौगम्य लघु विश्व ग्राफ़ थे 2016 में यूरी मालकोव एट अल द्वारा पेश किया गया ; पेपर काफी पठनीय है और मैं इसकी अत्यधिक अनुशंसा करता हूं। नीचे HNSW पर अधिक जानकारी दी गई है।

ग्राफ़ इंडेक्स के साथ चुनौती यह है कि जब कोई पंक्ति या दस्तावेज़ बदलता है तो आप पुराने (वेक्टर-संबद्ध) नोड को हटा नहीं सकते हैं; यदि आप ऐसा कुछ से अधिक बार करते हैं, तो आपका ग्राफ़ क्वेरी वेक्टर के अधिक समानता वाले क्षेत्रों की ओर बीएफएस (चौड़ाई-पहली खोज) को निर्देशित करने के अपने उद्देश्य को पूरा करने में सक्षम नहीं होगा।

तो आपको इस कचरा संग्रहण को करने के लिए किसी बिंदु पर अपने अनुक्रमणिका को फिर से बनाने की आवश्यकता होगी, लेकिन आप इसे कब और कैसे व्यवस्थित करते हैं? यदि परिवर्तन किए जाने पर आप हमेशा हर चीज का पुनर्निर्माण करते हैं, तो आप किए गए भौतिक लेखन में बड़े पैमाने पर वृद्धि करेंगे; इसे लेखन प्रवर्धन कहा जाता है। दूसरी ओर, यदि आप कभी भी पुनर्निर्माण नहीं करते हैं तो आप क्वेरी समय ("प्रवर्धन पढ़ें") पर अप्रचलित पंक्तियों को फ़िल्टर करने के लिए अतिरिक्त काम करेंगे।

यह एक और समस्याग्रस्त स्थान है जिस पर कैसेंड्रा वर्षों से काम कर रही है। चूँकि SAI इंडेक्स मुख्य भंडारण जीवनचक्र से जुड़े होते हैं, वे कैसेंड्रा में भी भाग लेते हैं संघनन , जो पढ़ने और लिखने के बीच एक स्वस्थ संतुलन प्रदान करने के लिए भंडारण इकाइयों को लघुगणकीय रूप से बढ़ाता है।

साइडबार: क्लाउड एप्लिकेशन कार्यभार

डेटास्टैक्स एस्ट्रा डीबी क्लाउड एप्लिकेशन वर्कलोड के लिए एक मंच प्रदान करने के लिए अपाचे कैसेंड्रा पर बनाता है।

इसका मतलब है कि कार्यभार जो हैं:

• प्रति सेकंड हजारों से लाखों अनुरोध बड़े पैमाने पर समवर्ती होते हैं, आमतौर पर केवल कुछ पंक्तियों को पुनः प्राप्त करने के लिए। यही कारण है कि आप नेटफ्लिक्स को स्नोफ्लेक पर नहीं चला सकते, भले ही आप इसे वहन कर सकें: स्नोफ्लेक और इसी तरह के विश्लेषणात्मक सिस्टम केवल कुछ समवर्ती अनुरोधों को संभालने के लिए डिज़ाइन किए गए हैं जो प्रत्येक कई सेकंड से लेकर मिनटों या उससे भी अधिक समय तक चलते हैं।

  
  

• मेमोरी से बड़ा यदि आपका डेटासेट किसी एक मशीन की मेमोरी में फिट बैठता है, तो इससे कोई फर्क नहीं पड़ता कि आप कौन से टूल का उपयोग करते हैं। स्क्लाइट, मोंगोडीबी, माईएसक्यूएल - ये सभी ठीक काम करेंगे। जब ऐसा नहीं होता है तो चीजें अधिक चुनौतीपूर्ण हो जाती हैं - और बुरी खबर यह है कि वेक्टर एम्बेडिंग आम तौर पर कई केबी होते हैं, या सामान्य डेटाबेस दस्तावेज़ों की तुलना में बड़े परिमाण के क्रम के आसपास होते हैं, इसलिए आप अपेक्षाकृत तेज़ी से बड़ी-से-मेमोरी तक पहुंच जाएंगे।

  
  

• एप्लिकेशन का मूल यदि आपको अपना डेटा खो जाने की परवाह नहीं है, या तो क्योंकि यह उतना महत्वपूर्ण नहीं है या क्योंकि आप इसे रिकॉर्ड के वास्तविक स्रोत से फिर से बना सकते हैं, तो फिर इससे कोई फर्क नहीं पड़ता कि आप कौन से टूल का उपयोग करते हैं। कैसेंड्रा और एस्ट्रा डीबी जैसे डेटाबेस आपके डेटा को उपलब्ध और टिकाऊ बनाए रखने के लिए बनाए गए हैं, चाहे कुछ भी हो।

समस्या 3: समवर्तीता

मैंने ऊपर उल्लेख किया है कि सुप्रसिद्ध ऐन-बेंचमार्क तुलना सभी एल्गोरिदम को एक ही कोर तक सीमित कर देती है। हालांकि यह खेल के मैदान को समतल करता है, यह उन लोगों को भी बाधित करता है जो पिछले दो दशकों में हार्डवेयर सुधार के प्रमुख स्रोत का लाभ उठा सकते हैं।

एक संबंधित समस्या यह है कि एन-बेंचमार्क एक समय में केवल एक ही प्रकार का ऑपरेशन करता है: पहले, यह सूचकांक बनाता है, फिर यह उस पर सवाल उठाता है। खोजों के साथ जुड़े अपडेट से निपटना वैकल्पिक है - और संभवतः एक बाधा भी; यदि आप जानते हैं कि आपको अपडेट से निपटने की आवश्यकता नहीं है, तो आप कई सरलीकृत धारणाएँ बना सकते हैं जो कृत्रिम बेंचमार्क पर अच्छी लगती हैं।

यदि आप अपने सूचकांक के साथ कई समवर्ती संचालन करने में सक्षम होने या इसके बनने के बाद इसे अपडेट करने की परवाह करते हैं, तो आपको यह समझने के लिए थोड़ा गहराई से देखने की जरूरत है कि यह कैसे काम करता है और इसमें कौन से ट्रेडऑफ शामिल हैं।

सबसे पहले, सभी सामान्य-उद्देश्य वाले वेक्टर डेटाबेस जिनके बारे में मैं जानता हूं, ग्राफ़-आधारित इंडेक्स का उपयोग करते हैं। ऐसा इसलिए है क्योंकि पहला वेक्टर डालते ही आप ग्राफ इंडेक्स को क्वेरी करना शुरू कर सकते हैं। अधिकांश अन्य विकल्पों के लिए आपको पूछताछ करने से पहले या तो संपूर्ण सूचकांक बनाना होगा या कम से कम कुछ सांख्यिकीय गुणों को जानने के लिए डेटा का प्रारंभिक स्कैन करना होगा।

हालाँकि, ग्राफ़ इंडेक्स श्रेणी के भीतर भी अभी भी महत्वपूर्ण कार्यान्वयन विवरण हैं। उदाहरण के लिए, हमने पहले सोचा था कि हम मोंगोडीबी इलास्टिक और सोलर की तरह ल्यूसीन के एचएनएसडब्ल्यू इंडेक्स कार्यान्वयन का उपयोग करके समय बचा सकते हैं। लेकिन हमें जल्दी ही पता चला कि ल्यूसीन केवल सिंगल-थ्रेडेड, गैर-समवर्ती सूचकांक निर्माण प्रदान करता है। यानी, आप न तो इसे क्वेरी कर सकते हैं क्योंकि इसे बनाया जा रहा है (जो इस डेटा संरचना का उपयोग करने के प्राथमिक कारणों में से एक होना चाहिए!) और न ही कई थ्रेड्स को इसे एक साथ बनाने की अनुमति दे सकते हैं।

एचएनएसडब्ल्यू पेपर सुझाव देता है कि एक बढ़िया लॉकिंग दृष्टिकोण काम कर सकता है, लेकिन हमने एक बेहतर तरीका अपनाया और एक गैर-अवरुद्ध सूचकांक बनाया। यह ओपन सोर्स है जेवेक्टर .

JVector समवर्ती अपडेट को कम से कम 32 थ्रेड्स तक रैखिक रूप से मापता है। यह ग्राफ़ x और y दोनों अक्षों पर लॉग-स्केल किया गया है, जिससे पता चलता है कि थ्रेड गिनती को दोगुना करने से निर्माण समय आधा हो जाता है।

इससे भी महत्वपूर्ण बात यह है कि JVector की गैर-अवरुद्ध समवर्ती खोजों को अद्यतनों के साथ मिलाकर अधिक यथार्थवादी कार्यभार का लाभ देती है। यहां विभिन्न डेटासेटों में पाइनकोन की तुलना में एस्ट्रा डीबी के प्रदर्शन (जेवेक्टर का उपयोग करके) की तुलना की गई है। जबकि स्थिर डेटासेट के लिए एस्ट्रा डीबी पाइनकोन से लगभग 10% तेज है, नए डेटा को अनुक्रमित करते समय यह 8x से 15x तेज है। हमने उच्च थ्रूपुट और कम विलंबता के लिए उनकी सिफारिशों के आधार पर पाइनकोन (पॉड प्रकार: पी2 और पॉड आकार: x8, 2 पॉड प्रति प्रतिकृति के साथ) के साथ सर्वोत्तम उपलब्ध पॉड टियर चुना। पाइनकोन यह खुलासा नहीं करता कि यह किन भौतिक संसाधनों से मेल खाता है। एस्ट्रा डीबी की ओर से, हमने डिफ़ॉल्ट PAYG परिनियोजन मॉडल चुना और संसाधनों को चुनने के बारे में चिंता करने की ज़रूरत नहीं थी क्योंकि यह सर्वर रहित है। का प्रयोग कर परीक्षण किये गये NoSQLबेंच .

एस्ट्रा डीबी उच्च रिकॉल और परिशुद्धता को बनाए रखते हुए भी ऐसा करता है ( F1 रिकॉल और परिशुद्धता का एक संयोजन है ) :

समस्या 4: डिस्क का प्रभावी उपयोग

हमने शुरुआत की HNSW ग्राफ़ अनुक्रमण एल्गोरिथ्म क्योंकि यह इंडेक्स बनाने में तेज़, क्वेरी करने में तेज़, अत्यधिक सटीक और लागू करने में आसान है। हालाँकि, इसका एक सर्वविदित नकारात्मक पक्ष है: इसके लिए बहुत अधिक मेमोरी की आवश्यकता होती है।

HNSW सूचकांक परतों की एक श्रृंखला है, जहां आधार परत के ऊपर प्रत्येक परत पिछले की तुलना में लगभग 10% अधिक नोड्स है। यह ऊपरी परतों को एक स्किप सूची के रूप में कार्य करने में सक्षम बनाता है, जिससे खोज को निचली परत के दाहिने पड़ोस पर शून्य करने की अनुमति मिलती है जिसमें सभी वैक्टर शामिल होते हैं।

हालाँकि, इस डिज़ाइन का मतलब है कि (सभी ग्राफ़ इंडेक्स के साथ आम तौर पर) आप यह कहकर बच नहीं सकते कि "डिस्क कैश हमें बचाएगा," क्योंकि, सामान्य डेटाबेस क्वेरी वर्कलोड के विपरीत, ग्राफ़ में प्रत्येक वेक्टर की लगभग समान संभावना होती है किसी खोज के लिए प्रासंगिक होना। (अपवाद ऊपरी परतें हैं, जिन्हें हम कैश कर सकते हैं।)

जब हम ल्यूसीन का उपयोग कर रहे थे, तब मेरे डेस्कटॉप पर 64 जीबी रैम के साथ विकिपीडिया आलेख खंडों (डिस्क पर लगभग 120 जीबी) के 100एम वेक्टर डेटासेट को परोसने की प्रोफ़ाइल इस प्रकार दिखती थी:

कैसेंड्रा अपना लगभग सारा समय डिस्क से वेक्टर पढ़ने के इंतजार में बिता रही है।

इस समस्या को हल करने के लिए, हमने डिस्कएएनएन नामक एक अधिक उन्नत एल्गोरिदम लागू किया और इसे एक स्टैंडअलोन एम्बेडेड वेक्टर खोज इंजन के रूप में ओपन-सोर्स किया, जेवेक्टर . (विशेष रूप से, JVector में वर्णित डिस्कएएनएन के वृद्धिशील संस्करण को लागू करता है फ्रेशडिस्कएएनएन कागज।) संक्षेप में, डिस्कएएनएन एचएनएसडब्ल्यू की तुलना में लंबे किनारों के साथ एक एकल-स्तरीय ग्राफ का उपयोग करता है और डिस्क आईओपीएस को कम करने के लिए वैक्टर और पड़ोसियों के एक अनुकूलित लेआउट का उपयोग करता है और समानता गणना को तेज करने के लिए मेमोरी में वैक्टर का एक संपीड़ित प्रतिनिधित्व रखता है। इसके परिणामस्वरूप विकिपीडिया कार्यभार का थ्रूपुट तीन गुना हो जाता है।

बिना क्लाइंट/सर्वर घटकों के विशुद्ध रूप से एम्बेडेड परिदृश्य में HNSW बनाम डिस्कएएनएन इस तरह दिखता है। यह ल्यूसीन (HNSW) और JVector (DiskANN) के तहत Deep100M डेटासेट की खोज की गति को मापता है। ल्यूसीन इंडेक्स 55GB है, जिसमें इंडेक्स और रॉ वैक्टर शामिल हैं। JVector इंडेक्स 64GB है। खोज मेरे 24 जीबी मैकबुक पर की गई थी, जिसमें रैम में इंडेक्स को रखने के लिए जितनी मेमोरी लगती है, उसमें लगभग एक तिहाई मेमोरी है।

समस्या 5: रचनाशीलता

डेटाबेस सिस्टम के संदर्भ में कंपोजिबिलिटी का तात्पर्य विभिन्न सुविधाओं और क्षमताओं को सुसंगत तरीके से एकीकृत करने की क्षमता से है। वेक्टर खोज जैसी क्षमता की एक नई श्रेणी के एकीकरण पर चर्चा करते समय यह विशेष रूप से महत्वपूर्ण है। गैर-खिलौना अनुप्रयोगों को हमेशा क्लासिक दोनों की आवश्यकता होगी सीआरयूडी डेटाबेस सुविधाओं के साथ-साथ नई वेक्टर खोज।

सरल पर विचार करें एआई चैटबॉट एस्ट्रा डीबी के लिए नमूना आवेदन। यह लगभग उतना ही शुद्ध आरएजी एप्लिकेशन है जितना आप पाएंगे, उपयोगकर्ता के सवालों का जवाब देने के लिए एलएलएम में उचित दस्तावेज पेश करने के लिए वेक्टर खोज का उपयोग किया जाता है। हालाँकि, इस तरह के एक साधारण डेमो में भी बातचीत के इतिहास को पुनः प्राप्त करने के लिए एस्ट्रा डीबी को "सामान्य", गैर-वेक्टर क्वेरी करने की आवश्यकता होती है, जिसे एलएलएम के प्रत्येक अनुरोध के साथ भी शामिल किया जाना चाहिए ताकि यह पहले से ही "याद" कर सके। के बदले स्थान ग्रहण किया। तो प्रमुख प्रश्नों में शामिल हैं:

1. उपयोगकर्ता के प्रश्न के लिए सबसे प्रासंगिक दस्तावेज़ (या दस्तावेज़ टुकड़े) ढूंढें
2. उपयोगकर्ता की बातचीत से अंतिम बीस संदेश पुनर्प्राप्त करें

अधिक यथार्थवादी उपयोग के मामले में, हमारा एक समाधान इंजीनियर हाल ही में एशिया की एक कंपनी के साथ काम कर रहा था जो अपने उत्पाद कैटलॉग में सिमेंटिक खोज जोड़ना चाहता था, लेकिन शब्द-आधारित मिलान को भी सक्षम करना चाहता था। उदाहरण के लिए, यदि उपयोगकर्ता ["लाल" बॉल वाल्व] खोजता है तो वे खोज को उन आइटमों तक सीमित रखना चाहते हैं जिनका विवरण "लाल" शब्द से मेल खाता है, भले ही वेक्टर एम्बेडिंग शब्दार्थ रूप से कितने समान हों। तब मुख्य नई क्वेरी (सत्र प्रबंधन, ऑर्डर इतिहास और शॉपिंग कार्ट अपडेट जैसी क्लासिक कार्यक्षमता के शीर्ष पर) इस प्रकार है: उत्पादों को उन उत्पादों तक सीमित रखें जिनमें सभी उद्धृत शब्द शामिल हैं, फिर उपयोगकर्ता की खोज के लिए सबसे समान खोजें

यह दूसरा उदाहरण यह स्पष्ट करता है कि न केवल अनुप्रयोगों को क्लासिक क्वेरी कार्यक्षमता और वेक्टर खोज दोनों की आवश्यकता होती है, बल्कि उन्हें अक्सर एक ही क्वेरी में प्रत्येक के तत्वों का उपयोग करने में सक्षम होने की आवश्यकता होती है।

इस युवा क्षेत्र में कला की वर्तमान स्थिति वह करने का प्रयास करना है जिसे मैं "सामान्य" डेटाबेस में क्लासिक क्वेरीज़ कह रहा हूं, वेक्टर डेटाबेस में वेक्टर क्वेरीज़, और फिर दोनों को तदर्थ तरीके से एक साथ जोड़ना जब दोनों हों एक ही समय में आवश्यक है. यह त्रुटि-प्रवण, धीमा और महंगा है; इसका एकमात्र गुण यह है कि आप इसे तब तक कार्यान्वित कर सकते हैं जब तक आपके पास बेहतर समाधान न हो।

एस्ट्रा डीबी में, हमने कैसेंड्रा एसएआई के शीर्ष पर बेहतर समाधान बनाया है (और ओपन-सोर्स किया है)। क्योंकि SAI कस्टम इंडेक्स प्रकार बनाने की अनुमति देता है जो कैसेंड्रा स्थिर और संघनन जीवन चक्र से जुड़े होते हैं, एस्ट्रा डीबी के लिए डेवलपर्स को बूलियन विधेय, शब्द-आधारित खोज और वेक्टर खोज को मिश्रण और मिलान करने की अनुमति देना सीधा है, बिना किसी ओवरहेड के। अलग-अलग सिस्टम को प्रबंधित और सिंक्रनाइज़ करना। इससे जेनेरिक एआई अनुप्रयोगों का निर्माण करने वाले डेवलपर्स को अधिक परिष्कृत क्वेरी क्षमताएं मिलती हैं जो अधिक उत्पादकता और तेजी से बाजार में पहुंचने में मदद करती हैं।

लपेटें

वेक्टर खोज इंजन कई वास्तुशिल्प चुनौतियों के साथ एक महत्वपूर्ण नई डेटाबेस सुविधा है, जिसमें स्केल-आउट, कचरा संग्रहण, समवर्ती, डिस्क का प्रभावी उपयोग और कंपोज़बिलिटी शामिल है। मेरा मानना है कि एस्ट्रा डीबी के लिए वेक्टर खोज के निर्माण में हम जेनेरिक एआई अनुप्रयोगों के डेवलपर्स के लिए सर्वोत्तम श्रेणी का अनुभव प्रदान करने के लिए कैसेंड्रा की क्षमताओं का लाभ उठाने में सक्षम हैं। एस्ट्रा डीबी के बारे में यहां और जानें , या यदि आप वेक्टर खोज एल्गोरिदम के करीब और व्यक्तिगत होना चाहते हैं, तो देखें जेवेक्टर .

- जोनाथन एलिस, डेटास्टैक्स द्वारा