प्रिय DELETE। निकोले समोख्वालोभ (Postgres.ai)

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

भिडियो:

• म पहिलो वर्षदेखि, अर्थात् २००७ देखि हाइलोड कार्यक्रम समितिमा छु।

• र म 2005 देखि Postgres संग भएको छु। धेरै परियोजनाहरूमा प्रयोग गरियो।

• RuPostges संग समूह पनि 2007 देखि।

• हामी Meetup मा 2100+ सहभागी भएका छौं। लामो समयसम्म सान फ्रान्सिस्कोले ओगटेको न्यूयोर्क पछि यो विश्वमा दोस्रो हो।

• म धेरै वर्षदेखि क्यालिफोर्नियामा बसेको छु। म ठूला कम्पनीहरू सहित अमेरिकी कम्पनीहरूसँग बढी कारोबार गर्छु। तिनीहरू पोस्टग्रेसका सक्रिय प्रयोगकर्ताहरू हुन्। र त्यहाँ सबै प्रकारका रोचक चीजहरू छन्।

https://postgres.ai/ मेरो कम्पनी हो। हामी विकास सुस्तता हटाउने स्वचालित कार्यहरूको व्यवसायमा छौं।

यदि तपाइँ केहि गर्दै हुनुहुन्छ भने, कहिलेकाँही त्यहाँ पोस्टग्रेस वरिपरि केहि प्रकारका प्लगहरू छन्। मानौं कि तपाइँ तपाइँको लागि एक परीक्षण स्ट्यान्ड सेट अप गर्न प्रशासक को लागी पर्खनु पर्छ, वा तपाइँ DBA लाई तपाइँको प्रतिक्रिया को लागी कुर्नु पर्छ। र हामी विकास, परीक्षण र प्रशासन प्रक्रियामा त्यस्ता अवरोधहरू फेला पार्छौं र स्वचालन र नयाँ दृष्टिकोणहरूको मद्दतले तिनीहरूलाई हटाउन प्रयास गर्छौं।

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

म भर्खरै लस एन्जलसको VLDB मा थिएँ। यो डाटाबेसमा सबैभन्दा ठूलो सम्मेलन हो। र त्यहाँ एक रिपोर्ट थियो कि भविष्यमा DBMS भण्डारण मात्र हुनेछैन, तर स्वचालित रूपमा डाटा मेटाउने। यो नयाँ विषय हो ।

जेटाबाइटको संसारमा धेरै भन्दा धेरै डाटा छ - त्यो 1 पेटाबाइट्स हो। र अब यो पहिले नै अनुमान गरिएको छ कि हामीसँग संसारमा भण्डारण गरिएको डाटा को 000 zettabytes भन्दा बढी छ। र तिनीहरूमध्ये धेरै र अधिक छन्।

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

र यसलाई के गर्ने? स्पष्ट रूपमा यसलाई हटाउन आवश्यक छ। यहाँ यो रोचक रिपोर्टको लिङ्क छ। तर हालसम्म DBMS मा यो लागू भएको छैन।

पैसा गन्न सक्नेलाई दुई कुरा चाहिन्छ। तिनीहरूले हामीलाई मेटाउन चाहन्छन्, त्यसैले प्राविधिक रूपमा हामीले यो गर्न सक्षम हुनुपर्छ।

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

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

सामान्यतया, कार्य केहि तालिकामा विशिष्ट चीजहरू, विशिष्ट रेखाहरू मेटाउने स्वचालित हो।

र हामीसँग यस्तो अनुरोध छ, जुन हामी आज कुरा गर्नेछौं, त्यो फोहोर हटाउने बारेमा।

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

डाटाबेस बढ्छ र बढ्छ। दैनिक DELETE अलि बिस्तारै काम गर्न थाल्छ।

त्यसपछि हामी बुझ्छौं कि हामीसँग अब मार्केटिङ कम्पनी छ र ट्राफिक धेरै गुणा ठूलो हुनेछ, त्यसैले हामी अस्थायी रूपमा अनावश्यक चीजहरू पज गर्ने निर्णय गर्छौं। र फर्कन बिर्से।

केही महिनापछि उनीहरुको याद आयो । र त्यो विकासकर्ताले छोड्यो वा अरू केहिमा व्यस्त छ, अर्कोलाई फिर्ता गर्न निर्देशन दियो।

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

अब के हुन्छ? त्यसपछि सबै कुरा हाम्रो लागि अलग हुन्छ। यो खस्छ कि कुनै बिन्दुमा सबै कुरा तल खस्छ। सबैजना स्तब्ध छन्, के भइरहेको छ कसैले बुझ्दैन। र त्यसपछि यो बाहिर जान्छ कि मामला यो DELETE मा थियो।

केहि गलत भयो? यहाँ के गलत हुन सक्छ को एक सूची छ। यी मध्ये सबैभन्दा महत्त्वपूर्ण कुन हो?

• उदाहरणका लागि, त्यहाँ कुनै समीक्षा थिएन, अर्थात् DBA विशेषज्ञले यसलाई हेरेनन्। उसले तुरुन्तै अनुभवी आँखाको साथ समस्या फेला पार्नेछ, र यसबाहेक, उसले उत्पादनमा पहुँच छ, जहाँ लाखौं लाइनहरू जम्मा भएका छन्।

• सायद तिनीहरूले केहि गलत जाँच गरे।

• हुनसक्छ हार्डवेयर पुरानो भएको छ र तपाईंले यो आधार अपग्रेड गर्न आवश्यक छ।

