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

दूरच्या भविष्यात कधीतरी, अनावश्यक डेटा स्वयंचलितपणे काढून टाकणे हे डीबीएमएस [१] च्या महत्त्वपूर्ण कार्यांपैकी एक असेल. यादरम्यान, अनावश्यक डेटा हटवण्याची किंवा कमी खर्चिक स्टोरेज सिस्टीममध्ये हलवण्याची काळजी आपण स्वतः घेणे आवश्यक आहे. समजा तुम्ही काही दशलक्ष पंक्ती हटवण्याचा निर्णय घेतला आहे. एक अगदी सोपे कार्य, विशेषत: जर स्थिती ज्ञात असेल आणि योग्य निर्देशांक असेल. "टेबल१ पासून हटवा जेथे col1 = :value" - काय सोपे असू शकते, बरोबर?

व्हिडिओ:

• मी पहिल्या वर्षापासून म्हणजे 2007 पासून हायलोड कार्यक्रम समितीवर आहे.

• आणि मी 2005 पासून पोस्टग्रेस सोबत आहे. अनेक प्रकल्पांमध्ये त्याचा वापर केला.

• 2007 पासून RuPostges सह गट.

• आम्ही Meetup मध्ये 2100+ सहभागी झालो आहोत. दीर्घकाळ सॅन फ्रान्सिस्कोने मागे टाकलेल्या न्यूयॉर्कनंतर हे जगातील दुसरे स्थान आहे.

• मी अनेक वर्षांपासून कॅलिफोर्नियामध्ये राहतो. मी मोठ्या कंपन्यांसह अमेरिकन कंपन्यांशी अधिक व्यवहार करतो. ते पोस्टग्रेसचे सक्रिय वापरकर्ते आहेत. आणि सर्व प्रकारच्या मनोरंजक गोष्टी आहेत.

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

जर तुम्ही काही करत असाल तर काही वेळा पोस्टग्रेसच्या आसपास काही प्रकारचे प्लग असतात. समजा तुम्ही तुमच्यासाठी चाचणी स्टँड सेट करण्यासाठी अॅडमिनची वाट पाहणे आवश्यक आहे किंवा तुम्हाला प्रतिसाद देण्यासाठी DBA ची वाट पाहणे आवश्यक आहे. आणि आम्हाला विकास, चाचणी आणि प्रशासन प्रक्रियेत असे अडथळे आढळतात आणि ऑटोमेशन आणि नवीन पद्धतींच्या मदतीने ते दूर करण्याचा प्रयत्न करतो.

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

मी अलीकडे लॉस एंजेलिसमधील VLDB मध्ये होतो. डेटाबेसवरील ही सर्वात मोठी परिषद आहे. आणि असा अहवाल आला की भविष्यात डीबीएमएस केवळ संचयित करणार नाही तर स्वयंचलितपणे डेटा देखील हटवेल. हा नवीन विषय आहे.

झेटाबाइट्सच्या जगात अधिकाधिक डेटा आहे - म्हणजे 1 पेटाबाइट्स. आणि आता असा अंदाज आहे की आमच्याकडे जगात 000 झेटाबाइट्सपेक्षा जास्त डेटा संग्रहित आहे. आणि त्यापैकी अधिक आणि अधिक आहेत.

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

आणि त्याचे काय करायचे? साहजिकच ते काढून टाकण्याची गरज आहे. या मनोरंजक अहवालाची लिंक येथे आहे. परंतु आतापर्यंत डीबीएमएसमध्ये याची अंमलबजावणी झालेली नाही.

ज्यांना पैसे मोजता येतात त्यांना दोन गोष्टी हव्या असतात. आम्ही हटवावे अशी त्यांची इच्छा आहे, त्यामुळे तांत्रिकदृष्ट्या आम्ही ते करू शकले पाहिजे.

मी पुढे काय सांगेन ती काही अमूर्त परिस्थिती ज्यामध्ये वास्तविक परिस्थितींचा समावेश आहे, म्हणजे माझ्या आणि आजूबाजूच्या डेटाबेसमध्ये अनेक वेळा, अनेक वर्षांनी काय घडले याचे एक प्रकारचे संकलन. रेक सर्वत्र असतात आणि प्रत्येकजण सतत त्यांच्यावर पाऊल ठेवतो.

समजा आपल्याकडे एक बेस किंवा अनेक बेस आहेत जे वाढत आहेत. आणि काही रेकॉर्ड उघडपणे रद्दी आहेत. उदाहरणार्थ, वापरकर्त्याने तेथे काहीतरी करणे सुरू केले, परंतु ते पूर्ण केले नाही. आणि काही काळानंतर आपल्याला माहित आहे की हे अपूर्ण यापुढे संग्रहित केले जाऊ शकत नाही. म्हणजेच, जागा वाचवण्यासाठी, कार्यप्रदर्शन सुधारण्यासाठी आम्ही काही कचरा साफ करू इच्छितो.

सर्वसाधारणपणे, काही टेबलमधील विशिष्ट गोष्टी, विशिष्ट रेषा स्वयंचलितपणे हटविणे हे कार्य आहे.

आणि आमच्याकडे अशी विनंती आहे, ज्याबद्दल आम्ही आज बोलणार आहोत, म्हणजे कचरा काढण्याबद्दल.

आम्ही एका अनुभवी विकसकाला ते करण्यास सांगितले. त्याने ही विनंती घेतली, ते स्वतःसाठी तपासले - सर्वकाही कार्य करते. स्टेजिंगवर चाचणी केली - सर्वकाही ठीक आहे. बाहेर आणले - सर्वकाही कार्य करते. दिवसातून एकदा आम्ही ते चालवतो - सर्व काही ठीक आहे.

डेटाबेस वाढतो आणि वाढतो. दैनिक DELETE थोडे अधिक हळू काम करू लागते.

मग आम्हाला समजले की आता आमच्याकडे एक विपणन कंपनी आहे आणि रहदारी अनेक पटींनी मोठी असेल, म्हणून आम्ही अनावश्यक गोष्टींना तात्पुरते विराम देण्याचा निर्णय घेतला. आणि परत यायला विसरा.

काही महिन्यांनी त्यांची आठवण झाली. आणि त्या विकासकाने ते सोडले किंवा दुसर्‍या कशात व्यस्त आहे, दुसर्‍याला ते परत करण्याची सूचना दिली.

त्याने dev वर, स्टेजिंगवर तपासले - सर्वकाही ठीक आहे. स्वाभाविकच, जे जमा झाले आहे ते आपल्याला अद्याप साफ करणे आवश्यक आहे. त्याने सर्व काम तपासले.

पुढे काय होणार? मग आपल्यासाठी सर्व काही वेगळे होते. ते इतके घसरते की काही क्षणी सर्वकाही खाली पडते. प्रत्येकजण शॉकमध्ये आहे, काय होत आहे हे कोणालाच समजत नाही. आणि मग हे प्रकरण या DELETE मध्ये होते हे कळते.

काहीतरी चूक झाली? काय चूक झाली असेल याची यादी येथे आहे. यापैकी सर्वात महत्वाचे कोणते?

• उदाहरणार्थ, कोणतेही पुनरावलोकन नव्हते, म्हणजे डीबीए तज्ञाने ते पाहिले नाही. त्याला अनुभवी डोळ्याने समस्या ताबडतोब सापडेल आणि त्याशिवाय, त्याच्याकडे प्रॉडमध्ये प्रवेश आहे, जिथे अनेक दशलक्ष ओळी जमा झाल्या आहेत.

• कदाचित त्यांनी काहीतरी चुकीचे तपासले असेल.

