प्रिय डिलीट। निकोले समोखावलोव (पोस्टग्रेज.ई)

सुदूर भविष्य में कभी-कभी, अनावश्यक डेटा को स्वचालित रूप से हटाना DBMS के महत्वपूर्ण कार्यों में से एक होगा [1]। इस बीच, हमें अनावश्यक डेटा को हटाने या कम महंगे स्टोरेज सिस्टम में ले जाने का ध्यान स्वयं रखना होगा। मान लीजिए कि आप कुछ मिलियन पंक्तियाँ हटाने का निर्णय लेते हैं। एक काफी सरल कार्य, खासकर यदि स्थिति ज्ञात हो और एक उपयुक्त सूचकांक हो। "तालिका1 से हटाएं जहां col1 = :मान" - इससे सरल क्या हो सकता है, है ना?

वीडियो:

• मैं हाईलोड कार्यक्रम समिति में पहले वर्ष से, यानी 2007 से हूं।

• और मैं 2005 से पोस्टग्रेज के साथ हूं। कई प्रोजेक्ट्स में इसका इस्तेमाल किया.

• 2007 से RuPostges के साथ समूह भी।

• मीटअप में हमारे प्रतिभागियों की संख्या 2100 से अधिक हो गई है। यह न्यूयॉर्क के बाद दुनिया में दूसरे स्थान पर है, लंबे समय तक सैन फ्रांसिस्को से आगे रहा।

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

https://postgres.ai/ मेरी कंपनी है. हम कार्यों को स्वचालित करने के व्यवसाय में हैं जो विकास संबंधी मंदी को दूर करता है।

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

मैं हाल ही में लॉस एंजिल्स में वीएलडीबी में था। यह डेटाबेस पर सबसे बड़ा सम्मेलन है। और एक रिपोर्ट आई थी कि भविष्य में DBMS न केवल डेटा को स्टोर करेगा, बल्कि स्वचालित रूप से डिलीट भी करेगा। यह एक नया विषय है.

ज़ेटाबाइट्स की दुनिया में अधिक से अधिक डेटा है - यानी 1 पेटाबाइट्स। और अब यह पहले से ही अनुमान लगाया गया है कि हमारे पास दुनिया भर में 000 ज़ेटाबाइट से अधिक डेटा संग्रहीत है। और उनमें से और भी अधिक हैं.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

और इसके साथ क्या करना है? जाहिर है इसे हटाने की जरूरत है. यहां इस दिलचस्प रिपोर्ट का लिंक दिया गया है. लेकिन अभी तक इसे DBMS में लागू नहीं किया गया है.

जो लोग पैसे गिन सकते हैं वे दो चीज़ें चाहते हैं। वे चाहते हैं कि हम हटा दें, इसलिए तकनीकी रूप से हमें ऐसा करने में सक्षम होना चाहिए।

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

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

सामान्य तौर पर, कार्य किसी तालिका में विशिष्ट चीज़ों, विशिष्ट पंक्तियों के विलोपन को स्वचालित करना है।

और हमारी एक ऐसी गुज़ारिश है जिसके बारे में हम आज बात करेंगे यानि कचरा हटाने के बारे में.

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

डेटाबेस बढ़ता है और बढ़ता है। दैनिक DELETE थोड़ा अधिक धीरे-धीरे काम करना शुरू कर देता है।

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

कुछ महीने बाद उन्हें याद आया. और उस डेवलपर ने नौकरी छोड़ दी या किसी और काम में व्यस्त हो गया, उसने दूसरे को इसे वापस करने का निर्देश दिया।

उन्होंने डेव पर, स्टेजिंग पर जाँच की - सब कुछ ठीक है। स्वाभाविक रूप से, आपको अभी भी जो जमा हुआ है उसे साफ़ करने की ज़रूरत है। उसने जाँच की कि सब कुछ काम करता है।

आगे क्या होता है? तब हमारे लिए सब कुछ बिखर जाता है। यह इतना गिर जाता है कि किसी बिंदु पर सब कुछ गिर जाता है। हर कोई सदमे में है, किसी को समझ नहीं आ रहा कि क्या हो रहा है. और फिर पता चला कि मामला इसी DELETE में था.

