S3 मेटाडेटा PostgreSQL में। यांडेक्स व्याख्यान

यह डेटाबेस पर जे। सुब्बोटनिक के साथ दूसरा व्याख्यान है - पहला हमने कुछ हफ़्ते पहले प्रकाशित किया था।

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


- सभी को नमस्कार! मेरा नाम दीमा है, यैंडेक्स में मैं डेटाबेस करता हूं। मैं आपको बताता हूं कि हमने S3 कैसे किया, हम S3 कैसे करते हैं, और किस तरह का भंडारण पहले हुआ था। उनमें से पहला है एलिप्टिक्स, यह खुले स्रोत में पोस्ट किया गया है, जो गीथहब पर उपलब्ध है। कई लोग इसके पार आ गए होंगे।

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

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

हम और आगे जा रहे हैं। पुनर्संतुलन की समस्याएं काफी गंभीर थीं, इसलिए अगला भंडारण दिखाई दिया।

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

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

फिर हम S3 को देखने लगे। यह कुंजी-मूल्य भंडारण है, ग्राहक कुंजी का प्रबंधन करता है, पूरे भंडारण को तथाकथित बाल्टी में विभाजित किया जाता है। प्रत्येक बाल्टी में, मुख्य स्थान माइनस इनफिनिटी से प्लस इन्फिनिटी तक है। कुंजी किसी प्रकार का पाठ स्ट्रिंग है। और हम इस पर, इस विकल्प पर बसे। क्यों S3?

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

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

एक निश्चित इकाई है, यहां इसे प्रॉक्सी कहा जाता है, तथाकथित बैकेंड। वह फ़ाइल को स्वीकार करता है, इसे स्टोरेज पर अपलोड करता है, वहां से कुंजी प्राप्त करता है और इसे डेटाबेस में बचाता है। सब कुछ काफी सरल है।

रसीद कैसी है? प्रॉक्सी डेटाबेस में आवश्यक कुंजी पाता है, स्टोरेज की कुंजी के साथ जाता है, वहां से ऑब्जेक्ट डाउनलोड करता है, क्लाइंट को देता है। सब कुछ सरल भी है।

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

हमने इस मेटाबेस के डेटाबेस के रूप में PostgreSQL को चुना।

आप पहले से ही जानते हैं कि हम उससे बहुत प्यार करते हैं। Yandex.Mail के स्थानांतरण के साथ, हमने PostgreSQL में पर्याप्त विशेषज्ञता प्राप्त की, और जब विभिन्न मेल सेवाओं को स्थानांतरित किया गया, तो हमने कई तथाकथित शार्किंग पैटर्न विकसित किए। उनमें से एक मामूली संशोधनों के साथ एस 3 पर अच्छी तरह से गिर गया, लेकिन यह वहां अच्छी तरह से चला गया।

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

अगला विकल्प, आप बाल्टी की ओर से हैश या आईडी से शार्द कर सकते हैं। एक डेटाबेस शार्क के अंदर एक बाल्टी रह सकता है।

एक अन्य विकल्प प्रमुख सीमाओं के पार शार्क है। बाल्टी के अंदर, माइनस इनफिनिटी से लेकर प्लस इनफिनिटी तक की जगह होती है, हम इसे किसी भी रेंज में बाँट सकते हैं, इस रेंज को हम चंक कहते हैं, यह केवल एक ही हिस्से में रह सकती है।

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

क्या हुआ था? पूरे डेटाबेस में तीन घटक होते हैं। S3 प्रॉक्सी - मेजबानों का एक समूह, एक डेटाबेस भी है। पीएल / प्रॉक्सी बैलेंसर के तहत हैं, उस बैकएंड से अनुरोध वहां उड़ते हैं। इसके अलावा S3Meta, बास का ऐसा समूह, जो बाल्टियों और चूजों के बारे में जानकारी संग्रहीत करता है। और S3DB, जहां वस्तुओं को संग्रहित किया जाता है, उन्हें हटा दें। यदि योजनाबद्ध तरीके से चित्रित किया गया है, तो यह इस तरह दिखता है।

S3Proxy के लिए एक अनुरोध आता है, यह S3Meta और S3DB पर जाता है और शीर्ष पर सूचना जारी करता है।

