हम PostgreSQL में सबलाइट पर लिखते हैं: 1 होस्ट, 1 दिन, 1TB

हाल ही में मैंने आपको मानक व्यंजनों का उपयोग करके बताया था कि कैसे SQL रीड क्वेरीज़ का प्रदर्शन बढ़ाएँ PostgreSQL डेटाबेस से। आज हम बात करेंगे कैसे रिकॉर्डिंग अधिक कुशलता से की जा सकती है कॉन्फ़िगरेशन में किसी भी "ट्विस्ट" का उपयोग किए बिना डेटाबेस में - बस डेटा प्रवाह को सही ढंग से व्यवस्थित करके।

#1. सेक्शनिंग

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

"बीते दिनों की बातें..."

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

वह समय लगभग महाकाव्य काल जैसा था, PostgreSQL 9.x के विभिन्न संस्करण प्रासंगिक थे, इसलिए सभी विभाजन "मैन्युअल रूप से" करना पड़ा - के माध्यम से टेबल इनहेरिटेंस और ट्रिगर्स गतिशील के साथ रूटिंग EXECUTE.

परिणामी समाधान इतना सार्वभौमिक निकला कि इसका सभी तालिकाओं में अनुवाद किया जा सकता है:

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

पीजी10: पहला प्रयास

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

PG10 में समर्थन लागू करके इस स्थिति को काफी हद तक अनुकूलित किया गया था मूल विभाजन. इसलिए, हमने स्टोरेज माइग्रेट करने के तुरंत बाद इसे लागू करने का प्रयास किया, लेकिन...

जैसा कि मैनुअल को खंगालने के बाद पता चला, इस संस्करण में मूल रूप से विभाजित तालिका है:

• सूचकांक विवरण का समर्थन नहीं करता
• इस पर ट्रिगर्स का समर्थन नहीं करता
• किसी का "वंशज" नहीं हो सकता
• समर्थन नहीं करते INSERT ... ON CONFLICT
• स्वचालित रूप से कोई अनुभाग उत्पन्न नहीं कर सकता

माथे पर एक रेक से दर्दनाक चोट लगने के बाद, हमें एहसास हुआ कि आवेदन को संशोधित किए बिना ऐसा करना असंभव होगा, और छह महीने के लिए आगे के शोध को स्थगित कर दिया।

पीजी10: दूसरा मौका

इसलिए, हमने एक-एक करके उत्पन्न होने वाली समस्याओं को हल करना शुरू किया:

1. क्योंकि ट्रिगर्स और ON CONFLICT हमने पाया कि हमें अभी भी यहां-वहां उनकी जरूरत है, इसलिए हमने उन पर काम करने के लिए एक मध्यवर्ती चरण बनाया प्रॉक्सी टेबल.
2. "रूटिंग" से छुटकारा मिल गया ट्रिगर्स में - यानी, से EXECUTE.
3. उन्होंने इसे अलग से निकाला सभी अनुक्रमणिका के साथ टेम्पलेट तालिकाताकि वे प्रॉक्सी तालिका में भी मौजूद न हों।

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

"काटने का कार्य" शब्दकोश

किसी भी विश्लेषणात्मक प्रणाली की तरह, हमारे पास भी था "तथ्य" और "कटौती" (शब्दकोश)। हमारे मामले में, इस क्षमता में उन्होंने कार्य किया, उदाहरण के लिए, टेम्पलेट बॉडी समान धीमी क्वेरी या स्वयं क्वेरी का पाठ।

"तथ्यों" को पहले ही काफी समय से दिन-ब-दिन खंडित किया गया था, इसलिए हमने शांतिपूर्वक पुराने खंडों को हटा दिया, और उन्होंने हमें परेशान नहीं किया (लॉग!)। लेकिन शब्दकोशों के साथ एक समस्या थी...

यह कहने की ज़रूरत नहीं है कि उनमें से बहुत सारे थे, लेकिन लगभग 100TB "तथ्यों" का परिणाम 2.5TB शब्दकोष में हुआ. आप ऐसी तालिका से कुछ भी आसानी से नहीं हटा सकते, आप इसे पर्याप्त समय में संपीड़ित नहीं कर सकते, और इस पर लिखना धीरे-धीरे धीमा हो गया।