कुछ गलत हो गया? यहां इसकी एक सूची दी गई है कि क्या गलत हो सकता था। इनमें से कौन सा सबसे महत्वपूर्ण है?

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

• हो सकता है कि उन्होंने कुछ ग़लत चेक किया हो.

• हो सकता है कि हार्डवेयर पुराना हो गया हो और आपको इस आधार को अपग्रेड करने की आवश्यकता हो।

• या डेटाबेस में ही कुछ गड़बड़ है, और हमें Postgres से MySQL पर जाने की आवश्यकता है।

• या हो सकता है कि ऑपरेशन में कुछ गड़बड़ हो.

• हो सकता है कि काम के संगठन में कुछ गलतियाँ हों और आपको किसी को नौकरी से निकालने और सर्वोत्तम लोगों को काम पर रखने की ज़रूरत हो?

कोई डीबीए जांच नहीं थी. यदि कोई डीबीए होता, तो वह इन कई मिलियन पंक्तियों को देखता और बिना किसी प्रयोग के भी कहता: "वे ऐसा नहीं करते।" मान लीजिए कि यदि यह कोड GitLab, GitHub में होता और वहां कोई कोड समीक्षा प्रक्रिया होती और ऐसा नहीं होता कि DBA की मंजूरी के बिना यह ऑपरेशन प्रोड पर होता, तो जाहिर तौर पर DBA कहता: “यह नहीं किया जा सकता है। ”

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

http://bit.ly/nancy-hl2018-2

दूसरी गलती - उन्होंने गलत जगह चेक किया। हमने इस तथ्य के बाद देखा कि उत्पाद पर बहुत सारा जंक डेटा जमा हो गया था, लेकिन डेवलपर के पास इस डेटाबेस में डेटा जमा नहीं था, और स्टेजिंग के दौरान किसी ने भी यह जंक नहीं बनाया था। तदनुसार, 1 पंक्तियाँ ऐसी थीं जिन पर शीघ्रता से कार्य किया गया।

हम समझते हैं कि हमारे परीक्षण कमजोर हैं, यानी जो प्रक्रिया बनाई गई है वह समस्याएं नहीं पकड़ती है। पर्याप्त DB प्रयोग नहीं किया गया.

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

शायद हमारे उपकरण ख़राब हैं? यदि आप देखें, तो विलंबता उछल गई। हमने देखा है कि उपयोग 100% है। बेशक, अगर ये आधुनिक NVMe ड्राइव होते, तो शायद यह हमारे लिए बहुत आसान होता। और शायद हम इससे लेटेंगे नहीं।

अगर आपके पास बादल हैं तो वहां अपग्रेड आसानी से हो जाता है। नए हार्डवेयर पर नई प्रतिकृतियाँ खड़ी कीं। पर स्विच। और सब ठीक है। बहुत आसान।

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

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

पोस्टग्रेज़ में सेटिंग्स पिछड़ रही हैं। इन्हें 10-15 साल पुराने डेटा और लेनदेन के लिए डिज़ाइन किया गया है। और चेकपॉइंट कोई अपवाद नहीं है.

यहां हमारी पोस्टग्रेज चेक-अप रिपोर्ट यानी स्वचालित स्वास्थ्य जांच की जानकारी दी गई है। और यहां कई टेराबाइट्स का कुछ डेटाबेस है। और यह अच्छी तरह से देखा जा सकता है कि लगभग 90% मामलों में मजबूरन चौकियाँ।

इसका मतलब क्या है? वहां दो सेटिंग्स हैं. चेकपॉइंट टाइमआउट पर आ सकता है, उदाहरण के लिए, 10 मिनट पर। या यह तब आ सकता है जब काफी सारा डेटा भर दिया गया हो।

