🥇आम्ही सबलाइटवर PostgreSQL मध्ये लिहितो: १ होस्ट, १ दिवस, १ TB

अलीकडेच मी तुम्हाला मानक पाककृती कशा वापरायच्या ते सांगितले. SQL रीड क्वेरीजची कामगिरी सुधारा. PostgreSQL डेटाबेसमधून. आज आपण कसे याबद्दल बोलू तुम्ही रेकॉर्डिंग अधिक कार्यक्षम बनवू शकता कॉन्फिगरेशनमध्ये कोणतेही "ट्विस्ट" न वापरता डेटाबेसमध्ये - फक्त डेटा प्रवाह योग्यरित्या आयोजित करून.

#१. विभागणी

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

"गेल्या काळातील गोष्टी..."

सुरुवातीला, कोणत्याही MVP प्रमाणे, आमचा प्रकल्प अगदी हलक्या भाराखाली सुरू झाला - देखरेख फक्त एक डझन सर्वात गंभीर सर्व्हरसाठी केली जात होती, सर्व टेबल्स तुलनेने कॉम्पॅक्ट होते... पण वेळ गेला, देखरेख केलेल्या होस्टची संख्या वाढत गेली आणि पुन्हा एकदा प्रयत्न केल्यानंतर त्यापैकी एकासह काहीतरी करण्याचा प्रयत्न केला. १.५ टीबी आकाराचे टेबल्स, आम्हाला जाणवले की असे जगणे शक्य असले तरी ते खूप गैरसोयीचे होते.

ते जवळजवळ पौराणिक काळ होते, आणि PostgreSQL 9.x च्या वेगवेगळ्या आवृत्त्या प्रासंगिक होत्या, म्हणून सर्व विभाजने "मॅन्युअली" करावी लागत होती - माध्यमातून टेबल इनहेरिटन्स आणि ट्रिगर्स डायनॅमिकसह राउटिंग EXECUTE.

परिणामी उपाय सर्व टेबलमध्ये अनुवादित करण्याइतका सार्वत्रिक ठरला:

एक रिकामा "शीर्षलेख" मूळ सारणी घोषित करण्यात आली, ज्यामध्ये सर्व वर्णन केले होते आवश्यक निर्देशांक आणि ट्रिगर्स.
क्लायंटच्या दृष्टिकोनातून, नोंद "रूट" टेबलमध्ये केली गेली आणि अंतर्गतरित्या राउटिंग ट्रिगर BEFORE INSERT रेकॉर्ड "भौतिकदृष्ट्या" आवश्यक विभागात समाविष्ट करण्यात आला होता. जर विभाग आधीच अस्तित्वात नसेल, तर आम्हाला एक अपवाद आढळला आणि...
… वापरून CREATE TABLE ... (LIKE ... INCLUDING ...) मूळ सारणीच्या टेम्पलेटवर आधारित तयार केले गेले. आवश्यक तारखेवर मर्यादा असलेला विभागजेणेकरून डेटा पुनर्प्राप्त करताना, वाचन फक्त त्यातच केले जाईल.

पीजी१०: पहिला प्रयत्न

परंतु इनहेरिटन्सद्वारे विभाजन करणे ऐतिहासिकदृष्ट्या सक्रिय लेखन रहदारी किंवा मोठ्या संख्येने वंशज विभाजने हाताळण्यासाठी कमी योग्य राहिले आहे. उदाहरणार्थ, एखाद्याला आठवत असेल की आवश्यक विभाजन निवडण्यासाठी अल्गोरिथममध्ये वर्गीय जटिलता, जे १००+ विभागांसह काम करते, ते कसे काम करते हे तुम्हाला माहिती आहे...

पीजी१० मध्ये, समर्थन लागू करून ही परिस्थिती मोठ्या प्रमाणात अनुकूल केली गेली मूळ विभाजन. म्हणून आम्ही स्टोरेज स्थलांतरित केल्यानंतर लगेच ते वापरण्याचा प्रयत्न केला, पण...

मॅन्युअलमधून खोदकाम केल्यानंतर असे दिसून आले की, या आवृत्तीतील मूळ विभाजन केलेले टेबल:

निर्देशांक वर्णनांना समर्थन देत नाही.
ते ट्रिगर्सना समर्थन देत नाही.
कोणाचाही "वंशज" असू शकत नाही.
समर्थन करू नका INSERT ... ON CONFLICT
आपोआप विभाग तयार करू शकत नाही.

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

पीजी१०: दुसरी संधी

म्हणून, आम्ही एकामागून एक उद्भवलेल्या समस्या सोडवण्यास सुरुवात केली:

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

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

आम्ही शब्दकोश पाहिले.

कोणत्याही विश्लेषणात्मक प्रणालीप्रमाणे, आमच्याकडे देखील होते "तथ्ये" आणि "विभाग" (शब्दकोश). आमच्या बाबतीत, उदाहरणार्थ, "टेम्पलेट" चा मुख्य भाग तत्सम स्लो क्वेरीज किंवा क्वेरीचाच मजकूर.

