डीबीए बॉट जो। अनातोली स्टैंसलर (Postgres.ai)

एक बैकएंड डेवलपर कैसे समझता है कि एक SQL क्वेरी "उत्पाद" पर अच्छा काम करेगी? बड़ी या तेजी से बढ़ती कंपनियों में, हर किसी के पास "उत्पाद" तक पहुंच नहीं होती है। और पहुंच के साथ, सभी अनुरोधों को दर्द रहित तरीके से जांचा नहीं जा सकता है, और डेटाबेस की एक प्रति बनाने में अक्सर घंटों लग जाते हैं। इन समस्याओं को हल करने के लिए, हमने एक कृत्रिम डीबीए - जो बनाया। इसे पहले ही कई कंपनियों में सफलतापूर्वक लागू किया जा चुका है और एक दर्जन से अधिक डेवलपर्स को मदद मिलती है।

वीडियो:

नमस्ते! मेरा नाम अनातोली स्टैंसलर है। मैं एक कंपनी के लिए काम करता हूं पोस्टग्रेस.एआई. हम डेवलपर्स, डीबीए और क्यूए से पोस्टग्रेज के काम से जुड़ी देरी को दूर करके विकास प्रक्रिया को तेज करने के लिए प्रतिबद्ध हैं।

हमारे पास बहुत अच्छे ग्राहक हैं और आज रिपोर्ट का कुछ हिस्सा उन मामलों पर केंद्रित होगा जो हमें उनके साथ काम करते समय मिले थे। मैं इस बारे में बात करूंगा कि कैसे हमने उन्हें काफी गंभीर समस्याओं को हल करने में मदद की।

जब हम विकसित हो रहे हैं और जटिल उच्च-भार वाले माइग्रेशन कर रहे हैं, तो हम खुद से सवाल पूछते हैं: "क्या यह माइग्रेशन आगे बढ़ेगा?" हम समीक्षा का उपयोग करते हैं, हम अधिक अनुभवी सहयोगियों, डीबीए विशेषज्ञों के ज्ञान का उपयोग करते हैं। और वे कह सकते हैं कि यह उड़ेगा या नहीं.

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

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

पहला दृष्टिकोण उत्पाद में परीक्षण करना है। या, जब कोई डेवलपर स्थानीय मशीन पर बैठता है, तो उसके पास परीक्षण डेटा होता है, किसी प्रकार का सीमित चयन होता है। और हम उत्पादन के लिए आगे बढ़ते हैं, और हमें यह स्थिति मिलती है।

यह दुखदायी है, यह महँगा है। संभवतः ऐसा न करना ही सर्वोत्तम है।

और इसे करने का सबसे अच्छा तरीका क्या है?

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

यह हमें कुछ त्रुटियों को दूर करने की अनुमति देगा, यानी उन्हें उत्पादन में आने से रोकेगा।

क्या समस्याएं हैं?

• समस्या यह है कि हम इस स्टेजिंग को सहकर्मियों के साथ साझा करते हैं। और बहुत बार ऐसा होता है कि आप किसी प्रकार का परिवर्तन करते हैं, बाम - और कोई डेटा नहीं है, काम बेकार हो जाता है। स्टेजिंग मल्टी-टेराबाइट थी। और इसके फिर से उभरने के लिए आपको लंबा इंतजार करना होगा। और हम कल इसे अंतिम रूप देने का निर्णय लेते हैं। बस, हमारा विकास है।
• और, निःसंदेह, हमारे कई सहयोगी, कई टीमें वहां काम कर रही हैं। और इसे मैन्युअल रूप से करना होगा. और यह असुविधाजनक है.

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

यह पिछले दृष्टिकोण से बेहतर है, लेकिन अभी भी उच्च संभावना है कि उत्पादन में किसी प्रकार की त्रुटि होगी।

हमें प्रत्येक डेवलपर को एक परीक्षण बेंच, एक पूर्ण आकार की प्रति देने से क्या रोकता है? मुझे लगता है कि यह स्पष्ट है कि रास्ते में क्या आता है।

टेराबाइट से बड़ा डेटाबेस किसके पास है? आधे से ज्यादा कमरा.

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

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

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

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

हम यहाँ क्या कर सकते हैं? आइए टेस्ट बेंच सस्ते बनाएं और प्रत्येक डेवलपर को अपनी टेस्ट बेंच दें।

और यह संभव है।