• कदाचित हार्डवेअर जुने झाले आहे आणि तुम्हाला हा बेस अपग्रेड करणे आवश्यक आहे.

• किंवा डेटाबेसमध्येच काहीतरी चूक आहे आणि आम्हाला पोस्टग्रेस वरून MySQL वर जाण्याची आवश्यकता आहे.

• किंवा कदाचित ऑपरेशनमध्ये काहीतरी चूक आहे.

• कदाचित कामाच्या संस्थेमध्ये काही चुका आहेत आणि आपल्याला एखाद्याला काढून टाकण्याची आणि सर्वोत्तम लोकांना नियुक्त करण्याची आवश्यकता आहे?

DBA चेक नव्हता. जर तेथे डीबीए असेल, तर त्याला या लाखो ओळी दिसतील आणि कोणतेही प्रयोग न करताही तो म्हणेल: "ते तसे करत नाहीत." समजा जर हा कोड GitLab, GitHub मध्ये असेल आणि कोड पुनरावलोकन प्रक्रिया असेल आणि DBA च्या मान्यतेशिवाय हे ऑपरेशन prod वर केले जाईल असे नाही, तर DBA म्हणेल: "हे केले जाऊ शकत नाही. "

आणि तो म्हणेल की तुम्हाला डिस्क IO मध्ये समस्या असतील आणि सर्व प्रक्रिया विलक्षण होतील, लॉक असू शकतात आणि तुम्ही ऑटोव्हॅक्यूमला काही मिनिटांसाठी ब्लॉक कराल, म्हणून हे चांगले नाही.

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

दुसरी चूक - त्यांनी चुकीच्या ठिकाणी तपासले. उत्पादनावर भरपूर जंक डेटा जमा झाल्याची वस्तुस्थिती आम्‍ही पाहिली, परंतु विकसकाने या डेटाबेसमध्‍ये डेटा जमा केला नाही आणि स्टेजिंग दरम्यान ही जंक कोणीही तयार केली नाही. त्यानुसार, 1 ओळी होत्या ज्या त्वरीत पूर्ण झाल्या.

आम्ही समजतो की आमच्या चाचण्या कमकुवत आहेत, म्हणजेच तयार केलेल्या प्रक्रियेमध्ये समस्या येत नाहीत. पुरेसा DB प्रयोग केला गेला नाही.

एक आदर्श प्रयोग शक्यतो त्याच उपकरणांवर केला जातो. समान उपकरणांवर हे करणे नेहमीच शक्य नसते, परंतु ते डेटाबेसची पूर्ण-आकाराची प्रत असणे फार महत्वाचे आहे. मी गेल्या अनेक वर्षांपासून हाच प्रचार करत आहे. आणि एक वर्षापूर्वी मी याबद्दल बोललो होतो, आपण हे सर्व YouTube वर पाहू शकता.

कदाचित आमची उपकरणे खराब आहेत? बघितलं तर लेटन्सी उडी मारली. आम्ही पाहिले आहे की उपयोग १००% आहे. अर्थात, जर या आधुनिक NVMe ड्राइव्हस् असत्या, तर ते आपल्यासाठी खूप सोपे झाले असते. आणि कदाचित आम्ही त्यापासून खाली पडणार नाही.

जर तुमच्याकडे ढग असतील तर तिथे अपग्रेड सहज करता येईल. नवीन हार्डवेअरवर नवीन प्रतिकृती तयार केल्या. स्विचओव्हर आणि सर्व ठीक आहे. तेही सोपे.

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

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

पोस्टग्रेसमधील सेटिंग्ज मागे पडत आहेत. ते 10-15 वर्षे जुन्या डेटा आणि व्यवहारांसाठी डिझाइन केलेले आहेत. आणि चेकपॉईंट अपवाद नाही.

आमच्या पोस्टग्रेस तपासणी अहवालातील माहिती ही आहे, म्हणजे स्वयंचलित आरोग्य तपासणी. आणि येथे काही टेराबाइट्सचा डेटाबेस आहे. आणि हे चांगले पाहिले जाऊ शकते की जवळजवळ 90% प्रकरणांमध्ये चेकपॉईंटची सक्ती केली जाते.

याचा अर्थ काय? तेथे दोन सेटिंग्ज आहेत. चेकपॉईंट कालबाह्य होऊन येऊ शकते, उदाहरणार्थ, 10 मिनिटांनी. किंवा जेव्हा भरपूर डेटा भरला गेला असेल तेव्हा ते येऊ शकते.

आणि बाय डीफॉल्ट max_wal_saze 1 गीगाबाइट वर सेट केले आहे. खरं तर, पोस्टग्रेसमध्ये 300-400 मेगाबाइट्स नंतर हे खरोखर घडते. तुम्ही इतका डेटा बदलला आहे आणि तुमचा चेकपॉईंट होतो.

आणि जर कोणीही ते ट्यून केले नाही, आणि सेवा वाढली, आणि कंपनीने भरपूर पैसे कमावले, त्यात बरेच व्यवहार आहेत, तर चेकपॉईंट मिनिटातून एकदा येतो, कधीकधी प्रत्येक 30 सेकंदात, आणि कधीकधी ओव्हरलॅप देखील होतो. हे खूपच वाईट आहे.

आणि ते कमी वारंवार येत असल्याचे सुनिश्चित करणे आवश्यक आहे. म्हणजेच, आपण max_wal_size वाढवू शकतो. आणि ते कमी वारंवार येईल.

परंतु आम्ही ते अधिक योग्यरित्या कसे करावे यासाठी एक संपूर्ण कार्यपद्धती विकसित केली आहे, म्हणजे, विशिष्ट डेटाच्या आधारे स्पष्टपणे सेटिंग्ज निवडण्याबद्दल निर्णय कसा घ्यावा.

त्यानुसार आम्ही डेटाबेसवर दोन मालिका प्रयोग करत आहोत.

पहिली मालिका - आम्ही max_wal_size बदलतो. आणि आम्ही एक मोठे ऑपरेशन करत आहोत. प्रथम, आम्ही ते 1 गीगाबाइटच्या डीफॉल्ट सेटिंगवर करतो. आणि आम्ही लाखो ओळींचा मोठ्या प्रमाणावर DELETE करतो.

आमच्यासाठी ते किती कठीण आहे ते तुम्ही पाहू शकता. आम्ही पाहतो की डिस्क IO खूप खराब आहे. आम्ही किती WAL व्युत्पन्न केले ते पाहतो, कारण हे खूप महत्वाचे आहे. बघू कितीवेळा चौकी झाली. आणि आपण पाहतो की ते चांगले नाही.

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

आणि अशा प्रकारे आम्ही आमच्या सिस्टमची देवाणघेवाण करू, आणि खराब वस्तुमान DELETE झाल्यास DBMS कसे वागेल, ते कसे चेकपॉइंट करेल हे आम्हाला माहित आहे.

रशियनमध्ये चेकपॉईंट चेकपॉईंट आहेत.

उदाहरण: अनुक्रमणिकेनुसार अनेक दशलक्ष पंक्ती हटवा, पंक्ती पृष्ठांवर "विखुरलेल्या" आहेत.

येथे एक उदाहरण आहे. हा काही आधार आहे. आणि max_wal_size साठी 1 gigabyte च्या डिफॉल्ट सेटिंगसह, हे अगदी स्पष्ट आहे की आमच्या डिस्क रेकॉर्डिंगसाठी शेल्फवर जातात. हे चित्र अत्यंत आजारी रुग्णाचे वैशिष्ट्यपूर्ण लक्षण आहे, म्हणजेच त्याला खरोखर वाईट वाटले. आणि तेथे एकच ऑपरेशन होते, अनेक दशलक्ष ओळींचा फक्त एक हटवा होता.

