सबसे पहले Apple के FoundationDB को देखें

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

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

FoundationDB में, लेन-देन कभी एक-दूसरे को अवरुद्ध नहीं करते हैं। रीडिंग को मल्टीवर्जन वर्जन कंट्रोल (MVCC) के माध्यम से लागू किया जाता है, और रीडिंग को आशावादी कंसीलर कंट्रोल (OCC) के माध्यम से लागू किया जाता है। डेवलपर्स का दावा है कि जब क्लस्टर की सभी मशीनें एक ही डेटा सेंटर में होती हैं, तो राइट लेटेंसी 2-3 ms होती है, और रीड लेटेंसी मिलीसेकंड से कम होती है। प्रलेखन में 10-15 एमएस के अनुमान शामिल हैं, जो वास्तविक परिस्थितियों में परिणामों के करीब है।

* कई शार्क पर ACID गुणों का समर्थन नहीं करता है।

FoundationDB का एक अनोखा लाभ है - स्वचालित पुनरुत्पादन। DBMS स्वयं क्लस्टर में मशीनों को लोड करना भी सुनिश्चित करता है: जब एक सर्वर भर जाता है, तो यह बैकग्राउंड में पड़ोसी को डेटा पुनर्वितरित करता है। इसी समय, सभी लेनदेन के लिए सीरियल के स्तर की गारंटी संरक्षित है, और ग्राहकों के लिए केवल ध्यान देने योग्य प्रभाव प्रतिक्रियाओं की विलंबता में थोड़ी वृद्धि है। डेटाबेस यह सुनिश्चित करता है कि सबसे अधिक और कम से कम लोड किए गए क्लस्टर सर्वर पर डेटा की मात्रा 5% से अधिक न हो।

आर्किटेक्चर

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



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

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



क्लस्टर नियंत्रक उपलब्ध प्रक्रियाओं की कुल संख्या जानता है और भूमिका वितरित करता है: ये 5 प्रॉक्सी होंगे, ये 2 रिज़ॉल्वर होंगे, यह एक मास्टर होगा। और अगर उनमें से किसी की मृत्यु हो जाती है, तो वह तुरंत उसके लिए एक प्रतिस्थापन ढूंढ लेगा, जो एक मनमानी मुक्त प्रक्रिया के लिए आवश्यक भूमिका प्रदान करता है। यह सब पृष्ठभूमि में होता है, आवेदन प्रोग्रामर के लिए अदृश्य।

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

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

प्रसंस्करण का अनुरोध करें

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

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



किसी भी क्लाइंट-सर्वर सिस्टम की तरह, ऐसे हालात होते हैं जब लेनदेन सफलतापूर्वक पूरा हो जाता है, लेकिन डिस्कनेक्ट होने के कारण क्लाइंट को पुष्टि नहीं मिली। क्लाइंट लाइब्रेरी उन्हें किसी अन्य त्रुटि की तरह मानती है - यह बस फिर से प्रयास करता है। यह संभावित रूप से पूरे लेनदेन के पुन: क्रियान्वयन का कारण बन सकता है। हालांकि, यदि लेन-देन उदासीन है, तो इसके साथ कोई समस्या नहीं है - यह अंतिम परिणाम को प्रभावित नहीं करेगा।

स्केलिंग

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

यदि वांछित संग्रहण सर्वर अनुपलब्ध है, तो क्लाइंट लाइब्रेरी क्लस्टर नियंत्रक से एक नया कॉन्फ़िगरेशन लेता है। यदि, सर्वर क्रैश के परिणामस्वरूप, क्लस्टर समझता है कि अतिरेक अपर्याप्त है, तो यह तुरंत अन्य संग्रहण के टुकड़ों से एक नया नोड एकत्र करना शुरू कर देता है।

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

कोई भी लेन-देन संभावित रूप से संघर्ष का स्रोत बन सकता है, और फिर इसे वापस रोल करना होगा। इसलिए, गति के लिए, जब तक प्रतिबद्ध कमांड नहीं आती है, तब तक रैम में वर्तमान परिवर्तनों को रखने के लिए समझ में आता है, और डिस्क पर नहीं। मान लीजिए कि आप डेटाबेस में 1GB / सेकंड के लोड के साथ डेटा लिख ​​रहे हैं। फिर, एक चरम मामले में, आपका क्लस्टर हर सेकंड 3 जीबी रैम आवंटित करेगा (हम 3 मशीनों पर लेनदेन लिखते हैं)। इस तरह के हिमस्खलन जैसी उपयोग की गई मेमोरी को कैसे सीमित करें? अधिकतम लेन-देन के समय को सीमित करना बहुत सरल है। FoundationDB में, एक लेनदेन 5 सेकंड से अधिक नहीं रह सकता है। यदि लेन-देन के खुलने के बाद क्लाइंट डेटाबेस में 5 सेकंड का उपयोग करने की कोशिश करता है, तो क्लस्टर अपने सभी आदेशों को अनदेखा कर देगा जब तक कि यह एक नया खोल नहीं देता।

सूचकांक

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

कुंजी	मूल्य
12345	(इवानोव इवान इवानोविच, एम, 35)

उन सभी लोगों की सूची कैसे प्राप्त करें जो बिना थकाऊ खोज के 30 साल के हैं? आमतौर पर, इसके लिए डेटाबेस में एक इंडेक्स बनाया जाता है। एक सूचकांक एक और डेटा दृश्य है जो अतिरिक्त विशेषताओं के लिए जल्दी से खोज करने के लिए बनाया गया है। हम केवल फॉर्म की प्रविष्टियाँ जोड़ सकते हैं:

कुंजी	मूल्य
(35, 12345)	''

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