और डिफ़ॉल्ट रूप से max_wal_saze 1 गीगाबाइट पर सेट है। वास्तव में, यह वास्तव में 300-400 मेगाबाइट के बाद पोस्टग्रेज में होता है। आपने इतना डेटा बदल दिया है और आपका चेकपॉइंट होता है।

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

और हमें यह सुनिश्चित करने की ज़रूरत है कि यह कम बार आए। यानी हम max_wal_size बढ़ा सकते हैं। और यह कम बार आएगा.

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

तदनुसार, हम डेटाबेस पर प्रयोगों की दो श्रृंखलाएँ कर रहे हैं।

पहली श्रृंखला - हम max_wal_size बदलते हैं। और हम एक बड़ा ऑपरेशन कर रहे हैं. सबसे पहले, हम इसे 1 गीगाबाइट की डिफ़ॉल्ट सेटिंग पर करते हैं। और हम लाखों पंक्तियों को बड़े पैमाने पर हटाते हैं।

आप देख सकते हैं कि यह हमारे लिए कितना कठिन है। हम देखते हैं कि डिस्क IO बहुत खराब है। हम देखते हैं कि हमने कितने वाल उत्पन्न किए हैं, क्योंकि यह बहुत महत्वपूर्ण है। देखते हैं कितनी बार चौकी हुई। और हम देखते हैं कि यह अच्छा नहीं है.

इसके बाद हम max_wal_size बढ़ाते हैं। हम दोहराते हैं। हम बढ़ाते हैं, हम दोहराते हैं। और बहुत बार. सिद्धांत रूप में, 10 अंक अच्छे हैं, जहां 1, 2, 4, 8 गीगाबाइट। और हम एक विशेष प्रणाली के व्यवहार को देखते हैं। यह स्पष्ट है कि यहां उपकरण उत्पाद जैसा होना चाहिए। आपके पास समान डिस्क, समान मात्रा में मेमोरी और समान पोस्टग्रेज सेटिंग्स होनी चाहिए।

और इस तरह हम अपने सिस्टम का आदान-प्रदान करेंगे, और हम जानते हैं कि खराब मास DELETE की स्थिति में DBMS कैसे व्यवहार करेगा, यह चेकपॉइंट कैसे करेगा।

रूसी में चेकपॉइंट चेकपॉइंट हैं।

उदाहरण: अनुक्रमणिका के अनुसार कई मिलियन पंक्तियाँ हटाएँ, पंक्तियाँ पृष्ठों पर "बिखरी हुई" हैं।

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

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

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

और जहां 64 गीगाबाइट देखा जा सकता है कि यह पूरी तरह से बेहतर हो गया है। पहले से ही दाँत स्पष्ट हैं, अन्य ऑपरेशनों से बचने और डिस्क के साथ कुछ करने के अधिक अवसर हैं।

ऐसा क्यों?

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

यदि चेकपॉइंट बहुत बार होता है, और हम अपनी पंक्तियों को क्रमिक रूप से अपडेट नहीं करते हैं, बल्कि इंडेक्स द्वारा ढूंढते हैं, जो अच्छा है, क्योंकि हम पूरी तालिका को नहीं हटाते हैं, तो ऐसा हो सकता है कि पहले हमने पहले पृष्ठ को छुआ, फिर हजारवें को, और फिर पहले पर लौट आया। और यदि पहले पृष्ठ पर इन विज़िट के बीच, चेकपॉइंट ने इसे पहले ही डिस्क पर सहेज लिया है, तो यह इसे फिर से सहेज लेगा, क्योंकि हमने इसे दूसरी बार गंदा कर दिया है।

और हम चेकपॉइंट को इसे बचाने के लिए कई बार मजबूर करेंगे। उसके लिए फालतू ऑपरेशन कैसे होंगे.

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

फॉरवर्ड लॉग के वाल पर लिखने का व्यवहार ऐसा है कि जब हमारे पास एक चेकपॉइंट होता है और हम पहली बार पेज बदलते हैं, तो पूरा पेज, यानी, सभी 8 किलोबाइट, फॉरवर्ड लॉग में आ जाते हैं, हालांकि हमने केवल बदला है लाइन, जिसका वजन 100 बाइट्स है। और हमें पूरा पेज लिखना है.