जर अशा ऑपरेशनला प्रोडमध्ये परवानगी असेल, तर आम्ही फक्त झोपू, कारण हे स्पष्ट आहे की एक DELETE आम्हाला शेल्फमध्ये मारतो.

पुढे, जिथे 16 गीगाबाइट्स, हे स्पष्ट आहे की दात आधीच गेले आहेत. दात आधीच चांगले आहेत, म्हणजे, आम्ही कमाल मर्यादा ठोठावत आहोत, परंतु इतके वाईट नाही. तिथे थोडं स्वातंत्र्य होतं. उजवीकडे रेकॉर्ड आहे. आणि ऑपरेशन्सची संख्या - दुसरा आलेख. आणि हे स्पष्ट आहे की 16 गीगाबाइट्स असताना आम्ही आधीच थोडे सोपे श्वास घेत आहोत.

आणि जिथे 64 गीगाबाइट्स पाहिले जाऊ शकतात ते पूर्णपणे चांगले झाले आहे. आधीच दात उच्चारले जातात, इतर ऑपरेशन्स टिकून राहण्यासाठी आणि डिस्कसह काहीतरी करण्याची अधिक संधी आहेत.

असे का

मी तपशीलांमध्ये थोडेसे जाईन, परंतु हा विषय, चेकपॉईंट ट्यूनिंग कसे चालवायचे, याचा परिणाम संपूर्ण अहवालात होऊ शकतो, म्हणून मी जास्त लोड करणार नाही, परंतु तेथे कोणत्या अडचणी आहेत याची मी थोडीशी रूपरेषा सांगेन.

जर चेकपॉईंट बर्‍याचदा घडत असेल आणि आम्ही आमच्या ओळी क्रमाक्रमाने अद्यतनित केल्या नाहीत, परंतु अनुक्रमणिकेनुसार शोधा, जे चांगले आहे, कारण आम्ही संपूर्ण सारणी हटवत नाही, तर असे होऊ शकते की प्रथम आम्ही पहिल्या पृष्ठाला स्पर्श केला, नंतर हजारव्या, आणि नंतर पहिल्याकडे परतलो. आणि जर पहिल्या पृष्ठावरील या भेटींदरम्यान, चेकपॉईंटने ते आधीच डिस्कवर जतन केले असेल, तर ते ते पुन्हा जतन करेल, कारण आम्हाला ते दुसऱ्यांदा गलिच्छ झाले आहे.

आणि आम्ही चेकपॉईंटला बर्याच वेळा जतन करण्यासाठी सक्ती करू. त्याच्यासाठी अनावश्यक ऑपरेशन्स कसे असतील.

पण एवढेच नाही. पृष्ठे पोस्टग्रेसमध्ये 8 किलोबाइट्स आणि लिनक्समध्ये 4 किलोबाइट्स आहेत. आणि पूर्ण_पृष्ठ_लेखन सेटिंग आहे. हे डीफॉल्टनुसार सक्षम केलेले आहे. आणि हे बरोबर आहे, कारण जर आपण ते बंद केले तर, क्रॅश झाल्यास केवळ अर्धे पृष्ठ जतन होईल असा धोका आहे.

फॉरवर्ड लॉगच्या WAL ला लिहिण्याचे वर्तन असे आहे की जेव्हा आमच्याकडे चेकपॉईंट असते आणि आम्ही प्रथमच पृष्ठ बदलतो तेव्हा संपूर्ण पृष्ठ, म्हणजे, सर्व 8 किलोबाइट्स, फॉरवर्ड लॉगमध्ये प्रवेश करतात, जरी आम्ही फक्त बदलले. ओळ, ज्याचे वजन 100 बाइट्स आहे. आणि आपल्याला संपूर्ण पान लिहावे लागेल.

त्यानंतरच्या बदलांमध्ये फक्त एक विशिष्ट टपल असेल, परंतु प्रथमच आम्ही सर्वकाही लिहून ठेवतो.

आणि, त्यानुसार, चेकपॉईंट पुन्हा घडल्यास, आपल्याला पुन्हा सुरवातीपासून सर्वकाही सुरू करावे लागेल आणि संपूर्ण पृष्ठ ढकलावे लागेल. वारंवार चेकपॉईंटसह, जेव्हा आपण त्याच पृष्ठांवरून फिरतो, तेव्हा full_page_writes = on शक्यतेपेक्षा जास्त असेल, म्हणजे आपण अधिक WAL तयार करतो. अधिक प्रतिकृती, संग्रहण, डिस्कवर पाठवले जाते.

आणि, त्यानुसार, आमच्याकडे दोन रिडंडंसी आहेत.

आम्ही max_wal_size वाढवल्यास, असे दिसून येते की आम्ही चेकपॉईंट आणि वाल लेखक या दोघांसाठी ते सोपे करतो. आणि ते छान आहे.

चला एक टेराबाइट टाकू आणि त्यासोबत जगू. त्यात वाईट काय आहे? हे वाईट आहे, कारण अयशस्वी झाल्यास, आम्ही तासभर चढू, कारण चेकपॉईंट खूप पूर्वीचे होते आणि बरेच काही बदलले आहे. आणि आपल्याला हे सर्व REDO करावे लागेल. आणि म्हणून आम्ही प्रयोगांची दुसरी मालिका करतो.

आम्ही ऑपरेशन करतो आणि चेकपॉईंट कधी पूर्ण होणार आहे ते पाहतो, आम्ही हेतुपुरस्सर -9 पोस्टग्रेस मारतो.

आणि त्यानंतर आम्ही ते पुन्हा सुरू करतो आणि या उपकरणावर ते किती काळ वाढेल ते पहा, म्हणजे या वाईट परिस्थितीत ते किती REDO होईल.

परिस्थिती वाईट आहे हे मी दोनदा लक्षात घेईन. प्रथम, आम्ही चेकपॉईंट संपण्यापूर्वीच क्रॅश झालो, त्यामुळे आम्हाला बरेच काही गमावायचे आहे. आणि दुसरे म्हणजे, आमचे एक मोठे ऑपरेशन झाले. आणि जर चेकपॉईंट कालबाह्य झाले असतील, तर, बहुधा, शेवटच्या चेकपॉईंटपासून कमी WAL व्युत्पन्न होईल. म्हणजेच तो दुहेरी तोटा आहे.

आम्ही अशी परिस्थिती वेगवेगळ्या max_wal_size आकारांसाठी मोजतो आणि समजतो की जर max_wal_size 64 gigabytes असेल, तर दुहेरी सर्वात वाईट परिस्थितीत आम्ही 10 मिनिटे चढू. आणि आपण विचार करतो की ते आपल्याला अनुकूल आहे की नाही. हा एक व्यावसायिक प्रश्न आहे. आम्हाला हे चित्र व्यावसायिक निर्णयांसाठी जबाबदार असलेल्यांना दाखवावे लागेल आणि विचारावे लागेल, “एखादी समस्या उद्भवल्यास आम्ही जास्तीत जास्त किती वेळ झोपू शकतो? आपण सर्वात वाईट परिस्थितीत 3-5 मिनिटे झोपू शकतो का? आणि तुम्ही निर्णय घ्या.

आणि येथे एक मनोरंजक मुद्दा आहे. आमच्याकडे परिषदेत संरक्षकांबद्दलचे दोन अहवाल आहेत. आणि कदाचित तुम्ही ते वापरत असाल. पोस्टग्रेससाठी हे ऑटोफेलओव्हर आहे. GitLab आणि Data Egret याविषयी बोलले.

