स्केलिंग पोस्टग्रेएसक्यूएल: हमने 10 बिलियन दैनिक रिकॉर्ड और 350 टीबी+ डेटा को कैसे नियंत्रित किया

इस साल की शुरुआत में, हमने अपनी कंपनी की सबसे बड़ी शुरुआत की कुत्ते को खाना खिलाने का प्रयास कभी। निर्माण करने के लिए इनसाइट्स , एक उपकरण जो हमारे उपयोगकर्ताओं को टाइमस्केल प्लेटफ़ॉर्म के भीतर उनके क्वेरी प्रदर्शन का विश्लेषण करने की अनुमति देता है, हमने अपने सभी ग्राहकों के डेटाबेस में क्वेरी आँकड़े एकत्र करने की कोशिश की, जिसमें प्रत्येक क्वेरी से संबंधित समय, सीपीयू, मेमोरी उपयोग और डिस्क I/O शामिल हैं। हमें एक ऐसे डेटाबेस की आवश्यकता थी जो बड़ी मात्रा में डेटा को संभाल सके, जिसमें शक्तिशाली विश्लेषणात्मक क्षमताएं हों (विशेषकर समय के साथ विश्लेषण के लिए), और जो परिचालन बोझ न बने।

स्वाभाविक रूप से, हमने टाइमस्केल को चुना, जो हमारे परिपक्व क्लाउड प्लेटफ़ॉर्म है, जिसके मूल में टाइमस्केलडीबी है। हम PostgreSQL के साथ काम करने के आदी हैं, और हमने PostgreSQL को तेज़ और अधिक स्केलेबल बनाने के लिए TimescaleDB का निर्माण किया - अपने स्वयं के उदाहरण से जीने से बेहतर क्या हो सकता है?

इस डॉगफूडिंग प्रयोग का वर्णन करने का सबसे आसान तरीका उन संख्याओं के साथ है जो इसके पैमाने को मापने में मदद करते हैं। इनसाइट्स बनाने के लिए, हमें लगातार चलने वाले उत्पादन डेटाबेस के अपने बेड़े में क्वेरी जानकारी एकत्र करने की आवश्यकता थी। हमने प्लेटफ़ॉर्म पर व्यक्तिगत (स्वच्छ) प्रश्नों के बारे में 1 ट्रिलियन से अधिक रिकॉर्ड एकत्र किए।

अब जबकि इनसाइट्स उत्पादन में है, हम एक दिन में 10 बिलियन से अधिक नए रिकॉर्ड ग्रहण कर रहे हैं। एकल टाइमस्केल सेवा द्वारा प्रदत्त डेटासेट प्रतिदिन लगभग 3 टीबी बढ़ता है और वर्तमान में कुल 350 टीबी से अधिक है, और वही डेटाबेस सेवा हमारे सभी ग्राहकों के लिए वास्तविक समय के डैशबोर्ड को शक्ति प्रदान करती है।

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

हमारे संपूर्ण बेड़े पर प्रश्नों का विश्लेषण करने के लिए PostgreSQL को स्केल करना

हमने अभी-अभी टाइमस्केल प्लेटफॉर्म पर अपने डॉगफूडिंग प्रयास का अंतिम उत्पाद, इनसाइट्स लॉन्च किया है। यह डेटाबेस अवलोकन उपकरण उपयोगकर्ताओं को बेहतर ढंग से समझने की अनुमति देता है कि उनकी क्वेरीज़ कैसा प्रदर्शन कर रही हैं। इनसाइट्स विभिन्न मेट्रिक्स को सहसंबंधित करता है - जिसमें क्वेरी विलंबता, सीपीयू, मेमोरी और I/O शामिल हैं - समवर्ती रूप से निष्पादित प्रश्नों के विरुद्ध, उपयोगकर्ताओं को कम प्रदर्शन वाले प्रश्नों को ढूंढने में मदद करता है जो समस्याएं पैदा कर सकते हैं। एक बार जब आप समस्याग्रस्त प्रश्नों की पहचान कर लेते हैं, तो इनसाइट्स आपको समस्या का पता लगाने में मदद करने के लिए एक निश्चित अवधि में साझा बफ़र्स और कैश हिट अनुपात जैसे पहलुओं का अधिक विस्तृत दृश्य प्रदान करता है।