बाद के परिवर्तनों में केवल एक विशिष्ट टपल होगा, लेकिन पहली बार हम सब कुछ लिखते हैं।

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

और, तदनुसार, हमारे पास दो अतिरेक हैं।

यदि हम max_wal_size बढ़ाते हैं, तो यह पता चलता है कि हम इसे चेकपॉइंट और वाल राइटर दोनों के लिए आसान बनाते हैं। और यह बहुत अच्छा है.

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

हम एक ऑपरेशन करते हैं और देखते हैं कि जब चेकपॉइंट पूरा होने वाला होता है, तो हम जानबूझकर -9 पोस्टग्रेज को मार देते हैं।

और उसके बाद हम इसे फिर से शुरू करते हैं, और देखते हैं कि यह इस उपकरण पर कितनी देर तक ऊपर उठेगा, यानी इस खराब स्थिति में यह कितना REDO करेगा।

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

हम ऐसी स्थिति को विभिन्न max_wal_size आकारों के लिए मापते हैं और समझते हैं कि यदि max_wal_size 64 गीगाबाइट है, तो दोगुनी सबसे खराब स्थिति में हम 10 मिनट तक चढ़ेंगे। और हम सोचते हैं कि ये हमें सूट करेगा या नहीं. यह एक व्यवसायिक प्रश्न है. हमें व्यावसायिक निर्णयों के लिए जिम्मेदार लोगों को यह तस्वीर दिखानी होगी और पूछना होगा, "किसी समस्या की स्थिति में हम अधिकतम कितनी देर तक लेटे रह सकते हैं?" क्या हम बुरी से बुरी स्थिति में भी 3-5 मिनट तक लेटे रह सकते हैं? और आप निर्णय लें.

और यहाँ एक दिलचस्प बात है. हमारे पास सम्मेलन में पेट्रोनी के बारे में कुछ रिपोर्टें हैं। और हो सकता है कि आप इसका इस्तेमाल कर रहे हों. यह पोस्टग्रेज़ के लिए एक ऑटोफ़ेलओवर है। GitLab और Data Egret ने इस बारे में बात की।

और यदि आपके पास एक ऑटोफ़ेलओवर है जो 30 सेकंड में आता है, तो शायद हम 10 मिनट तक लेटे रह सकते हैं? क्योंकि इस बिंदु तक हम प्रतिकृति पर स्विच कर देंगे, और सब कुछ ठीक हो जाएगा। यह एक विवादास्पद मुद्दा है. मुझे कोई स्पष्ट उत्तर नहीं पता. मुझे बस यही लगता है कि यह विषय केवल क्रैश रिकवरी से संबंधित नहीं है।

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

मैं अभी भी बहुत आगे नहीं जाऊंगा, भले ही हमारे पास ऑटोफ़ेलओवर हो। एक नियम के रूप में, 64, 100 गीगाबाइट जैसे मान अच्छे मान हैं। कभी-कभी यह कम चुनने लायक भी होता है। सामान्यतः यह एक सूक्ष्म विज्ञान है।

पुनरावृत्तियाँ करने के लिए, उदाहरण के लिए, max_wal_size =1, 8, आपको बड़े पैमाने पर ऑपरेशन को कई बार दोहराना होगा। आपने कर दिखाया। और उसी आधार पर आप इसे दोबारा करना चाहते हैं, लेकिन आप पहले ही सब कुछ हटा चुके हैं। क्या करें?

मैं बाद में हमारे समाधान के बारे में बात करूंगा, ऐसी स्थितियों में पुनरावृत्ति के लिए हम क्या करते हैं। और यही सबसे सही तरीका है.

लेकिन इस मामले में हम भाग्यशाली थे. यदि, जैसा कि यहां कहा गया है "शुरू करें, हटाएं, रोलबैक करें", तो हम हटाएं दोहरा सकते हैं। यानी अगर हमने इसे खुद रद्द किया है तो हम इसे दोहरा सकते हैं. और भौतिक रूप से आपके पास डेटा उसी स्थान पर पड़ा रहेगा। आपको कोई सूजन भी नहीं होती. आप ऐसे DELETEs पर पुनरावृति कर सकते हैं।