आणि जर तुमच्याकडे ऑटोफेलओव्हर असेल जो 30 सेकंदात येतो, तर कदाचित आम्ही 10 मिनिटे झोपू शकतो? कारण आम्ही या टप्प्यापर्यंत प्रतिकृतीवर स्विच करू आणि सर्व काही ठीक होईल. हा एक महत्त्वाचा मुद्दा आहे. मला स्पष्ट उत्तर माहित नाही. मला असे वाटते की हा विषय केवळ क्रॅश रिकव्हरीच्या आसपास नाही.

अयशस्वी झाल्यानंतर दीर्घकाळ पुनर्प्राप्ती झाल्यास, इतर अनेक परिस्थितींमध्ये आपण अस्वस्थ होऊ. उदाहरणार्थ, त्याच प्रयोगांमध्ये, जेव्हा आपण काहीतरी करतो आणि कधीकधी 10 मिनिटे थांबावे लागते.

आमच्याकडे ऑटोफेलओव्हर असला तरीही मी अजूनही फार दूर जाणार नाही. नियमानुसार, 64, 100 गीगाबाइट्स सारखी मूल्ये चांगली मूल्ये आहेत. कधीकधी ते कमी निवडणे देखील योग्य असते. सर्वसाधारणपणे, हे एक सूक्ष्म विज्ञान आहे.

पुनरावृत्ती करण्यासाठी, उदाहरणार्थ, max_wal_size =1, 8, तुम्हाला मास ऑपरेशन अनेक वेळा पुन्हा करावे लागेल. तू करून दाखवलस. आणि त्याच आधारावर तुम्हाला ते पुन्हा करायचे आहे, परंतु तुम्ही आधीच सर्वकाही हटवले आहे. काय करायचं?

अशा परिस्थितीत पुनरावृत्ती करण्यासाठी आम्ही काय करतो, आम्ही आमच्या उपायाबद्दल नंतर बोलू. आणि हा सर्वात योग्य दृष्टीकोन आहे.

पण या प्रकरणात आम्ही भाग्यवान होतो. जर, इथे म्हटल्याप्रमाणे "BEGIN, DELETE, ROLLBACK", तर आपण DELETE पुन्हा करू शकतो. म्हणजेच, जर आपण ते स्वतः रद्द केले असेल तर आपण ते पुन्हा करू शकतो. आणि भौतिकदृष्ट्या तुमच्याकडे डेटा त्याच ठिकाणी असेल. तुम्हाला फुगवटाही येत नाही. तुम्ही अशा DELETEs वर पुनरावृत्ती करू शकता.

ROLLBACK सह हे DELETE चेकपॉईंट ट्यूनिंगसाठी आदर्श आहे, जरी तुमच्याकडे डेटाबेस लॅब योग्यरित्या तैनात नसल्या तरीही.

आम्ही एका स्तंभ "i" सह एक प्लेट बनविली. Postgres मध्ये उपयुक्तता स्तंभ आहेत. विशेषत: मागितल्याशिवाय ते अदृश्य असतात. हे आहेत: ctid, xmid, xmax.

Ctid हा एक भौतिक पत्ता आहे. शून्य पृष्ठ, पृष्ठातील पहिले टपल.

हे पाहिले जाऊ शकते की ROOLBACK नंतर ट्यूपल त्याच ठिकाणी राहिले. म्हणजेच, आपण पुन्हा प्रयत्न करू शकतो, ते त्याच प्रकारे वागेल. ही मुख्य गोष्ट आहे.

Xmax हा टपलच्या मृत्यूचा काळ आहे. त्यावर शिक्का मारण्यात आला होता, परंतु पोस्टग्रेसला माहित आहे की व्यवहार परत आणला गेला आहे, त्यामुळे तो 0 आहे किंवा तो रोल बॅक व्यवहार आहे हे महत्त्वाचे नाही. हे सूचित करते की DELETE वर पुनरावृत्ती करणे आणि सिस्टीम वर्तनाची मोठ्या प्रमाणात ऑपरेशन्स तपासणे शक्य आहे. तुम्ही गरिबांसाठी डेटाबेस लॅब बनवू शकता.

हे प्रोग्रामरबद्दल आहे. डीबीए बद्दल देखील, ते यासाठी प्रोग्रामरना नेहमी खडसावतात: "तुम्ही इतके लांब आणि कठीण ऑपरेशन का करत आहात?". हा पूर्णपणे वेगळा लंब विषय आहे. पूर्वी प्रशासन होते, आता विकास होणार आहे.

साहजिकच, आम्ही तुकडे तुकडे केले नाहीत. हे स्पष्ट आहे. अशा DELETE ला लाखो ओळींच्या ढीग भागांमध्ये खंडित न करणे अशक्य आहे. हे 20 मिनिटे केले जाईल, आणि सर्व काही आडवे होईल. परंतु, दुर्दैवाने, अगदी मोठ्या कंपन्यांमध्ये देखील अनुभवी विकासक चुका करतात.

तोडणे महत्वाचे का आहे?

• जर आपल्याला दिसले की डिस्क हार्ड आहे, तर चला ते कमी करूया. आणि जर आपण तुटलो आहोत, तर आपण विराम जोडू शकतो, आपण थ्रॉटलिंग कमी करू शकतो.

• आणि आम्ही इतरांना बर्याच काळासाठी अवरोधित करणार नाही. काही प्रकरणांमध्ये काही फरक पडत नाही, जर तुम्ही वास्तविक कचरा हटवत असाल ज्यावर कोणीही काम करत नसेल, तर बहुधा तुम्ही ऑटोव्हॅक्यूम कार्य वगळता कोणालाही ब्लॉक करणार नाही, कारण ते व्यवहार पूर्ण होण्याची प्रतीक्षा करेल. पण तुम्ही एखादी गोष्ट काढून टाकली की ज्याची कोणीतरी विनंती करू शकते, तर ते ब्लॉक केले जातील, एक प्रकारची साखळी प्रतिक्रिया असेल. वेबसाइट्स आणि मोबाईल ऍप्लिकेशन्सवर लांबचे व्यवहार टाळावेत.

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

हे मनोरंजक आहे. मी अनेकदा पाहतो की विकासक विचारतात: "मी कोणता पॅक आकार निवडावा?".

हे स्पष्ट आहे की बंडलचा आकार जितका मोठा असेल तितका व्यवहार ओव्हरहेड लहान असेल, म्हणजे, व्यवहारांमधून अतिरिक्त ओव्हरहेड. परंतु त्याच वेळी, या व्यवहारासाठी वेळ वाढतो.

माझा एक अतिशय सोपा नियम आहे: तुम्ही जितके घेऊ शकता तितके घ्या, परंतु प्रति सेकंद एक्झिक्युटेबलच्या वर जाऊ नका.

एक सेकंद का? स्पष्टीकरण अगदी सोपे आणि प्रत्येकासाठी समजण्यासारखे आहे, अगदी गैर-तांत्रिक लोकांनाही. आम्ही एक प्रतिक्रिया पाहतो. चला 50 मिलीसेकंद घेऊ. जर काहीतरी बदलले असेल तर आपली नजर प्रतिक्रिया देईल. जर कमी असेल तर अधिक कठीण. जर एखादी गोष्ट 100 मिलीसेकंदांनंतर प्रतिसाद देत असेल, उदाहरणार्थ, तुम्ही माउसवर क्लिक केले आणि 100 मिलीसेकंदांनी तुम्हाला उत्तर दिले, तर तुम्हाला आधीच हा थोडा विलंब जाणवत आहे. एक सेकंद आधीच ब्रेक म्हणून समजला जातो.