• वा डाटाबेसमा नै केहि गलत छ, र हामीले Postgres बाट MySQL मा सार्न आवश्यक छ।

• वा अपरेसनमा केही गडबड हुन सक्छ।

• हुनसक्छ त्यहाँ कामको संगठनमा केही गल्तीहरू छन् र तपाईंले कसैलाई बर्खास्त गर्न र उत्तम व्यक्तिहरूलाई भाडामा लिनु आवश्यक छ?

त्यहाँ कुनै DBA जाँच थिएन। यदि त्यहाँ एक DBA थियो भने, उसले यी लाखौं लाइनहरू देख्नेछ र कुनै पनि प्रयोग बिना पनि भन्थे: "उनीहरूले त्यसो गर्दैनन्।" मान्नुहोस् कि यदि यो कोड GitLab, GitHub मा भएको थियो र त्यहाँ कोड समीक्षा प्रक्रिया हुनेछ र यो DBA को स्वीकृति बिना यो अपरेशन उत्पादनमा हुने थिएन भने, तब स्पष्ट रूपमा DBA ले यसो भन्नेछ: "यो गर्न सकिँदैन। "

र उसले भन्यो कि तपाईलाई डिस्क IO मा समस्या हुनेछ र सबै प्रक्रियाहरू पागल हुनेछन्, त्यहाँ लकहरू हुन सक्छन्, र तपाईले मिनेटको गुच्छाको लागि अटोभ्याक्यूम ब्लक गर्नुहुनेछ, त्यसैले यो राम्रो होइन।

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

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

हामी बुझ्छौं कि हाम्रो परीक्षणहरू कमजोर छन्, अर्थात्, निर्माण गरिएको प्रक्रियाले समस्याहरू समात्दैन। पर्याप्त DB प्रयोग गरिएन।

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

सायद हाम्रो उपकरण खराब छ? हेर्यो भने विलम्ब उफ्रियो । हामीले देख्यौं कि उपयोग 100% छ। निस्सन्देह, यदि यी आधुनिक NVMe ड्राइभहरू थिए भने, त्यसपछि यो हाम्रो लागि धेरै सजिलो हुनेछ। र सायद हामी यसबाट ढल्ने छैनौं।

यदि तपाईंसँग बादलहरू छन् भने, त्यहाँ अपग्रेड सजिलैसँग गरिन्छ। नयाँ हार्डवेयरमा नयाँ प्रतिकृतिहरू उठाइयो। परिवर्तन गर। र सबै राम्रो छ। धेरै सजिलो।

के यो सम्भव छ कि कुनै पनि साना डिस्क छुन? र यहाँ, केवल DBA को मद्दतले, हामी चेकपोइन्ट ट्युनिङ भनिने निश्चित विषयमा डुब्छौं। यो बाहिर जान्छ कि हामीसँग चेकपोइन्ट ट्युनिङ छैन।

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

Postgres मा सेटिङहरू पछाडि छन्। तिनीहरू डेटा र लेनदेनको 10-15 वर्ष पुरानो मात्राको लागि डिजाइन गरिएको हो। र चेकपोइन्ट कुनै अपवाद छैन।

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

यसको मतलब के हो? त्यहाँ दुई सेटिङहरू छन्। चेकपोइन्ट टाइमआउटद्वारा आउन सक्छ, उदाहरणका लागि, १० मिनेटमा। वा यो आउन सक्छ जब धेरै डाटा भरिएको छ।

र पूर्वनिर्धारित रूपमा max_wal_saze 1 gigabyte मा सेट गरिएको छ। वास्तवमा, यो वास्तवमै 300-400 मेगाबाइट पछि Postgres मा हुन्छ। तपाईंले धेरै डाटा परिवर्तन गर्नुभयो र तपाईंको चेकपोइन्ट हुन्छ।

र यदि कसैले यसलाई ट्युन गरेन, र सेवा बढ्यो, र कम्पनीले धेरै पैसा कमाउँछ, यसमा धेरै लेनदेनहरू छन्, त्यसपछि चेकपोइन्ट एक मिनेटमा एक पटक आउँछ, कहिलेकाहीँ प्रत्येक 30 सेकेन्डमा, र कहिलेकाहीँ ओभरल्याप पनि हुन्छ। यो एकदम नराम्रो छ।

र हामीले यो सुनिश्चित गर्न आवश्यक छ कि यो कम पटक आउँछ। त्यो हो, हामी अधिकतम_वाल_साइज बढाउन सक्छौं। र यो कम बारम्बार आउनेछ।

तर हामीले यसलाई अझ सही तरिकाले कसरी गर्ने भन्ने सम्पूर्ण विधि विकास गरेका छौं, त्यो हो, सेटिङहरू छनौट गर्ने बारे निर्णय कसरी गर्ने, स्पष्ट रूपमा निर्दिष्ट डेटामा आधारित।

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

पहिलो श्रृंखला - हामी max_wal_size परिवर्तन गर्छौं। र हामी एक ठूलो अपरेशन गर्दैछौं। पहिले, हामी यसलाई 1 गीगाबाइटको पूर्वनिर्धारित सेटिङमा गर्छौं। र हामी लाखौं लाइनहरूको ठूलो DELETE गर्छौं।