इनसाइट्स को साकार करने के लिए, हमें अपना डेटाबेस एडमिनिस्ट्रेटर बनना पड़ा और PostgreSQL को कई टेराबाइट्स डेटा तक स्केल करने के लिए कुछ तकनीकी चुनौतियों से निपटना पड़ा। हम अपने केंद्रीय डेटाबेस के रूप में टाइमस्केल सेवा का उपयोग करना चाहते थे, जो बिना किसी "विशेष" बुनियादी ढांचे के हमारे प्लेटफ़ॉर्म पर होस्ट की गई थी। इसका मतलब निम्नलिखित था:

• हमें एक ऐसी पाइपलाइन बनानी थी जो प्रतिदिन अरबों रिकॉर्ड को एक ही टाइमस्केल सेवा में समाहित करने में सक्षम हो। टाइमस्केल उच्च अंतर्ग्रहण दरों को संभाल सकता है, और यह हमारे ग्राहकों के लिए नियमित रूप से ऐसा करता है, लेकिन उत्पादन क्वेरी लोड के तहत पैमाने का यह स्तर हमेशा भौंहें चढ़ाता है।

  
  

• हमारे ग्राहकों को इनसाइट्स द्वारा प्रदान किए जाने वाले सभी विश्लेषणों को सशक्त बनाने के लचीलेपन के साथ इस डेटाबेस से पूछताछ करने में सक्षम होना था, और हम उन्हें प्रतिक्रिया के लिए मिनटों तक इंतजार नहीं कराना चाहते थे!

  
  

• हमें एक ही टाइमस्केल सेवा में सैकड़ों टीबी संग्रहीत करने की आवश्यकता थी क्योंकि प्रत्येक दिन हम कई टीबी जोड़ रहे हैं। पुराने डेटा (यानी, कुछ सप्ताह से अधिक पुराने) को एक्सेस करने की आवश्यकता है, लेकिन क्वेरी के लिए तेज़ होना ज़रूरी नहीं है।

हमने इसे कैसे बनाया: एक (विशाल) डेटाबेस के साथ रीयल-टाइम एनालिटिक्स को सशक्त बनाना

बहुत सारा डेटा एकत्र करना और लिखना

डेटा संग्रह पक्ष से, हमने टाइमस्केल प्लेटफ़ॉर्म की वास्तुकला का लाभ उठाया। टाइमस्केल कुबेरनेट्स (k8s) पर चलता है, और हमारे पास विभिन्न भौगोलिक क्षेत्रों में कई k8s क्लस्टर चल रहे हैं। उन समूहों में नोड्स होते हैं जो एक या अधिक ग्राहक डेटाबेस सेवाएँ रखते हैं। उन सभी डेटाबेस के लिए क्वेरी निष्पादन एकत्र करने के लिए, हम उस डेटाबेस से क्षेत्रीय स्तर तक बबल करते हैं और फिर एक क्षेत्रीय लेखक रखते हैं जो टाइमस्केल डेटाबेस सेवा में रिकॉर्ड के बैचों को संग्रहीत करता है जो इनसाइट्स को शक्ति प्रदान करता है।

हाथ हिलाने के लिए क्षमा करें जो कुछ निम्न-स्तरीय रक्तरंजित विवरणों से बचता है, लेकिन व्यापक रूप से, चीजें इस तरह काम करती हैं: बेड़े में चलने वाले प्रत्येक डेटाबेस को हर क्वेरी के बाद एक रिकॉर्ड (गोपनीयता और सुरक्षा के लिए स्वच्छ) बनाने के लिए उपकरण दिया जाता है, जिसमें शामिल हैं स्वयं क्वेरी करें और आँकड़े जिनकी हमें परवाह है।

उन रिकॉर्ड्स को नोड स्तर पर एकत्र किया जाता है, लेबल के साथ टैग किया जाता है ताकि उन्हें उस डेटाबेस सेवा से संबद्ध रखा जा सके, और क्षेत्रीय लेखक को भेजे जाने के लिए बैच किया जाता है। प्रत्येक क्षेत्र में भार को संभालने के लिए आवश्यकतानुसार क्षेत्रीय लेखक सेवा को दोहराया जाता है। प्रत्येक लेखक प्रत्येक क्लस्टर में नोड्स से बैच एकत्र करता है और उससे भी बड़े बैच बनाता है।