त्यानुसार, जर आम्ही आमची मास ऑपरेशन्स 10-सेकंदात मोडली, तर आम्हाला धोका आहे की आम्ही एखाद्याला ब्लॉक करू. आणि ते काही सेकंदांसाठी कार्य करेल आणि लोकांना ते आधीच लक्षात येईल. म्हणून, मी एका सेकंदापेक्षा जास्त न करणे पसंत करतो. परंतु त्याच वेळी, ते अगदी बारीकपणे खंडित करू नका, कारण व्यवहार ओव्हरहेड लक्षात येईल. पाया कठीण होईल, आणि इतर विविध समस्या उद्भवू शकतात.

आम्ही पॅकचा आकार निवडतो. प्रत्येक बाबतीत, आम्ही ते वेगळ्या पद्धतीने करू शकतो. स्वयंचलित करता येते. आणि आम्हाला एका पॅकच्या प्रक्रियेच्या कार्यक्षमतेबद्दल खात्री आहे. म्हणजेच, आम्ही एक पॅक हटवतो किंवा अपडेट करतो.

तसे, मी जे काही बोलत आहे ते फक्त DELETE बद्दलच नाही. तुम्ही अंदाज लावल्याप्रमाणे, ही डेटावरील कोणतीही मोठ्या प्रमाणात ऑपरेशन्स आहेत.

आणि आम्ही पाहतो की योजना उत्कृष्ट आहे. तुम्ही इंडेक्स स्कॅन पाहू शकता, फक्त इंडेक्स स्कॅन अधिक चांगले आहे. आणि आमच्याकडे थोड्या प्रमाणात डेटा गुंतलेला आहे. आणि एका सेकंदापेक्षा कमी पूर्ण होते. उत्कृष्ट.

आणि तरीही कोणतीही अधोगती होणार नाही याची काळजी घेणे आवश्यक आहे. असे घडते की प्रथम पॅक त्वरीत कार्य करतात आणि नंतर ते खराब, वाईट आणि वाईट होते. प्रक्रिया अशी आहे की आपल्याला खूप चाचणी घ्यावी लागेल. डेटाबेस लॅबसाठी नेमके हेच आहे.

आणि आम्हाला अजूनही काहीतरी तयार करायचे आहे जेणेकरुन ते आम्हाला उत्पादनात याचे योग्यरित्या पालन करण्यास अनुमती देईल. उदाहरणार्थ, आपण लॉगमध्ये वेळ लिहू शकतो, आपण आता कुठे आहोत आणि आता कोण हटवले आहे हे लिहू शकतो. आणि हे आपल्याला नंतर काय होत आहे हे समजून घेण्यास अनुमती देईल. आणि काहीतरी चूक झाल्यास, समस्या त्वरित शोधा.

जर आम्हाला विनंत्यांची कार्यक्षमता तपासायची असेल आणि आम्हाला बर्‍याच वेळा पुनरावृत्ती करायची असेल, तर सहकारी बॉट सारखी गोष्ट आहे. तो आधीच तयार आहे. हे दररोज डझनभर विकासक वापरतात. आणि विनंती केल्यावर ३० सेकंदात तुमची स्वतःची प्रत कशी द्यायची हे त्याला माहीत आहे. आणि तुम्ही तिथे काहीतरी हटवू शकता आणि RESET म्हणू शकता आणि ते पुन्हा हटवू शकता. तुम्ही अशा प्रकारे प्रयोग करू शकता. मला या गोष्टीचे भविष्य दिसत आहे. आणि आम्ही ते आधीच करत आहोत.

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

विभाजन धोरण काय आहेत? मला 3 भिन्न विभाजन धोरणे दिसत आहेत ज्या पॅकवरील विकसक वापरत आहेत.

पहिला अगदी सोपा आहे. आमच्याकडे संख्यात्मक आयडी आहे. आणि ते वेगवेगळ्या कालांतराने खंडित करू आणि त्यासह कार्य करूया. नकारात्मक बाजू स्पष्ट आहे. पहिल्या विभागात, आमच्याकडे वास्तविक कचरा 100 ओळी असू शकतात, दुसर्‍या 5 ओळींमध्ये किंवा अजिबात नाही, किंवा सर्व 1 ओळी कचरा बनतील. खूप असमान काम, परंतु ते खंडित करणे सोपे आहे. त्यांनी कमाल आयडी घेऊन तो फोडला. हा एक भोळा दृष्टिकोन आहे.

दुसरी रणनीती म्हणजे संतुलित दृष्टीकोन. हे गिटलॅबमध्ये वापरले जाते. त्यांनी टेबल घेतले आणि स्कॅन केले. आम्हाला आयडी पॅकच्या सीमा आढळल्या जेणेकरून प्रत्येक पॅकमध्ये 10 रेकॉर्ड असतील. आणि त्यांना एका रांगेत उभे करा. आणि मग आम्ही प्रक्रिया करतो. तुम्ही हे अनेक थ्रेड्समध्ये करू शकता.

पहिल्या रणनीतीमध्ये, तसे, आपण हे अनेक थ्रेडमध्ये करू शकता. ते अवघड नाही.

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

पण एक थंड आणि चांगला दृष्टीकोन आहे. ही तिसरी रणनीती आहे. आणि जेव्हा शक्य असेल तेव्हा ते निवडणे चांगले. आम्ही हे विशेष निर्देशांकाच्या आधारे करतो. या प्रकरणात, ते बहुधा आमच्या कचरा स्थिती आणि आयडीनुसार अनुक्रमणिका असेल. आम्ही आयडी समाविष्ट करू जेणेकरुन ते फक्त इंडेक्स स्कॅन असेल जेणेकरून आम्ही ढिगाऱ्यावर जाऊ नये.

साधारणपणे, फक्त इंडेक्स स्कॅन इंडेक्स स्कॅनपेक्षा वेगवान आहे.

आणि आम्हाला आमचे आयडी पटकन सापडतात जे आम्हाला काढायचे आहेत. BATCH_SIZE आम्ही आगाऊ निवडतो. आणि आम्ही ते केवळ मिळवत नाही, तर आम्ही त्यांना एका खास मार्गाने मिळवतो आणि ताबडतोब हॅक करतो. पण आम्ही लॉक करत आहोत जेणेकरून ते आधीच लॉक केलेले असतील तर आम्ही त्यांना कुलूप लावत नाही, तर पुढे जाऊ आणि पुढील घेऊ. हे अपडेट वगळण्यासाठी लॉक केलेले आहे. Postgres चे हे सुपर फीचर आम्हाला हवे असल्यास अनेक थ्रेड्समध्ये काम करू देते. एका प्रवाहात ते शक्य आहे. आणि इथे एक CTE आहे - ही एक विनंती आहे. आणि आमच्याकडे या सीटीईच्या दुसऱ्या मजल्यावर एक वास्तविक हटवण्याचे काम सुरू आहे - returning *. आपण आयडी परत करू शकता, परंतु ते चांगले आहे *जर तुमच्याकडे प्रत्येक ओळीवर जास्त डेटा नसेल.

आम्हाला त्याची गरज का आहे? हे आम्हाला परत कळवण्याची गरज आहे. आम्ही आता खरं तर बर्‍याच ओळी हटवल्या आहेत. आणि आमच्याकडे आयडी द्वारे किंवा तयार_एट सारख्या सीमा आहेत. तुम्ही किमान, कमाल करू शकता. अजून काही करता येईल. आपण येथे भरपूर सामग्री करू शकता. आणि हे निरीक्षणासाठी खूप सोयीस्कर आहे.