और इस दृष्टिकोण में, जब हम प्रत्येक डेवलपर के लिए पतले क्लोन बनाते हैं, तो हम इसे एक मशीन पर साझा कर सकते हैं। उदाहरण के लिए, यदि आपके पास 10TB डेटाबेस है और आप इसे 10 डेवलपर्स को देना चाहते हैं, तो आपके पास XNUMX x XNUMXTB डेटाबेस होना आवश्यक नहीं है। आपको एक मशीन का उपयोग करके प्रत्येक डेवलपर के लिए पतली पृथक प्रतियां बनाने के लिए केवल एक मशीन की आवश्यकता है। मैं आपको थोड़ी देर बाद बताऊंगा कि यह कैसे काम करता है।

वास्तविक उदाहरण:

• डीबी - 4,5 टेराबाइट्स।

• हम 30 सेकंड में स्वतंत्र प्रतियां प्राप्त कर सकते हैं।

आपको टेस्ट स्टैंड के लिए इंतजार करने की जरूरत नहीं है और न ही इस पर निर्भर रहने की जरूरत है कि यह कितना बड़ा है। आप इसे सेकंडों में प्राप्त कर सकते हैं. यह पूरी तरह से अलग-थलग वातावरण होगा, लेकिन जो आपस में डेटा साझा करते हैं।

यह भी खूब रही। यहां हम जादू और समानांतर ब्रह्मांड के बारे में बात कर रहे हैं।

हमारे मामले में, यह OpenZFS प्रणाली का उपयोग करके काम करता है।

OpenZFS एक कॉपी-ऑन-राइट फ़ाइल सिस्टम है जो बॉक्स से बाहर स्नैपशॉट और क्लोन का समर्थन करता है। यह विश्वसनीय और स्केलेबल है. उसे मैनेज करना बहुत आसान है. इसे वस्तुतः दो टीमों में तैनात किया जा सकता है।

अन्य विकल्प भी हैं:

• एलवीएम,

• भंडारण (उदाहरण के लिए, शुद्ध भंडारण)।

मैं जिस डेटाबेस लैब की बात कर रहा हूं वह मॉड्यूलर है। इन विकल्पों का उपयोग करके कार्यान्वित किया जा सकता है। लेकिन अभी के लिए, हमने OpenZFS पर ध्यान केंद्रित किया है, क्योंकि विशेष रूप से LVM के साथ समस्याएं थीं।

यह काम किस प्रकार करता है? हर बार जब हम डेटा बदलते हैं तो उसे दोबारा लिखने के बजाय, हम इसे केवल यह चिह्नित करके सहेजते हैं कि यह नया डेटा समय के एक नए बिंदु, एक नए स्नैपशॉट से है।

और भविष्य में, जब हम रोलबैक करना चाहते हैं या हम किसी पुराने संस्करण से एक नया क्लोन बनाना चाहते हैं, तो हम बस इतना कहते हैं: "ठीक है, हमें डेटा के ये ब्लॉक दें जो इस तरह चिह्नित हैं।"

और यह उपयोगकर्ता ऐसे डेटा सेट के साथ काम करेगा। वह धीरे-धीरे उन्हें बदल देगा, अपने स्नैपशॉट बना लेगा।

और हम शाखा लगाएंगे. हमारे मामले में प्रत्येक डेवलपर के पास अपना स्वयं का क्लोन रखने का अवसर होगा जिसे वह संपादित करेगा, और जो डेटा साझा किया जाएगा वह सभी के बीच साझा किया जाएगा।

घर पर ऐसी प्रणाली को तैनात करने के लिए, आपको दो समस्याओं को हल करने की आवश्यकता है:

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

• दूसरा वह स्थान है जहां आप डेटाबेस लैब होस्ट करना चाहते हैं। यह क्लाउड हो सकता है, यह ऑन-प्रिमाइसेस हो सकता है। यहां यह कहना जरूरी है कि ZFS डेटा कंप्रेशन को सपोर्ट करता है। और यह इसे काफी अच्छे से करता है।

कल्पना करें कि ऐसे प्रत्येक क्लोन के लिए, हम आधार के साथ जो ऑपरेशन करते हैं, उसके आधार पर, किसी प्रकार का विकास बढ़ेगा। इसके लिए देव को जगह की भी जरूरत होगी. लेकिन इस तथ्य के कारण कि हमने 4,5 टेराबाइट्स का आधार लिया, ZFS इसे 3,5 टेराबाइट्स तक संपीड़ित कर देगा। यह सेटिंग्स के आधार पर भिन्न हो सकता है। और हमारे पास अभी भी देव के लिए जगह है।

