CobbleDB: कम लेटेंसी और लागत के लिए AI सर्च स्टोरेज का पुनर्निर्माण

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

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

DynamoDB जैसे प्रबंधित डेटाबेस ने विश्वसनीय स्टोरेज प्रदान किया, लेकिन डेटा को कैसे स्टोर किया गया और रीड्स को कैसे सर्व किया गया, इस पर हमारा सीमित नियंत्रण था, और उपयोग-आधारित मूल्य निर्धारण हमारे इंडेक्स साइज़ और क्वेरी वॉल्यूम के साथ बढ़ा। अलग से, हमारी पिछली पाइपलाइन ने डॉक्यूमेंट प्रोसेसिंग को सीधे सर्विंग डेटाबेस के साथ जोड़ा, जिससे लाइव रीड्स से स्वतंत्र रूप से अपडेट को प्रबंधित करना मुश्किल हो गया।

एक नए आंतरिक कोडिंग एजेंट स्वार्म की मदद से, हमने CobbleDB के आसपास इस लेयर को फिर से बनाया, जो एक की-वैल्यू हॉट स्टोर है, जिसे ड्यूरेबल डॉक्यूमेंट स्टेट और पब्लिशिंग के लिए Pillar द्वारा समर्थित किया गया है, और बैच्ड अपडेट्स के लिए Lorry द्वारा समर्थित है। रीडिज़ाइन डॉक्यूमेंट प्रोसेसिंग को हॉट-स्टोर इंजेशन से अलग करता है और हमें हमारे वर्कफ़्लो के लिए सर्विंग को ट्यून करने देता है। प्रोडक्शन बिफोर-एंड-आफ्टर माप लगभग 5× कम बैच-रीड लेटेंसी दिखाते हैं, और हमारा आंतरिक लागत मॉडल DynamoDB के सापेक्ष कम से कम 20% बचत का अनुमान लगाता है।

AI-नेटिव सर्च के लिए स्टोरेज इन्फ्रास्ट्रक्चर

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

कच्चे HTML को मॉडल-तैयार सामग्री में बदलने के लिए, हमारी प्रोसेसिंग पाइपलाइन प्रत्येक पृष्ठ को साफ करती है, इसे सिमेंटिक रूप से सुसंगत मार्ग (पैसेज) में विभाजित करती है, उनके एम्बेडिंग की गणना करती है, और डेटाबेस में मार्ग और एम्बेडिंग को एक साथ स्टोर करती है। क्वेरी के समय, सर्विंग पाइपलाइन क्वेरी के लिए सबसे प्रासंगिक पाठ का चयन करती है और इसे मॉडल को पास करती है।

दो अलग-अलग वर्कफ़्लो

इसलिए स्टोरेज लेयर को विभिन्न मांगों के साथ दो वर्कफ़्लो का समर्थन करना चाहिए: प्रोसेसिंग पाइपलाइन से अपडेट इंजस्ट करना और कम लेटेंसी वाले रीड्स को सर्व करना।

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

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

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

कहाँ प्रबंधित डेटाबेस कम पड़ जाता है

DynamoDB ने हमें डिस्ट्रिब्यूटेड डेटाबेस को संचालित करने के बोझ के बिना अत्यधिक उपलब्ध स्टोरेज प्रदान किया। एक समर्पित प्रिपर्ड-पेज टेबल में क्वेरी-टाइम रीड्स के लिए पैसेज और एम्बेडिंग्स थे, जबकि पूर्ण पेज सामग्री और मेटाडाटा को अलग से स्टोर किया गया था। हालाँकि, जैसे-जैसे हमारा वर्कलोड बढ़ा, तीन बाधाएँ महत्वपूर्ण हो गईं।

पहला, उपयोग-आधारित मूल्य निर्धारण पढ़े गए या लिखे गए प्रत्येक बाइट से शुल्क लेता है। एक सिंगल सर्च API अनुरोध में 100-120 कीज़ होती हैं जो उन पृष्ठों से मेल खाती हैं जिन्हें हमें प्राप्त करने की आवश्यकता है। डेटा पुनर्प्राप्ति प्रक्रिया एक अनुरोध को 10-20 पेज कीज़ के छोटे बैचों में विभाजित करती है जिसमें औसत आइटम साइज़ लगभग 50 KB होता है। उन रिकॉर्ड्स को बार-बार पढ़ने से काफी क्षमता की खपत हुई, जबकि लगातार क्रॉल और चंकिंग या एम्बेडिंग मॉडल में बदलाव ने अधिक राइट्स उत्पन्न किए। अर्थशास्त्र केवल API कॉल की संख्या पर नहीं, बल्कि रिकॉर्ड के आकार और आवृत्ति पर भी निर्भर करता है।

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