तपाईं देख्न सक्नुहुन्छ कि यो हाम्रो लागि कति गाह्रो छ। हामी देख्छौं कि डिस्क IO धेरै खराब छ। हामीले कति वालहरू उत्पन्न गरेका छौं भनेर हेर्छौं, किनभने यो धेरै महत्त्वपूर्ण छ। हेरौं कति पटक चेकपोइन्ट भयो। र हामी देख्छौं कि यो राम्रो छैन।

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

र यस तरिकाले हामी हाम्रो प्रणालीलाई साटासाट गर्नेछौं, र हामीलाई थाहा छ कि DBMS ले खराब मास DELETE को अवस्थामा कसरी व्यवहार गर्नेछ, यसले कसरी चेकपोइन्ट गर्नेछ।

रूसीमा चेकपोइन्टहरू चेकपोइन्टहरू हुन्।

उदाहरण: अनुक्रमणिका द्वारा धेरै मिलियन पङ्क्तिहरू मेटाउनुहोस्, पङ्क्तिहरू पृष्ठहरूमा "छरिएका" छन्।

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

यदि यस्तो अपरेसनलाई प्रोडमा अनुमति दिइएको छ भने, हामी मात्र सुत्नेछौं, किनभने यो स्पष्ट छ कि एउटा DELETE ले हामीलाई शेल्फमा मार्छ।

यसबाहेक, जहाँ 16 गीगाबाइट, यो स्पष्ट छ कि दाँत पहिले नै गएको छ। दाँत पहिले नै राम्रो छ, त्यो हो, हामी छतमा ढकढक गर्दैछौं, तर यति खराब छैन। त्यहाँ केही स्वतन्त्रता थियो। दायाँमा रेकर्ड छ। र सञ्चालन संख्या - दोस्रो ग्राफ। र यो स्पष्ट छ कि हामी पहिले नै 16 गीगाबाइट जब अलि सजिलो सास फेर्दै छौं।

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

किन त्यसो

म विवरणहरूमा थोरै डुब्नेछु, तर यो विषय, कसरी चेकपोइन्ट ट्युनिङ सञ्चालन गर्ने, यसले सम्पूर्ण रिपोर्टमा परिणाम ल्याउन सक्छ, त्यसैले म धेरै लोड गर्नेछैन, तर म त्यहाँ कस्ता कठिनाइहरू छन् भनेर थोरै रूपरेखा गर्नेछु।

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

र हामी यसलाई धेरै पटक बचाउनको लागि चेकपोइन्टलाई जबरजस्ती गर्नेछौं। उसको लागि अनावश्यक अपरेशन कसरी हुनेछ।

तर त्यो सबै होइन। पृष्ठहरू Postgres मा 8 किलोबाइट र लिनक्समा 4 किलोबाइटहरू छन्। र त्यहाँ फुल_पेज_राइट सेटिङ छ। यो पूर्वनिर्धारित रूपमा सक्षम छ। र यो सही छ, किनकि यदि हामीले यसलाई बन्द गर्यौं भने, यदि यो क्र्यास भयो भने पृष्ठको आधा मात्र बचत हुने खतरा छ।

फर्वार्ड लगको WAL मा लेख्ने व्यवहार यस्तो छ कि जब हामीसँग चेकपोइन्ट हुन्छ र हामीले पहिलो पटक पृष्ठ परिवर्तन गर्छौं, सम्पूर्ण पृष्ठ, अर्थात्, सबै 8 किलोबाइट, फर्वार्ड लगमा पुग्छ, यद्यपि हामीले मात्र परिवर्तन गर्यौं। रेखा, जसको तौल १०० बाइट हुन्छ। र हामीले पूरै पृष्ठ लेख्नु पर्छ।

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

र, तदनुसार, यदि चेकपोइन्ट फेरि भयो भने, हामीले फेरि स्क्र्याचबाट सबै कुरा सुरु गर्नुपर्छ र सम्पूर्ण पृष्ठ धकेल्नु पर्छ। बारम्बार चेकपोइन्टहरूको साथ, जब हामी समान पृष्ठहरू मार्फत हिंड्छौं, full_page_writes = on यो हुन सक्ने भन्दा बढी हुनेछ, अर्थात् हामीले थप WAL उत्पन्न गर्छौं। थप प्रतिकृतिहरूमा, अभिलेखमा, डिस्कमा पठाइन्छ।

र, तदनुसार, हामीसँग दुई रिडन्डन्सीहरू छन्।

यदि हामीले max_wal_size बढाउछौं भने, हामीले चेकपोइन्ट र वाल लेखक दुवैलाई सजिलो बनाउँछौं। र त्यो महान छ।

टेराबाइटमा राखौं र यसको साथ बाँचौं। यसमा के नराम्रो छ? यो खराब छ, किनकि असफलताको अवस्थामा, हामी घण्टाको लागि चढ्नेछौं, किनकि चेकपोइन्ट धेरै पहिले थियो र धेरै परिवर्तन भइसकेको छ। र हामीले यो सबै REDO गर्न आवश्यक छ। र त्यसैले हामी प्रयोगहरूको दोस्रो श्रृंखला गर्छौं।

हामी एक अपरेशन गर्छौं र हेर्छौं जब चेकपोइन्ट पूरा हुन लागेको छ, हामी उद्देश्यमा -9 पोस्टग्रेस मार्छौं।

र त्यस पछि हामी यसलाई फेरि सुरु गर्छौं, र यो उपकरणमा कति लामो समयसम्म बढ्छ, अर्थात् यो खराब अवस्थामा यो कत्तिको REDO हुनेछ हेर्नुहोस्।

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

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