फिर उन बड़े बैचों को पहले `COPY` का उपयोग करके एक अस्थायी तालिका में लिखा जाता है (कोई राइट-अहेड लॉगिंग = तेज़ नहीं)। फिर उस अस्थायी तालिका की प्रविष्टियों का उपयोग आवश्यक तालिकाओं को अद्यतन करने के लिए किया जाता है (नीचे देखें)। अस्थायी तालिका हमें डुप्लिकेट के बारे में चिंता किए बिना `COPY` का उपयोग करने की अनुमति देती है, जिसे बाद के संचालन द्वारा अस्थायी तालिका से रिकॉर्ड को मंग करके नियंत्रित किया जाता है।

इसे संक्षेप में कहें:

• हमारे पास कई भौगोलिक क्षेत्रों में k8s क्लस्टर हैं। उन क्षेत्रों के अंदर नोड हैं जो एक या अधिक ग्राहक डेटाबेस चलाते हैं।
• ग्राहक डेटाबेस से स्वच्छ क्वेरी आँकड़े एकत्र और बैच किए जाते हैं (क्षेत्र के अंदर)।
• एक बार जब पर्याप्त संख्या में इवेंट हो जाते हैं, तो इन्हें हमारी केंद्रीकृत टाइमस्केल डेटाबेस सेवा में भेज दिया जाता है।

आइए उस डेटाबेस पर ज़ूम करें जो इनसाइट्स को शक्ति प्रदान कर रहा है। हम इनसाइट्स को "ऑफ-द-शेल्फ" टाइमस्केल सेवा में चला रहे हैं उच्च उपलब्धता प्रतिकृति , जिसका उपयोग रीड-स्केलिंग के लिए भी किया जाता है (उस पर बाद में अधिक जानकारी)। "ऑफ-द-शेल्फ" से हमारा मतलब है कि हम अपने ग्राहकों के लिए उपलब्ध (या जल्द ही उपलब्ध होने वाली 😉) सभी समान सुविधाओं का उपयोग कर रहे हैं। कोई विशेष काला जादू नहीं क्योंकि हम बुनियादी ढांचे को भी नियंत्रित करते हैं।

इनसाइट्स को सशक्त बनाने वाले डेटाबेस में कई हिस्से हैं, लेकिन हम सबसे महत्वपूर्ण हिस्सों को उजागर करने का प्रयास करेंगे।

सबसे पहले, हमारे पास दो नियमित PostgreSQL तालिकाएँ हैं जो "संदर्भ तालिकाएँ" के रूप में काम करती हैं। इन तालिकाओं में सूचना डेटाबेस मेटाडेटा और क्वेरी स्ट्रिंग मेटाडेटा शामिल हैं। यहां उनकी (छद्म)स्कीमाएं हैं:

डेटाबेस मेटाडेटा

 Table "insights.cloud_db" Column | Type | Collation | Nullable | Default ---------------+--------------------------+-----------+----------+-------------------------------------- id | bigint | | not null | nextval('cloud_db_id_seq'::regclass) service_id | text | | not null | project_id | text | | not null | created | timestamp with time zone | | not null | now() Indexes: "cloud_db_pkey" PRIMARY KEY, btree (id) "cloud_db_project_id_service_id_key" UNIQUE CONSTRAINT, btree (project_id, service_id)

क्वेरी मेटाडेटा

 Table "insights.queries" Column | Type | Collation | Nullable | Default ---------------+--------------------------+-----------+----------+-------------------------------------- hash | text | | not null | normalized_query | text | | not null | created | timestamp with time zone | | not null | now() Indexes: "queries_pkey" PRIMARY KEY, btree (hash)

जब भी किसी नए डेटाबेस में क्वेरीज़ चलने लगेंगी, तो उसे `insights.cloud_db` में जोड़ दिया जाएगा। जब भी कोई नई सामान्यीकृत क्वेरी चलाई जाती है, तो उसे `insights.queries` में जोड़ दिया जाएगा।