रोलबैक के साथ यह DELETE चेकपॉइंट ट्यूनिंग के लिए आदर्श है, भले ही आपके पास ठीक से तैनात डेटाबेस लैब न हो।

हमने एक कॉलम "i" के साथ एक प्लेट बनाई। पोस्टग्रेज़ में उपयोगिता कॉलम हैं। जब तक विशेष रूप से न मांगा जाए, वे अदृश्य हैं। ये हैं: ctid, xmid, xmax।

सीटीआईडी ​​एक भौतिक पता है. शून्य पृष्ठ, पृष्ठ में पहला टपल।

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

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

यह प्रोग्रामर के बारे में है। डीबीए के बारे में भी, वे हमेशा प्रोग्रामर को इसके लिए डांटते हैं: "आप इतने लंबे और कठिन ऑपरेशन क्यों कर रहे हैं?" यह बिल्कुल अलग लंब विषय है. पहले प्रशासन था और अब विकास होगा.

जाहिर है, हम टुकड़ों में नहीं टूटे हैं. यह स्पष्ट है। लाखों लाइनों के ढेर के लिए ऐसे DELETE को भागों में तोड़ना असंभव नहीं है। इसे 20 मिनट तक किया जाएगा और सब कुछ लेट जाएगा। लेकिन, दुर्भाग्य से, अनुभवी डेवलपर्स भी गलतियाँ करते हैं, यहाँ तक कि बहुत बड़ी कंपनियों में भी।

तोड़ना क्यों ज़रूरी है?

• यदि हम देखते हैं कि डिस्क कठोर है, तो आइए इसे धीमा कर दें। और यदि हम टूट गए हैं, तो हम विराम जोड़ सकते हैं, हम थ्रॉटलिंग को धीमा कर सकते हैं।

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

https://postgres.ai/products/joe/

यह दिलचस्प है। मैं अक्सर देखता हूं कि डेवलपर्स पूछते हैं: "मुझे कौन सा पैक आकार चुनना चाहिए?"।

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

मेरा एक बहुत ही सरल नियम है: जितना हो सके उतना लें, लेकिन प्रति सेकंड निष्पादनयोग्य से आगे न बढ़ें।

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

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

हम पैक का आकार चुनते हैं। प्रत्येक मामले में, हम इसे अलग तरीके से कर सकते हैं। स्वचालित किया जा सकता है. और हम एक पैक के प्रसंस्करण की दक्षता से आश्वस्त हैं। यानी हम एक पैक को DELETE या UPDATE करते हैं।

वैसे, मैं जो भी बात कर रहा हूं वह केवल DELETE के बारे में नहीं है। जैसा कि आपने अनुमान लगाया, ये डेटा पर कोई भी थोक ऑपरेशन हैं।

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

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

और हमें अभी भी कुछ तैयार करना है ताकि यह हमें उत्पादन में इसका सही ढंग से पालन करने की अनुमति दे सके। उदाहरण के लिए, हम लॉग में समय लिख सकते हैं, हम लिख सकते हैं कि हम अभी कहाँ हैं और हमने अब किसे हटा दिया है। और इससे हमें यह समझने में मदद मिलेगी कि बाद में क्या हो रहा है। और अगर कुछ गलत होता है, तो तुरंत समस्या का पता लगाएं।

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

https://docs.gitlab.com/ee/development/background_migrations.html

विभाजन रणनीतियाँ क्या हैं? मैं 3 अलग-अलग विभाजन रणनीतियाँ देखता हूँ जिनका उपयोग पैक पर डेवलपर्स कर रहे हैं।

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