ऐसी प्रणाली का उपयोग विभिन्न मामलों के लिए किया जा सकता है।

• ये डेवलपर हैं, क्वेरी सत्यापन के लिए, अनुकूलन के लिए डीबीए।

• इसका उपयोग QA परीक्षण में किसी विशेष माइग्रेशन का परीक्षण करने के लिए किया जा सकता है, इससे पहले कि हम इसे उत्पाद में रोल आउट करें। और हम वास्तविक डेटा के साथ QA के लिए विशेष वातावरण भी बना सकते हैं, जहां वे नई कार्यक्षमता का परीक्षण कर सकते हैं। और इसमें घंटों प्रतीक्षा करने के बजाय कुछ सेकंड लगेंगे, और कुछ अन्य मामलों में जहां पतली प्रतियों का उपयोग नहीं किया जाता है, इसमें कुछ दिन भी लग सकते हैं।

• और एक और मामला. यदि कंपनी के पास एनालिटिक्स सिस्टम सेटअप नहीं है, तो हम उत्पाद आधार का एक पतला क्लोन अलग कर सकते हैं और इसे लंबे प्रश्नों या विशेष इंडेक्स में दे सकते हैं जिनका उपयोग एनालिटिक्स में किया जा सकता है।

इस दृष्टिकोण के साथ:

1. "उत्पाद" पर त्रुटियों की कम संभावना, क्योंकि हमने पूर्ण आकार के डेटा पर सभी परिवर्तनों का परीक्षण किया।

2. हमारे यहां परीक्षण की संस्कृति है, क्योंकि अब आपको अपने पक्ष के लिए घंटों इंतजार नहीं करना पड़ता।

3. और परीक्षणों के बीच कोई बाधा नहीं है, कोई प्रतीक्षा नहीं है। आप वास्तव में जाकर जांच कर सकते हैं। और यह इस तरह से बेहतर होगा क्योंकि हम विकास को गति देंगे।

• रिफैक्टरिंग कम होगी. उत्पाद में कम बग समाप्त होंगे। हम उन्हें बाद में कम रिफैक्टर करेंगे।

• हम अपरिवर्तनीय परिवर्तनों को उलट सकते हैं। यह मानक दृष्टिकोण नहीं है.

1. यह फायदेमंद है क्योंकि हम परीक्षण बेंचों के संसाधनों को साझा करते हैं।

पहले से ही अच्छा है, लेकिन और क्या तेज़ किया जा सकता है?

ऐसी प्रणाली के लिए धन्यवाद, हम ऐसे परीक्षण में प्रवेश के लिए सीमा को काफी कम कर सकते हैं।

अब एक दुष्चक्र है, जब एक डेवलपर को वास्तविक पूर्ण आकार के डेटा तक पहुंच प्राप्त करने के लिए एक विशेषज्ञ बनना होगा। ऐसी पहुंच के लिए उस पर भरोसा किया जाना चाहिए।'

लेकिन अगर यह है ही नहीं तो कैसे बढ़ें. लेकिन क्या होगा यदि आपके पास परीक्षण डेटा का केवल एक बहुत छोटा सेट उपलब्ध हो? तब आपको कोई वास्तविक अनुभव नहीं मिलेगा.

इस घेरे से बाहर कैसे निकला जाए? किसी भी स्तर के डेवलपर्स के लिए सुविधाजनक पहले इंटरफ़ेस के रूप में, हमने स्लैक बॉट को चुना। लेकिन यह कोई अन्य इंटरफ़ेस भी हो सकता है.

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

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

लेकिन निस्संदेह, समस्याएं हैं। क्योंकि यह वास्तविक दुनिया है, और हम एक साथ कई क्लोन होस्ट करने वाले सर्वर का उपयोग कर रहे हैं, हमें क्लोन के लिए उपलब्ध मेमोरी और सीपीयू पावर की मात्रा को संपीड़ित करना होगा।

लेकिन इन परीक्षणों के विश्वसनीय होने के लिए, आपको किसी तरह इस समस्या को हल करने की आवश्यकता है।