तीसरा, प्रोसेसिंग सीधे हॉट-स्टोर राइट्स से जुड़ी थी। हमारी पिछली प्रोसेसिंग पाइपलाइन ने प्रत्येक प्रिपर्ड पेज को सीधे DynamoDB पर लिखा। इसलिए एक बड़ा रीप्रोसेसिंग जॉब व्यक्तिगत हॉट-स्टोर अपडेट्स की एक लहर बन गया, और प्रोसेसिंग को हॉट स्टोर की थ्रूपुट सीमाओं और रीट्राय व्यवहार को समायोजित करना पड़ा। हम एक नए चंकिंग मेथड को आज़माने, अपने एम्बेडिंग मॉडल को बदलने, या एक नया फ़ील्ड जोड़ने के लिए 1-2 दिनों में पूरे डेटाबेस पर MapReduce नहीं चला सकते थे। सहेजे गए पेज अपडेट का कोई स्वतंत्र स्ट्रीम नहीं था जिसे एक अलग सेवा बैच कर सके और अपनी गति से हॉट स्टोर तक पहुँचा सके।

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

अलग डॉक्यूमेंट स्टेट, अपडेट डिलीवरी और सर्विंग

नई आर्किटेक्चर प्रत्येक ज़िम्मेदारी को एक अलग कंपोनेंट को सौंपती है। Pillar एक टिकाऊ दस्तावेज़ स्थिति बनाए रखता है और तय करता है कि क्या प्रकाशित करना है। Lorry उन एक्सपोर्ट्स को विभाजित बैचों में बदलता है। CobbleDB बैचों को इन्गेस्ट करता है और पेज की के द्वारा तैयार रिकॉर्ड्स सर्व करता है.

बड़ा करें

CobbleDB: ट्यूनेबल रीड पाथ

CobbleDB क्वेरी के समय तैयार रिकॉर्ड परोसने के लिए अनुकूलित हमारा हॉट स्टोर है। यह एक वितरित की-वैल्यू स्टोर है: कीज़ पेज आइडेंटिफ़ायर (हैश्ड URL) हैं, और वैल्यूज़ पेज का प्रोसेस किया गया रिप्रजेंटेशन हैं (उनके प्री-चंक्ड पैसेज और प्रति-चंक वेक्टर एम्बेडिंग)।

महत्वपूर्ण परिवर्तन स्टोरेज कॉन्फ़िगरेशन पर हमारा नियंत्रण है।

डेटा को पार्टिशंड और डेटा नोड्स में विभाजित किया जाता है। यह वितरित प्रारूप यह सुनिश्चित करता है कि डेटाबेस प्रोसेस किए गए पृष्ठों के एक विशाल कॉर्पस को समायोजित करने के लिए क्षैतिज रूप से स्केल कर सकता है। प्रत्येक पार्टिशन में तीन अलग-अलग नोड्स पर तीन प्रतिकृतियां हैं; यदि एक कॉपी अनुपलब्ध हो जाती है, तो अन्य रीड्स सर्व करना जारी रख सकती हैं।

प्रत्येक डेटा नोड को पार्टिशंस का एक सबसेट सौंपा जाता है। नोड अपना डेटा RocksDB का उपयोग करके स्टोर करता है, जो एक ओपन-सोर्स एम्बेडेड की-वैल्यू स्टोरेज इंजन है जो बैच इंजेशन द्वारा संचालित रीड-हेवी वर्कलोड के लिए बेहद उपयुक्त है।

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

एक स्टेटलेस क्वेरी राउटर कीज़ को पार्टिशंस में हैश करता है और समानांतर में नोड्स पर अनुरोधों को रूट करता है। आर्किटेक्चर में PostgreSQL-समर्थित मेटाडाटा सेवा और ड्यूरेबल ऑब्जेक्ट स्टोरेज भी शामिल है।