एक शब्दकोष की तरह... इसमें प्रत्येक प्रविष्टि को ठीक एक बार प्रस्तुत किया जाना चाहिए... और यह सही है, लेकिन!.. हमें ऐसा करने से कोई नहीं रोक रहा है प्रत्येक दिन के लिए एक अलग शब्दकोश! हाँ, यह एक निश्चित अतिरेक लाता है, लेकिन यह अनुमति देता है:

• तेजी से लिखें/पढ़ें छोटे अनुभाग आकार के कारण
• कम मेमोरी खपत करें अधिक कॉम्पैक्ट इंडेक्स के साथ काम करके
• कम डेटा स्टोर करें पुराने को जल्दी से हटाने की क्षमता के कारण

उपायों के पूरे परिसर के परिणामस्वरूप सीपीयू लोड ~30% कम हुआ, डिस्क लोड ~50% कम हुआ:

साथ ही, हमने डेटाबेस में बिल्कुल वही चीज़ लिखना जारी रखा, बस कम लोड के साथ।

#2. डेटाबेस विकास और रिफैक्टरिंग

इसलिए हमारे पास जो है उस पर हमने समझौता कर लिया प्रत्येक दिन का अपना अनुभाग होता है डेटा के साथ. वास्तव में, CHECK (dt = '2018-10-12'::date) - और एक विभाजन कुंजी और रिकॉर्ड के लिए एक विशिष्ट अनुभाग में आने की शर्त है।

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

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

अनुकूलन की दिशा स्पष्ट-सरल है सभी अनुक्रमणिकाओं से दिनांक फ़ील्ड हटाएँ विभाजित तालिकाओं पर. हमारी मात्रा को देखते हुए, लाभ लगभग है 1टीबी/सप्ताह!

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

#3. चरम भार को "फैलाना"।

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

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

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

setInterval(sendToDB, interval)

यहाँ समस्या बिल्कुल इसी तथ्य में निहित है सभी धागे लगभग एक ही समय पर शुरू होते हैं, इसलिए उनका भेजने का समय लगभग हमेशा "टू द पॉइंट" से मेल खाता है। उफ़ #2...

सौभाग्य से, इसे ठीक करना काफी आसान है, एक "यादृच्छिक" रन-अप जोड़ना समय के अनुसार:

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

#4. हमें जो चाहिए उसे हम कैश कर लेते हैं

तीसरी पारंपरिक हाईलोड समस्या है कोई कैश नहीं कहां है वह सकता है होना है।

उदाहरण के लिए, हमने योजना नोड्स (इन सभी) के संदर्भ में विश्लेषण करना संभव बना दिया है Seq Scan on users), लेकिन तुरंत सोचें कि अधिकांश भाग के लिए वे वही हैं - वे भूल गए।

नहीं, बेशक, डेटाबेस में दोबारा कुछ भी नहीं लिखा जाता है, इससे ट्रिगर कट जाता है INSERT ... ON CONFLICT DO NOTHING. लेकिन यह डेटा अभी भी डेटाबेस तक पहुंचता है, और यह अनावश्यक है संघर्ष की जाँच के लिए पढ़ना करना पड़ेगा। उफ़ #3...

कैशिंग सक्षम होने से पहले/बाद में डेटाबेस में भेजे गए रिकॉर्ड की संख्या में अंतर स्पष्ट है:

और यह भंडारण भार में गिरावट के साथ है:

कुल मिलाकर

"प्रति दिन टेराबाइट" डरावना लगता है। यदि आप सब कुछ ठीक करते हैं, तो यह उचित है 2^40 बाइट्स / 86400 सेकंड = ~12.5MB/sयहां तक ​​कि डेस्कटॉप आईडीई स्क्रू भी पकड़े हुए हैं। 🙂

लेकिन गंभीरता से, दिन के दौरान लोड के दस गुना "तिरछा" होने पर भी, आप आसानी से आधुनिक एसएसडी की क्षमताओं को पूरा कर सकते हैं।

स्रोत: www.habr.com