(सामान्यीकृत क्वेरी क्या है? यह एक ऐसी क्वेरी है जहां सभी स्थिरांक को प्लेसहोल्डर से बदल दिया गया है: पहले के लिए $1, दूसरे के लिए $2, और इसी तरह, इसलिए हम केवल क्वेरी का "आकार" देखते हैं, उसके मान नहीं .)

इस बिंदु तक, हम बिना टाइमस्केल गुप्त सॉस के केवल नियमित पोस्टग्रेज का उपयोग कर रहे हैं। लेकिन डेटाबेस में अन्य महत्वपूर्ण ऑब्जेक्ट TimescaleDB के लिए अद्वितीय हैं, जो PostgreSQL को दूसरे स्तर पर स्केल करने में मदद करते हैं। यहीं पर जादू होता है: हाइपरटेबल्स और निरंतर समुच्चय।

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

  
  

• निरंतर समुच्चय टाइमस्केल के PostgreSQL भौतिक दृश्यों का उन्नत संस्करण है, जो वृद्धिशील और स्वचालित सामग्रीकरण की अनुमति देता है, जो इनसाइट्स का निर्माण करते समय बहुत उपयोगी साबित हुआ।

आइए देखें कि हमने उपयोगकर्ताओं की ओर से तेज़ विश्लेषणात्मक प्रश्नों को सक्षम करने के लिए इन सुविधाओं का उपयोग कैसे किया।

वास्तविक समय विश्लेषण को सशक्त (तेज़) बनाना

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

 Table "insights.records" Column | Type | Collation | Nullable | Default -----------------------------+--------------------------+-----------+----------+--------- cloud_db_id | bigint | | not null | query_hash | text | | | created | timestamp with time zone | | not null | total_time | bigint | | | rows | bigint | | | ...

अब, हमें उपयोगकर्ता की ओर से तेज़ क्वेरी की अनुमति देनी होगी—लेकिन यह तालिका बहुत बड़ी है। चीजों को गति देने के लिए, हमने निरंतर समुच्चय (उपयोग) पर बहुत अधिक भरोसा किया श्रेणीबद्ध सतत समुच्चय , सटीक होना)।

इनसाइट्स जैसे वास्तविक समय, उपयोगकर्ता-सामना वाले विश्लेषण की पेशकश करने वाले उत्पाद में निरंतर समुच्चय बहुत मायने रखता है। उपयोगकर्ताओं को कार्रवाई योग्य जानकारी प्रदान करने के लिए, हमें मेट्रिक्स को एकत्रित करने की आवश्यकता है: हम उपयोगकर्ताओं को उनके द्वारा की गई प्रत्येक क्वेरी का लॉग उसके आगे आँकड़ों के साथ नहीं दिखा रहे हैं - कुछ डेटाबेस प्रति सेकंड हजारों क्वेरी कर रहे हैं, इसलिए इसे खोजना एक दुःस्वप्न होगा कुछ भी उपयोगी. इसके बजाय, हम उपयोगकर्ताओं को समुच्चय प्रदान कर रहे हैं।

इसलिए, हम इस तथ्य का भी लाभ उठा सकते हैं कि हम उपयोगकर्ताओं को कच्चे व्यक्तिगत रिकॉर्ड नहीं दिखा रहे हैं और परिणाम नहीं रख रहे हैं materialized त्वरित प्रतिक्रिया के लिए. ग्राहकों के लिए, इसका मतलब है कि इनसाइट्स का उपयोग करते समय परिशुद्धता में एक छोटा सा समझौता (यानी, उन्हें सेकंड से लेकर सटीक समय सीमा नहीं मिल सकती है), लेकिन यह भुगतान करने के लिए एक बहुत ही उचित मूल्य है।

हम PostgreSQL भौतिक दृश्यों का उपयोग कर सकते थे, लेकिन टाइमस्केल के निरंतर समुच्चय के कई फायदे हैं जो हमारे लिए विशेष रूप से उपयोगी थे। हम दृश्यों को बहुत बार ताज़ा करते हैं, और निरंतर समुच्चय में स्वचालित ताज़ा करने के लिए अंतर्निहित नीतियां होती हैं, और वे क्रमिक रूप से ताज़ा होते हैं।