र यहाँ एक रोचक बिन्दु छ। हामीसँग सम्मेलनमा Patroni बारे रिपोर्टहरू छन्। र सायद तपाइँ यसलाई प्रयोग गर्दै हुनुहुन्छ। यो Postgres को लागि एक autofailover छ। GitLab र Data Egret ले यसको बारेमा कुरा गरे।

र यदि तपाइँसँग 30 सेकेन्डमा आउने स्वत: फेलओभर छ भने, त्यसपछि हामी 10 मिनेटको लागि सुत्न सक्छौं? किनभने हामी यस बिन्दुमा प्रतिकृतिमा स्विच गर्नेछौं, र सबै कुरा ठीक हुनेछ। यो एउटा मुट बिन्दु हो। मलाई स्पष्ट जवाफ थाहा छैन। मलाई लाग्छ कि यो विषय क्र्यास रिकभरीको वरिपरि मात्र होइन।

यदि हामी असफलता पछि एक लामो रिकभरी छ भने, त्यसपछि हामी अन्य धेरै परिस्थितिहरूमा असहज हुनेछौं। उदाहरणका लागि, एउटै प्रयोगहरूमा, जब हामी केहि गर्छौं र कहिलेकाहीँ 10 मिनेट पर्खनुपर्छ।

हामीसँग अटोफेलओभर भए पनि म अझै धेरै टाढा जाने छैन। नियमको रूपमा, मानहरू जस्तै 64, 100 गीगाबाइटहरू राम्रो मानहरू हुन्। कहिलेकाहीँ यो पनि कम छनोट गर्न लायक छ। सामान्यतया, यो एक सूक्ष्म विज्ञान हो।

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

म हाम्रो समाधानको बारेमा पछि कुरा गर्नेछु, हामी त्यस्ता परिस्थितिहरूमा पुनरावृत्ति गर्न के गर्छौं। र यो सबैभन्दा सही दृष्टिकोण हो।

तर यस मामला मा, हामी भाग्यशाली थियौं। यदि, यहाँ "BEGIN, DELETE, ROLLBACK" भनिएको छ भने, हामी DELETE दोहोर्याउन सक्छौं। त्यो हो, यदि हामीले यसलाई आफैले रद्द गर्यौं भने, हामी यसलाई दोहोर्याउन सक्छौं। र भौतिक रूपमा तपाईमा डाटा एकै ठाउँमा रहनेछ। तपाईलाई कुनै पखाला पनि लाग्दैन। तपाईं त्यस्ता DELETE हरू मा दोहोर्याउन सक्नुहुन्छ।

ROLLBACK सँगको यो DELETE चेकपोइन्ट ट्युनिङका लागि उपयुक्त छ, तपाईंसँग राम्ररी तैनाथ गरिएको डाटाबेस ल्याबहरू नभए पनि।

हामीले एउटा स्तम्भ "i" को साथ प्लेट बनायौं। Postgres सँग उपयोगिता स्तम्भहरू छन्। तिनीहरू अदृश्य छन् जबसम्म विशेष रूपमा सोधिएको छैन। यी हुन्: ctid, xmid, xmax।

Ctid एक भौतिक ठेगाना हो। शून्य पृष्ठ, पृष्ठमा पहिलो टपल।

यो देख्न सकिन्छ कि ROOLBACK पछि टपल एकै ठाउँमा रह्यो। त्यो हो, हामी फेरि प्रयास गर्न सक्छौं, यो समान रूपमा व्यवहार गर्नेछ। यो मुख्य कुरा हो।

Xmax tuple को मृत्यु को समय हो। यो स्ट्याम्प गरिएको थियो, तर पोस्टग्रेसलाई थाहा छ कि लेनदेन फिर्ता भयो, त्यसैले यो ० हो वा यो रोल ब्याक लेनदेन हो भन्ने कुराले फरक पार्दैन। यसले सुझाव दिन्छ कि यो DELETE मा दोहोर्याउन र प्रणाली व्यवहारको बल्क अपरेशनहरू जाँच गर्न सम्भव छ। तपाईं गरिबहरूको लागि डाटाबेस प्रयोगशाला बनाउन सक्नुहुन्छ।

यो प्रोग्रामरहरूको बारेमा हो। DBA को बारेमा पनि, तिनीहरू सधैं यसका लागि प्रोग्रामरहरूलाई गाली गर्छन्: "तपाईं किन यति लामो र कठिन अपरेशनहरू गर्दै हुनुहुन्छ?"। यो एकदम फरक लम्बवत विषय हो। पहिले प्रशासन थियो, अब विकास हुनेछ ।

जाहिर छ, हामी टुक्रा-टुक्रामा परेका छैनौं। यो स्पष्ट छ। यस्तो DELETE लाई भागहरूमा लाखौं लाइनहरूको थुप्रोमा तोड्न असम्भव छ। यो 20 मिनेटको लागि गरिन्छ, र सबै कुरा सुत्नेछ। तर, दुर्भाग्यवश, धेरै ठूला कम्पनीहरूमा पनि अनुभवी विकासकर्ताहरूले गल्तीहरू गर्छन्।

यो तोड्न किन महत्त्वपूर्ण छ?

• यदि हामीले देख्यौं कि डिस्क कडा छ, त्यसपछि यसलाई ढिलो गरौं। र यदि हामी भाँचिएका छौं भने, हामी पजहरू थप्न सक्छौं, हामी थ्रोटलिंगलाई ढिलो गर्न सक्छौं।