आइए अधिक विस्तार से विचार करें। S3Proxy, इसके अंदर के कार्य प्रक्रियात्मक भाषा PLProxy में बनाए गए हैं, यह ऐसी भाषा है जो आपको दूरस्थ रूप से संग्रहीत प्रक्रियाओं या अनुरोधों को निष्पादित करने की अनुमति देती है। यह है कि ObjectInfo फ़ंक्शन का कोड कैसा दिखता है, संक्षेप में, एक अनुरोध प्राप्त करें।

LProxy क्लस्टर में क्लस्टर ऑपरेटर है, इस मामले में db_ro। इसका क्या मतलब है?

यदि एक सामान्य डेटाबेस शार्प कॉन्फ़िगरेशन है, तो एक मास्टर और दो प्रतिकृतियां हैं। मास्टर db_rw क्लस्टर में प्रवेश करता है, सभी तीन होस्ट db-ro में प्रवेश करते हैं, यह वह जगह है जहां आप केवल एक अनुरोध पढ़ सकते हैं, और एक लिखित अनुरोध db_rw को भेजा जाता है। Db_rw क्लस्टर में सभी शार्क के सभी स्वामी शामिल हैं।

अगले RUN ON स्टेटमेंट में, यह या तो सभी का मूल्य लेता है, जिसका अर्थ है कि सभी शार्क पर या तो किसी सरणी या किसी प्रकार के शार्क पर अमल करना। इस स्थिति में, यह इनपुट के रूप में get_object_shard फ़ंक्शन का परिणाम प्राप्त करता है; यह उस शार्ड की संख्या है जिस पर दिए गए ऑब्जेक्ट निहित हैं।

और टारगेट - जिसे रिमोट शार्द पर कॉल करना है। वह इस फ़ंक्शन को कॉल करेगा और इस फ़ंक्शन में उड़ने वाले तर्कों को प्रतिस्थापित करेगा।

Get_object_shard फ़ंक्शन PLProxy में भी लिखा गया है, जो पहले से ही एक मेटा_रो क्लस्टर है, अनुरोध S3Meta शार्क पर उड़ान भरेगा, जो इस फ़ंक्शन get_bucket_meta_shard को लौटाएगा।

S3Meta को भी तेज किया जा सकता है, हमने इसे भी रखा है, जबकि यह अप्रासंगिक है, लेकिन एक अवसर है। और यह S3Meta पर get_object_shard फ़ंक्शन को कॉल करेगा।

get_bucket_meta_shard एक बाल्टी की ओर से पाठ का एक हैश है, हमने S3Meta को केवल एक बाल्टी की ओर से हैश से बदल दिया है।

S3Meta पर विचार करें कि इसमें क्या हो रहा है। सबसे महत्वपूर्ण जानकारी यह है कि वहाँ एक टेबल है जिसमें विखंडू है। मैंने कुछ अनावश्यक जानकारी को थोड़ा काट दिया, सबसे महत्वपूर्ण बात बकेट_आईडी है, स्टार्ट की, एंड की और शार्द जिसमें यह चंक है।

ऐसी तालिका पर एक क्वेरी क्या दिखती है, जो हमें उस चंक में लौटाएगी, उदाहरण के लिए, परीक्षण वस्तु निहित है? इस तरह। टेक्स्ट रूप में माइनस इनफिनिटी, हमने इसे एक शून्य मान के रूप में प्रस्तुत किया, ऐसे सूक्ष्म बिंदु हैं जिन्हें आपको n_ के लिए start_key और end_key की जांच करने की आवश्यकता है।

अनुरोध बहुत अच्छा नहीं लगता है, और योजना और भी बदतर दिखती है। इस तरह के एक अनुरोध के लिए एक विकल्प के रूप में, BitmapOr। और ऐसी योजना के तहत 6,000 हड्डियां।

यह कोई अलग कैसे हो सकता है? PostgreSQL में जिस्ट इंडेक्स के रूप में एक ऐसी अद्भुत चीज है, जो रेंज प्रकार को इंडेक्स कर सकती है, रेंज अनिवार्य रूप से वह है जो हमें चाहिए। हमने इस प्रकार बनाया, s3.to_keyrange फ़ंक्शन हमें देता है, वास्तव में, रेंज। हम इसमें शामिल ऑपरेटर के साथ जांच कर सकते हैं, यह पता लगाएं कि हमारी कुंजी किस में है। और इसके लिए, यहां अतिक्रमण को बाहर रखा गया है, जो इन चकों के गैर-चौराहे को सुनिश्चित करता है। हमें डेटाबेस स्तर पर, अधिमानतः, कुछ बाधाओं को यह सुनिश्चित करने की अनुमति देने की आवश्यकता है कि चूजे एक-दूसरे के साथ अंतर नहीं कर सकते, ताकि अनुरोध के जवाब में केवल एक पंक्ति वापस आ जाए। अन्यथा, यह वही नहीं होगा जो हम चाहते थे। इस तरह के अनुरोध की योजना सामान्य इंडेक्स_स्कैन लगती है। यह स्थिति पूरी तरह से सूचकांक की स्थिति में फिट होती है, और इस तरह की योजना में केवल 700 हड्डियां होती हैं, 10 गुना कम।