हम हर पांच मिनट में दृश्यों को ताज़ा करते हैं, इसलिए हर पांच मिनट में संपूर्ण भौतिक जानकारी को पुन: उत्पन्न करने के बजाय, निरंतर समुच्चय मूल तालिका में परिवर्तनों को ट्रैक करके दृश्य को क्रमिक रूप से अपडेट करते हैं। जिस पैमाने पर हम काम कर रहे हैं, हम हर पांच मिनट में अपने मुख्य हाइपरटेबल को ऊपर से नीचे तक स्कैन करने का जोखिम नहीं उठा सकते हैं, इसलिए निरंतर समुच्चय की यह कार्यक्षमता हमारे लिए एक मौलिक "अनलॉक" थी।

पर्दे के पीछे की अंतर्दृष्टि को सशक्त बनाने वाले इन निरंतर समुच्चय में, हम अधिकांश दिलचस्प आँकड़ों को भी एक में एकत्रित कर रहे हैं यूडीडीएसस्केच , जो हमारे संग्रह का हिस्सा है हाइपरफ़ंक्शन टाइमस्केल में. UDDSketch अपने द्वारा संसाधित किए गए डेटा से अनुमानित सांख्यिकीय माप प्राप्त करने में माहिर है। यह हमें माध्यिका, 95वें प्रतिशतक (या पी95) जैसे आवश्यक मेट्रिक्स, और विलंबता या पंक्ति गणना जैसे मेट्रिक्स के लिए और अधिक प्रस्तुत करने की अनुमति देता है।

फिर भी, एक निश्चित बिंदु पर, डेटाबेस ने इन सभी कच्चे रिकॉर्डों को सम्मिलित करने और फिर उन्हें सेवा के लिए मूर्त रूप देने के लिए बहुत काम करना शुरू कर दिया। हम कितना निगल सकते हैं और कितना रख सकते हैं, इस पर कुछ सीमाएं लगा रहे थे।

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

 Table "insights.sketches" Column | Type | Collation | Nullable | Default -----------------------------+--------------------------+-----------+----------+--------- cloud_db_id | bigint | | not null | query_hash | text | | | created | timestamp with time zone | | not null | total_time_dist | uddsketch | | | rows_dist | uddsketch | | | ...

UDDSketchs का सबसे अच्छा हिस्सा यह है कि बड़ी समय सीमा का समर्थन करने के लिए स्केच को लगातार "रोल अप" करना बहुत आसान है। इस तरह के रोलअप का उपयोग करते हुए, संकीर्ण समय सीमा को कवर करने वाले स्केच को एक ऐसे स्केच में एकत्रित किया जा सकता है जो एक विस्तृत समय सीमा को कवर करता है, दोनों एक पदानुक्रमित निरंतर समुच्चय का निर्माण करते समय और क्वेरी समय पर।

एक और उपकरण जिसका लाभ हमने यह सुनिश्चित करने के लिए उठाया कि तेजी से अंतर्ग्रहण और क्वेरी दोनों प्रतिकृतियां पढ़ी जाएं। हमारे मामले में उच्च उपलब्धता और प्रदर्शन दोनों के लिए प्रतिकृति का उपयोग सर्वोपरि है, यह देखते हुए कि इनसाइट्स टाइमस्केल प्लेटफ़ॉर्म के लिए एक प्रमुख, ग्राहक-सामना करने वाली सुविधा प्रदान करता है।

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

एक ही टाइमस्केल उदाहरण में सैकड़ों टीबी का भंडारण

अंततः, हमें सैकड़ों टीबी को एक ही टाइमस्केल सेवा में आराम से फिट करने की आवश्यकता थी। इनसाइट्स डेटाबेस तेजी से बढ़ रहा है: जब हमने शुरुआत की थी तो यह 100 टीबी के ऑर्डर पर था, और अब यह 350 टीबी से अधिक है (और बढ़ रहा है)।

इतने अधिक डेटा को कुशलतापूर्वक संग्रहीत करने के लिए, हमने सक्षम किया टाइमस्केल का स्तंभ संपीड़न हमारे हाइपरटेबल में और हमारे सभी निरंतर समुच्चय में (हाँ, आप निरंतर समुच्चय को संपीड़ित भी कर सकते हैं क्योंकि वे अनिवार्य रूप से चाइल्ड हाइपरटेबल हैं!)। हमने अपनी संपीड़न दरें भी डायल कर लीं- आख़िरकार टीम संपीड़न को अनुकूलित करने के बारे में काफी कुछ बातें जानती है।