आमचे "तथ्ये" बऱ्याच काळापासून दिवसानुरूप विभागले गेले होते, त्यामुळे आम्ही जुने विभाग सहजपणे हटवू शकत होतो, ते मार्गात न येता (शेवटी, ते नोंदी होते!). पण शब्दकोशांमध्ये थोडी समस्या होती...

मी असे म्हणणार नाही की त्यापैकी बरेच होते, पण अंदाजे १०० टीबी "तथ्ये" मुळे २.५ टीबी शब्दकोश तयार झाला.अशा टेबलमधून तुम्ही काहीही सोयीस्करपणे हटवू शकत नाही, तुम्ही ते योग्य वेळेत कॉम्प्रेस करू शकत नाही आणि त्यावर लिहिणे हळूहळू मंद होत गेले.

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

जलद लिहा/वाचा लहान विभागाच्या आकारामुळे
कमी मेमरी वापरा अधिक कॉम्पॅक्ट इंडेक्ससह काम करून
कमी डेटा साठवा अप्रचलित गोष्टी लवकर काढून टाकण्याच्या क्षमतेमुळे

उपाययोजनांच्या संपूर्ण श्रेणीचा परिणाम म्हणून CPU लोड ~३०% ने कमी झाला, डिस्क लोड ~५०% ने कमी झाला.:

त्याच वेळी, आम्ही डेटाबेसमध्ये अगदी तेच लिहित राहिलो, फक्त कमी लोडसह.

#२. डेटाबेस उत्क्रांती आणि पुनर्घटकीकरण

तर, आमच्याकडे जे आहे त्यावर आम्ही निर्णय घेतला प्रत्येक दिवसासाठी एक विभाग आहे. डेटासह. खरं तर, CHECK (dt = '2018-10-12'::date) — आणि रेकॉर्ड एका विशिष्ट विभागात येण्यासाठी एक विभाजन की आणि एक अट आहे.

आमच्या सेवेतील सर्व अहवाल एका विशिष्ट तारखेसाठी तयार केलेले असल्याने, त्यांच्यासाठी निर्देशांक "विभाजन नसलेल्या काळापासून" समान आहेत. (सर्व्हर, तारीख, योजना टेम्पलेट), (सर्व्हर, तारीख, प्लॅन नोड), (तारीख, त्रुटी वर्ग, सर्व्हर)...

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

ऑप्टिमायझेशनची दिशा स्पष्ट आहे - फक्त सर्व निर्देशांकांमधून तारीख फील्ड काढून टाका. विभाजित टेबलांवर. आमच्या खंडांसह, फायदा सुमारे आहे १ टीबी/आठवडा!

आता आपण हे लक्षात घेऊया की हे टेराबाइट अजूनही कसे तरी लिहायचे होते. म्हणजेच, आपण देखील डिस्क आता कमी लोड झाली पाहिजे.हे चित्र एका आठवड्यात आम्ही केलेल्या स्वच्छतेचे परिणाम स्पष्टपणे दर्शवते:

#३. जास्तीत जास्त भार पसरवा

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

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

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

setInterval(sendToDB, interval)

येथे समस्या नेमकी ही आहे की सर्व प्रवाह एकाच वेळी सुरू होतात., म्हणून त्यांच्या पाठवण्याच्या वेळा जवळजवळ नेहमीच "मुद्द्याशी जुळतात." अरेरे #२...

सुदैवाने, हे दुरुस्त करणे खूप सोपे आहे, "यादृच्छिक" स्कॅटरिंग जोडत आहे वेळेनुसार:

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#४. आपल्याला जे हवे आहे ते आपण साठवतो.

उच्च भाराची तिसरी पारंपारिक समस्या आहे कॅशे नाही तो कुठे आहे? करू शकलो असणे.

उदाहरणार्थ, आम्ही प्लॅन नोड्सचे विश्लेषण करणे शक्य केले (हे सर्व Seq Scan on users), पण लगेच वाटले की ते सर्वसाधारणपणे सारखेच आहेत - ते विसरले.

नाही, अर्थातच, डेटाबेसमध्ये पुन्हा काहीही लिहिले जात नाही, हे ट्रिगरने कापले जाते. INSERT ... ON CONFLICT DO NOTHINGपण हा डेटा अजूनही डेटाबेसमध्ये पोहोचतो, आणि अनावश्यक डेटा देखील. संघर्ष तपासण्यासाठी वाचन मला ते करावेच लागेल. अरेरे #३...

कॅशिंग सक्षम करण्यापूर्वी/नंतर डेटाबेसला पाठवलेल्या रेकॉर्डच्या संख्येतील फरक स्पष्ट आहे:

आणि स्टोरेजवरील भार कमी होण्यामागील हे आहे:

एकूण

"टेराबाइट्स प्रति दिवस" फक्त भयानक वाटते. जर तुम्ही सर्वकाही बरोबर केले तर ते फक्त २^४० बाइट्स / ८६४०० सेकंद = ~१२.५MB/सेकंद, जे डेस्कटॉप IDE स्क्रू देखील धरू शकतात. 🙂

पण गंभीरपणे, दिवसा दहापट भार "तिरपे" असतानाही, तुम्ही आधुनिक SSD च्या क्षमतांमध्ये सहजपणे बसू शकता.

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