निर्देशांकाबद्दल आणखी एक टीप आहे. जर आम्ही ठरवले की आम्हाला या कार्यासाठी विशेष निर्देशांकाची आवश्यकता आहे, तर आम्हाला हे सुनिश्चित करणे आवश्यक आहे की ते फक्त ट्यूपल्स अद्यतने खराब करणार नाही. म्हणजेच पोस्टग्रेसकडे अशी आकडेवारी आहे. हे तुमच्या टेबलसाठी pg_stat_user_tables मध्ये पाहिले जाऊ शकते. गरम अद्यतने वापरली जात आहेत की नाही हे आपण पाहू शकता.

अशी परिस्थिती असते जेव्हा तुमचा नवीन निर्देशांक त्यांना कापून टाकू शकतो. आणि तुमच्याकडे इतर सर्व अद्यतने आहेत जी आधीपासूनच कार्यरत आहेत, हळू करा. केवळ निर्देशांक दिसला म्हणून नाही (प्रत्येक निर्देशांक थोडासा कमी होतो, परंतु थोडासा) परंतु येथे तो अजूनही खराब होतो. आणि या टेबलसाठी विशेष ऑप्टिमायझेशन करणे अशक्य आहे. हे कधी कधी घडते. ही अशी सूक्ष्मता आहे जी फार कमी लोकांना आठवते. आणि या रेकवर पाऊल टाकणे सोपे आहे. काहीवेळा असे होते की आपल्याला दुसर्‍या बाजूने एक दृष्टीकोन शोधणे आवश्यक आहे आणि तरीही या नवीन निर्देशांकाशिवाय करणे आवश्यक आहे, किंवा दुसरी अनुक्रमणिका बनवा किंवा इतर काही मार्गाने, उदाहरणार्थ, आपण दुसरी पद्धत वापरू शकता.

परंतु ही सर्वात इष्टतम रणनीती आहे, बॅचेसमध्ये कसे विभाजित करावे आणि एका विनंतीसह बॅचवर शूट कसे करावे, थोडेसे हटवा इ.

लांबचे व्यवहार https://gitlab.com/snippets/1890447

अवरोधित ऑटोव्हॅक्यूम - https://gitlab.com/snippets/1889668

ब्लॉकिंग समस्या - https://gitlab.com/snippets/1890428

चूक #5 ही मोठी आहे. ओकमीटरमधील निकोलाई पोस्टग्रेस मॉनिटरिंगबद्दल बोलले. आदर्श पोस्टग्रेस मॉनिटरिंग, दुर्दैवाने, अस्तित्वात नाही. काही जवळ आहेत, काही दूर आहेत. Okmeter परिपूर्ण होण्यासाठी पुरेसे जवळ आहे, परंतु बरेच काही गहाळ आहे आणि जोडणे आवश्यक आहे. यासाठी तुम्ही तयार असणे आवश्यक आहे.

उदाहरणार्थ, मृत ट्यूपल्सचे सर्वोत्तम निरीक्षण केले जाते. जर तुमच्याकडे टेबलमध्ये बर्याच मृत वस्तू असतील तर काहीतरी चुकीचे आहे. आता प्रतिक्रिया देणे चांगले आहे, अन्यथा अधोगती होऊ शकते आणि आपण आडवे होऊ शकतो. असे घडत असते, असे घडू शकते.

जर मोठा आयओ असेल तर हे स्पष्ट आहे की हे चांगले नाही.

लांबचे व्यवहारही. ओएलटीपीवर दीर्घ व्यवहारांना परवानगी देऊ नये. आणि येथे स्निपेटचा एक दुवा आहे जो तुम्हाला हा स्निपेट घेण्यास आणि आधीच लांब व्यवहारांचा काही ट्रॅकिंग करण्यास अनुमती देतो.

लांबचे व्यवहार वाईट का असतात? कारण सर्व कुलूप फक्त शेवटी सोडले जातील. आणि आम्ही सर्वांना स्क्रू करतो. शिवाय, आम्ही सर्व टेबलांसाठी ऑटोव्हॅक्यूम ब्लॉक करतो. हे अजिबात चांगले नाही. जरी तुम्ही प्रतिकृतीवर हॉट स्टँडबाय सक्षम केले असले तरीही ते खराब आहे. सर्वसाधारणपणे, लांब व्यवहार टाळणे कोठेही चांगले नाही.

जर आमच्याकडे अनेक टेबल्स आहेत जे व्हॅक्यूम केलेले नाहीत, तर आम्हाला अलर्ट असणे आवश्यक आहे. येथे अशी परिस्थिती शक्य आहे. आम्ही अप्रत्यक्षपणे ऑटोव्हॅक्यूमच्या ऑपरेशनवर परिणाम करू शकतो. हे अविटोचे स्निपेट आहे, जे मी किंचित सुधारले आहे. आणि ऑटोव्हॅक्यूममध्ये आपल्याकडे काय आहे हे पाहण्यासाठी हे एक मनोरंजक साधन ठरले. उदाहरणार्थ, काही टेबल तिथे वाट पाहत आहेत आणि त्यांच्या वळणाची वाट पाहत नाहीत. तुम्हाला ते मॉनिटरिंगमध्ये ठेवणे आणि अलर्ट असणे देखील आवश्यक आहे.

आणि ब्लॉक जारी करतात. ब्लॉक झाडांचे जंगल. मला कोणाकडून काहीतरी घेऊन त्यात सुधारणा करायला आवडते. येथे मी डेटा एग्रेट कडून एक मस्त रिकर्सिव सीटीई घेतला जो लॉक ट्रीजचे जंगल दर्शवितो. हे एक चांगले निदान साधन आहे. आणि त्याच्या आधारावर, आपण देखरेख देखील तयार करू शकता. परंतु हे काळजीपूर्वक केले पाहिजे. तुम्हाला स्वतःसाठी एक लहान विधान_कालबाह्य करणे आवश्यक आहे. आणि लॉक_टाइमआउट इष्ट आहे.

कधीकधी या सर्व त्रुटी बेरीज मध्ये आढळतात.

माझ्या मते, येथे मुख्य चूक संघटनात्मक आहे. ते संघटनात्मक आहे, कारण तंत्र खेचत नाही. हा क्रमांक 2 आहे - त्यांनी चुकीच्या ठिकाणी तपासले.

आम्ही चुकीच्या ठिकाणी तपासले, कारण आमच्याकडे उत्पादन क्लोन नाही, जो तपासणे सोपे आहे. विकसकाला उत्पादनात अजिबात प्रवेश नसू शकतो.

आणि आम्ही तिथे तपासले नाही. आम्ही तिथे तपासले असते तर ते आम्ही स्वतः पाहिले असते. डेव्हलपरने हे सर्व DBA शिवाय देखील पाहिले, जर त्याने ते चांगल्या वातावरणात तपासले, जेथे समान प्रमाणात डेटा आणि एकसारखे स्थान आहे. ही सर्व अधोगती त्याने पाहिली असती आणि त्याला लाज वाटली असेल.

ऑटोव्हॅक्यूम बद्दल अधिक. आम्ही अनेक दशलक्ष ओळींचा मोठा स्वीप केल्यानंतर, आम्हाला अजूनही REPACK करणे आवश्यक आहे. हे विशेषतः निर्देशांकांसाठी महत्वाचे आहे. आम्ही तिथे सर्व काही साफ केल्यानंतर त्यांना वाईट वाटेल.