हम अपने मुख्य हाइपरटेबल पर 20x से अधिक संपीड़न दर देख रहे हैं।

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

हम टाइमस्केल के डेटा टियरिंग के भी भारी उपयोगकर्ता हैं। यह सुविधा इस वर्ष की शुरुआत में आरंभिक पहुंच में आ गई (जल्द ही जीए समाचार की प्रतीक्षा करें 🔥) और हमें अपने टाइमस्केल डेटाबेस के माध्यम से सैकड़ों टीबी को सुलभ रखने की अनुमति देता है। डेटा टियरिंग भी बहुत कुशल साबित हुई है: हम यहां अद्भुत संपीड़न दर भी देखते हैं, जिसमें 130 टीबी अत्यधिक संसाधन-कुशल 5 टीबी में सिकुड़ जाता है।

टाइमस्केल का उपयोग करके 350 टीबी+ पोस्टग्रेएसक्यूएल डेटाबेस को स्केल करना: सीखे गए सबक

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

आइए इन सबके बारे में जानें: अच्छा, और वैसा।

टाइमस्केल हाइलाइट्स

• हमारी निर्लज्जता के लिए क्षमा करें, लेकिन कभी-कभी हमें अपने उत्पाद पर बहुत गर्व महसूस होता है। पहले से ही सैकड़ों टीबी वाले एकल PostgreSQL डेटाबेस में प्रतिदिन अरबों रिकॉर्ड दर्ज करना कोई परेशानी की बात नहीं है। जब डेटाबेस में तेजी आनी शुरू हुई तो हमने उसे व्यवस्थित करने में कुछ हफ़्ते बिताए, लेकिन अब यह बच्चों की देखभाल या निरंतर निगरानी के बिना, बस काम करता है । (ध्यान दें कि यह निगरानी न किए जाने से अलग है, इसकी निश्चित रूप से निगरानी की जाती है!)

  
  

• हमारा एक्सप्लोरर इस प्रक्रिया में दृश्य महत्वपूर्ण था, जो मूल्यवान अंतर्दृष्टि प्रदान करता था और प्रदर्शन को अनुकूलित करने के लिए आसान कॉन्फ़िगरेशन परिवर्तनों की अनुमति देता था, उदाहरण के लिए, जब चंक (विभाजन) आकार को अनुकूलित किया जाता था।

  
  

• संपीड़न ने हमारे लिए बहुत अच्छा काम किया। जैसा कि हमने पिछले अनुभाग में साझा किया था, हमें एक सरल एकल `सेगमेंटबाय` विकल्प का उपयोग करके प्रभावशाली संपीड़न दर (20x!) प्राप्त हुई। हमारे लिए, नीति को स्थापित करने और समायोजित करने का अनुभव कठिन नहीं था - हालाँकि, निश्चित रूप से, हमने यह सुविधा बनाई... कोई कह सकता है कि हमें थोड़ी बढ़त मिली है। 🙂 साथ ही, संपीड़ित डेटा में नए कॉलमों को निर्बाध रूप से जोड़ने की क्षमता ने हमारे डेटाबेस के लचीलेपन और अनुकूलनशीलता को और बढ़ाया। हमने बिना किसी जटिलता के इस क्षमता का उपयोग किया।

  
  

• निरंतर समुच्चय ने विभिन्न समयावधियों के निर्माण, डेटा विश्लेषण और प्रसंस्करण को सुव्यवस्थित करने में तर्क को सरल बनाया। हमने ढेर सारे पदानुक्रमित सतत समुच्चय का उपयोग किया।

  
  

• टाइमकेल के हाइपरफंक्शन में शामिल सन्निकटन एल्गोरिदम ने हमारे कार्यान्वयन को सरल बनाया और हमारे विश्लेषण को काफी बढ़ाया। हमारे ग्राहक-सामना वाले इनसाइट डैशबोर्ड में विभिन्न समय सीमाओं और टाइम बकेट ग्रैन्युलैरिटी का कुशलतापूर्वक समर्थन करने के लिए स्केच को आसानी से रोलअप करने की क्षमता भी महत्वपूर्ण थी।

  
  

