आम्ही Sublight वर PostgreSQL मध्ये लिहितो: 1 होस्ट, 1 दिवस, 1TB

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

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

ते कसे आणि का आयोजित करणे योग्य आहे याबद्दल एक लेख "सिद्धांतानुसार" विभाजन लागू आधीच केले गेले आहे, येथे आपण आपल्या अंतर्गत काही दृष्टिकोन लागू करण्याच्या सरावाबद्दल बोलू शेकडो 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)

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

सुदैवाने, हे निराकरण करणे अगदी सोपे आहे, एक "यादृच्छिक" रन-अप जोडत आहे वेळेनुसार:

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

#४. आम्हाला जे आवश्यक आहे ते आम्ही कॅश करतो

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

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

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

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

आणि स्टोरेज लोडमध्ये ही सोबतची घट आहे:

एकूण

"टेराबाइट-प्रति-दिवस" ​​फक्त भितीदायक वाटते. जर आपण सर्वकाही बरोबर केले तर हे फक्त आहे 2^40 बाइट / 86400 सेकंद = ~12.5MB/sअगदी डेस्कटॉप IDE screws धरले. 🙂

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

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