PostgreSQL में डेटाबेस आकार में कमी के लिए रणनीतियाँ: एक उपयोग-आधारित दृष्टिकोण

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

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

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

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

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

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

PostgreSQL स्टोरेज मॉडल पर त्वरित पुनर्कथन

उपयोग-आधारित मॉडल में अपने डेटाबेस के आकार को प्रबंधित करने पर हमारी चर्चा के लिए एक सामान्य आधार तैयार करने के लिए, आइए हमारे PostgreSQL प्लेटफ़ॉर्म में मूल्य निर्धारण कैसे काम करता है, इसे जल्दी से शुरू करें ( समयमान ) और इसकी तुलना अन्य प्रबंधित PostgreSQL उत्पादों से कैसे की जाती है, जैसे PostgreSQL के लिए Amazon RDS और Amazon Aurora।

कल (💥) से, हम टाइमस्केल प्लेटफ़ॉर्म में दो प्रकार की डेटाबेस सेवाएँ प्रदान करते हैं:

• गतिशील PostgreSQL सेवाएँ , जहां डेवलपर्स प्रदर्शन से समझौता किए बिना पैसे बचाने के लिए गतिशील गणना के साथ PostgreSQL डेटाबेस बना सकते हैं।

  
  

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

  
  

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

• डेवलपर्स से उनके द्वारा उपयोग की जाने वाली मात्रा के लिए शुल्क लिया जाता है, बिना छोटे प्रिंट के - कोई न्यूनतम डेटाबेस आकार नहीं, कोई न्यूनतम स्केलिंग चरण नहीं। यदि, महीने के अंत तक, आपने 128 जीबी का उपयोग कर लिया है, तो आपसे उतना ही बिल लिया जाएगा। आप 1 जीबी से शुरू कर सकते हैं और टीबी तक बढ़ा सकते हैं।

• लिखित डेटा, डेटा ट्रांसफर या क्वेरीज़ के आधार पर कोई शुल्क नहीं है।

• डेटाबेस बनाते समय या स्केलिंग करते समय भंडारण आवंटित करने की कोई आवश्यकता नहीं है।

• डिस्क का आकार मैन्युअल रूप से छोटा करने की कोई आवश्यकता नहीं है.

  
  

इसे घर लाने के लिए, आइए इस मॉडल, Amazon RDS PostgreSQL और Amazon Aurora के बीच अंतर बताएं:

संक्षेप में, हमारी तुलना से तीन मुख्य निष्कर्ष यहां दिए गए हैं:

• टाइमस्केल और ऑरोरा दोनों आपके वास्तविक डेटाबेस आकार के लिए शुल्क लेते हैं। इसके विपरीत, RDS PostgreSQL प्रावधानित भंडारण के लिए शुल्क लेता है। आप आरडीएस में वॉल्यूम कम नहीं कर सकते।

  
  

• टाइमस्केल लिखित डेटा, डेटा ट्रांसफर या क्वेरी संचालन के लिए शुल्क नहीं लेता है। आरडीएस और ऑरोरा दोनों प्रति डेटा ट्रांसफर, अतिरिक्त बैकअप स्टोरेज के लिए शुल्क लेते हैं, और आप किस प्रकार का स्टोरेज चुन रहे हैं इसके आधार पर आपको कुछ अतिरिक्त I/O शुल्क लग सकते हैं।

  
  

• टाइमस्केल में कोई न्यूनतम स्केलिंग चरण नहीं है, जबकि ऑरोरा 10 जीबी से शुरू करने के बाद 10 जीबी की वृद्धि में स्केल करता है।

  
  

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

कैसे उपयोग-आधारित मूल्य-निर्धारण PostgreSQL संग्रहण प्रबंधन में सुधार करता है

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

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

उपयोग-आधारित मॉडल भंडारण की अधिकता की समस्या को खत्म करते हैं

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

स्केलिंग बढ़ाते समय आपको भंडारण के बारे में सोचने की ज़रूरत नहीं है