दूसरी रणनीति एक संतुलित दृष्टिकोण है। इसका उपयोग Gitlab में किया जाता है। उन्होंने मेज ली और स्कैन की। हमने आईडी पैक्स की सीमाएँ ज्ञात कीं ताकि प्रत्येक पैक में ठीक 10 रिकॉर्ड हों। और उन्हें एक कतार में खड़ा कर दिया. और फिर हम प्रक्रिया करते हैं। आप इसे एकाधिक थ्रेड में कर सकते हैं.

वैसे, पहली रणनीति में भी आप इसे कई धागों में कर सकते हैं। यह मुश्किल नहीं है।

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

आम तौर पर, केवल इंडेक्स स्कैन इंडेक्स स्कैन से तेज़ होता है।

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

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

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

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

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

लंबे लेन-देन https://gitlab.com/snippets/1890447

अवरुद्ध ऑटोवैक्यूम - https://gitlab.com/snippets/1889668

अवरोधन मुद्दा - https://gitlab.com/snippets/1890428

गलती #5 बहुत बड़ी है. ओकेमेटर के निकोलाई ने पोस्टग्रेज मॉनिटरिंग के बारे में बात की। आदर्श पोस्टग्रेज मॉनिटरिंग, दुर्भाग्य से, मौजूद नहीं है। कुछ करीब हैं, कुछ दूर हैं. ओकेमीटर परफेक्ट होने के काफी करीब है, लेकिन बहुत कुछ छूट गया है और उसे जोड़ने की जरूरत है। आपको इसके लिए तैयार रहना होगा.

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

यदि कोई बड़ा आईओ है, तो यह स्पष्ट है कि यह अच्छा नहीं है।

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

लंबे लेन-देन ख़राब क्यों हैं? क्योंकि सभी ताले अंत में ही खुलेंगे। और हम हर किसी से पंगा लेते हैं। साथ ही, हम सभी तालिकाओं के लिए ऑटोवैक्यूम को ब्लॉक करते हैं। यह बिल्कुल भी अच्छा नहीं है. भले ही आपने प्रतिकृति पर हॉट स्टैंडबाय सक्षम किया हो, फिर भी यह खराब है। सामान्य तौर पर, लंबे लेनदेन से बचना कहीं बेहतर नहीं है।

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

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

कभी-कभी ये सभी त्रुटियाँ एक साथ होती हैं।

मेरी राय में, यहाँ मुख्य गलती संगठनात्मक है। यह संगठनात्मक है, क्योंकि तकनीक खींचती नहीं है। यह नंबर 2 है - उन्होंने ग़लत जगह पर जाँच की।

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

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

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

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

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

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

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

उदाहरण: 5 टेराबाइट डेटाबेस, 30 सेकंड से भी कम समय में एक प्रति प्राप्त करना। और यह आकार पर भी निर्भर नहीं करता है, यानी इससे कोई फर्क नहीं पड़ता कि कितने टेराबाइट्स हैं।

आज आप जा सकते हैं पोस्टग्रेस.एआई और हमारे उपकरणों में खोदो। आप यह देखने के लिए पंजीकरण कर सकते हैं कि वहां क्या है। आप इस बॉट को इंस्टॉल कर सकते हैं. यह निःशुल्क है। लिखना।

सवाल

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

ये बहुत अच्छा तरीका है और बहुत अच्छा काम है. यह काफी हद तक वैसा ही है जैसा pg_repack करता है, यह काफी हद तक वैसा ही है जैसा आपको तब करना होता है जब आप आईडी 4 बाइट्स बनाते हैं। कई फ्रेमवर्क ने कुछ साल पहले ऐसा किया था, और केवल प्लेटें बड़ी हो गई हैं, और उन्हें 8 बाइट्स में परिवर्तित करने की आवश्यकता है।

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

अगर GitHub पर pg_repack को देखें तो वहां जब एक आईडी को int 4 से int 8 में बदलने का काम आया तो pg_repack को ही इस्तेमाल करने का विचार आया। यह भी संभव है, लेकिन यह थोड़ा हैक है, लेकिन यह इसके लिए भी काम करेगा। आप उस ट्रिगर में हस्तक्षेप कर सकते हैं जो pg_repack उपयोग करता है और वहां कहता है: "हमें इस डेटा की आवश्यकता नहीं है", यानी हम केवल वही स्थानांतरित करते हैं जो हमें चाहिए। और फिर वह बस स्विच करता है और बस इतना ही।