यह महत्वपूर्ण है कि रिकॉर्ड को जोड़ने का कार्य और इसके सूचकांक को एक लेनदेन में किया जाता है।

विश्वसनीयता

FoundationDB C ++ में लिखा गया है। लेखकों ने 2009 में इस पर काम करना शुरू किया, पहला संस्करण 2013 में जारी किया गया था, और मार्च 2015 में, ऐप्पल ने उन्हें खरीदा था। तीन साल बाद, Apple ने अप्रत्याशित रूप से स्रोत कोड खोला। अफवाह यह है कि Apple इसका उपयोग, अन्य चीजों के अलावा, iCloud सेवा डेटा को स्टोर करने के लिए करता है।

अनुभवी डेवलपर्स आमतौर पर नए समाधानों पर तुरंत भरोसा नहीं करते हैं। प्रौद्योगिकी को मज़बूती से स्थापित करने में कई साल लग सकते हैं और यह बड़े पैमाने पर उत्पादों में बड़े पैमाने पर इस्तेमाल होने लगता है। इस समय को कम करने के लिए, लेखकों ने C ++: Flow भाषा का एक दिलचस्प विस्तार किया। यह आपको कार्यक्रम के निष्पादन की पूर्ण पूर्वानुमेय पुनरावृत्ति की संभावना के साथ अविश्वसनीय रूप से बाहरी घटकों के साथ काम करने की अनुमति देता है। नेटवर्क या डिस्क पर प्रत्येक कॉल कुछ आवरण (अभिनेता) में लिपटी है, और प्रत्येक अभिनेता के पास कई कार्यान्वयन हैं। मानक कार्यान्वयन इरादा के अनुसार डिस्क या नेटवर्क पर डेटा लिखते हैं। और दूसरा 1000 में से 999 बार डिस्क को लिखता है, और 1000 में से 1 बार खो देता है। एक वैकल्पिक नेटवर्क कार्यान्वयन, उदाहरण के लिए, नेटवर्क पैकेट में बाइट्स स्वैप कर सकता है। यहां तक ​​कि ऐसे अभिनेता भी हैं जो एक लापरवाह सिस्टम व्यवस्थापक के काम की नकल करते हैं। यह डेटा फ़ोल्डर को हटा सकता है या दो फ़ोल्डरों को स्वैप कर सकता है। डेवलपर्स हजारों सिमुलेशन चलाते हैं , विभिन्न अभिनेताओं को प्रतिस्थापित करते हैं, और फ़्लो का उपयोग करके 100% प्रजनन क्षमता प्राप्त करते हैं: यदि कुछ परीक्षण विफल हो जाते हैं, तो वे सिमुलेशन को फिर से शुरू कर सकते हैं और उसी स्थान पर एक दुर्घटना प्राप्त कर सकते हैं। विशेष रूप से, थ्रेड स्विच करने वाले ओएस अनुसूचक द्वारा शुरू की गई अनिश्चितता को खत्म करने के लिए, प्रत्येक फाउंडेशनडीबी प्रक्रिया सख्ती से एकल-थ्रेडेड है।

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

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

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

प्रतिबंध

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

• क्वेरी भाषा SQL नहीं है, अर्थात, SQL अनुभव वाले डेवलपर्स को फिर से भरना होगा।
  
• क्लाइंट लाइब्रेरी केवल 5 उच्च-स्तरीय भाषाओं (फाइटन, रूबी, जावा, गोलंग और सी) का समर्थन करती है। C # के लिए अभी तक कोई आधिकारिक क्लाइंट नहीं है। चूंकि कोई REST API नहीं है, इसलिए किसी अन्य भाषा का समर्थन करने का एकमात्र तरीका मानक C लाइब्रेरी के ऊपर उस पर एक आवरण लिखना है।
  
• कोई साझाकरण तंत्र नहीं हैं, यह सभी तर्क आपके आवेदन द्वारा प्रदान किए जाने चाहिए।
  
• डेटा स्टोरेज प्रारूप का दस्तावेजीकरण नहीं किया गया है (हालाँकि यह आमतौर पर वाणिज्यिक डेटाबेस में भी प्रलेखित नहीं है)। यह एक जोखिम है, क्योंकि अगर अचानक क्लस्टर इकट्ठा नहीं होता है, तो यह तुरंत स्पष्ट नहीं है कि क्या करना है और स्रोत फ़ाइलों में तल्लीन करना होगा।
  
• एक सख्ती से अतुल्यकालिक प्रोग्रामिंग मॉडल नौसिखिए डेवलपर्स के लिए जटिल लग सकता है।
  
• आपको लेन-देन की बेवकूफी के बारे में लगातार सोचने की जरूरत है।
  
• यदि आपको लंबे लेनदेन को छोटे लोगों में तोड़ना है, तो आपको स्वयं वैश्विक स्तर पर ईमानदारी का ध्यान रखना होगा।
  

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

आज तक, Apple ने FoundationDB के शीर्ष पर 2 परतें विकसित और प्रकाशित की हैं: डॉक्यूमेंट लेयर (MongoDB API का समर्थन करता है) और रिकॉर्ड लेयर ( प्रोटोकॉल बफर में फ़ील्ड सेट के रूप में रिकॉर्ड रिकॉर्ड करता है, इंडेक्स का समर्थन करता है, केवल जावा में उपलब्ध है)। यह सुखद और सुखद आश्चर्य की बात है कि Apple की ऐतिहासिक रूप से बंद कंपनी आज Google और Microsoft के नक्शेकदम पर चलती है और अंदर उपयोग की जाने वाली प्रौद्योगिकियों के स्रोत कोड को प्रकाशित करती है।

संभावनाओं

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

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