• र हामी अरूलाई लामो समयको लागि ब्लक गर्दैनौं। केहि केसहरूमा यसले फरक पार्दैन, यदि तपाइँ वास्तविक फोहोरहरू मेटाउँदै हुनुहुन्छ जसमा कसैले काम गरिरहेको छैन, तब सम्भवतः तपाईले अटोभ्याक्यूम कार्य बाहेक कसैलाई ब्लक गर्नुहुने छैन, किनकि यसले लेनदेन पूरा हुनको लागि पर्खनेछ। तर यदि तपाईंले अरू कसैले अनुरोध गर्न सक्ने कुरा हटाउनुभयो भने, तिनीहरू अवरुद्ध हुनेछन्, त्यहाँ केही प्रकारको चेन प्रतिक्रिया हुनेछ। वेबसाइटहरू र मोबाइल अनुप्रयोगहरूमा लामो लेनदेनबाट जोगिनै पर्छ।

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

यो रोचक छ। म प्राय: विकासकर्ताहरूले सोध्ने गरेको देख्छु: "मैले कुन प्याक साइज रोज्नुपर्छ?"।

यो स्पष्ट छ कि बन्डल साइज जति ठूलो हुन्छ, लेनदेन ओभरहेड सानो हुन्छ, अर्थात्, लेनदेनबाट थप ओभरहेड। तर एकै समयमा, यो लेनदेनको लागि समय बढ्छ।

मसँग एक धेरै सरल नियम छ: तपाईले सकेसम्म धेरै लिनुहोस्, तर प्रति सेकेन्ड कार्यान्वयनयोग्यहरू नजानुहोस्।

किन एक सेकेन्ड? व्याख्या धेरै सरल र सबैलाई बुझ्न योग्य छ, गैर-प्राविधिक मानिसहरू पनि। हामी प्रतिक्रिया देख्छौं। 50 मिलिसेकेन्ड लिनुहोस्। यदि केहि परिवर्तन भएको छ भने, हाम्रो आँखाले प्रतिक्रिया गर्नेछ। कम भए झन् गाह्रो । यदि केहि 100 मिलिसेकेन्ड पछि प्रतिक्रिया दिन्छ, उदाहरण को लागी, तपाईले माउस क्लिक गर्नुभयो, र यसले तपाईलाई 100 मिलिसेकेन्ड पछि जवाफ दियो, तपाईले पहिले नै यो थोरै ढिलाइ महसुस गर्नुहुन्छ। एक सेकेन्ड पहिले नै ब्रेकको रूपमा मानिन्छ।

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

हामी प्याकको साइज छनौट गर्छौं। प्रत्येक अवस्थामा, हामी यसलाई फरक तरिकाले गर्न सक्छौं। स्वचालित गर्न सकिन्छ। र हामी एक प्याक को प्रशोधन को दक्षता मा विश्वस्त छौं। अर्थात्, हामी एउटा प्याकलाई DELETE वा अद्यावधिक गर्छौं।

वैसे, मैले कुरा गरिरहेको सबै कुरा DELETE को बारेमा मात्र होइन। तपाईले अनुमान गर्नुभए अनुसार, यी डेटामा कुनै पनि बल्क अपरेशनहरू हुन्।

र हामी देख्छौं कि योजना उत्कृष्ट छ। तपाईले अनुक्रमणिका स्क्यान हेर्न सक्नुहुन्छ, अनुक्रमणिका मात्र स्क्यान अझ राम्रो छ। र हामीसँग थोरै मात्रामा डाटा समावेश छ। र एक सेकेन्ड भन्दा कम पूरा हुन्छ। सुपर।

र हामीले अझै पनि यो सुनिश्चित गर्न आवश्यक छ कि त्यहाँ कुनै गिरावट छैन। यो हुन्छ कि पहिलो प्याकहरू चाँडै काम गर्छन्, र त्यसपछि यो खराब, खराब र खराब हुन्छ। प्रक्रिया यस्तो छ कि तपाईंले धेरै परीक्षण गर्न आवश्यक छ। यो ठ्याक्कै के हो डाटाबेस प्रयोगशालाहरूको लागि हो।

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

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

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 हामीले अग्रिम चयन गर्छौं। र हामी तिनीहरूलाई मात्र प्राप्त गर्दैनौं, हामी तिनीहरूलाई विशेष तरिकामा पाउँछौं र तुरुन्तै तिनीहरूलाई ह्याक गर्छौं। तर हामी लक गर्दैछौं ताकि यदि तिनीहरू पहिले नै बन्द छन् भने, हामी तिनीहरूलाई लक गर्दैनौं, तर अगाडि बढ्छौं र अर्कोहरू लिन्छौं। यो स्किप लक गरिएको अद्यावधिकको लागि हो। Postgres को यो सुपर सुविधाले हामीलाई धेरै थ्रेडहरूमा काम गर्न अनुमति दिन्छ यदि हामी चाहन्छौं। यो एक धारामा सम्भव छ। र यहाँ CTE छ - यो एउटा अनुरोध हो। र हामीसँग यो CTE को दोस्रो तल्लामा वास्तविक मेटाउने काम भइरहेको छ - returning *। तपाईं आईडी फिर्ता गर्न सक्नुहुन्छ, तर यो राम्रो छ *यदि तपाइँसँग प्रत्येक लाइनमा धेरै डाटा छैन भने।

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