निष्कासन बाधा क्या है?

चलो दो स्तंभों के साथ एक परीक्षण तालिका बनाते हैं, और इसमें दो बाधाएं जोड़ते हैं, एक अद्वितीय जिसे हर कोई जानता है, और एक बाधा को बाहर करता है, जिसमें पैरामीटर समान हैं, ऐसे ऑपरेटर। आइए इसे दो ऑपरेटरों के बराबर सेट करें, इस तरह की एक प्लेट बनाई गई थी।

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

वास्तव में, एक अद्वितीय बाधा समान ऑपरेटरों के साथ अपवर्जित बाधा है, लेकिन अपवर्जित बाधा के मामले में, आप कुछ और सामान्य मामलों का निर्माण कर सकते हैं।

हमारे पास ऐसे सूचकांक हैं। यदि आप बारीकी से देखते हैं, तो आप देखेंगे कि ये दोनों जिस्ट इंडेक्स हैं, और सामान्य तौर पर वे समान हैं। आप शायद पूछते हैं कि इस व्यवसाय की नकल आखिर क्यों। मैं आपको बताऊंगा।

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

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

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

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

जब हमने यह सब किया, तो हमने 9.5 S3DB संस्करण पर शुरू किया, योजना के अनुसार, हमने प्रत्येक शार्क में 10 बिलियन वस्तुओं को ढेर करने की योजना बनाई। जैसा कि आप जानते हैं, 1 बिलियन से अधिक और पहले की समस्याएं तब शुरू होती हैं जब एक टेबल में कई पंक्तियाँ होती हैं, सब कुछ बहुत खराब हो जाता है। बिदाई की प्रथा है। उस समय दो विकल्प थे, या तो विरासत के माध्यम से मानक, लेकिन यह बहुत अच्छी तरह से काम नहीं करता है, क्योंकि एक रैखिक विभाजन चयन गति है। और वस्तुओं की संख्या को देखते हुए, हमें बहुत सारे विभाजन की आवश्यकता है। Postgres Pro के लोगों ने तब सक्रिय रूप से pg_pathman एक्सटेंशन को देखा।

हमने pg_pathman को चुना, हमारे पास और कोई विकल्प नहीं था। यहां तक ​​कि संस्करण 1.4। और जैसा कि आप देख सकते हैं, हम 256 विभाजन का उपयोग करते हैं। हमने वस्तुओं के पूरे टेबल को 256 विभाजनों में तोड़ दिया।

Pg_pathman क्या करता है? इस अभिव्यक्ति का उपयोग करते हुए, आप 256 कॉलम बना सकते हैं जो कि बिड कॉलम से हैश द्वारा विभाजित किए गए हैं।

Pg_pathman कैसे काम करता है?

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

पहली समस्या इसे अपडेट करने में कठिनाई है। दूसरी समस्या तैयार बयान है।

आइए अधिक विस्तार से विचार करें। विशेष रूप से, अद्यतन। Pg_pathman में क्या शामिल है?

इसमें अनिवार्य रूप से C कोड होता है, जिसे लाइब्रेरी में पैक किया जाता है। और इसमें एक SQL भाग, विभाजन बनाने के लिए सभी प्रकार के कार्य शामिल हैं, और इसी तरह। साथ ही, लाइब्रेरी में होने वाले कार्यों के लिए इंटरफेस। इन दो भागों को एक ही समय में अपडेट नहीं किया जा सकता है।

यहाँ से कठिनाइयाँ उत्पन्न होती हैं, pg_pathman के संस्करण को अपडेट करने के लिए यह एल्गोरिथम कुछ इस तरह का है, हम पहले एक नए संस्करण के साथ एक नया पैकेज रोल करते हैं, लेकिन PostgreSQL में पुराने संस्करणों को मेमोरी में लोड किया गया है, यह इसका उपयोग करता है। यह किसी भी मामले में तुरंत है, आधार को फिर से शुरू करना होगा।

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

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

