CobbleDB: कमी लेटन्सी आणि खर्चासाठी AI सर्च स्टोरेजची पुनर्बांधणी

AI-नेटिव्ह शोधामुळे वेब सामग्री कशी प्रक्रिया, साठवण आणि सर्व्ह केली जाते यावर वेगळी आवश्यकता येते. त्या मागण्या मोठ्या प्रमाणावर पूर्ण करण्यासाठी, आम्ही कार्यक्षमता सुधारण्यासाठी आणि खर्च कमी करण्यासाठी संपूर्ण स्टॅक सुरुवातीपासून पुन्हा तयार करत आहोत.

कार्यक्षम प्रोसेसिंग आणि जलद सर्व्हिंगला शक्ती देण्यासाठी आम्ही आमची स्वतःची क्रॉलिंग, इंडेक्सिंग आणि रँकिंग इन्फ्रास्ट्रक्चर, एम्बेडिंग मॉडेल्स, आणि इन्फरन्स इंजिन्स तयार केली आहेत. प्रोसेसिंग ज्यावर रायट करतो आणि सर्व्हिंग ज्यातून रीड करतो तो जोडणारा दुवा असलेल्या स्टोरेजपर्यंत आम्ही आता तो दृष्टिकोन वाढवत आहोत.

DynamoDB सारखे व्यवस्थापित डेटाबेस (मॅनेज्ड डेटाबेस) विश्वासार्ह स्टोरेज प्रदान करतात, परंतु डेटा कसा स्टोअर केला जातो आणि रीड्स कसे सर्व्ह केले जातात यावर आमचे मर्यादित नियंत्रण होते, आणि वापर-आधारित किंमत आमच्या इंडेक्स आकारा आणि क्वेरी व्हॉल्यूमसह वाढली. स्वतंत्रपणे, आमची मागील पाइपलाइन डॉक्युमेंट प्रोसेसिंग थेट सर्व्हिंग डेटाबेसशी जोडत होती, ज्यामुळे लाईव्ह रीड्सपासून स्वतंत्रपणे अपडेट्स व्यवस्थापित करणे कठीण झाले.

नवीन अंतर्गत कोडिंग एजंट स्वॉर्मच्या मदतीने, आम्ही हे लेयर CobbleDB (एक की-व्हॅल्यू हॉट स्टोअर)भोवती पुनर्बांधणी केले, ज्याला टिकाऊ डॉक्युमेंट स्टेट आणि पब्लिशिंगसाठी Pillar द्वारे आणि बॅच केलेल्या अपडेट्ससाठी Lorry द्वारे समर्थन मिळाले. पुनर्रचना डॉक्युमेंट प्रोसेसिंगला हॉट-स्टोअर इन्जेशनपासून वेगळी करते आणि आम्हाला आमच्या वर्कलोडनुसार सर्व्हिंग ट्यून करण्याची परवानगी देते. प्रोडक्शन बिफॉर-ॲंड-आफ्टर मोजमाप अंदाजे 5× कमी बॅच-रीड लेटन्सी दर्शवतात, आणि आमचे अंतर्गत खर्च मॉडेल DynamoDB च्या तुलनेत किमान 20% बचतीचा अंदाज वर्तवते.

AI-नेटिव्ह सर्चसाठी स्टोरेज इन्फ्रास्ट्रक्चर

क्लासिक सर्च स्टॅक मानवी वाचकांसाठी बनवलेला आहे, भाषेच्या मॉडेलसाठी नाही. हा फरक ग्रॅन्युलॅरिटी बदलतो ज्यावर सिस्टीमने वेब सामग्री तयार करणे, स्टोअर करणे आणि सर्व्ह करणे आवश्यक आहे.

रॉ HTML ला मॉडेलसाठी तयार सामग्रीमध्ये बदलण्यासाठी, आमची प्रोसेसिंग पाइपलाइन प्रत्येक पेज स्वच्छ करते, त्याचे सिमेंटिकदृष्ट्या सुसंगत पॅशांत विभाजन करते, त्यांची एम्बेडिंग्ज मोजते आणि डेटाबेसमध्ये पॅसेज व एम्बेडिंग्ज एकत्र स्टोअर करते. क्वेरीच्या वेळी, सर्व्हिंग पाइपलाइन क्वेरीशी सर्वाधिक संबंधित मजकूर निवडते आणि तो मॉडेलकडे पास करते.