सूचकांकको बारेमा थप एउटा नोट छ। यदि हामीले निर्णय गर्छौं कि हामीलाई यो कार्यको लागि विशेष अनुक्रमणिका चाहिन्छ, तब हामीले यो सुनिश्चित गर्न आवश्यक छ कि यसले ढेर मात्र टुपल्स अद्यावधिकहरू बिगार्दैन। त्यो हो, Postgres यस्तो तथ्याङ्क छ। यो तपाइँको तालिकाको लागि pg_stat_user_tables मा देख्न सकिन्छ। तपाईं तातो अपडेटहरू प्रयोग भइरहेको छ वा छैन भनेर हेर्न सक्नुहुन्छ।

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

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

लामो लेनदेन https://gitlab.com/snippets/1890447

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

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

गल्ती #5 ठूलो छ। ओकमिटरबाट निकोलाईले पोस्टग्रेस निगरानीको बारेमा कुरा गरे। आदर्श पोस्टग्रेस निगरानी, ​​दुर्भाग्यवश, अवस्थित छैन। कोही नजिक छन्, कोही टाढा छन्। Okmeter सिद्ध हुनको लागि पर्याप्त नजिक छ, तर धेरै हराइरहेको छ र थप्न आवश्यक छ। तपाईं यसको लागि तयार हुन आवश्यक छ।

उदाहरण को लागी, मृत tuples राम्रो निगरानी गरिन्छ। यदि तपाइँसँग तालिकामा धेरै मृत चीजहरू छन् भने, केहि गलत छ। अहिले नै प्रतिक्रिया दिनु राम्रो हो, नत्र पतन हुन सक्छ र हामी सुत्न सक्छौं। यस्तो हुन्छ।

यदि त्यहाँ ठूलो IO छ भने, यो स्पष्ट छ कि यो राम्रो छैन।

लामो लेनदेन पनि। OLTP मा लामो लेनदेन अनुमति दिनु हुँदैन। र यहाँ एउटा स्निपेटको लिङ्क छ जसले तपाईंलाई यो स्निपेट लिन र पहिले नै लामो लेनदेनको केही ट्र्याकिङ गर्न अनुमति दिन्छ।

किन लामो लेनदेन खराब छ? किनभने सबै तालाहरू अन्त्यमा मात्र रिलिज हुनेछन्। र हामी सबैलाई बिगार्छौं। साथै, हामी सबै टेबलहरूको लागि autovacuum रोक्छौं। यो पटक्कै राम्रो होइन। यदि तपाईंसँग प्रतिकृतिमा हट स्ट्यान्डबाइ सक्षम छ भने, यो अझै खराब छ। सामान्यतया, लामो लेनदेनबाट बच्नु कतै राम्रो छैन।

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

र समस्याहरू ब्लकहरू। ब्लक रूखहरूको जंगल। म कसैबाट केहि लिन र सुधार गर्न चाहन्छु। यहाँ मैले डेटा एग्रेटबाट एउटा राम्रो पुनरावर्ती CTE लिएँ जसले लक रूखहरूको जंगल देखाउँछ। यो एक राम्रो निदान उपकरण हो। र यसको आधारमा, तपाईं पनि निगरानी निर्माण गर्न सक्नुहुन्छ। तर यो सावधानीपूर्वक गर्नुपर्छ। तपाईंले आफ्नो लागि एउटा सानो स्टेटमेन्ट_टाइमआउट बनाउन आवश्यक छ। र lock_timeout वांछनीय छ।

कहिलेकाहीँ यी सबै त्रुटिहरू योगमा हुन्छन्।

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

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

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

Autovacuum बारे थप। हामीले धेरै मिलियन लाइनहरूको ठूलो स्वीप गरिसकेपछि, हामीले अझै पनि REPACK गर्न आवश्यक छ। यो अनुक्रमणिका लागि विशेष गरी महत्त्वपूर्ण छ। हामीले त्यहाँ सबै सफा गरेपछि उनीहरूलाई नराम्रो लाग्नेछ।

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

हामी के गर्छौं खुला स्रोत हो। GitLab मा पोस्ट गरिएको छ। र हामी यसलाई बनाउँछौं ताकि मानिसहरूले DBA बिना पनि जाँच गर्न सक्छन्। हामी डाटाबेस ल्याब गर्दैछौं, त्यो हो, हामी बेस कम्पोनेन्टलाई कल गर्छौं जसमा जो हाल काम गरिरहेको छ। र तपाईं उत्पादन को एक प्रतिलिपि समात्न सक्नुहुन्छ। अब ढिलोको लागि जोको कार्यान्वयन छ, तपाइँ त्यहाँ भन्न सक्नुहुन्छ: "यस्तो र यस्तो अनुरोधको व्याख्या गर्नुहोस्" र तुरुन्तै डाटाबेसको प्रतिलिपिको लागि परिणाम प्राप्त गर्नुहोस्। तपाईं त्यहाँ मेटाउन पनि सक्नुहुन्छ, र कसैले यसलाई याद गर्नेछैन।

मानौं तपाईसँग १० टेराबाइट छ, हामीले डाटाबेस ल्याब पनि १० टेराबाइट बनाउँछौं। र एक साथ १० टेराबाइट डाटाबेसको साथ, १० विकासकर्ताहरूले एकै साथ काम गर्न सक्छन्। सबैले आफूले चाहेको काम गर्न सक्छन्। मेटाउन सक्छ, छोड्न सक्छ, आदि। त्यो यस्तो काल्पनिक हो। हामी भोलि यस बारे कुरा गर्नेछौं।