साफ है कि अहम बात वही डेटा है. लेकिन हमारे पास यह पहले से ही है. और हम वही कॉन्फ़िगरेशन हासिल करना चाहते हैं। और हम ऐसा लगभग समान विन्यास दे सकते हैं।

उत्पादन के समान हार्डवेयर रखना अच्छा होगा, लेकिन यह भिन्न हो सकता है।

आइए याद रखें कि पोस्टग्रेज मेमोरी के साथ कैसे काम करता है। हमारे पास दो कैश हैं. एक फ़ाइल सिस्टम से और एक देशी पोस्टग्रेज़, यानी साझा बफ़र कैश।

यह ध्यान रखना महत्वपूर्ण है कि पोस्टग्रेज़ शुरू होने पर साझा बफ़र कैश आवंटित किया जाता है, यह इस पर निर्भर करता है कि आपने कॉन्फ़िगरेशन में कौन सा आकार निर्दिष्ट किया है।

और दूसरा कैश सभी उपलब्ध स्थान का उपयोग करता है।

और जब हम एक मशीन पर कई क्लोन बनाते हैं, तो पता चलता है कि हम धीरे-धीरे मेमोरी भरते हैं। और एक अच्छे तरीके से, शेयर्ड बफ़र कैश मशीन पर उपलब्ध मेमोरी की कुल मात्रा का 25% है।

और यह पता चला है कि यदि हम इस पैरामीटर को नहीं बदलते हैं, तो हम एक मशीन पर केवल 4 उदाहरण चला पाएंगे, यानी ऐसे सभी पतले क्लोनों में से 4। और यह निस्संदेह बुरा है, क्योंकि हम उनमें से बहुत कुछ पाना चाहते हैं।

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

उदाहरण के लिए, यदि हमारे उत्पाद पर बड़ा कैश है, तो पोस्टग्रेज़ एक इंडेक्स का उपयोग करना पसंद करेगा। और यदि नहीं, तो SeqScan होगा. और अगर हमारी योजनाएँ मेल नहीं खातीं तो क्या मतलब होगा?

लेकिन यहां हम इस निष्कर्ष पर पहुंचे हैं कि वास्तव में पोस्टग्रेज में योजना योजना में साझा बफर में निर्दिष्ट विशिष्ट आकार पर निर्भर नहीं करती है, यह प्रभावी_कैश_साइज पर निर्भर करती है।

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

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

लेकिन इससे समय पर असर पड़ सकता है. और हम समय के आधार पर प्रश्नों को अनुकूलित करते हैं, लेकिन यह महत्वपूर्ण है कि समय कई कारकों पर निर्भर करता है:

• यह उस लोड पर निर्भर करता है जो वर्तमान में उत्पाद पर है।

• यह मशीन की विशेषताओं पर ही निर्भर करता है।

और यह एक अप्रत्यक्ष पैरामीटर है, लेकिन वास्तव में हम परिणाम प्राप्त करने के लिए इस क्वेरी द्वारा पढ़े जाने वाले डेटा की मात्रा को ठीक से अनुकूलित कर सकते हैं।

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

आइए देखें कि जो को विशेष रूप से कैसे अनुकूलित किया गया है।

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

हम चैनल को एक संदेश लिख रहे हैं, हमारे लिए एक क्लोन तैनात किया गया है। और हम देखेंगे कि ऐसा अनुरोध 2,5 मिनट में पूरा हो जाएगा। यह पहली चीज़ है जिस पर हम ध्यान देते हैं।

बी जो आपको योजना और मेट्रिक्स के आधार पर स्वचालित अनुशंसाएँ दिखाएगा।

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

आइए विस्तार से देखें कि क्या हुआ। दरअसल, हम देखते हैं कि हमने फ़ाइल कैश या यहां तक ​​कि डिस्क से लगभग डेढ़ गीगाबाइट डेटा पढ़ा है। और यह अच्छा नहीं है, क्योंकि हमें केवल 142 पंक्तियाँ मिलीं।

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

और योजना में ऐसा इस तथ्य के कारण हुआ कि क्वेरी में स्थितियाँ और सूचकांक में स्थितियाँ आंशिक रूप से मेल नहीं खातीं।

आइए सूचकांक को अधिक सटीक बनाने का प्रयास करें और देखें कि उसके बाद क्वेरी निष्पादन कैसे बदलता है।