• डेटा टियरिंग के माध्यम से टाइमस्केल डेटाबेस के पास मौजूद "अनंत" वार्म स्टोरेज 100 टीबी तक स्केल करने के लिए महत्वपूर्ण था, जिसमें बढ़ने के लिए पर्याप्त गुंजाइश थी। हमारी वर्तमान __ डेटा टियरिंग नीति __ तीन सप्ताह के रिकॉर्ड को हॉट स्टोरेज में रखती है।

  
  

अंत में, हमने अवलोकन क्षमता बढ़ाने (जैसे नौकरी इतिहास की निगरानी) और प्रयोगात्मक ताज़ा रणनीतियों को लागू करने के लिए कस्टम नौकरियां बनाने की क्षमता का उपयोग किया।

सुधार के अवसर (हमने ध्यान दिया)

आपको सभी महान चीजें बताने के बाद, अब उन चीजों को स्वीकार करने का समय आ गया है जो इतनी महान नहीं हैं। टाइमस्केल सहित कुछ भी पूर्ण नहीं है। अपनी पाइपलाइन को लागू करते समय हमें कुछ चुनौतियों का सामना करना पड़ा, और हम इन्हें शिकायतों के रूप में नहीं समझते हैं:

टाइमस्केल प्लेटफ़ॉर्म में डेटाबेस अवलोकन में सुधार किया जा सकता है, विशेष रूप से नौकरियों और निरंतर समुच्चय के भौतिकीकरण के प्रदर्शन के आसपास।

TimescaleDB ज्यादातर स्नैपशॉट-आधारित दृश्य प्रदान करता है, जिससे समय के साथ प्रदर्शन और रुझानों को समझना चुनौतीपूर्ण हो जाता है। उदाहरण के लिए, कोई आउट-ऑफ़-द-बॉक्स "नौकरी इतिहास" तालिका उपलब्ध नहीं है। प्रारंभ में, हमने देखा कि हमारे निरंतर समुच्चय के वृद्धिशील भौतिककरण में अधिक समय लग रहा था - अंततः एक बग की खोज हुई - लेकिन हमारे पास दायरे की पुष्टि या मात्रा निर्धारित करने का कोई तरीका नहीं था।

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

जब अंतर्निहित डेटा बड़ा हो तो निरंतर समुच्चय को सही करना मुश्किल हो सकता है।

निरंतर समुच्चय बनाते समय `__ विद नो डेटा` विकल्प का उपयोग करना __ एक जीवनरक्षक है। रिफ्रेश नीति के लिए अपने ऑफसेट के साथ विवेकपूर्ण होना भी महत्वपूर्ण है, ताकि आपके द्वारा लगातार रिफ्रेश किए जा रहे डेटा की मात्रा गलती से बहुत बड़ी न हो जाए।

यहां तक कि अगर आप इस सलाह का पालन करते हैं, तब भी आप एक निरंतर समुच्चय के साथ समाप्त हो सकते हैं जिसे ताज़ा करने में आपके द्वारा किए जा रहे डेटा की मात्रा की तुलना में अधिक समय लगता है, उदाहरण के लिए, 15 मिनट के डेटा को तैयार करने में 30 मिनट लगते हैं। ऐसा इसलिए होता है, क्योंकि कभी-कभी, निरंतर समग्र अंतर्निहित कार्य मेमोरी में फिट होने के लिए बहुत बड़ा होता है और डिस्क पर फैल जाता है।

हमें इस समस्या का सामना करना पड़ा, जो हमें मिले एक-एक बग के कारण और बढ़ गई थी (अब ठीक हो गई है) जिसके कारण क्वेरी योजना में अतिरिक्त खंडों को शामिल करना पड़ा, भले ही वे अंततः भौतिकीकरण में कोई डेटा योगदान नहीं करते थे। इस बग को ढूंढना वास्तव में "डॉगफ़ूडसेप्शन" का मामला था: जब हम इसे बना रहे थे तो इनसाइट्स का उपयोग करते समय हमें इस प्रदर्शन समस्या का पता चला। इनसाइट्स में हमने जो समय की जानकारी देखी, उससे पता चला कि यहां कुछ गड़बड़ है, और हमने EXPLAIN का उपयोग करके और योजनाओं को देखकर समस्या का खुलासा किया। तो हम आपको बता सकते हैं कि यह काम करता है!