दोन वेगळे वर्कफ्लो

म्हणून स्टोरेज स्तराने वेगवेगळ्या मागण्यांसह दोन वर्कफ्लो समर्थित केले पाहिजेत: प्रोसेसिंग पाइपलाइनमधून अपडेट्स इन्जस्ट करणे आणि कमी लेटन्सीचे रीड्स सर्व्ह करणे.

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

याउलट, क्वेरी-टाईम रीड्स पेज की च्या बॅचेसची विनंती करतात आणि रँकिंग व पॅसेज निवडीसाठी संबंधित पॅसेज मजकूर आणि एम्बेडिंग्ज पुनर्प्राप्त करतात. हे रीड्स अंतिम उत्तराच्या मार्गावर बसतात, त्यामुळे ते जलद पूर्ण करणे आवश्यक आहे.

या वर्कलोड्ससाठी वेगवेगळ्या डिझाइनची आवश्यकता असते. प्रोसेसिंगला टिकाऊ रांगा आणि अपडेट्स कार्यक्षमतेने वितरित करण्याची क्षमता, अपयशांची पुनरावृत्ती करण्याची क्षमता आणि मोठ्या प्रमाणावर विद्यमान रेकॉर्ड अद्ययावत आणण्याची क्षमता याद्वारे फायदा होतो. सर्व्हिंगला पूर्वगणित रेकॉर्ड्स, वॉर्म कॅशेस आणि किमान क्वेरी-टाईम कामासह जलद बॅच केलेल्या रीड्सचा फायदा होतो. दोघांमधील घट्ट जोडणीमुळे पुनर्प्राप्तीचे काम आणि मोठे अपडेट्स लेटन्सी-संवेदनशील रीड्सशी स्पर्धा करू शकतात.

व्यवस्थापित डेटाबेस कुठे कमी पडतो

DynamoDB ने आम्हाला वितरित डेटाबेस चालवण्याच्या ओझ्याशिवाय उच्च उपलब्ध स्टोरेज दिले. क्वेरी-टाईम रीड्ससाठी एका समर्पित प्रिपर्ड-पेजेस टेबलमध्ये पॅसेज आणि एम्बेडिंग्ज ठेवले गेले, तर पूर्ण पेज सामग्री आणि मेटाडेटा वेगवेगळे स्टोअर केले गेले. तथापि, आमचा वर्कलोड वाढला तसे, तीन निकष महत्त्वाचे बनले.

पहिले, वापर-आधारित किंमत वाचलेली किंवा लिहिलेली प्रत्येक बाइट आकारते. एकाच सर्च API रिक्वेस्टमध्ये आम्हाला आणण्यासाठी आवश्यक असलेल्या पेजेसशी संबंधित 100-120 की असतात. डेटा पुनर्प्राप्ती प्रक्रिया एका रिक्वेस्टला सरासरी आयटमचा आकार सुमारे 50 KB असलेल्या 10-20 पेज की च्या लहान बॅचेसमध्ये विभाजित करते. त्या रेकॉर्ड्सची वारंवार वाचन केल्याने लक्षणीय क्षमता वापरली गेली, तर सतत क्रॉल आणि चंकिंग किंवा एम्बेडिंग मॉडेल्समधील बदलांमुळे अधिक राईट्स तयार झाले. अर्थशास्त्र केवळ 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 एमएस वरून 5.60 एमएस पर्यंत खाली आली. p90 56.7 एमएस वरून 9.77 एमएस पर्यंत खाली आली, आणि p99 123 एमएस वरून 24.2 एमएस पर्यंत खाली आली. ठराविक रिक्वेस्ट्स आणि टेल या दोन्हीमधील सुधारणांसह, प्रमाण 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 एजंट्स खरेदी करण्यापेक्षा तयार करण्याच्या बाजूने कॅल्क्युलसला आणखी पुढे नेतात.

AI-नेटिव्ह सर्च सिस्टीम तयार करणारे इतर संघ आमच्या उत्पादनांच्या आत शोध जलद आणि स्वस्त बनवणाऱ्या त्याच स्टोरेज लेयरचा लाभ घेऊ शकतील, यासाठी आम्ही लवकरच CobbleDB ओपन-सोर्स करण्याची योजना आखत आहोत.

उद्धरण

@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}
}