सूचकांक के निर्माण में काफी लंबा समय लगा, लेकिन अब हम क्वेरी की जांच करते हैं और देखते हैं कि समय 2,5 मिनट के बजाय केवल 156 मिलीसेकंड है, जो काफी अच्छा है। और हम केवल 6 मेगाबाइट डेटा पढ़ते हैं।

और अब हम केवल इंडेक्स स्कैन का उपयोग करते हैं।

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

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

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

निःसंदेह, हर कोई explore.depesz.com को जानता है। इस विज़ुअलाइज़ेशन की एक अच्छी विशेषता यह है कि हम टेक्स्ट प्लान को सहेजते हैं और कुछ बुनियादी मापदंडों को एक तालिका में भी डालते हैं ताकि हम सॉर्ट कर सकें।

और जिन डेवलपर्स ने अभी तक इस विषय पर गहराई से विचार नहीं किया है, वे भी explore.depesz.com का उपयोग करते हैं, क्योंकि उनके लिए यह पता लगाना आसान होता है कि कौन से मेट्रिक्स महत्वपूर्ण हैं और कौन से नहीं।

विज़ुअलाइज़ेशन के लिए एक नया दृष्टिकोण है - यह explore.dalibo.com है। वे एक वृक्ष विज़ुअलाइज़ेशन करते हैं, लेकिन नोड्स की एक दूसरे से तुलना करना बहुत कठिन है। यहां आप स्ट्रक्चर को अच्छे से समझ सकते हैं, हालांकि अगर कोई बड़ी रिक्वेस्ट है तो आपको आगे-पीछे स्क्रॉल करने की जरूरत होगी, लेकिन एक विकल्प भी होगा।

सहयोग

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

हमें ऐसा लगता है कि पूर्ण आकार के डेटा पर परीक्षण करना महत्वपूर्ण है। ऐसा करने के लिए, हमने अपडेट डेटाबेस लैब टूल बनाया, जो ओपन सोर्स में उपलब्ध है। आप जो बॉट का भी उपयोग कर सकते हैं. आप इसे अभी ले सकते हैं और अपने यहां लागू कर सकते हैं. वहां सभी गाइड उपलब्ध हैं.

यह भी ध्यान रखना महत्वपूर्ण है कि समाधान स्वयं क्रांतिकारी नहीं है, क्योंकि डेल्फ़िक्स है, लेकिन यह एक उद्यम समाधान है। यह पूरी तरह से बंद है, यह बहुत महंगा है. हम विशेष रूप से पोस्टग्रेज़ में विशेषज्ञ हैं। ये सभी ओपन सोर्स उत्पाद हैं। हमसे जुड़ें!

यहीं पर मैं समाप्त करता हूं। धन्यवाद!

सवाल

नमस्ते! रिपोर्ट के लिए धन्यवाद! बहुत दिलचस्प, विशेषकर मेरे लिए, क्योंकि मैंने कुछ समय पहले इसी समस्या का समाधान किया था। और इसलिए मेरे पास कई प्रश्न हैं। उम्मीद है मुझे इसका कम से कम कुछ हिस्सा तो मिलेगा.

मुझे आश्चर्य है कि आप इस वातावरण के लिए स्थान की गणना कैसे करते हैं? प्रौद्योगिकी का अर्थ है कि कुछ परिस्थितियों में, आपके क्लोन अधिकतम आकार तक बढ़ सकते हैं। मोटे तौर पर कहें तो, यदि आपके पास दस टेराबाइट डेटाबेस और 10 क्लोन हैं, तो ऐसी स्थिति का अनुकरण करना आसान है जहां प्रत्येक क्लोन का वजन 10 अद्वितीय डेटा होता है। आप इस स्थान की गणना कैसे करते हैं, अर्थात्, वह डेल्टा जिसके बारे में आपने बात की थी, जिसमें ये क्लोन रहेंगे?

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

हाँ, मेरे पास एक नेस्टेड प्रश्न है। अर्थात्, आप इन मॉड्यूलों का जीवन चक्र कैसे सुनिश्चित करते हैं? हमारे पास यह समस्या है और एक पूरी अलग कहानी है। ये कैसे होता है?

प्रत्येक क्लोन के लिए कुछ टीटीएल है। मूलतः, हमारे पास एक निश्चित टीटीएल है।

रहस्य नहीं तो क्या?