आणि जर तुम्हाला दैनंदिन साफसफाईचे काम परत आणायचे असेल तर मी ते अधिक वेळा करा, परंतु लहान असे सुचवेन. हे मिनिटातून एकदा किंवा त्याहून अधिक वेळा थोडेसे असू शकते. आणि आपल्याला दोन गोष्टींचे निरीक्षण करणे आवश्यक आहे: या गोष्टीमध्ये कोणतीही त्रुटी नाही आणि ती मागे नाही. मी दाखवलेली युक्ती हे फक्त सोडवेल.

आम्ही जे करतो ते ओपन सोर्स आहे. हे GitLab वर पोस्ट केले आहे. आणि आम्ही ते तयार करतो जेणेकरून लोक DBA शिवाय देखील तपासू शकतील. आम्ही डेटाबेस लॅब करत आहोत, म्हणजेच जो सध्या काम करत असलेल्या बेस घटकाला आम्ही कॉल करतो. आणि तुम्ही उत्पादनाची प्रत घेऊ शकता. आता स्लॅकसाठी जोची अंमलबजावणी आहे, तुम्ही तिथे म्हणू शकता: "अशा आणि अशा विनंतीचे स्पष्टीकरण द्या" आणि डेटाबेसच्या तुमच्या प्रतीसाठी लगेच निकाल मिळवा. तुम्ही तिथे DELETE देखील करू शकता आणि ते कोणाच्याही लक्षात येणार नाही.

समजा तुमच्याकडे 10 टेराबाइट्स आहेत, आम्ही डेटाबेस लॅब देखील 10 टेराबाइट्स बनवतो. आणि एकाच वेळी 10 टेराबाइट डेटाबेससह, 10 विकासक एकाच वेळी कार्य करू शकतात. प्रत्येकजण त्यांना पाहिजे ते करू शकतो. हटवू शकता, ड्रॉप करू शकता, ही एक कल्पनारम्य गोष्ट आहे. याविषयी आपण उद्या बोलू.

याला पातळ तरतूद म्हणतात. ही सूक्ष्म तरतूद आहे. ही एक प्रकारची कल्पनारम्य गोष्ट आहे जी विकासात, चाचणीतील विलंब मोठ्या प्रमाणात दूर करते आणि या संदर्भात जगाला एक चांगले स्थान बनवते. म्हणजेच, ते आपल्याला मोठ्या प्रमाणात ऑपरेशन्ससह समस्या टाळण्याची परवानगी देते.

उदाहरण: 5 टेराबाइट डेटाबेस, 30 सेकंदांपेक्षा कमी वेळेत कॉपी मिळवणे. आणि ते आकारावर देखील अवलंबून नाही, म्हणजेच किती टेराबाइट्स हे महत्त्वाचे नाही.

आज तुम्ही जाऊ शकता postgres.ai आणि आमच्या साधनांमध्ये खणणे. तेथे काय आहे ते पाहण्यासाठी तुम्ही नोंदणी करू शकता. तुम्ही हा बॉट इन्स्टॉल करू शकता. ते फुकट आहे. लिहा.

प्रश्न

बर्‍याचदा वास्तविक परिस्थितींमध्ये असे दिसून येते की टेबलमध्ये जो डेटा ठेवला पाहिजे तो हटवला जाणे आवश्यक आहे त्यापेक्षा खूपच कमी आहे. म्हणजेच, अशा परिस्थितीत, नवीन ऑब्जेक्ट तयार करणे, तेथे फक्त आवश्यक डेटा कॉपी करणे आणि जुने टेबल ट्रंक करणे सोपे असते तेव्हा अशा पद्धतीची अंमलबजावणी करणे बरेचदा सोपे असते. हे स्पष्ट आहे की या क्षणासाठी प्रोग्रामेटिक दृष्टीकोन आवश्यक आहे, जेव्हा आपण स्विच करत असाल. हा दृष्टिकोन कसा आहे?

हा एक अतिशय चांगला दृष्टीकोन आणि खूप चांगले कार्य आहे. हे pg_repack जे करते त्यासारखेच आहे, तुम्ही आयडी 4 बाइट बनवता तेव्हा तुम्हाला काय करावे लागेल यासारखेच आहे. बर्याच फ्रेमवर्कने काही वर्षांपूर्वी हे केले होते आणि फक्त प्लेट्स वाढल्या आहेत आणि त्यांना 8 बाइट्समध्ये रूपांतरित करणे आवश्यक आहे.

हे काम खूपच अवघड आहे. आम्ही ते केले. आणि आपण खूप सावध असणे आवश्यक आहे. कुलूप वगैरे आहेत पण ते केले जात आहे. म्हणजेच, pg_repack सह जाणे हा मानक दृष्टिकोन आहे. तुम्ही असे लेबल घोषित करा. आणि तुम्ही त्यात स्नॅपशॉट डेटा अपलोड करणे सुरू करण्यापूर्वी, तुम्ही सर्व बदलांचा मागोवा घेणारी एक प्लेट देखील घोषित करता. एक युक्ती आहे की आपण काही बदलांचा मागोवा घेऊ शकत नाही. सूक्ष्मता आहेत. आणि मग तुम्ही रोलिंग बदल करून स्विच करता. जेव्हा आम्ही प्रत्येकजण बंद करतो तेव्हा थोडा विराम मिळेल, परंतु सर्वसाधारणपणे हे केले जात आहे.

जर तुम्ही GitHub वर pg_repack बघितले, तर तिथे, जेव्हा int 4 वरून int 8 मध्ये आयडी रूपांतरित करण्याचे कार्य होते, तेव्हा pg_repack स्वतः वापरण्याची कल्पना होती. हे देखील शक्य आहे, परंतु हे थोडेसे हॅक आहे, परंतु हे यासाठी देखील कार्य करेल. तुम्ही pg_repack वापरत असलेल्या ट्रिगरमध्ये हस्तक्षेप करू शकता आणि तेथे म्हणू शकता: "आम्हाला या डेटाची गरज नाही", म्हणजे आम्ही फक्त आम्हाला आवश्यक ते हस्तांतरित करतो. आणि मग तो फक्त स्विच करतो आणि तेच.

या दृष्टिकोनासह, आम्हाला अजूनही टेबलची दुसरी प्रत मिळते, ज्यामध्ये डेटा आधीपासूनच अनुक्रमित केलेला आहे आणि सुंदर अनुक्रमणिकेसह अगदी समान रीतीने स्टॅक केलेला आहे.

ब्लोट उपस्थित नाही, हा एक चांगला दृष्टीकोन आहे. परंतु मला माहित आहे की यासाठी ऑटोमेशन विकसित करण्याचे प्रयत्न आहेत, म्हणजे एक सार्वत्रिक उपाय तयार करणे. मी तुम्हाला या ऑटोमेशनच्या संपर्कात ठेवू शकतो. हे पायथनमध्ये लिहिले आहे, ही चांगली गोष्ट आहे.

मी MySQL च्या जगापासून थोडासा दूर आहे, म्हणून मी ऐकायला आलो. आणि आम्ही ही पद्धत वापरतो.

पण ९०% असेल तरच. जर आमच्याकडे 90% असेल तर ते वापरणे फार चांगले नाही.

अहवालाबद्दल धन्यवाद! उत्पादनाची संपूर्ण प्रत तयार करण्यासाठी संसाधने नसल्यास, लोड किंवा आकार मोजण्यासाठी कोणतेही अल्गोरिदम किंवा सूत्र आहे का?

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