अगली समस्या बयान तैयार की जाती है।

यदि हम समान सामान्य अनुरोध को रोकते हैं, तो बोली और कुंजी द्वारा खोजें, इसे निष्पादित करने का प्रयास करें। पांच बार प्रदर्शन करें - सब ठीक है। हम छठी बाहर ले जाते हैं - हम इस तरह की योजना देखते हैं। और इस संबंध में हम सभी 256 विभाजन देखते हैं। यदि आप इन स्थितियों को करीब से देखते हैं, तो हम डॉलर 1, डॉलर 2 देखते हैं, यह तथाकथित सामान्य योजना है, सामान्य योजना है। पहले पांच प्रश्नों को व्यक्तिगत रूप से बनाया गया था, इन मापदंडों के लिए व्यक्तिगत योजनाओं का उपयोग किया गया था, pg_pathman तुरंत निर्धारित कर सकता था, क्योंकि पैरामीटर पहले से जाना जाता है, यह तुरंत तालिका निर्धारित कर सकता है कि कहां जाना है। इस मामले में, वह ऐसा नहीं कर सकता। तदनुसार, योजना में सभी 256 विभाजन होने चाहिए, और जब निष्पादक ऐसा करने के लिए जाता है, तो वह जाता है और सभी 256 विभाजनों के लिए एक साझा लॉक लेता है, और इस तरह के समाधान का प्रदर्शन अभी ठीक नहीं है। यह बस अपने सभी फायदे खो देता है, और किसी भी अनुरोध को लंबे समय तक किया जाता है।

हम इस स्थिति से कैसे बाहर निकले? मुझे गतिशील एसक्यूएल को निष्पादित करने में संग्रहीत प्रक्रियाओं के अंदर सब कुछ लपेटना पड़ा, ताकि तैयार किए गए बयानों का उपयोग नहीं किया गया और हर बार योजना का निर्माण किया गया। यह कैसे काम करता है

नकारात्मक पक्ष यह है कि आपको इन तालिकाओं को छूने वाली संरचनाओं में सभी कोड को रटना होगा। यहाँ पढ़ना कठिन है।

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

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

जब आप इस बाल्टी में डेटा डालते हैं, तो इस चंक में सभी डेटा डाले जाते हैं, जब एक निश्चित आकार तक पहुँच जाता है, तो एक विशेष रोबोट आता है और इस चंक को साझा करता है।

हम इन चूजों को छोटा करते हैं। हम ऐसा करते हैं कि किस स्थिति में इस छोटे से हिस्से को दूसरे हिस्से में खींचा जा सकता है। कैसे एक छिन्न विभाजन होता है? यहां एक नियमित रोबोट है, यह S3DB में इस चंक को दो-चरण की प्रतिबद्धताओं के साथ जाता है और S3Meta में जानकारी को अपडेट करता है।

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

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

इसका क्या मतलब है? यदि परिधि सेट नहीं है, तो हम देखते हैं कि हमें बस फाइलों की एक सूची दी गई है। यदि हम परिधि को सेट करते हैं, तो संक्षेप में, एस 3 हमें फ़ोल्डर्स दिखाना चाहिए। मुझे यह समझना चाहिए कि ऐसे फ़ोल्डर हैं, और वास्तव में, यह वर्तमान फ़ोल्डर में सभी फ़ोल्डर्स और फ़ाइलों को दिखाता है। वर्तमान फ़ोल्डर उपसर्ग है, यह पैरामीटर अशक्त है। हम देखते हैं कि 10 फ़ोल्डर हैं।

सभी कुंजी किसी प्रकार के पदानुक्रमित वृक्ष संरचना में संग्रहीत नहीं हैं, जैसा कि फ़ाइल सिस्टम में है। प्रत्येक ऑब्जेक्ट को एक स्ट्रिंग के रूप में संग्रहीत किया जाता है, और उनके पास एक सामान्य सामान्य उपसर्ग होता है। S3 को खुद समझना होगा कि यह एक गधा है।

SQL, . , PL/pgSQL. , repeatable read. , . , - - , .

Recursive CTE, , - , execute PL/pgSQL. , . , , , list objects. , .

, .

. , .

Docker, Behave Behave . , , , .

. , , CPU S3Meta. Gist index CPU, , . CPU S3Meta . , . PLProxy , S3Meta S3DB. , . S3Meta . , .

, , . — , range btree. , btree . , , btree. , . PL/pgSQL-. , .