“टाइमस्केल के उपयोग-आधारित भंडारण का मतलब है कि मुझे अब डिस्क आकार के बारे में सोचने की ज़रूरत नहीं है। हमारी भंडारण लागत 30% कम हो गई है, और मुझे कुछ भी करने की ज़रूरत नहीं है!"

एडम मैकक्रीया, जूडोस्केल (टाइमस्केल ग्राहक)

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

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

आप डाउनस्केल कर सकते हैं (आपके द्वारा हटाए गए डेटा के लिए भुगतान करना बंद करें)

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

उपयोग-आधारित मॉडल को प्रभावी ढंग से कैसे नेविगेट करें: आपके पोस्टग्रेज डेटाबेस आकार को कम करने के लिए युक्तियाँ

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

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

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

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

इसे ध्यान में रखते हुए, आइए कुछ प्रथाओं पर गौर करें जो आपके पोस्टग्रेएसक्यूएल डेटाबेस आकार को व्यवस्थित तरीके से कम करते हुए, भंडारण के लिए उपयोग-आधारित मॉडल को यथासंभव प्रभावी ढंग से नेविगेट करने में आपकी सहायता करेंगे। टाइमस्केल के विशेष मामले में, हमारे पास कुछ विशेष रूप से उपयोगी विशेषताएं हैं, जिन्हें हम भी कवर करेंगे।

अपने PostgreSQL डेटाबेस में ब्लोट कम करें

उपयोग-आधारित मॉडल में सबसे पहले यह करना होगा कि पोस्टग्रेएसक्यूएल स्टोरेज कैसे काम करता है, इसकी बारीकियों पर ध्यान दें, यानी, आपको नियमित आधार पर ब्लोट को कम करना होगा। इससे आपको न केवल आपके डेटाबेस आकार में बल्कि आपकी I/O आवश्यकताओं में भी मदद मिलेगी। हम आपको इस अनुभाग में कुछ बुनियादी बातों की ओर संकेत करेंगे, लेकिन इस एचएन थ्रेड में कुछ बेहतरीन सलाह हैं , और हमने लिखा भी है PostgreSQL में टेबल ब्लोट पर एक ब्लॉग पोस्ट .

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

  
  

• बार-बार वैक्यूम करें। टेबल ब्लोट से प्रभावी ढंग से निपटने के लिए, आप ऑटोवैक्यूम को अधिक बार चलाने के लिए कॉन्फ़िगर करना चाह सकते हैं। Postgresql.conf में ऑटोवैक्यूम सेटिंग्स को विश्व स्तर पर समायोजित करने के बजाय, इन सेटिंग्स को प्रति-तालिका के आधार पर ठीक करना अधिक सटीक है। यह इस तथ्य को पूरा करता है कि विभिन्न तालिकाओं में मृत टुपल्स को जमा करने की अलग-अलग प्रवृत्ति हो सकती है। लंबे समय तक चलने वाले लेनदेन की निगरानी करना भी महत्वपूर्ण है जो ऑटोवैक्यूम संचालन में बाधा उत्पन्न कर सकता है।

  
  

• अप्रयुक्त पृष्ठों को पुनः प्राप्त करें. जबकि ऑटोवैक्यूम और वैक्यूम मृत टुपल्स को संबोधित करते हैं, अप्रयुक्त पृष्ठों को पुनः प्राप्त करने के लिए एक अलग दृष्टिकोण की आवश्यकता होती है। हालाँकि इस उद्देश्य के लिए VACUUM FULL का उपयोग किया जा सकता है, लेकिन इसमें पूरी तालिका को लॉक करने की अंतर्निहित सीमा है। Pg_repack इसमें आपकी मदद कर सकते हैं.

कुछ PostgreSQL फ़ाइन-ट्यूनिंग करें

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

• shared_buffers : PostgreSQL के पेज कैश के लिए उपयोग की जाने वाली मेमोरी को नियंत्रित करता है, और यह आमतौर पर सिस्टम की कुल RAM के 25% पर सेट होता है।

  
  