यसलाई पातलो प्रावधान भनिन्छ। यो सूक्ष्म प्रावधान हो। यो केहि प्रकारको काल्पनिक हो जसले विकासमा ढिलाइलाई धेरै हटाउँछ, परीक्षणमा र यस सन्दर्भमा संसारलाई राम्रो स्थान बनाउँछ। त्यो हो, यसले तपाईंलाई बल्क अपरेशनको साथ समस्याहरूबाट बच्न अनुमति दिन्छ।

उदाहरण: 5 टेराबाइट डाटाबेस, 30 सेकेन्ड भन्दा कममा प्रतिलिपि प्राप्त गर्दै। र यो पनि आकार मा निर्भर गर्दैन, त्यो हो, यो कति टेराबाइट्स फरक पर्दैन।

आज तपाईं जान सक्नुहुन्छ postgres.ai र हाम्रो उपकरणहरूमा खन्नुहोस्। तपाईं त्यहाँ के छ हेर्न दर्ता गर्न सक्नुहुन्छ। तपाईं यो बोट स्थापना गर्न सक्नुहुन्छ। यो नि:शुल्क छ। लेख्नुहोस्।

तपाईंका प्रश्नहरू

धेरै पटक वास्तविक परिस्थितिहरूमा यो बाहिर जान्छ कि तालिकामा रहनु पर्ने डाटा मेटाउन आवश्यक भन्दा धेरै कम छ। त्यो हो, यस्तो अवस्थामा, यस्तो दृष्टिकोण लागू गर्न अक्सर सजिलो हुन्छ, जब नयाँ वस्तु सिर्जना गर्न सजिलो हुन्छ, त्यहाँ आवश्यक डेटा मात्र प्रतिलिपि गर्नुहोस्, र पुरानो तालिका ट्रंक गर्नुहोस्। यो स्पष्ट छ कि यस क्षणको लागि प्रोग्रामेटिक दृष्टिकोण आवश्यक छ, जब तपाईं स्विच गर्दै हुनुहुन्छ। यो दृष्टिकोण कस्तो छ?

यो एक धेरै राम्रो दृष्टिकोण र एक धेरै राम्रो काम हो। यो pg_repack ले गर्ने कुरासँग धेरै मिल्दोजुल्दो छ, यो तपाईंले ID 4 बाइटहरू बनाउनुहुँदा के गर्नुपर्छ। धेरै फ्रेमवर्कले केहि वर्ष पहिले यो गरेको थियो, र केवल प्लेटहरू बढेका छन्, र तिनीहरूलाई 8 बाइटहरूमा रूपान्तरण गर्न आवश्यक छ।

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

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

यस दृष्टिकोणको साथ, हामीले अझै पनि तालिकाको दोस्रो प्रतिलिपि पाउँछौं, जसमा डेटा पहिले नै अनुक्रमित गरिएको छ र सुन्दर अनुक्रमणिकाहरूसँग धेरै समान रूपमा स्ट्याक गरिएको छ।

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

म MySQL को संसारबाट थोरै मात्र छु, त्यसैले म सुन्न आएको हुँ। र हामी यो दृष्टिकोण प्रयोग गर्छौं।

तर हामीसँग ९० प्रतिशत छ भने मात्र हुन्छ । यदि हामीसँग 90% छ भने, यसलाई प्रयोग गर्न धेरै राम्रो छैन।

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

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

रिपोर्ट को लागी धन्यवाद! तपाईंले पहिले यस तथ्यको बारेमा सुरु गर्नुभयो कि त्यहाँ एक राम्रो पोस्टग्रेस छ, जसमा यस्ता र त्यस्ता सीमितताहरू छन्, तर यो विकास भइरहेको छ। र यो सबै एक आधार र ठूलो छ। के यो सबै Postgres को विकास संग विरोधाभास मा छैन, जसमा केहि DELETE deferent देखा पर्नेछ वा अन्य केहि जुन निम्न स्तरमा राख्नु पर्छ जुन हामीले यहाँ हाम्रा केहि अनौठो माध्यमहरु संग स्मियर गर्न खोजिरहेका छौं?

यदि हामीले एक लेनदेनमा धेरै रेकर्डहरू मेटाउन वा अपडेट गर्न SQL मा भन्यौं भने, त्यसपछि Postgres ले त्यहाँ कसरी वितरण गर्न सक्छ? हामी शारीरिक रूपमा सञ्चालनमा सीमित छौं। हामी अझै लामो समय सम्म यो गर्नेछौं। र हामी यस समयमा लक गर्नेछौं, आदि।

अनुक्रमणिकाको साथ सम्पन्न भयो।

म मान्न सक्छु कि उही चेकपोइन्ट ट्युनिङ स्वचालित हुन सक्छ। कुनै दिन यो हुन सक्छ। तर त्यसपछि मैले प्रश्नलाई साँच्चै बुझिन।

प्रश्न यो छ, के त्यहाँ विकासको वेक्टर छ जुन यता उता जान्छ र यहाँ तपाईको समानान्तर हुन्छ? ती। के उनीहरूले अहिलेसम्म यसबारे सोचेका छैनन्?