कार्यान्वयन को तेज़ बनाने के लिए, हमने एक कस्टम वृद्धिशील ताज़ा नीति बनाई, जिसने ताज़ा करने के लिए वेतन वृद्धि के आकार को सीमित कर दिया। हम यह देखने पर काम कर रहे हैं कि क्या यह कुछ ऐसा है जिसे हम TimescaleDB में ठीक से सामान्यीकृत कर सकते हैं।

परिवर्तन बड़े पैमाने पर कठिन है .

एक बार जब आपका डेटा एक निश्चित आकार तक पहुंच जाता है, तो TimescaleDB में कुछ DDL (स्कीमा संशोधन) संचालन में आदर्श से अधिक समय लग सकता है। हम पहले ही कुछ तरीकों से इसका अनुभव कर चुके हैं।

उदाहरण के लिए, बड़े हाइपरटेबल्स में नए इंडेक्स जोड़ना समय निर्धारण का एक अभ्यास बन जाता है। क्योंकि TimescaleDB वर्तमान में `CREATE INDEX` के साथ `CONCURRENTLY` का उपयोग करने का समर्थन नहीं करता है, अगला सबसे अच्छा विकल्प एक समय में इंडेक्स का एक हिस्सा बनाने के लिए इसकी अंतर्निहित विधि का उपयोग करना है। हमारे मामले में, हमें नया हिस्सा बनने के तुरंत बाद इसे बंद करना होगा, इसलिए "सक्रिय" हिस्से पर लॉकिंग न्यूनतम है। यानी, जब कोई हिस्सा नया हो तो एक इंडेक्स बनाने का मतलब है कि यह (लगभग) खाली है और इसलिए, जल्दी से पूरा हो सकता है और नए इंसर्ट को ब्लॉक नहीं कर सकता है।

एक और तरीका परिवर्तन कठिन है जब नए मेट्रिक्स (कॉलम) जोड़ने के लिए निरंतर समुच्चय को अद्यतन किया जाता है। सतत समुच्चय वर्तमान में `ALTER` का समर्थन नहीं करते। इसलिए, जब हम उपयोगकर्ताओं के लिए एक नई मीट्रिक प्रदर्शित करना चाहते हैं, तो हम निरंतर समुच्चय का एक नया "संस्करण" बनाते हैं, अर्थात, निरंतर समुच्चय "फू" के लिए हमारे पास "foo_v2", "foo_v3", आदि होंगे। आदर्श से कम लेकिन वर्तमान में काम कर रहा है।

अंत में, संपीड़न सेटिंग्स को बदलना बड़े पैमाने पर काफी कठिन है। वास्तव में, यह अभी हमारे लिए प्रभावी रूप से संभव नहीं है, क्योंकि इसके लिए सभी संपीड़ित टुकड़ों को डीकंप्रेस करना, सेटिंग्स में बदलाव करना और फिर उन्हें पुनः संपीड़ित करना आवश्यक होगा, जो हमारे वर्तमान पैमाने पर संभव नहीं है।

इन सभी चीजों का व्यावहारिक समाधान निकालने के लिए हम अपने सहयोगियों के साथ विचार-मंथन करते रहते हैं। न केवल हमारे लिए, बल्कि सभी टाइमस्केल उपयोगकर्ताओं के लिए।

लपेटें

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

बिल्डिंग इनसाइट्स हमारी टीम के लिए एक गहरा अनुभव था। हमने पहली बार देखा है कि हम टाइमस्केल को कितनी दूर तक ले जा सकते हैं, इसे प्रभावशाली पैमाने की संख्याओं तक पहुँचा सकते हैं। इस प्रक्रिया के दौरान हमें जिन दर्द बिंदुओं का सामना करना पड़ा, उन्होंने हमें ग्राहकों के प्रति इतनी सहानुभूति दी है - यही डॉगफूडिंग की खूबसूरती है।

अगले वर्ष, मुझे आशा है कि मैं एक और ब्लॉग पोस्ट लिखूंगा कि कैसे हम अधिक डेटाबेस की निगरानी कर रहे हैं और कैसे हमने बड़े पैमाने पर टाइमस्केल के साथ काम करने के अनुभव को बेहतर बनाना जारी रखा है।

तब आप देखना! 👋