अहवालाबद्दल धन्यवाद! आपण प्रथम या वस्तुस्थितीबद्दल सुरुवात केली की एक मस्त पोस्टग्रेस आहे, ज्यामध्ये अशा आणि अशा मर्यादा आहेत, परंतु ते विकसित होत आहे. आणि हे सर्व एक क्रॅच आहे. हे सर्व पोस्टग्रेसच्याच विकासाशी विरोधाभास नाही का, ज्यामध्ये काही DELETE deferent दिसतील किंवा आणखी काही ज्याने आपण येथे आपल्या काही विचित्र माध्यमांद्वारे स्मीअर करण्याचा प्रयत्न करीत आहोत ते कमी पातळीवर ठेवायला हवे?

जर आम्ही SQL मध्ये एका व्यवहारात अनेक रेकॉर्ड हटवायचे किंवा अपडेट करायचे म्हटले, तर पोस्टग्रेस ते तिथे कसे वितरित करू शकतात? आम्ही शारीरिकरित्या ऑपरेशनमध्ये मर्यादित आहोत. आम्ही अजून बराच काळ करू. आणि आम्ही यावेळी लॉक करू इ.

इंडेक्ससह केले.

मी असे गृहीत धरू शकतो की समान चेकपॉईंट ट्यूनिंग स्वयंचलित असू शकते. एखाद्या दिवशी ते असू शकते. पण मग मला प्रश्न खरोखरच समजला नाही.

प्रश्न असा आहे की, इकडे तिकडे जाणारा आणि इथे तुमचा समांतर असा विकासाचा वेक्टर आहे का? त्या. त्यांनी अजून विचार केला नाही का?

मी आता वापरल्या जाऊ शकतील अशा तत्त्वांबद्दल बोललो. आणखी एक बॉट आहे नॅन्सी, यासह तुम्ही स्वयंचलित चेकपॉईंट ट्यूनिंग करू शकता. ते एखाद्या दिवशी पोस्टग्रेसमध्ये असेल का? मला माहीत नाही, त्यावर अजून चर्चाही झालेली नाही. त्यापासून आपण अजून दूर आहोत. पण नवीन प्रणाली बनवणारे शास्त्रज्ञ आहेत. आणि ते आम्हाला स्वयंचलित इंडेक्समध्ये ढकलतात. घडामोडी आहेत. उदाहरणार्थ, आपण स्वयं ट्यूनिंग पाहू शकता. ते आपोआप पॅरामीटर्स निवडते. परंतु तो अद्याप तुमच्यासाठी चेकपॉईंट ट्यूनिंग करणार नाही. म्हणजेच, ते कार्यप्रदर्शन, शेल बफर इत्यादीसाठी उचलेल.

आणि चेकपॉईंट ट्यूनिंगसाठी, तुम्ही हे करू शकता: जर तुमच्याकडे हजारो क्लस्टर्स आणि भिन्न हार्डवेअर, क्लाउडमध्ये भिन्न व्हर्च्युअल मशीन्स असतील, तर तुम्ही आमचा बॉट वापरू शकता. नॅन्सी ऑटोमेशन करा. आणि max_wal_size तुमच्या लक्ष्य सेटिंगनुसार आपोआप निवडले जाईल. परंतु दुर्दैवाने आतापर्यंत हे अगदी जवळ नाही.

शुभ दुपार तुम्ही दीर्घ व्यवहारांच्या धोक्यांबद्दल बोललात. तुम्ही म्हणालात की हटवण्याच्या बाबतीत ऑटोव्हॅक्यूम ब्लॉक केला जातो. ते आपले आणखी कसे नुकसान करते? कारण आम्ही जागा मोकळी करणे आणि ते वापरण्यास सक्षम असण्याबद्दल अधिक बोलत आहोत. आम्ही आणखी काय गमावत आहोत?

ऑटोव्हॅक्यूम ही कदाचित येथे सर्वात मोठी समस्या नाही. आणि दीर्घ व्यवहारामुळे इतर व्यवहार लॉक होऊ शकतात ही शक्यता अधिक धोकादायक आहे. ती भेटू शकते किंवा नाही भेटू शकते. जर ती भेटली तर ते खूप वाईट होऊ शकते. आणि ऑटोव्हॅक्यूमसह - ही देखील एक समस्या आहे. OLTP मध्ये दीर्घ व्यवहारांमध्ये दोन समस्या आहेत: लॉक आणि ऑटोव्हॅक्यूम. आणि जर तुमच्याकडे प्रतिकृतीवर हॉट स्टँडबाय फीडबॅक सक्षम असेल, तर तुम्हाला मास्टरवर ऑटोव्हॅक्यूम लॉक प्राप्त होईल, तो प्रतिकृतीमधून येईल. पण किमान कुलूप नसतील. आणि लोक असतील. आम्ही डेटा बदलांबद्दल बोलत आहोत, म्हणून लॉक हा एक महत्त्वाचा मुद्दा आहे. आणि जर हे सर्व दीर्घ, दीर्घ काळासाठी असेल, तर अधिकाधिक व्यवहार लॉक केले जातात. ते इतरांना चोरू शकतात. आणि लोक वृक्ष दिसतात. मी स्निपेटची लिंक दिली आहे. आणि ही समस्या ऑटोव्हॅक्यूमच्या समस्येपेक्षा अधिक वेगाने लक्षात येते, जी केवळ जमा होऊ शकते.

अहवालाबद्दल धन्यवाद! तुम्ही चुकीच्या पद्धतीने चाचणी केली असे सांगून तुमचा अहवाल सुरू केला. आम्ही आमची कल्पना पुढे चालू ठेवली की आम्हाला त्याच प्रकारे बेससह समान उपकरणे घेणे आवश्यक आहे. समजा आम्ही विकासकाला आधार दिला. आणि त्याने विनंतीचे पालन केले. आणि तो ठीक आहे असे दिसते. परंतु तो थेट तपासत नाही, परंतु थेट साठी, उदाहरणार्थ, आमच्याकडे 60-70% भार आहे. आणि जरी आपण हे ट्यूनिंग वापरत असलो तरी ते फारसे काम करत नाही.

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

जेव्हा आम्ही आधीच कचरा निवडत असतो आणि आमच्याकडे, उदाहरणार्थ, हटवलेला ध्वज असतो

पोस्टग्रेसमध्ये ऑटोव्हॅक्यूम आपोआप हेच करते.

अरे, तो करतो का?

ऑटोव्हॅक्यूम हा कचरा गोळा करणारा आहे.

धन्यवाद!

अहवालाबद्दल धन्यवाद! सर्व कचरा मुख्य टेबलापासून बाजूला कोठेतरी घाणेरडा होईल अशा प्रकारे विभाजनासह डेटाबेस त्वरित डिझाइन करण्याचा पर्याय आहे का?

अर्थातच आहेत.

आपण वापरू नये असे टेबल लॉक केले असेल तर स्वतःचे संरक्षण करणे शक्य आहे का?

अर्थातच आहेत. पण तो कोंबडी आणि अंड्याचा प्रश्न आहे. भविष्यात काय घडेल हे आपल्या सर्वांना माहित असल्यास, नक्कीच, आम्ही सर्वकाही छान करू. परंतु व्यवसाय बदलत आहे, नवीन स्तंभ आहेत, नवीन विनंत्या आहेत. आणि मग – अरेरे, आम्हाला ते काढायचे आहे. परंतु ही आदर्श परिस्थिती, जीवनात ती येते, परंतु नेहमीच नसते. पण एकूणच ही एक चांगली कल्पना आहे. फक्त कापून टाका आणि तेच.

स्त्रोत: www.habr.com