मैले अहिले प्रयोग गर्न सकिने सिद्धान्तहरूको बारेमा कुरा गरें। त्यहाँ अर्को बोट छ नैन्सी, यो संग तपाईं स्वचालित चेकपोइन्ट ट्युनिङ गर्न सक्नुहुन्छ। के यो कुनै दिन Postgres मा हुनेछ? मलाई थाहा छैन, यो अझै छलफल भएको छैन। त्यसबाट हामी अझै टाढा छौं । तर नयाँ प्रणाली बनाउने वैज्ञानिकहरू छन्। र तिनीहरूले हामीलाई स्वचालित अनुक्रमणिकाहरूमा धकेल्छन्। त्यहाँ विकासहरू छन्। उदाहरणका लागि, तपाईं स्वत: ट्युनिङ हेर्न सक्नुहुन्छ। यसले स्वचालित रूपमा प्यारामिटरहरू चयन गर्दछ। तर उसले अझै तपाईंको लागि चेकपोइन्ट ट्युनिङ गर्ने छैन। त्यो हो, यो प्रदर्शन, शेल बफर, आदि को लागी उठ्नेछ।

र चेकपोइन्ट ट्युनिङको लागि, तपाईंले यो गर्न सक्नुहुन्छ: यदि तपाईंसँग हजारौं क्लस्टरहरू र विभिन्न हार्डवेयरहरू छन्, क्लाउडमा विभिन्न भर्चुअल मेसिनहरू छन् भने, तपाईंले हाम्रो बोट प्रयोग गर्न सक्नुहुन्छ। नैन्सी स्वचालन गर्ने। र max_wal_size स्वचालित रूपमा तपाइँको लक्षित सेटिङ अनुसार चयन गरिनेछ। तर अहिले सम्म यो कोर मा नजिक पनि छैन, दुर्भाग्यवश।

शुभ दिउँसो तपाईंले लामो लेनदेनको खतराहरूको बारेमा कुरा गर्नुभयो। तपाईंले भन्नुभयो कि अटोभ्याक्यूम मेटाइएको अवस्थामा अवरुद्ध छ। यसले हामीलाई कसरी हानि गर्छ? किनभने हामी ठाउँ खाली गर्ने र यसलाई प्रयोग गर्न सक्षम हुने बारे थप कुरा गरिरहेका छौं। अरु के के कमी छ र ?

Autovacuum यहाँ सबैभन्दा ठूलो समस्या होइन। र तथ्य यो छ कि एक लामो लेनदेनले अन्य लेनदेनहरू लक गर्न सक्छ, यो सम्भावना अझ खतरनाक छ। उसले भेट्न पनि सक्छ, नभेट्न पनि सक्छ । यदि उसले भेट्यो भने, यो धेरै खराब हुन सक्छ। र autovacuum संग - यो पनि एक समस्या हो। OLTP मा लामो लेनदेन संग दुई समस्या छन्: ताला र autovacuum। र यदि तपाइँसँग प्रतिकृतिमा हट स्ट्यान्डबाइ प्रतिक्रिया सक्षम छ भने, तब अटोभ्याक्यूम लक पनि मास्टरमा आइपुग्छ, यो प्रतिकृतिबाट आइपुग्छ। तर कम्तिमा त्यहाँ कुनै तालाहरू हुनेछैनन्। र त्यहाँ लोकहरू हुनेछन्। हामी डेटा परिवर्तनहरूको बारेमा कुरा गर्दैछौं, त्यसैले तालाहरू यहाँ महत्त्वपूर्ण बिन्दु हुन्। र यदि यो सबै लामो, लामो समयको लागि हो भने, त्यसपछि थप र अधिक लेनदेनहरू बन्द छन्। तिनीहरूले अरूलाई चोर्न सक्छन्। र लोक रूखहरू देखा पर्छन्। मैले स्निपेटको लिङ्क प्रदान गरें। र यो समस्या अटोभ्याक्यूमको समस्या भन्दा चाँडो देखिने हुन्छ, जुन जम्मा हुन सक्छ।

रिपोर्ट को लागी धन्यवाद! तपाईंले गलत परीक्षण गरेको भन्दै आफ्नो रिपोर्ट सुरु गर्नुभयो। हामीले हाम्रो विचारलाई जारी राख्यौं कि हामीले एउटै उपकरण लिनु पर्छ, आधारको साथ एउटै तरीकाले। मानौं हामीले विकासकर्तालाई आधार दियौं। र उसले अनुरोधलाई पालन गर्यो। र उहाँ ठीक हुनुहुन्छ जस्तो देखिन्छ। तर उसले लाइभको लागि जाँच गर्दैन, तर लाइभको लागि, उदाहरणका लागि, हामीसँग 60-70% भार छ। र यदि हामीले यो ट्युनिङ प्रयोग गर्छौं भने पनि, यसले राम्रोसँग काम गर्दैन।

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

जब हामी पहिले नै फोहोर चयन गर्दैछौं र हामीसँग छ, उदाहरणका लागि, मेटाइएको झण्डा

Postgres मा Autovacuum ले यो स्वचालित रूपमा गर्छ।

ओह, उसले गर्छ?

Autovacuum फोहोर सङ्कलन हो।

धन्यवाद!

रिपोर्ट को लागी धन्यवाद! के त्यहाँ सबै फोहोरहरू मुख्य टेबलबाट छेउमा फोहोर हुने गरी विभाजन गरेर तुरुन्तै डाटाबेस डिजाइन गर्ने विकल्प छ?

अवश्य पनि छ।

यदि हामीले प्रयोग गर्न नहुने टेबल लक गरेका छौं भने के यो आफैलाई बचाउन सम्भव छ?

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

स्रोत: www.habr.com