• work_mem : यह एक क्वेरी के भीतर प्रति ऑपरेशन आवंटित मेमोरी सेट करता है। टाइमस्केल में, अनुशंसित सेटिंग (25 % of RAM) / max_connections है।

  
  

• max_connections : यह डेटाबेस के लिए अनुमत समवर्ती कनेक्शन की अधिकतम संख्या निर्धारित करता है। कनेक्शन पूलर कई अल्पकालिक कनेक्शनों को प्रबंधित करने में मदद कर सकते हैं।

  
  

• max_worker_processes : यह निर्धारित करता है कि PostgreSQL आरंभ करने वाली कार्यकर्ता प्रक्रियाओं की अधिकतम संख्या निर्धारित कर सकता है। यदि टाइमस्केल का उपयोग कर रहे हैं, तो इस पैरामीटर को सेट करने का सूत्र है: max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers ।

  
  

• max_parallel_workers : यह समानांतर प्रश्नों का समर्थन करने वाले श्रमिकों की अधिकतम संख्या निर्दिष्ट करता है। डिफ़ॉल्ट इसे उपलब्ध सीपीयू की संख्या के बराबर सेट करना है।

  
  

• autovacuum_max_workers : यह समवर्ती ऑटोवैक्यूम प्रक्रियाओं की अधिकतम संख्या निर्धारित करता है। टाइमस्केल में, यह डिफ़ॉल्ट रूप से 10 पर सेट है।

स्वच्छता को अनुक्रमित करने का अभ्यास करें

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

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

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

ऐसा करने का एक तरीका pg_stat_user_indexes का उपयोग करना है:

 -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname;

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

टाइमस्केल कम्प्रेशन के माध्यम से अपनी बड़ी तालिकाओं को सिकोड़ें

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

टाइमस्केल का संपीड़न नियमित पंक्ति-आधारित डेटा को अधिक कॉम्पैक्ट स्तंभ प्रारूप में परिवर्तित करके काम करता है। यह प्रक्रिया समय-श्रृंखला डेटा के लिए विशेष रूप से प्रभावी है, जहां कई स्तंभों में दोहराव वाले मान हो सकते हैं; हम प्रत्येक डेटा प्रकार के आधार पर विभिन्न संपीड़न एल्गोरिदम लागू करके प्रभावशाली संपीड़न दर (+90%) प्राप्त कर सकते हैं। इसका मतलब है कि आपकी बड़ी टेबल को 10x तक छोटा किया जा सकता है।

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

 -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks');

संपीड़न के बारे में अधिक जानने के लिए, हमारे दस्तावेज़ देखें .

डेटा प्रबंधन रणनीति सेट करें: पुराने डेटा को सस्ते स्टोरेज में ले जाएं, उस डेटा को हटा दें जिसकी अब आपको आवश्यकता नहीं है

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

एक सरल टियरिंग नीति बनाकर, आप पुराने, कम पहुंच वाले डेटा को अथाह ऑब्जेक्ट स्टोरेज परत पर ले जा सकते हैं:

 -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month);

इस ऑब्जेक्ट स्टोर में निम्नलिखित विशेषताएं हैं:

• यह हमारे उच्च-प्रदर्शन भंडारण की तुलना में कम कीमत के साथ आता है, जिससे आप बहुत कम कीमत पर कई टीबी डेटा संग्रहीत कर सकते हैं।
• यह अनंत है, यानी आप जितना चाहें उतना डेटा संग्रहीत कर सकते हैं।
  

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

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

इस कम लागत वाली भंडारण परत की पेशकश के अलावा, टाइमस्केल उस डेटा को हटाने के लिए डेटा प्रतिधारण नीतियों को सेट करना आसान बनाता है जिसकी आपको अब आवश्यकता नहीं है:

 -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months');

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

उपयोग-आधारित मॉडल और डेटा प्रबंधन प्रतिमान

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

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

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

- कार्लोटा सोटा द्वारा लिखित।