यह डिज़ाइन उन रीड पैटर्न का समर्थन करता है जिनकी वर्कलोड को आवश्यकता होती है। प्रासंगिक पृष्ठों का एक उम्मीदवार सेट प्राप्त करने के लिए क्वेरी के पुनःप्राप्ति और रैंकिंग से गुजरने के बाद, उन पृष्ठों की सामग्री के लिए थोक में हॉट स्टोर से पूछताछ की जाती है। ये रीड अनुरोध राउटर पर आते हैं और एक संबंधित डेटा नोड पर रूट किए जाते हैं। राउटर क्रॉस-ज़ोन लेटेंसी को कम करने के लिए, यदि संभव हो तो, उसी उपलब्धता ज़ोन में किसी नोड पर अनुरोध भेजने को प्राथमिकता देता है। प्रत्येक डेटा नोड MultiGet का उपयोग करके पेज की सामग्री ला सकता है, जो एक RocksDB बैच-रीड API है जिसे कम लेटेंसी पर एक साथ कई कीज़ लाने के लिए डिज़ाइन किया गया है। यदि कोई नोड प्रतिक्रिया देने में धीमा है, तो सिस्टम किसी भिन्न नोड पर किसी अन्य पार्टिशन प्रतिकृति से भी पूछताछ कर सकता है, जिससे टेल लेटेंसी में सुधार होता है।

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

बड़ा करें

Pillar और Lorry: ड्यूरेबल राइट पाथ

एक अलग स्टोरेज लेयर हमारी क्रॉल और प्रोसेस की जाने वाली हर चीज़ पर नज़र रखती है, अपडेट्स को वर्शंड डॉक्यूमेंट स्टेट में मर्ज करती है और आवश्यक रिप्रजेंटेशन को CobbleDB तथा सर्च इंडेक्स पर पब्लिश करती है। इस उद्देश्य के लिए हमने अपना डॉक्यूमेंट स्टेट और पब्लिशिंग लेयर, Pillar बनाया है।

Pillar को YTsaurus का समर्थन प्राप्त है। यह अलग YTsaurus टेबल परिवारों में पेज घटकों (जैसे मेटाडाटा, चंक और एम्बेडिंग) को स्टोर करता है। यह चंक और एम्बेडिंग के वर्शन को भी ट्रैक करता है, जिससे कई रिप्रजेंटेशन को एक-दूसरे को ओवरराइट किए बिना सह-अस्तित्व में रहने की अनुमति मिलती है ताकि अंतर्निहित मॉडल बदल सकें। चूँकि Pillar और YTsaurus सस्ते HDD स्टोरेज का उपयोग करते हैं, इसलिए हम DynamoDB में पहले स्टोर किए गए दस्तावेज़ों की तुलना में बहुत अधिक दस्तावेज़ स्टोर कर सकते हैं।

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

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

CobbleDB अपेक्षा करता है कि अपडेट्स को पार्टिशन के अनुसार बैच्ड किया जाए। Pillar एक्सपोर्ट्स को Lorry नामक एक स्टेटलेस सेवा द्वारा इस प्रारूप में परिवर्तित किया जाता है। इसका एकमात्र काम एक निरंतर पार्टिशन-संरेखित कतार से एक्सपोर्ट रिकॉर्ड पढ़ना, उन्हें प्रति-पार्टिशन बैच फ़ाइलों में संचित करना और उन्हें CobbleDB को सौंपना है।

Lorry और Cobble के बीच, एक अतिरिक्त प्रोटोकॉल डेटा प्लेन (S3) को कंट्रोल प्लेन से अलग करता है। Lorry एक अद्वितीय पहचानकर्ता के तहत S3 पर बैच लिखता है और Cobble के भीतर बैच को पंजीकृत करता है। Cobble पार्टिशन प्रतिकृतियां स्वतंत्र रूप से अगले S3 बैच को इंजस्ट करने के लिए बैच या कंट्रोल प्लेन API से पूछताछ करती हैं और कालानुक्रमिक क्रम में बैच अपडेट को एसिंक्रोनस रूप से लागू करती हैं। इसका मतलब यह है कि एक धीमा या पुनर्प्राप्त करने वाला नोड बाकी सिस्टम को धीमा करने के बजाय अपनी गति से पकड़ सकता है।

बड़ा करें

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

सत्यापन

5x तेज़

हॉट स्टोर को माइग्रेट करने के बाद, औसत बैच-रीड लेटेंसी 31.4 ms से गिरकर 5.60 ms हो गई। p90 56.7 ms से गिरकर 9.77 ms हो गया, और p99 123 ms से गिरकर 24.2 ms हो गया। अनुपात 5.08× से 5.80× तक है, जिसमें सामान्य अनुरोधों और टेल दोनों में सुधार हुआ है।

बड़ा करें