1 घंटा, यानी निष्क्रिय - 1 घंटा। अगर इसका इस्तेमाल नहीं होता तो हम इसे पटक देते हैं. लेकिन यहां कोई आश्चर्य की बात नहीं है, क्योंकि हम क्लोन को सेकंडों में बढ़ा सकते हैं। और अगर आपको दोबारा इसकी जरूरत पड़े तो कृपया.

मुझे प्रौद्योगिकियों के चुनाव में भी दिलचस्पी है, क्योंकि, उदाहरण के लिए, हम किसी न किसी कारण से समानांतर में कई तरीकों का उपयोग करते हैं। ज़ेडएफएस क्यों? आपने एलवीएम का उपयोग क्यों नहीं किया? आपने बताया कि एलवीएम में समस्याएँ थीं। समस्याएँ क्या थीं? मेरी राय में, प्रदर्शन के मामले में सबसे इष्टतम विकल्प भंडारण है।

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

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

निकोलाई समोखावलोव: क्या मैं आगे टिप्पणी कर सकता हूँ? मेरा नाम निकोले है, हम अनातोली के साथ मिलकर काम करते हैं। मैं सहमत हूं कि भंडारण बढ़िया है। और हमारे कुछ ग्राहकों के पास प्योर स्टोरेज आदि है।

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

लेकिन ZFS सभी के लिए उपलब्ध है। डेल्फ़िक्स पहले से ही पर्याप्त है, उनके पास 300 ग्राहक हैं। इनमें से फॉर्च्यून 100 के 50 ग्राहक हैं, यानी उनका लक्ष्य नासा आदि है। अब समय आ गया है कि हर कोई इस तकनीक को प्राप्त कर ले। और इसीलिए हमारे पास एक खुला स्रोत कोर है। हमारे पास एक इंटरफ़ेस भाग है जो खुला स्रोत नहीं है। यह वह मंच है जिसे हम दिखाएंगे।' लेकिन हम चाहते हैं कि यह सभी के लिए सुलभ हो। हम एक क्रांति लाना चाहते हैं ताकि सभी परीक्षक लैपटॉप पर अनुमान लगाना बंद कर दें। हमें SELECT लिखना है और तुरंत देखना है कि यह धीमा है। डीबीए द्वारा आपको इसके बारे में बताने की प्रतीक्षा करना बंद करें। यहीं मुख्य लक्ष्य है. और मुझे लगता है कि हम सब इस पर आएंगे। और हम यह चीज़ हर किसी के खाने के लिए बनाते हैं। इसलिए ZFS, क्योंकि यह हर जगह उपलब्ध होगा। समस्याओं को हल करने और ओपन सोर्स लाइसेंस आदि के लिए समुदाय को धन्यवाद।*

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

और दूसरा सवाल स्टैंड्स की असमानता को लेकर है. मान लीजिए कि मेरे पास यहां ZFS है और सब कुछ अच्छा है, लेकिन उत्पाद पर क्लाइंट के पास ZFS नहीं है, लेकिन उदाहरण के लिए ext4 है। इस मामले में कैसे?

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

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

मेरे दो प्रश्न हैं. ये तो बहुत मस्त चीज़ है. क्या ऐसे मामले सामने आए हैं जहां उत्पादन डेटा महत्वपूर्ण है, जैसे क्रेडिट कार्ड नंबर? क्या पहले से ही कुछ तैयार है या यह कोई अलग कार्य है? और दूसरा प्रश्न - क्या MySQL के लिए ऐसा कुछ है?

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

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

लेकिन चूंकि सिस्टम एक्स्टेंसिबल है, इसलिए इसका उपयोग MySQL के लिए भी किया जा सकता है। और ऐसे उदाहरण हैं. यांडेक्स के पास भी ऐसी ही चीज़ है, लेकिन वे इसे कहीं भी प्रकाशित नहीं करते हैं। वे इसका उपयोग Yandex.Metrica के अंदर करते हैं। और MySQL के बारे में बस एक कहानी है। लेकिन प्रौद्योगिकियाँ वही हैं, ZFS।

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

और मैं तुरंत दूसरा प्रश्न स्टैंड की समानता, योजनाओं की समानता के बारे में पूछूंगा। यह योजना पोस्टग्रेज़ द्वारा एकत्र किए गए आँकड़ों पर भी निर्भर करती है। आपके द्वारा इस समस्या को कैसे हल किया जाएगा?

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

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

हर बार इंडेक्स बनाया जाएगा?

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