इस दृष्टिकोण के साथ, हमें अभी भी तालिका की दूसरी प्रति मिलती है, जिसमें डेटा पहले से ही अनुक्रमित है और सुंदर अनुक्रमित के साथ बहुत समान रूप से स्टैक्ड है।

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

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

लेकिन यह तभी है जब हमारे पास 90% है। यदि हमारे पास 5% है तो इसका उपयोग करना बहुत अच्छा नहीं है।

रिपोर्ट के लिए धन्यवाद! यदि उत्पाद की पूरी प्रतिलिपि बनाने के लिए कोई संसाधन नहीं हैं, तो क्या लोड या आकार की गणना करने के लिए कोई एल्गोरिदम या सूत्र है?

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

रिपोर्ट के लिए धन्यवाद! आपने सबसे पहले इस तथ्य के बारे में शुरुआत की कि एक अच्छा पोस्टग्रेज़ है, जिसकी ऐसी और ऐसी सीमाएँ हैं, लेकिन यह विकसित हो रहा है। और यह सब कुल मिलाकर एक बैसाखी है। क्या यह सब पोस्टग्रेज़ के विकास के साथ संघर्ष में नहीं है, जिसमें कुछ DELETE डिफ्रेंट दिखाई देंगे या कुछ और जिसे निम्न स्तर पर रखा जाना चाहिए जिसे हम यहां अपने कुछ अजीब साधनों के साथ खराब करने की कोशिश कर रहे हैं?

यदि हमने SQL में एक लेनदेन में कई रिकॉर्ड हटाने या अपडेट करने के लिए कहा है, तो Postgres इसे वहां कैसे वितरित कर सकता है? हम संचालन में भौतिक रूप से सीमित हैं। हम अभी भी इसे लंबे समय तक करेंगे. और हम इस समय ताला लगा देंगे, आदि।

अनुक्रमणिका के साथ हो गया.

मैं मान सकता हूं कि समान चेकपॉइंट ट्यूनिंग को स्वचालित किया जा सकता है। किसी दिन ऐसा हो सकता है. लेकिन तब मैं वास्तव में प्रश्न को समझ नहीं पाता हूँ।

सवाल यह है कि क्या विकास का कोई ऐसा वेक्टर है जो इधर-उधर जाता है और यहां आपका समानांतर चलता है? वे। क्या उन्होंने अभी तक इसके बारे में नहीं सोचा?

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

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

नमस्कार आपने लंबे लेन-देन के खतरों के बारे में बात की। आपने कहा कि हटाए जाने की स्थिति में ऑटोवैक्यूम अवरुद्ध हो जाता है। और यह हमें कैसे नुकसान पहुंचाता है? क्योंकि हम जगह खाली करने और उसका उपयोग करने में सक्षम होने के बारे में अधिक बात कर रहे हैं। हम और क्या खो रहे हैं?

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

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

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

जब हम पहले से ही कचरा चयन कर रहे हैं और हमारे पास, उदाहरण के लिए, एक हटाया हुआ ध्वज है

पोस्टग्रेज़ में ऑटोवैक्यूम स्वचालित रूप से यही करता है।

ओह, क्या वह ऐसा करता है?

ऑटोवैक्यूम कचरा संग्रहकर्ता है।

शुक्रिया!

रिपोर्ट के लिए धन्यवाद! क्या किसी डेटाबेस को तुरंत विभाजन के साथ इस तरह से डिज़ाइन करने का कोई विकल्प है कि सारा कचरा मुख्य टेबल से कहीं किनारे तक गंदा हो जाए?

जरूर है।

तो क्या यह संभव है कि हम अपनी सुरक्षा कर सकें यदि हमने उस मेज पर ताला लगा दिया है जिसका उपयोग नहीं किया जाना चाहिए?

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

स्रोत: www.habr.com