💲 ☸️ 🔩 हम PostgreSQL में एक उपलाइट पर लिखते हैं: 1 होस्ट, 1 दिन, 1 टीबी ✂️ ⏳ 👩🏻‍🤝‍👨🏿

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

# 1। विभाजन

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

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

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

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

परिणामी समाधान निकला सर्वव्यापी होने के कारण इसे सभी तालिकाओं में अनुवाद करने में सक्षम होना चाहिए:

«» , .
«» , BEFORE INSERT «» . — ...
… CREATE TABLE ... (LIKE ... INCLUDING ...) , .

PG10:

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

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

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

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

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

PG10: दूसरा मौका

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

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

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

"देखा" शब्दकोशों

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

हमारे "तथ्यों" को लंबे समय तक विभाजित किया गया था, इसलिए हमने शांति से अप्रचलित वर्गों को हटा दिया, और उन्होंने हमें (लॉग!) नहीं किया। लेकिन जिन शब्दकोशों के साथ यह समस्या

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

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

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

उपायों के पूरे परिसर के परिणामस्वरूप , सीपीयू लोड ~ 30% और डिस्क द्वारा घटाया गया - ~ 50% द्वारा :

उसी समय, हमने डेटाबेस में ठीक उसी चीज़ को लिखना जारी रखा, बस कम लोड के साथ।

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

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

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

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

अनुकूलन की दिशा स्पष्ट है - बस विभाजित तालिकाओं पर सभी अनुक्रमित से दिनांक फ़ील्ड निकालें । हमारे वॉल्यूम के साथ, लाभ लगभग 1TB / सप्ताह है !

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

# 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 है , जो कि डेस्कटॉप IDE शिकंजा भी है। :)

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

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