हामी Sublight मा PostgreSQL मा लेख्छौं: 1 होस्ट, 1 दिन, 1TB

भर्खरै मैले मानक व्यञ्जनहरू प्रयोग गरेर कसरी, तपाईंलाई भनें SQL पढ्ने प्रश्नहरूको प्रदर्शन बढाउनुहोस् PostgreSQL डाटाबेसबाट। आज हामी कसरी कुरा गर्नेछौं रेकर्डिङ अधिक कुशलतापूर्वक गर्न सकिन्छ कन्फिगरेसनमा कुनै पनि "ट्विस्ट" प्रयोग नगरी डाटाबेसमा - केवल डाटा प्रवाहहरू सही रूपमा व्यवस्थित गरेर।

#१। खण्डीकरण

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

"बितेका दिनहरु..."

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

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

नतिजा समाधान पर्याप्त सार्वभौमिक भयो कि यो सबै तालिकाहरूमा अनुवाद गर्न सकिन्छ:

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

PG10: पहिलो प्रयास

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

PG10 मा यो अवस्था समर्थन लागू गरेर धेरै अनुकूलित गरिएको थियो मूल विभाजन। तसर्थ, हामीले भण्डारण स्थानान्तरण पछि तुरुन्तै यसलाई लागू गर्ने प्रयास गर्यौं, तर ...

यो म्यानुअल मार्फत खन्ने पछि बाहिर निस्कियो, यस संस्करणमा नेटिभ रूपमा विभाजन गरिएको तालिका हो:

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

रेकको साथ निधारमा पीडादायी प्रहार प्राप्त गरेपछि, हामीले एप्लिकेसन परिमार्जन नगरी यो गर्न असम्भव छ भनेर महसुस गर्यौं, र छ महिनाको लागि थप अनुसन्धान स्थगित गर्‍यौं।

PG10: दोस्रो मौका

त्यसोभए, हामीले एक-एक गरेर उत्पन्न भएका समस्याहरू समाधान गर्न थाल्यौं:

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

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

"साविंग" शब्दकोश

कुनै पनि विश्लेषणात्मक प्रणालीमा जस्तै, हामीसँग पनि थियो "तथ्य" र "कटहरू" (शब्दकोशहरू)। हाम्रो अवस्थामा, यो क्षमतामा तिनीहरूले काम गरे, उदाहरणका लागि, टेम्प्लेट शरीर समान ढिलो प्रश्नहरू वा प्रश्नको पाठ।

"तथ्यहरू" लाई पहिले नै लामो समयको लागि दिन द्वारा खण्ड गरिएको थियो, त्यसैले हामीले शान्तपूर्वक पुराना सेक्सनहरू मेटायौं, र तिनीहरूले हामीलाई परेशान गरेनन् (लगहरू!)। तर शब्दकोशमा समस्या थियो...

भन्नु पर्दैन कि त्यहाँ धेरै थिए, तर लगभग 100TB "तथ्यहरू" को परिणाम 2.5TB शब्दकोशमा भयो। तपाईले त्यस्तो तालिकाबाट कुनै पनि कुरा सजिलै मेटाउन सक्नुहुन्न, तपाईले यसलाई पर्याप्त समयमा कम्प्रेस गर्न सक्नुहुन्न, र त्यसमा लेख्ने क्रम बिस्तारै ढिलो हुँदै गयो।

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

• छिटो लेख्नुहोस्/पढ्नुहोस् सानो खण्ड आकारको कारण
• कम मेमोरी खपत थप कम्प्याक्ट अनुक्रमणिकाहरूसँग काम गरेर
• कम डाटा भण्डारण चाँडै पुरानो हटाउने क्षमताको कारण

उपायहरूको सम्पूर्ण जटिलताको परिणामको रूपमा CPU लोड ~ 30%, डिस्क लोड ~ 50% ले घट्यो:

एकै समयमा, हामीले डाटाबेसमा ठ्याक्कै उस्तै कुरा लेख्न जारी राख्यौं, कम लोडको साथ।

#२। डाटाबेस विकास र रिफ्याक्टरिंग

त्यसैले हामीसँग जे छ त्यसमा बस्यौं प्रत्येक दिनको आफ्नै खण्ड छ डाटा संग। वास्तवमा, CHECK (dt = '2018-10-12'::date) — र त्यहाँ विभाजन गर्ने कुञ्जी र रेकर्डको लागि निश्चित खण्डमा पर्ने अवस्था छ।

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

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

अनुकूलन को दिशा स्पष्ट छ - सरल सबै अनुक्रमणिकाहरूबाट मिति क्षेत्र हटाउनुहोस् विभाजित टेबलहरूमा। हाम्रो मात्रा दिएर, लाभ लगभग छ 1TB/हप्ता!

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

#३। शिखर भार "फैल्दै"

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

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

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

setInterval(sendToDB, interval)

समस्या यहाँ ठ्याक्कै वास्तवमा निहित छ सबै थ्रेडहरू लगभग एकै समयमा सुरु हुन्छ, त्यसैले तिनीहरूको पठाउने समय लगभग सधैं "बिन्दुमा" मेल खान्छ। उफ् #२...

सौभाग्य देखि, यो ठीक गर्न एकदम सजिलो छ, "यादृच्छिक" रन-अप थप्दै समय द्वारा:

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

#४। हामीलाई चाहिने कुरा क्यास गर्छौं

तेस्रो परम्परागत हाईलोड समस्या हो कुनै क्यास छैन उहाँ कहाँ हुनुहुन्छ सक्छ हुनु।

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

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

क्यासिंग सक्षम हुनु अघि / पछि डाटाबेसमा पठाइएका रेकर्डहरूको संख्यामा भिन्नता स्पष्ट छ:

र यो भण्डारण लोडमा सँगै ड्रप हो:

कुल

"टेराबाइट-प्रति-दिन" डरलाग्दो सुनिन्छ। यदि तपाइँ सबै कुरा ठीक गर्नुहुन्छ भने, यो मात्र हो 2^40 बाइट्स / 86400 सेकेन्ड = ~12.5MB/sत्यो पनि डेस्कटप IDE स्क्रू राखिएको छ। 🙂

तर गम्भीर रूपमा, दिनको समयमा लोडको दस गुणा "स्क्यू" संग पनि, तपाइँ सजिलै संग आधुनिक SSD को क्षमताहरू पूरा गर्न सक्नुहुन्छ।

स्रोत: www.habr.com