ये नंबर बैच्ड रीड्स से प्राप्त होते हैं, जहाँ प्रत्येक क्वेरी लगभग 10-15 कीज़ का अनुरोध करती है। औसत पेलोड आइटम साइज़ 50KB है। दोनों प्रणालियों से लगभग 200k rps पर पूछताछ की गई थी, हालांकि हमने बिना किसी गिरावट के 500k rps तक लोड टेस्ट भी चलाए।

CobbleDB के योगदान को अलग करने के लिए, सेटअप के अन्य सभी पहलुओं को स्थिर रखा गया था। हालाँकि, यह अभी भी एक ऑब्जर्वेशनल बिफोर-एंड-आफ्टर तुलना है; सिस्टम ने नियंत्रित स्थितियों के तहत समान अनुरोधों के बजाय अलग-अलग समय पर लाइव प्रोडक्शन ट्रैफ़िक को सर्व किया। इसलिए हमने एक सिंथेटिक बेंचमार्क पर दोनों प्रणालियों के प्रदर्शन को भी मापा। प्रोडक्शन में देखे गए अनुरोधों का अनुमान लगाने के लिए, हमने 10-15 कीज़ और 100B से 100 KiB तक के वैल्यूज़ के बैच के साथ दोनों से पूछताछ की।

बड़ा करें

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

20% सस्ता

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

हमने स्टोरेज साइज़, राइट कैपेसिटी यूनिट्स और रीड कैपेसिटी यूनिट्स के आंतरिक अनुमानों के आधार पर लागत बचत की गणना की। हर कमिटमेंट टियर पर, CobbleDB, DynamoDB से कम से कम 20% सस्ता है। वास्तविक बचत संभवतः इससे भी अधिक है, क्योंकि इन परिणामों में संपीड़न (कंप्रेसन) से होने वाली संभावित बैकअप बचत को ध्यान में नहीं रखा गया है।

AI एजेंटों का एक समूह इसे बनाने में हमारी कैसे मदद करता है

CobbleDB और आसपास के बुनियादी ढांचे का निर्माण मामूली नहीं था। अकेले CobbleDB का कोर डेटाबेस लगभग 40,000 लाइन का Rust है, और माइग्रेशन के लिए प्रोडक्शन पैमाने पर शुद्धता और विफलता व्यवहार को सत्यापित करने, CobbleDB को प्रोसेसिंग और सर्विंग दोनों पथों के साथ एकीकृत करने और लाइव ट्रैफ़िक को सुरक्षित रूप से स्थानांतरित करने के लिए व्यापक कार्य की भी आवश्यकता थी।

हमने एक आंतरिक प्रणाली का उपयोग करके इस प्रयास को तेज किया जो कोडिंग एजेंटों के एक झुंड का संचालन करती है। सिस्टम को अत्यधिक लगातार होने के लिए डिज़ाइन किया गया है; यह सत्रों में प्रोजेक्ट के लक्ष्यों, सक्रिय जोखिमों, रिपॉजिटरी इतिहास और पूर्व निर्णयों को बनाए रखता है।

हमने CobbleDB प्रोजेक्ट को ऐसे सक्रिय, हमेशा चालू रहने वाले एजेंटों का एक समूह सौंपा। उनका पहला कार्य पहले से चल रहे कार्य का एक सटीक मॉडल बनाना था। उन्होंने प्रोजेक्ट चैनल और सक्रिय थ्रेड्स का ऑडिट किया, उत्कृष्ट वस्तुओं को उनके pull requests और स्वामियों से जोड़ा, और सिस्टम स्वास्थ्य और अगले कार्यों का वर्तमान रीडआउट तैयार किया। वहाँ से, उन्होंने इंजीनियरिंग लूप के कई हिस्सों में काम किया:

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

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

निष्कर्ष

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

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

हमारी योजना जल्द ही CobbleDB को ओपन-सोर्स करने की है, ताकि AI-नेटिव सर्च सिस्टम बनाने वाली अन्य टीमें उसी स्टोरेज लेयर से लाभ उठा सकें जो हमारे उत्पादों के अंदर खोज को तेज़ और सस्ता बनाती है।

उद्धरण

@online{perplexity2026Cobbledb,
  author = {{Perplexity} and Alexandr Yarats and Marco Montagna and Aleksei Bykov and Alexey Gusev and Ali Abdullaev and Amir Mokhammed-Ali and Andrey Zosimov and Denis Kremko and Gleb Vishnevsky and Micah Zirn and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma and Denis Yarats},
  title = {{CobbleDB: Rebuilding AI search storage for lower latency and cost}},
  date = {2026-09-14},
  url = {https://www.perplexity.ai/hub/blog/cobbledb}
}