जहाँ तक आँकड़ों का प्रश्न है, यदि हम बैकअप से पुनर्स्थापित करते हैं, यदि हम प्रतिकृति बनाते हैं, तो हमारे आँकड़े बिल्कुल समान होंगे। क्योंकि हमारे पास संपूर्ण भौतिक डेटा संरचना है, यानी हम सभी सांख्यिकी मेट्रिक्स के साथ भी डेटा लाएंगे।

यहाँ एक और समस्या है. यदि आप क्लाउड सॉल्यूशन का उपयोग करते हैं, तो वहां केवल लॉजिकल डंप ही उपलब्ध होते हैं, क्योंकि Google, Amazon आपको फिजिकल कॉपी लेने की अनुमति नहीं देते हैं। ऐसी दिक्कत होगी.

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

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

वे नहीं जायेंगे क्योंकि ZFS इसी तरह काम करता है। प्रतिकृति के कारण आने वाले फ़ाइल सिस्टम परिवर्तनों को हम एक थ्रेड में अलग-अलग रख सकते हैं। और उन क्लोनों को रखें जिनका उपयोग डेवलपर्स डेटा के पुराने संस्करणों पर करते हैं। और यह हमारे लिए काम करता है, इसके साथ सब कुछ क्रम में है।

यह पता चला है कि अद्यतन एक अतिरिक्त परत के रूप में होगा, और इस परत के आधार पर सभी नई तस्वीरें पहले ही चली जाएंगी, है ना?

पिछली परतों से जो पिछली प्रतिकृतियों से थीं।

पिछली परतें गिर जाएंगी, लेकिन वे पुरानी परत को संदर्भित करेंगी, और क्या वे अद्यतन में प्राप्त अंतिम परत से नई छवियां लेंगे?

सामान्य तौर पर, हाँ।

फिर परिणामस्वरूप हमारे पास परतों की एक संख्या होगी। और समय के साथ उन्हें संपीड़ित करने की आवश्यकता होगी?

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

नमस्ते, रिपोर्ट के लिए धन्यवाद! जो के बारे में प्रश्न. आपने कहा कि ग्राहक हर किसी को डेटा तक पहुंच नहीं देना चाहता। सच कहें तो अगर किसी व्यक्ति के पास एक्सप्लेन एनालिसिस का रिजल्ट है तो वह डेटा में झांक सकता है।

मै सोने के लिए जाना चाहता हूँ। उदाहरण के लिए, हम लिख सकते हैं: "ईमेल कहां से चुनें = उस तक"। यानी हम डेटा खुद तो नहीं देखेंगे, लेकिन कुछ अप्रत्यक्ष संकेत देख सकते हैं. इसे समझना होगा. लेकिन दूसरी ओर, यह सब वहाँ है। हमारे पास एक लॉग ऑडिट है, हमारे पास अन्य सहयोगियों का नियंत्रण है जो यह भी देखते हैं कि डेवलपर्स क्या कर रहे हैं। और अगर कोई ऐसा करने की कोशिश करता है तो सुरक्षा सेवा उनके पास आएगी और इस मुद्दे पर काम करेगी।

नमस्कार रिपोर्ट के लिए धन्यवाद! मेरा एक छोटा सा प्रश्न है. यदि कंपनी स्लैक का उपयोग नहीं करती है, तो क्या अब इसके लिए कोई बाध्यता है, या क्या डेवलपर्स के लिए परीक्षण एप्लिकेशन को डेटाबेस से कनेक्ट करने के लिए इंस्टेंस तैनात करना संभव है?

अब स्लैक के लिए एक लिंक है, यानी कोई अन्य संदेशवाहक नहीं है, लेकिन मैं वास्तव में अन्य संदेशवाहकों के लिए भी समर्थन बनाना चाहता हूं। आप क्या कर सकते हैं? आप जो के बिना DB लैब को तैनात कर सकते हैं, REST API की मदद से या हमारे प्लेटफ़ॉर्म की मदद से जा सकते हैं और क्लोन बना सकते हैं और PSQL से जुड़ सकते हैं। लेकिन यह तब किया जा सकता है जब आप अपने डेवलपर्स को डेटा तक पहुंच देने के लिए तैयार हों, क्योंकि अब कोई स्क्रीन नहीं होगी।

मुझे इस परत की आवश्यकता नहीं है, लेकिन मुझे ऐसे अवसर की आवश्यकता है।

तो हाँ, यह किया जा सकता है।

स्रोत: www.habr.com