बड़े PostgreSQL डेटाबेस में कॉलमर कम्प्रेशन लागू करने की रणनीतियाँ

बढ़ते अनुप्रयोगों के लिए डेटाबेस को स्केल करना एक संस्कार है। जैसे ही आप देखते हैं कि आपकी तालिकाएँ लाखों या यहाँ तक कि अरबों पंक्तियों के साथ विस्तारित हो रही हैं, आपकी एक बार की त्वरित क्वेरीज़ पिछड़ने लगती हैं, और बढ़ती बुनियादी ढाँचे की लागत आपकी निचली रेखा पर एक लंबी छाया डालना शुरू कर देती है। आप एक पहेली में फंस गए हैं: आप अपने प्रिय PostgreSQL से अलग नहीं होना चाहते हैं, लेकिन ऐसा लगता है कि आपको अपने बढ़ते डेटासेट से निपटने के लिए एक अधिक प्रभावी तरीके की आवश्यकता होगी। पोस्टग्रेज़ इस लेख में, हम आपको इसकी कहानी बताएंगे कि कैसे हमने बनाया। विशेष संपीड़न एल्गोरिदम के साथ स्तंभ भंडारण को जोड़कर, हम किसी भी अन्य संबंधपरक डेटाबेस (+95%) में अद्वितीय प्रभावशाली संपीड़न दर प्राप्त करने में सक्षम हैं। PostgreSQL की स्केलेबिलिटी में सुधार करने के लिए एक लचीला, उच्च-प्रदर्शन स्तंभ संपीड़न तंत्र अपने डेटासेट को संपीड़ित करके, आप अपने PostgreSQL डेटाबेस को और अधिक बढ़ा सकते हैं। जैसा कि हम इस लेख में देखेंगे, यह अत्यधिक प्रभावी संपीड़न डिज़ाइन आपको अपने बड़े PostgreSQL तालिकाओं के आकार को 10-20x तक कम करने की अनुमति देता है। आप क्वेरी प्रदर्शन में सुधार करते हुए छोटी डिस्क पर अधिक डेटा संग्रहीत कर सकते हैं (यानी पैसे की बचत)। टाइमस्केल संपीड़न भी पूरी तरह से परिवर्तनशील है, जिससे डेटाबेस प्रबंधन और संचालन आसान हो जाता है: आप संपीड़ित तालिकाओं में कॉलम जोड़, बदल और छोड़ सकते हैं, और आप सीधे डेटा सम्मिलित, अद्यतन और हटा सकते हैं। अधिक स्केलेबल PostgreSQL में आपका स्वागत है! सामग्री अवलोकन PostgreSQL को डेटाबेस संपीड़न की आवश्यकता क्यों है? लेकिन टोस्ट के बारे में क्या? संपीड़न PostgreSQL का मूल निवासी क्यों नहीं है? पंक्ति बनाम स्तंभ-उन्मुख डेटाबेस का एक परिचय पंक्ति बनाम स्तंभ-उन्मुख डेटाबेस: क्या चुनें? रो-ओरिएंटेड डेटाबेस पर कॉलमर स्टोरेज का निर्माण PostgreSQL को हाइब्रिड पंक्ति-स्तंभ स्टोर में बदलना पर्दे के पीछे: पंक्ति डेटा से लेकर संपीड़ित स्तंभ सरणी तक संपीड़ित डेटा को कुशलतापूर्वक क्वेरी करना आमतौर पर पूछे जाने वाले डेटा को कॉलम के आधार पर समूहीकृत करना segmentby स्तंभों परिभाषित करना segmentby माध्यम से उन्नत फ़ाइन-ट्यूनिंग orderby टाइमस्केल के संपीड़न का विकास अंतिम परिणाम: बड़े पोस्टग्रेएसक्यूएल डेटाबेस के लिए तेज़ क्वेरीज़, कम स्टोरेज फ़ुटप्रिंट संपीड़न और स्तरीय भंडारण: टाइमस्केल भंडारण जीवनचक्र PostgreSQL के साथ बने रहें PostgreSQL को डेटाबेस संपीड़न की आवश्यकता क्यों है? लेकिन हमने संपीड़न कैसे बनाया, इसके विवरण में जाने से पहले, आइए इस प्रश्न का उत्तर देने में कुछ मिनट बिताएँ: PostgreSQL में एक नया डेटाबेस संपीड़न तंत्र जोड़ना क्यों आवश्यक है? आइए पहले आधुनिक अनुप्रयोगों की आवश्यकताओं और सॉफ़्टवेयर इतिहास को थोड़ा समझें। हम पोस्टग्रेज़ को पसंद करते हैं: हमारा मानना है कि यह अनुप्रयोगों के निर्माण के लिए सबसे अच्छा आधार है क्योंकि इसकी विश्वसनीयता, लचीलेपन और समृद्ध पारिस्थितिकी तंत्र का संयोजन किसी भी अन्य डेटाबेस से मेल खाना बहुत कठिन है। लेकिन पोस्टग्रेज़ का जन्म दशकों पहले हुआ था—यह मजबूती बिना किसी नकारात्मक पहलू के नहीं आती। आज, डेवलपर्स PostgreSQL का उपयोग पारंपरिक OLTP (ऑनलाइन ट्रांजेक्शन प्रोसेसिंग) उपयोग के मामले से कहीं अधिक के लिए कर रहे हैं, जिसके लिए यह जाना जाता है। कई डेटा-गहन, मांग वाले एप्लिकेशन - 24/7 चल रहे हैं और डेटा की लगातार बढ़ती मात्रा को संभाल रहे हैं - PostgreSQL द्वारा संचालित हैं: PostgreSQL डेटाबेस का उपयोग ट्रैफ़िक प्रबंधन प्रणालियों, उपयोगिता नेटवर्क और सार्वजनिक सुरक्षा मॉनिटर से बड़ी मात्रा में सेंसर डेटा स्ट्रीमिंग को प्राप्त करने के लिए किया जा रहा है। ऊर्जा कंपनियां स्मार्ट ग्रिड और नवीकरणीय ऊर्जा स्रोतों से मेट्रिक्स को संग्रहीत और विश्लेषण करने के लिए PostgreSQL का उपयोग कर रही हैं। वित्तीय क्षेत्र में, PostgreSQL वास्तविक समय में मार्केट टिक डेटा पर नज़र रखने वाले सिस्टम के मूल में है। ई-कॉमर्स प्लेटफ़ॉर्म उपयोगकर्ता इंटरैक्शन द्वारा उत्पन्न घटनाओं को ट्रैक और विश्लेषण करने के लिए PostgreSQL का उपयोग कर रहे हैं। एआई अनुप्रयोगों की नई लहर को सशक्त बनाने के लिए पोस्टग्रेज को वेक्टर डेटाबेस के रूप में भी उपयोग किया जा रहा है। इसके परिणामस्वरूप पोस्टग्रेज़ तालिकाएँ बहुत तेज़ी से बढ़ रही हैं, और तालिकाओं का अरबों पंक्तियों तक पहुँचना उत्पादन में नया सामान्य है। दुर्भाग्य से, PostgreSQL डेटा की इस मात्रा से निपटने के लिए मूल रूप से अपर्याप्त है: क्वेरी प्रदर्शन धीमा होने लगता है, और डेटाबेस प्रबंधन दर्दनाक हो जाता है। इन सीमाओं को संबोधित करने के लिए, हमने निर्माण किया , एक एक्सटेंशन जो और टाइमस्केलडीबी स्वचालित विभाजन, निरंतर एकत्रीकरण, क्वेरी प्लानर सुधार कई अन्य सुविधाओं के माध्यम से मांग वाले अनुप्रयोगों के लिए PostgreSQL के प्रदर्शन को मापता है। PostgreSQL के लिए एक उच्च प्रदर्शन संपीड़न तंत्र का निर्माण एक समान रूप से महत्वपूर्ण अनलॉक था। ये लगातार बढ़ते डेटासेट न केवल अच्छे प्रदर्शन के लिए चुनौतीपूर्ण हैं, बल्कि उनके डेटा के संचय से बड़ी डिस्क और उच्च भंडारण बिल होता है। PostgreSQL को एक समाधान की आवश्यकता थी। लेकिन टोस्ट के बारे में क्या? लेकिन PostgreSQL की मौजूदा TOAST विधि के बारे में क्या? इसके अद्भुत नाम के बावजूद 🍞😋, TOAST आपके बड़े PostgreSQL डेटाबेस के आकार को व्यवस्थित रूप से कम करने में प्रभावी नहीं है . TOAST एक स्वचालित तंत्र है जिसका उपयोग PostgreSQL बड़े मानों को संग्रहीत और प्रबंधित करने के लिए करता है जो व्यक्तिगत डेटाबेस पृष्ठों में फिट नहीं होते हैं। जबकि TOAST इसे प्राप्त करने के लिए अपनी तकनीकों में से एक के रूप में संपीड़न को शामिल करता है, TOAST की प्राथमिक भूमिका बोर्ड भर में भंडारण स्थान को अनुकूलित करना नहीं है। उदाहरण के लिए, यदि आपके पास छोटे टुपल्स से बना 1 टीबी डेटाबेस है, तो TOAST आपको व्यवस्थित रूप से उस 1 टीबी को 80 जीबी में बदलने में मदद नहीं करेगा, चाहे आप कितनी भी फाइन-ट्यूनिंग की कोशिश करें। जैसे ही बड़े आकार की विशेषताएँ 2 KB की सीमा से अधिक हो जाती हैं, TOAST स्वचालित रूप से एक पंक्ति में संपीड़ित हो जाएगा, लेकिन TOAST छोटे मानों (टुपल्स) के लिए मदद नहीं करता है, न ही आप अधिक उन्नत उपयोगकर्ता-कॉन्फ़िगर करने योग्य कॉन्फ़िगरेशन लागू कर सकते हैं जैसे कि एक महीने से अधिक पुराने सभी डेटा को संपीड़ित करना एक विशिष्ट तालिका में. TOAST का संपीड़न पूरी तरह से व्यक्तिगत कॉलम मानों के आकार पर आधारित है, न कि व्यापक तालिका या डेटासेट विशेषताओं पर। TOAST महत्वपूर्ण I/O ओवरहेड भी पेश कर सकता है, विशेष रूप से बड़ी तालिकाओं के लिए जिनमें अक्सर बड़े आकार के कॉलम होते हैं। ऐसे मामलों में, PostgreSQL को TOAST तालिका से आउट-ऑफ़-लाइन डेटा पुनर्प्राप्त करने की आवश्यकता होती है, जो मुख्य तालिका तक पहुंचने से एक अलग I/O ऑपरेशन है, क्योंकि PostgreSQL को पढ़ने के लिए मुख्य तालिका से TOAST तालिका तक पॉइंटर्स का पालन करना होगा। पूरा डेटा. यह आम तौर पर खराब प्रदर्शन की ओर ले जाता है। अंत में, TOAST का संपीड़न विशेष रूप से उच्च संपीड़न अनुपात प्रदान करने के लिए डिज़ाइन नहीं किया गया है, क्योंकि यह सभी डेटा प्रकारों के लिए एक मानक एल्गोरिदम का उपयोग करता है। संपीड़न PostgreSQL का मूल निवासी क्यों नहीं है? पंक्ति बनाम स्तंभ-उन्मुख डेटाबेस का एक परिचय TOAST का यह त्वरित उल्लेख हमें डेटा को प्रभावी ढंग से संपीड़ित करने में PostgreSQL की सीमाओं को समझने में भी मदद करता है। जैसा कि हमने अभी देखा, TOAST का संपीड़न पंक्ति-दर-पंक्ति डेटा को संभालता है, लेकिन यह पंक्ति-उन्मुख आर्किटेक्चर उस समरूपता को बिखेर देता है जिस पर संपीड़न एल्गोरिदम पनपते हैं, जिससे संपीड़न कितना परिचालनात्मक हो सकता है, इस पर एक मौलिक छत बन जाती है। यह एक बुनियादी कारण है कि जब भंडारण अनुकूलन की बात आती है तो रिलेशनल डेटाबेस (जैसे देशी पोस्टग्रेज) अक्सर कम पड़ जाते हैं। आइए इसे तोड़ें। परंपरागत रूप से, डेटाबेस दो श्रेणियों में से एक में आते हैं: डेटा को पंक्तियों द्वारा व्यवस्थित करते हैं, प्रत्येक पंक्ति में एक विशेष रिकॉर्ड के लिए सभी डेटा होते हैं। वे लेन-देन प्रसंस्करण के लिए अनुकूलित हैं जहां रिकॉर्ड को सम्मिलित करना, अपडेट करना और हटाना अक्सर होता है, और वे ओएलटीपी सिस्टम के लिए कुशल हैं जहां संचालन में व्यक्तिगत रिकॉर्ड या डेटा के छोटे उपसमूह शामिल होते हैं (उदाहरण के लिए, किसी विशिष्ट ग्राहक के बारे में सभी जानकारी पुनर्प्राप्त करना)। पंक्ति-उन्मुख डेटाबेस दूसरी ओर , कॉलम द्वारा डेटा व्यवस्थित करते हैं। प्रत्येक कॉलम एक विशेष विशेषता के लिए सभी डेटा को कई रिकॉर्ड में संग्रहीत करता है। वे आम तौर पर ओएलएपी सिस्टम (ऑनलाइन विश्लेषणात्मक प्रसंस्करण) के लिए अनुकूलित होते हैं, जहां प्रश्नों में अक्सर कई रिकॉर्डों में एकत्रीकरण और संचालन शामिल होते हैं। , कॉलम-उन्मुख (उर्फ "कॉलमनार") डेटाबेस आइए इसे एक उदाहरण से स्पष्ट करें। मान लें कि हमारे पास चार कॉलम वाली एक तालिका है: , , , और । यदि यह तालिका दस लाख उपयोगकर्ताओं के लिए डेटा संग्रहीत करती है, तो इसमें प्रभावी रूप से दस लाख पंक्तियाँ और चार कॉलम होंगे, जो प्रत्येक उपयोगकर्ता के डेटा (यानी, प्रत्येक पंक्ति) को डिस्क पर भौतिक रूप से संग्रहीत करेंगे। users user_id name logins last_login इस पंक्ति-उन्मुख सेटअप में, user_id = 500,000 के लिए पूरी पंक्ति को सन्निहित रूप से संग्रहीत किया जाता है, जिससे पुनर्प्राप्ति तेज़ हो जाती है। परिणामस्वरूप, एक पंक्ति स्टोर पर उथली और चौड़ी क्वेरीज़ तेज़ होंगी (उदाहरण के लिए, "उपयोगकर्ता X के लिए सभी डेटा प्राप्त करें"): -- Create table CREATE TABLE users ( user_id SERIAL PRIMARY KEY, name VARCHAR(100), logins INT DEFAULT 0, last_login TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Assume we have inserted 1M user records into the 'users' table -- Shallow-and-wide query example (faster in row store) SELECT * FROM users WHERE user_id = 500000; इसके विपरीत, एक कॉलमर स्टोर सभी को एक साथ, सभी नामों को एक साथ, सभी लॉगिन मानों को एक साथ, इत्यादि संग्रहीत करेगा, ताकि प्रत्येक कॉलम का डेटा डिस्क पर लगातार संग्रहीत हो। यह डेटाबेस आर्किटेक्चर गहरे और संकीर्ण प्रश्नों का समर्थन करता है, उदाहरण के लिए, "सभी उपयोगकर्ताओं के लिए लॉगिन की औसत संख्या की गणना करें": user_id -- Deep-and-narrow query example (faster in column store) SELECT AVG(logins) FROM users; स्तंभकार स्टोर संकीर्ण प्रश्नों के साथ विशेष रूप से अच्छा प्रदर्शन करते हैं। एक स्तंभ डेटाबेस में, औसत की गणना करने के लिए केवल कॉलम डेटा को पढ़ने की आवश्यकता होती है, जो डिस्क से प्रत्येक उपयोगकर्ता के लिए संपूर्ण डेटासेट लोड किए बिना किया जा सकता है। व्यापक डेटा पर logins जैसा कि आप अब तक अनुमान लगा चुके होंगे, पंक्तियों बनाम स्तंभों में डेटा संग्रहीत करने से इस बात पर भी प्रभाव पड़ता है कि डेटा को कितनी अच्छी तरह संपीड़ित किया जा सकता है। एक स्तंभ डेटाबेस में, डेटा के अलग-अलग कॉलम आम तौर पर एक ही प्रकार के होते हैं और अक्सर अधिक सीमित डोमेन या सीमा से खींचे जाते हैं। परिणामस्वरूप, उदाहरण के लिए, हमारा कॉलम पहले पूर्णांक प्रकार का होता था और इसमें संभवतः संख्यात्मक मानों की एक छोटी श्रृंखला शामिल होती थी (और इस प्रकार इसमें कम एन्ट्रॉपी होती है, जो अच्छी तरह से संपीड़ित होती है)। इसकी तुलना पंक्ति-उन्मुख प्रारूप से करें, जहां डेटा की एक पूरी विस्तृत पंक्ति में कई अलग-अलग डेटा प्रकार और श्रेणियां शामिल होती हैं। स्तंभ भंडार आम तौर पर पंक्ति-उन्मुख डेटाबेस से बेहतर संपीड़ित होते हैं। logins लेकिन भले ही वे OLAP-शैली के प्रश्नों और संपीड़ितता में लाभ दिखाते हों, स्तंभ भंडार व्यापार-बंद के बिना नहीं हैं: अलग-अलग पंक्तियों को पुनः प्राप्त करने वाली क्वेरीज़ बहुत कम प्रदर्शन करने वाली होती हैं (कभी-कभी चलाना असंभव भी होता है)। उनका आर्किटेक्चर पारंपरिक ACID लेनदेन के लिए उतना अनुकूल नहीं है। कॉलमर स्टोर्स में अपडेट करना अक्सर संभव नहीं होता है। पंक्ति-आधारित दुकानों के लिए इसका लाभ उठाना आसान है (उदाहरण के लिए, बी-ट्री) उचित रिकॉर्ड शीघ्रता से ढूंढने के लिए। अनुक्रमणिका पंक्ति संग्रह के साथ, अपने डेटासेट को सामान्य बनाना आसान होता है, ताकि आप अन्य तालिकाओं में संबंधित डेटासेट को अधिक कुशलता से संग्रहीत कर सकें। पंक्ति बनाम स्तंभ-उन्मुख डेटाबेस: क्या चुनें? तो, क्या बेहतर है: पंक्ति-उन्मुख या स्तंभ-उन्मुख? परंपरागत रूप से, आप अपने कार्यभार के आधार पर दोनों के बीच तालमेल का मूल्यांकन करेंगे। यदि आप एक विशिष्ट OLTP उपयोग केस चला रहे थे, तो आप संभवतः PostgreSQL जैसे पंक्ति-उन्मुख रिलेशनल डेटाबेस को चुनेंगे; यदि आपका उपयोग मामला स्पष्ट रूप से OLAP था, तो आप ClickHouse जैसे स्तंभ स्टोर की ओर झुक सकते हैं। लेकिन क्या होगा यदि आपका कार्यभार वास्तव में दोनों का मिश्रण है? आपकी एप्लिकेशन क्वेरी आम तौर पर उथली और चौड़ी हो सकती हैं, जिसमें एक व्यक्तिगत क्वेरी डेटा के कई कॉलमों के साथ-साथ कई अलग-अलग डिवाइस/सर्वर/आइटम में डेटा तक पहुंच प्राप्त करती है। उदाहरण के लिए, आप एक उपयोगकर्ता-सामना वाले विज़ुअलाइज़ेशन को सशक्त बना रहे होंगे जिसके लिए एक विशिष्ट विनिर्माण संयंत्र में सभी सेंसरों के लिए अंतिम रिकॉर्ड किए गए तापमान और आर्द्रता को प्रदर्शित करने की आवश्यकता होती है। ऐसी क्वेरी के लिए सभी पंक्तियों में कई स्तंभों तक पहुंचने की आवश्यकता होगी जो भवन मानदंडों से मेल खाते हैं, संभावित रूप से हजारों या लाखों रिकॉर्ड तक फैले हुए हैं। लेकिन आपकी कुछ क्वेरीज़ गहरी और संकीर्ण भी हो सकती हैं, जिसमें एक व्यक्तिगत क्वेरी लंबी अवधि में एक विशिष्ट सेंसर के लिए कम संख्या में कॉलम का चयन करती है। उदाहरण के लिए, आपको विसंगतियों का निरीक्षण करने के लिए पिछले महीने में किसी विशिष्ट उपकरण के तापमान रुझान का विश्लेषण करने की भी आवश्यकता हो सकती है। इस प्रकार की क्वेरी एक एकल कॉलम (तापमान) पर केंद्रित होगी, लेकिन लक्ष्य अवधि में प्रत्येक समय अंतराल के अनुरूप बड़ी संख्या में पंक्तियों से इस जानकारी को पुनर्प्राप्त करने की आवश्यकता होगी। आपका एप्लिकेशन डेटा-सघन और भारी इन्सर्ट (जोड़ना) भी हो सकता है। जैसा कि हमने पहले चर्चा की, प्रति सेकंड सैकड़ों-हजारों लेखन से निपटना नई सामान्य बात है। आपके डेटासेट भी संभवतः बहुत बारीक हैं, उदाहरण के लिए, आप हर सेकंड डेटा एकत्र कर रहे होंगे। पिछले उदाहरण को जारी रखते हुए, आपके डेटाबेस को वास्तविक समय में आपके उपयोगकर्ता-सामना वाले विज़ुअलाइज़ेशन को सशक्त बनाने के लिए लगातार पढ़ने के साथ-साथ इन भारी लेखन की सेवा करने की आवश्यकता होगी। आपका डेटा है, लेकिन जरूरी नहीं । आपको कभी-कभी पुराने रिकॉर्ड को अपडेट करने या संभवतः देर से आने वाले या ऑर्डर से बाहर होने वाले डेटा को रिकॉर्ड करने की आवश्यकता हो सकती है। अधिकतर संलग्न कि केवल संलग्न हो यह कार्यभार पारंपरिक अर्थों में न तो OLTP है और न ही OLAP है। इसके बजाय, इसमें दोनों के तत्व शामिल हैं। इसलिए क्या करना है? हाइब्रिड जाओ! रो-ओरिएंटेड डेटाबेस पर कॉलमर स्टोरेज का निर्माण पिछले उदाहरण की तरह कार्यभार को पूरा करने के लिए, एक एकल डेटाबेस में निम्नलिखित को शामिल करना होगा: प्रति सेकंड सैकड़ों-हजारों राइट्स में आसानी से उच्च-सम्मिलित दरों को बनाए रखने की क्षमता देर से या ऑर्डर से बाहर डेटा डालने के साथ-साथ मौजूदा डेटा को संशोधित करने के लिए समर्थन एक बड़े डेटासेट में उथले और चौड़े और गहरे और संकीर्ण दोनों प्रकार के प्रश्नों को कुशलतापूर्वक संसाधित करने के लिए पर्याप्त लचीलापन एक संपीड़न तंत्र भंडारण दक्षता में सुधार के लिए डेटाबेस आकार को काफी कम करने में सक्षम है TimescaleDB (और इसलिए, PostgreSQL में) में स्तंभ संपीड़न जोड़ते समय हमने यही हासिल करने का लक्ष्य रखा था। PostgreSQL को हाइब्रिड पंक्ति-स्तंभ स्टोर में बदलना जैसा कि हमने पिछले अनुभाग में बताया था, हमने PostgreSQL को अधिक प्रदर्शन और स्केलेबिलिटी के साथ विस्तारित करने के लिए TimescaleDB का निर्माण किया, जिससे यह कार्यभार की मांग के लिए उपयुक्त हो गया। TimescaleDB को PostgreSQL एक्सटेंशन के रूप में कार्यान्वित किया गया है: ऐसा करने पर, यह PostgreSQL के बारे में जो कुछ भी महान है, उसे विरासत में मिला है, जैसे पूर्ण SQL, विशाल क्वेरी और डेटा मॉडल लचीलापन, युद्ध-परीक्षणित विश्वसनीयता, एक उत्साही डेवलपर और उपयोगकर्ता आधार, और सबसे बड़े डेटाबेस पारिस्थितिकी तंत्र में से एक आस-पास। समय श्रृंखला डेटा। सिद्धांत रूप में, इसका मतलब यह है कि TimescaleDB को इसकी मामूली संपीड़ितता के साथ, PostgreSQL के पंक्ति-उन्मुख भंडारण प्रारूप में भी बंद कर दिया गया है। वास्तव में, ऐसा कुछ भी नहीं है जिसे थोड़ी सी इंजीनियरिंग हल नहीं कर सकती। दो अवलोकन. पहला, , अर्थात्, वे शिथिल अनुक्रमिक मुख्य कुंजी, जैसे टाइमस्टैम्प या सीरियल ईवेंट आईडी के साथ परिशिष्ट-भारी (बनाम अद्यतन-भारी) हैं। दूसरा, ऐसे डेटासेट से नियमित रूप से स्कैन या रोलअप के माध्यम से पूछताछ की जाती है, न कि केवल बिंदु क्वेरी के माध्यम से। उन अवलोकनों को ध्यान में रखते हुए, हमने टाइमस्केलडीबी के लिए एक उपन्यास स्तंभ भंडारण सुविधा तैयार की (जिसे हम अगले भाग में विस्तार से कवर करेंगे) जो हमें संपीड़न के अद्वितीय स्तर को प्राप्त करने की अनुमति देता है। अधिकांश बड़े PostgreSQL वर्कलोड में समय-श्रृंखला जैसी संरचना होती है वास्तव में, इस पंक्ति-से-स्तंभ परिवर्तन को आपके संपूर्ण डेटाबेस पर लागू करने की आवश्यकता नहीं है। टाइमस्केल उपयोगकर्ता के रूप में, आप अपनी पोस्टग्रेएसक्यूएल तालिकाओं को हाइब्रिड पंक्ति-स्तंभ भंडार में बदल सकते हैं, यह चुनकर कि किस डेटा को स्तंभ रूप में संपीड़ित करना है हमारे सरल एपीआई के माध्यम से और आपके एप्लिकेशन की आवश्यकता के अनुसार दोनों स्टोरेज आर्किटेक्चर से लाभ उठाएं। आइए एक उदाहरण से स्पष्ट करें कि यह व्यावहारिक रूप से कैसे काम करता है। एक तापमान निगरानी प्रणाली की कल्पना करें जो कई उपकरणों से हर सेकंड रीडिंग एकत्र करती है, टाइमस्टैम्प, डिवाइस आईडी, स्थिति कोड और तापमान जैसे डेटा संग्रहीत करती है। नवीनतम तापमान डेटा को कुशलतापूर्वक एक्सेस करने के लिए, विशेष रूप से परिचालन प्रश्नों के लिए जहां आप विभिन्न उपकरणों से नवीनतम रीडिंग का विश्लेषण करना चाहते हैं, आप सबसे हालिया डेटा (उदाहरण के लिए, पिछले सप्ताह) को पारंपरिक असम्पीडित, पंक्ति-उन्मुख पोस्टग्रेएसक्यूएल संरचना में रख सकते हैं . यह उच्च अंतर्ग्रहण दरों का समर्थन करता है और हाल के डेटा के बारे में बिंदु प्रश्नों के लिए भी बहुत अच्छा है: -- Find the most recent data from a specific device SELECT * FROM temperature_data WHERE device_id = 'A' ORDER BY timestamp DESC LIMIT 1; -- Find all devices in the past hour that are above a temperature threshold SELECT DISTINCT device_id, MAX(temperature) FROM temperature WHERE timestamp > NOW() - INTERVAL '1 hour' AND temperature > 40.0; लेकिन एक बार जब यह डेटा कुछ दिन पुराना हो जाता है, तो पिछले वाले की तरह उथली और चौड़ी क्वेरीज़ अब बार-बार नहीं चलाई जाती हैं: इसके बजाय, गहरी और संकीर्ण विश्लेषणात्मक क्वेरीज़ अधिक सामान्य होती हैं। इसलिए इस प्रकार की क्वेरी के लिए भंडारण दक्षता और क्वेरी प्रदर्शन में सुधार करने के लिए, आप स्वचालित रूप से एक सप्ताह से अधिक पुराने सभी डेटा को अत्यधिक संपीड़ित स्तंभ प्रारूप में बदलना चुन सकते हैं। टाइमस्केल में ऐसा करने के लिए, आप एक संपीड़न नीति को इस प्रकार परिभाषित करेंगे: -- Add a compression policy to compress temperature data older than 1 week SELECT add_compression_policy('temperature_data', INTERVAL '7 days'); एक बार जब आपका डेटा संपीड़ित हो जाता है, तो तापमान डेटा (चाहे किसी विशिष्ट डिवाइस पर या कई डिवाइसों पर) पर गहरी और संकीर्ण विश्लेषणात्मक क्वेरी चलाने से इष्टतम क्वेरी प्रदर्शन दिखाई देगा। -- Find daily max temperature for a specific device across past year SELECT time_bucket('1 day', timestamp) AS day, MAX(temperature) FROM temperature_data WHERE timestamp > NOW() - INTERVAL '1 year' AND device_id = 'A' ORDER BY day; -- Find monthly average temperatures across all devices SELECT device_id, time_bucket('1 month', timestamp) AS month, AVG(temperature) FROM temperature_data WHERE timestamp < NOW() - INTERVAL '2 weeks' GROUP BY device_id, month ORDER BY month; हम एक पंक्ति से कॉलम प्रारूप में "शिफ्ट" का प्रतिनिधित्व कैसे करते हैं? टाइमस्केल के हाइपरटेबल्स एक विभाजन कुंजी, जैसे टाइमस्टैम्प या अन्य सीरियल आईडी कॉलम के आधार पर डेटा को "खंडों" में विभाजित करने का काम करते हैं। प्रत्येक खंड उस विभाजन कुंजी के लिए टाइमस्टैम्प या अन्य मानों की एक निश्चित सीमा के अनुरूप रिकॉर्ड संग्रहीत करता है। उपरोक्त उदाहरण में, तापमान डेटा को सप्ताह के अनुसार विभाजित किया जाएगा ताकि नवीनतम हिस्सा पंक्ति प्रारूप में रहे, और सभी पुराने सप्ताह स्तंभ प्रारूप में परिवर्तित हो जाएं। यह हाइब्रिड रो-कॉलम स्टोरेज इंजन स्टोरेज फ़ुटप्रिंट को नाटकीय रूप से कम करते हुए बड़े PostgreSQL डेटाबेस में क्वेरी प्रदर्शन को अनुकूलित करने के लिए एक अविश्वसनीय रूप से शक्तिशाली उपकरण है। जैसा कि हम इस लेख में बाद में देखेंगे, डेटा को एक स्तंभ प्रारूप में परिवर्तित करके और विशेष संपीड़न तंत्र लागू करके, हम न केवल आपके विश्लेषणात्मक प्रश्नों को तेज़ करने में सक्षम हैं, बल्कि हम 98% तक संपीड़न दर भी प्राप्त कर सकते हैं। कल्पना कीजिए कि यह आपके भंडारण बिल पर क्या प्रभाव डालता है! पर्दे के पीछे: पंक्ति डेटा से लेकर संपीड़ित स्तंभ सरणी तक क्वेरी प्रदर्शन और भंडारण बचत के बारे में विवरण प्राप्त करने से पहले, आइए देखें कि यह तंत्र हुड के नीचे कैसे काम करता है: पंक्ति से स्तंभों में परिवर्तन वास्तव में कैसे किया जाता है और स्तंभ डेटा पर संपीड़न कैसे लागू किया जाता है। जब संपीड़न नीति लागू होती है, तो यह अनिवार्य रूप से मूल PostgreSQL हाइपरटेबल में पारंपरिक रूप से कई व्यक्तिगत रिकॉर्ड को बदल देती है - 1,000 घनी पैक पंक्तियों की कल्पना करें - एक एकल, अधिक कॉम्पैक्ट पंक्ति संरचना में। इस संकुचित रूप में, प्रत्येक विशेषता या कॉलम अब प्रत्येक पंक्ति से एकल प्रविष्टियाँ संग्रहीत नहीं करता है। इसके बजाय, यह इन 1,000 पंक्तियों से सभी संबंधित मानों के निरंतर, क्रमबद्ध अनुक्रम को समाहित करता है। आइए इन 1,000 पंक्तियों को एक के रूप में देखें। बैच इसे स्पष्ट करने के लिए, आइए इस तरह की एक तालिका की कल्पना करें: | Timestamp | Device ID | Status Code | Temperature | |-----------|-----------|-------------|-------------| | 12:00:01 | A | 0 | 70.11 | | 12:00:01 | B | 0 | 69.70 | | 12:00:02 | A | 0 | 70.12 | | 12:00:02 | B | 0 | 69.69 | | 12:00:03 | A | 0 | 70.14 | | 12:00:03 | B | 4 | 69.70 | इस डेटा को संपीड़न के लिए तैयार करने के लिए, टाइमस्केल पहले इस सारणीबद्ध डेटा को एक स्तंभ भंडार में बदल देगा। डेटा के एक बैच (~1,000 पंक्तियाँ) को देखते हुए, प्रक्रिया का परिणाम एक पंक्ति में होता है, जिसमें प्रत्येक कॉलम उस बैच से मानों की एक श्रृंखला संग्रहीत करता है। प्रत्येक कॉलम का डेटा एक सरणी में एकत्रित किया जाता है, जिसमें प्रत्येक सरणी तत्व मूल पंक्तियों में से एक के मान के अनुरूप होता है। | Timestamp | Device ID | Status Code | Temperature | |------------------------------|--------------------|--------------------|-------------------------------| | [12:00:01, 12:00:01, 12...] | [A, B, A, B, A, B] | [0, 0, 0, 0, 0, 4] | [70.11, 69.70, 70.12, 69....] | संपीड़न एल्गोरिदम लागू करने से पहले ही, यह प्रारूप टाइमस्केल के आंतरिक प्रति-पंक्ति ओवरहेड को बहुत कम करके तुरंत भंडारण बचाता है। PostgreSQL आम तौर पर प्रति पंक्ति ~27 बाइट्स ओवरहेड जोड़ता है (उदाहरण के लिए, मल्टी-वर्जन कॉन्करेंसी कंट्रोल या एमवीसीसी के लिए)। तो बिना किसी संपीड़न के भी, यदि हमारा उपरोक्त स्कीमा, मान लीजिए, 32 बाइट्स है, तो एक बैच से डेटा की 1,000 पंक्तियाँ जो पहले लेती थीं, अब लेती हैं । [1,000 * (32 + 27)] ~= 59 किलोबाइट्स [1,000 * 32 + 27 ] ~= इस प्रारूप में 32 किलोबाइट [ : एक बड़ी तालिका को छोटे बैचों में "समूहीकृत" करने और फिर प्रत्येक बैच के कॉलम को संगत रूप से संग्रहीत करने की यह धारणा (संपूर्ण तालिका के बजाय) वास्तव में Apache Parquet फ़ाइल प्रारूप में "पंक्ति समूहों" के समान दृष्टिकोण है। हालाँकि हमें उस समानता का एहसास इस तथ्य के बाद ही हुआ!] एक तरफ लेकिन इस परिवर्तन का बड़ा फायदा यह है कि अब, एक ऐसा प्रारूप दिया गया है जहां समान डेटा (टाइमस्टैम्प, डिवाइस आईडीएस, तापमान रीडिंग इत्यादि) को लगातार संग्रहीत किया जाता है, . इस प्रकार टाइमस्केल प्रभावशाली संपीड़न दर प्राप्त करता है। हम इसमें प्रकार-विशिष्ट संपीड़न एल्गोरिदम को नियोजित कर सकते हैं ताकि प्रत्येक सरणी अलग से संपीड़ित हो टाइमस्केल स्वचालित रूप से निम्नलिखित संपीड़न एल्गोरिदम को नियोजित करता है। ये सभी एल्गोरिदम हैं " , '' इसलिए हम अपने संपीड़न के माध्यम से सटीकता को बर्बाद नहीं करते हैं या अशुद्धियाँ पेश नहीं करते हैं; किसी भी परिणामी डीकंप्रेसन से मूल मूल्यों का पूरी तरह से पुनर्निर्माण होता है। दोषरहित फ्लोट्स के लिए गोरिल्ला संपीड़न डेल्टा-ऑफ़-डेल्टा + साथ टाइमस्टैम्प और अन्य पूर्णांक-जैसे प्रकारों के लिए संपीड़न सरल-8बी रन-लेंथ एन्कोडिंग कुछ दोहराए जाने वाले मानों वाले स्तंभों के लिए संपूर्ण-पंक्ति शब्दकोश संपीड़न (+ शीर्ष पर LZ संपीड़न) अन्य सभी प्रकारों के लिए एलजेड-आधारित सरणी संपीड़न हमने डीकंप्रेसिंग डेटा को उल्टे क्रम में संभालने के लिए गोरिल्ला और सिंपल-8बी का विस्तार किया, जिससे हमें बैकवर्ड स्कैन का उपयोग करने वाली क्वेरीज़ को तेज़ करने की अनुमति मिली। हमने इस प्रकार-विशिष्ट संपीड़न को काफी शक्तिशाली पाया है: उच्च संपीड़ितता के अलावा, गोरिल्ला और डेल्टा-ऑफ-डेल्टा जैसी कुछ तकनीकें डिकोडिंग के दौरान एलजेड-आधारित संपीड़न की तुलना में 40x तक तेज हो सकती हैं, जिससे क्वेरी प्रदर्शन में काफी सुधार होता है। . डेटा समय, टाइमस्केल इन अलग-अलग संपीड़ित बैचों पर काम कर सकता है, उन्हें बैच दर बैच और केवल अनुरोधित कॉलम पर डीकंप्रेस कर सकता है। इसलिए यदि क्वेरी इंजन यह निर्धारित कर सकता है कि केवल 20 बैचों (डेटा की 20,000 मूल पंक्तियों के अनुरूप) को तालिका खंड से संसाधित करने की आवश्यकता है जिसमें मूल रूप से डेटा की दस लाख पंक्तियां शामिल हैं, तो क्वेरी बहुत तेज़ी से निष्पादित हो सकती है, क्योंकि यह पढ़ रही है और डीकंप्रेसिंग कर रही है बहुत कम डेटा. आइए देखें कि यह ऐसा कैसे करता है। को डीकंप्रेस करते संपीड़ित डेटा को कुशलतापूर्वक क्वेरी करना पिछला सरणी-आधारित प्रारूप एक चुनौती प्रस्तुत करता है: अर्थात्, किसी क्वेरी को हल करने के लिए डेटाबेस को कौन सी पंक्तियाँ लानी चाहिए और डीकंप्रेस करनी चाहिए? आइए अपने तापमान डेटा का उदाहरण फिर से लें। कई स्वाभाविक प्रकार की क्वेरीज़ बार-बार सामने आती हैं: समय सीमा के अनुसार डेटा का चयन करना और उसे क्रमित करना या उसकी डिवाइस आईडी के आधार पर डेटा का चयन करना (या तो WHERE क्लॉज में या ग्रुप बाय के माध्यम से)। हम ऐसे प्रश्नों का कुशलतापूर्वक समर्थन कैसे कर सकते हैं? अब, यदि हमें अंतिम दिन के डेटा की आवश्यकता है, तो क्वेरी को टाइमस्टैम्प डेटा के माध्यम से नेविगेट करना होगा, जो अब एक संपीड़ित सरणी का हिस्सा है। तो क्या डेटाबेस को हाल के दिन के डेटा का पता लगाने के लिए संपूर्ण खंडों (या यहां तक कि संपूर्ण हाइपरटेबल) को डीकंप्रेस करना चाहिए? या भले ही हम अलग-अलग "बैचों" की पहचान कर सकें जिन्हें एक संपीड़ित सरणी (ऊपर वर्णित) में समूहीकृत किया गया है, क्या विभिन्न उपकरणों का डेटा एक साथ मिला हुआ है, इसलिए हमें यह पता लगाने के लिए पूरे सरणी को डीकंप्रेस करना होगा कि क्या इसमें किसी विशिष्ट डिवाइस के बारे में डेटा शामिल है? हालाँकि यह सरल दृष्टिकोण अभी भी अच्छी संपीड़ितता प्रदान कर सकता है, लेकिन यह क्वेरी प्रदर्शन के दृष्टिकोण से उतना कुशल नहीं होगा। विशिष्ट प्रश्नों के लिए डेटा को उसके स्तंभ प्रारूप में कुशलतापूर्वक ढूंढने और डीकंप्रेस करने की चुनौती को हल करने के लिए, टाइमस्केल "सेगमेंट बाय" और "ऑर्डर बाय" कॉलम की अवधारणा पेश करता है . आमतौर पर पूछे जाने वाले डेटा को कॉलम के आधार पर समूहीकृत करना segmentby याद रखें कि टाइमस्केल में डेटा को प्रारंभ में खंड-दर-खंड आधार पर संपीड़ित स्तंभ रूप में परिवर्तित किया जाता है। किसी विशिष्ट कॉलम के आधार पर फ़िल्टर की जाने वाली क्वेरीज़ की दक्षता बढ़ाने के लिए (उदाहरण के लिए, अक्सर द्वारा क्वेरी करना), आपके पास इस विशेष कॉलम को "के रूप में परिभाषित करने का विकल्प होता है" " स्तंभ। संपीड़ित डेटा को व्यवस्थित करने के लिए यह दृष्टिकोण अत्यधिक फायदेमंद है। device_id Compress_segmentby इन कॉलम का उपयोग प्रत्येक संपीड़ित खंड के भीतर डेटा को तार्किक रूप से विभाजित करने के लिए किया जाता है। जैसा कि ऊपर दिखाया गया है, मनमाने मूल्यों की एक संपीड़ित सरणी बनाने के बजाय, संपीड़न इंजन पहले कुंजी द्वारा समान वाले सभी मानों को एक साथ समूहित करता है। segmentby segmentby तो, डिवाइस_आईडी ए के बारे में डेटा की 1,000 पंक्तियों को एक संपीड़ित पंक्ति में संग्रहीत करने से पहले सघन रूप से समर्थित किया जाता है, डिवाइस_आईडी बी के बारे में 1,000 पंक्तियाँ, इत्यादि। इसलिए, यदि कॉलम के रूप में चुना जाता है, तो प्रत्येक संपीड़ित पंक्ति में एक विशिष्ट डिवाइस आईडी के बारे में डेटा के संपीड़ित कॉलमर बैच शामिल होते हैं, जो उस पंक्ति में असम्पीडित रूप से संग्रहीत होता है। टाइमस्केल अतिरिक्त रूप से संपीड़ित खंड के भीतर इन खंडों के मूल्यों पर एक सूचकांक बनाता है। device_id segmentby | Device ID | Timestamp | Status Code | Temperature | |-----------|--------------------------------|-------------|-----------------------| | A | [12:00:01, 12:00:02, 12:00:03] | [0, 0, 0] | [70.11, 70.12, 70.14] | | B | [12:00:01, 12:00:02, 12:00:03] | [0, 0, 4] | [69.70, 69.69, 69.70] | डेटा का यह सन्निहित भंडारण कॉलम द्वारा फ़िल्टर किए गए प्रश्नों की दक्षता को काफी बढ़ाता है। द्वारा फ़िल्टर की गई एक क्वेरी चलाते समय, जहां कॉलम है, टाइमस्केल तुरंत (एक इंडेक्स के माध्यम से) चंक में सभी संपीड़ित पंक्तियों का चयन कर सकता है जिनमें निर्दिष्ट डिवाइस आईडी हैं, और यह जल्दी से डेटा को छोड़ देता है (और डीकंप्रेसिंग से बचाता है) ) अनुरोधित डिवाइस से असंबद्ध डेटा। segmentby device_id device_id segmentby उदाहरण के लिए, इस क्वेरी में, टाइमस्केल कुशलतापूर्वक केवल उन संपीड़ित पंक्तियों का पता लगाएगा और संसाधित करेगा जिनमें डिवाइस_आईडी ए के लिए डेटा शामिल है: SELECT AVG(temperature) FROM sensor_data WHERE device_id = 'A' AND time >= '2023-01-01' AND time < '2023-02-01'; इसके अतिरिक्त, टाइमस्केल हाइपरटेबल्स प्रत्येक चंक से जुड़े मेटाडेटा को संग्रहीत करता है, जो चंक द्वारा कवर किए गए मानों की सीमा को निर्दिष्ट करता है। इसलिए यदि हाइपरटेबल को टाइमस्टैम्प को सप्ताह के अनुसार विभाजित किया गया है, तो जब क्वेरी प्लानर उपरोक्त क्वेरी चलाता है, तो वह केवल जनवरी के महीने को कवर करने वाले उन 4-5 हिस्सों को संसाधित करना जानता है, जिससे क्वेरी प्रदर्शन में और सुधार होता है। स्तंभों परिभाषित करना segmentby जब आप पहली बार हाइपरटेबल के संपीड़न को सक्षम करते हैं तो आप निर्दिष्ट कर सकते हैं कि सेगमेंटबी के लिए कौन से कॉलम का उपयोग करना है। किस कॉलम का उपयोग करना है इसका चुनाव इस बात पर आधारित होना चाहिए कि आपके प्रश्नों में कौन सा कॉलम या कॉलम अक्सर उपयोग किया जाता है। वास्तव में, आप विभाजित करने के लिए कॉलम का उपयोग कर सकते हैं: उदाहरण के लिए, डिवाइस_आईडी के आधार पर बैचों को एक साथ समूहीकृत करने के बजाय, आप उन बैचों को समूहित कर सकते हैं (कह सकते हैं) जिनमें किरायेदार_आईडी और डिवाइस_आईडी दोनों एक साथ हैं। एकाधिक फिर भी, सावधान रहें कि चयनात्मकता को ज़्यादा न करें: बहुत से खंड-दर-स्तंभों को परिभाषित करने से संपीड़न की दक्षता कम हो जाएगी क्योंकि प्रत्येक अतिरिक्त खंड-दर-स्तंभ प्रभावी रूप से डेटा को छोटे और छोटे बैचों में विभाजित करता है। यदि आप अब डेटा के 1,000 रिकॉर्ड बैच नहीं बना सकते हैं, बल्कि इसके बजाय केवल पांच रिकॉर्ड हैं जिनमें एक विशिष्ट खंड के भीतर निर्दिष्ट सेगमेंटबाई कुंजियाँ हैं, तो यह बिल्कुल भी अच्छी तरह से संपीड़ित नहीं होगा! लेकिन एक बार जब आप पहचान लेते हैं कि आप किन कॉलमों को विभाजित करना चाहते हैं, तो आपके हाइपरटेबल में संपीड़न सक्षम करते समय उन्हें कॉन्फ़िगर करना आसान हो जाता है: ALTER TABLE temperature_data SET ( timescaledb.compress, timescaledb.compress_segmentby = 'device_id' ); माध्यम से उन्नत फ़ाइन-ट्यूनिंग orderby TimescaleDB प्रत्येक खंड के भीतर रणनीतिक डेटा ऑर्डरिंग के माध्यम से संपीड़ित डेटा पर क्वेरी प्रदर्शन को बढ़ाता है, जो पैरामीटर द्वारा निर्धारित होता है। जबकि टाइमस्टैम्प द्वारा ऑर्डर करने की डिफ़ॉल्ट सेटिंग (समय-श्रृंखला डेटा में विशिष्ट विभाजन कुंजी) अधिकांश परिदृश्यों के लिए उपयुक्त है, इस अनुकूलन को समझना मूल्यवान हो सकता है। और भी गहरे तकनीकी परिप्रेक्ष्य के लिए आगे पढ़ें। compress_orderby साप्ताहिक खंडों और एक क्वेरी के उदाहरण पर फिर से विचार करें जो केवल एक दिन के डेटा का अनुरोध करता है। टाइमस्टैम्प इंडेक्स वाली एक नियमित तालिका में, क्वेरी दिन के डेटा को खोजने के लिए इस इंडेक्स पर कुशलतापूर्वक चल सकती है। हालाँकि, संपीड़ित डेटा के साथ स्थिति अलग है: टाइमस्टैम्प संपीड़ित होते हैं और पूरे बैच को डीकंप्रेस किए बिना उन तक नहीं पहुंचा जा सकता है। प्रत्येक व्यक्तिगत टाइमस्टैम्प पर एक सूचकांक बनाना प्रतिकूल होगा, क्योंकि यह अत्यधिक बड़ा होकर संपीड़न के लाभों को नकार सकता है। टाइमस्केल मूल रूप से अपने टाइमस्टैम्प के अनुसार बैच किए जाने वाले डेटा को "सॉर्टिंग" करके इसे संबोधित करता है। इसके बाद यह प्रत्येक बैच के लिए न्यूनतम और अधिकतम टाइमस्टैम्प के बारे में मेटाडेटा रिकॉर्ड करता है। जब कोई क्वेरी निष्पादित की जाती है, तो यह मेटाडेटा क्वेरी इंजन को तुरंत पहचानने में सक्षम बनाता है कि कौन सी संपीड़ित पंक्तियाँ (बैच) क्वेरी की समय सीमा के लिए प्रासंगिक हैं, इस प्रकार पूर्ण डीकंप्रेसन की आवश्यकता कम हो जाती है। यह पद्धति सेगमेंटबी कॉलम के उपयोग के साथ अच्छी तरह से काम करती है। संपीड़न प्रक्रिया के दौरान, डेटा को पहले सेगमेंटबी कॉलम द्वारा समूहीकृत किया जाता है, फिर ऑर्डरबी पैरामीटर के आधार पर ऑर्डर किया जाता है, और अंत में छोटे, टाइमस्टैम्प-ऑर्डर किए गए "मिनी-बैच" में विभाजित किया जाता है, जिनमें से प्रत्येक में 1,000 पंक्तियाँ होती हैं। TimescaleDB के विभाजन और क्रम का संयोजन सामान्य समय-श्रृंखला और विश्लेषणात्मक प्रश्नों के प्रदर्शन को महत्वपूर्ण रूप से बढ़ाता है। समय ( माध्यम से) और स्थान ( माध्यम से) दोनों में यह अनुकूलन यह सुनिश्चित करता है कि टाइमस्केलडीबी बड़े पैमाने पर समय-श्रृंखला डेटा को प्रभावी ढंग से प्रबंधित और क्वेरी करता है, जो संपीड़न और पहुंच के बीच एक अनुकूलित संतुलन प्रदान करता है। orderby segmentby टाइमस्केल के संपीड़न का विकास हमारे कंप्रेशन डिज़ाइन का पहला संस्करण 2019 में के साथ जारी किया गया था। कई रिलीज़ के बाद, टाइमस्केल कम्प्रेशन ने एक लंबा सफर तय किया है। TimescaleDB 1.5 हमारी आरंभिक रिलीज़ की मुख्य सीमाओं में से एक यह थी कि हम डेटा के किसी भी अन्य संशोधन की अनुमति नहीं देते थे - जैसे, INSERTs, UPDATEs, DELETEs - एक बार जब डेटा पूरे हाइपरटेबल खंड को मैन्युअल रूप से डीकंप्रेस किए बिना संपीड़ित हो गया था जिसमें वह रहता था। यह देखते हुए कि हम विश्लेषणात्मक और समय-श्रृंखला डेटा के आधार पर डेटा-गहन उपयोग के मामलों के लिए अनुकूलन कर रहे थे, जो मुख्य रूप से सम्मिलित-भारी हैं और अद्यतन-भारी नहीं हैं, यह पारंपरिक ओएलटीपी उपयोग के मामले की तुलना में बहुत कम सीमा थी। जहां डेटा बार-बार अपडेट किया जाता है (उदाहरण के लिए, ग्राहक सूचना तालिका)। तथापि, , ऐसी स्थितियाँ हैं जिनमें बैकफ़िलिंग आवश्यक है, और यह टाइमस्केलडीबी का उपयोग करने वाले डेवलपर पाइपलाइनों को काफी जटिल बनाता है। जैसा कि हम इस लेख में चर्चा करते हैं हमारी प्रारंभिक संपीड़न रिलीज़ की एक और सीमा यह थी कि हमने संपीड़ित डेटा सहित तालिकाओं में स्कीमा संशोधन की अनुमति नहीं दी थी। इसका मतलब यह था कि डेवलपर्स पूरी तालिका को डीकंप्रेस किए बिना अपनी डेटा संरचना विकसित नहीं कर सकते थे, . जैसे कि नए मेट्रिक्स या नए उपकरणों में फिट होने के लिए नए कॉलम जोड़ना आज ये सभी सीमाएँ दूर हो गई हैं। टाइमस्केल अब आपको संपीड़ित डेटा पर पूर्ण डेटा मैनिपुलेशन लैंग्वेज (डीएमएल) और डेटा डेफिनिशन लैंग्वेज (डीडीएल) संचालन करने की अनुमति देता है: आप संपीड़ित खंडों पर डेटा सम्मिलित कर सकते हैं (शानदार प्रदर्शन के साथ)। आप अपडेट, यूपीएसईआरटी और डिलीट कर सकते हैं। आप डिफ़ॉल्ट मान सहित कॉलम जोड़ सकते हैं। आप कॉलम का नाम बदल सकते हैं और हटा सकते हैं। संपीड़ित डेटा पर डेटा संशोधन को स्वचालित करने के लिए (इसे हमारे उपयोगकर्ताओं के लिए निर्बाध बनाते हुए), हमने "स्टेजिंग क्षेत्र" पेश करके अपने संपीड़न दृष्टिकोण को बदल दिया - अनिवार्य रूप से, एक ओवरलैपिंग खंड जो असंपीड़ित रहता है और जिसमें हम "असंपीड़ित डेटा पर" ऑपरेशन करते हैं। ढकना। एक उपयोगकर्ता के रूप में, आपको मैन्युअल रूप से कुछ भी करने की ज़रूरत नहीं है: आप सीधे अपने डेटा को संशोधित कर सकते हैं जबकि हमारा इंजन कवर के तहत स्वचालित रूप से सब कुछ का ख्याल रखता है। संपीड़ित डेटा में परिवर्तन करने की क्षमता टाइमस्केल के हाइब्रिड पंक्ति-स्तंभ भंडारण इंजन को अधिक लचीला बनाती है। स्टेजिंग क्षेत्र के माध्यम से यह डिज़ाइन INSERTs को असम्पीडित खंडों में डालने जितना तेज़ बनाता है क्योंकि वास्तव में यही हो रहा है (जब आप एक संपीड़ित खंड में डालते हैं, तो आप अब स्टेजिंग क्षेत्र में लिख रहे हैं)। इसने हमें सीधे अपडेट, यूपीएसईआरटी और डिलीट का समर्थन करने की भी अनुमति दी: जब किसी मान को बदलने की आवश्यकता होती है, तो इंजन संपीड़ित डेटा के प्रासंगिक हिस्से को स्टेजिंग क्षेत्र में ले जाता है, इसे डीकंप्रेस करता है, परिवर्तन करता है, और (एसिंक्रोनस रूप से) इसे फिर से ले जाता है मुख्य तालिका में इसके संपीड़ित रूप में। (डेटा का यह क्षेत्र आम तौर पर 1,000 मानों तक के संपीड़ित "मिनी-बैच" के पैमाने पर काम करता है, जिसमें संशोधनों का समर्थन करने के लिए असंपीड़ित किए जाने वाले डेटा की मात्रा को कम करने के लिए अंतर्निहित पोस्टग्रेएसक्यूएल स्टोरेज में एक "पंक्ति" शामिल होती है।) इस "स्टेजिंग क्षेत्र" में अभी भी नियमित लेन-देन संबंधी शब्दार्थ हैं, और जैसे ही इन्हें इसमें डाला जाता है, आपके प्रश्न इन मूल्यों को देखते हैं। दूसरे शब्दों में, क्वेरी प्लानर यह समझने में काफी स्मार्ट है कि इन पंक्ति-आधारित "स्टेजिंग" खंडों और नियमित स्तंभ भंडारण में ठीक से क्वेरी कैसे की जाए। अंतिम परिणाम: बड़े पोस्टग्रेएसक्यूएल डेटाबेस के लिए तेज़ क्वेरीज़, कम स्टोरेज फ़ुटप्रिंट इस बिंदु पर, अगला तार्किक प्रश्न यह है: अंतिम परिणाम क्या है? संपीड़न क्वेरी प्रदर्शन को कैसे प्रभावित करता है, और इसका उपयोग करके मैं कितना डिस्क आकार बचा सकता हूं? संपीड़न से पहले बनाम बाद में क्वेरी प्रदर्शन जैसा कि हम इस लेख में चर्चा कर रहे हैं, स्तंभ भंडार आम तौर पर व्यक्तिगत पंक्तियों को पुनर्प्राप्त करने वाले प्रश्नों के लिए बहुत अच्छा प्रदर्शन नहीं करते हैं, लेकिन वे समग्र मूल्यों को देखते हुए विश्लेषणात्मक प्रश्नों के लिए बहुत बेहतर प्रदर्शन करते हैं। यह वही है जो हम टाइमस्केल में देखते हैं: औसत से जुड़े गहरे और संकीर्ण प्रश्नों में संपीड़न का उपयोग करते समय महत्वपूर्ण प्रदर्शन सुधार दिखाई देते हैं। आइए कुछ प्रश्न चलाकर इसे स्पष्ट करें , टाइमस्केल में हमारे द्वारा प्रदान किए गए उदाहरण डेटासेट में से एक। इस डेटासेट में टैक्सी यात्राओं की जानकारी शामिल है, जिसमें पिक-अप और ड्रॉप-ऑफ समय, स्थान, दूरियां, किराया और बहुत कुछ शामिल है। NYC टैक्सी डेटासेट निम्नलिखित क्वेरी पर विचार करें, एक विशिष्ट समय सीमा के भीतर टैक्सी डेटासेट के सबसेट से उच्चतम किराया राशि पूछी जा रही है: SELECT max(fare_amount) FROM demo.yellow_compressed_ht WHERE tpep_pickup_datetime >= '2019-09-01' AND tpep_pickup_datetime <= '2019-12-01'; जब असम्पीडित डेटासेट के विरुद्ध चलाया जाता है, तो क्वेरी निष्पादन समय 4.7 सेकंड होता है। हम एक छोटी, अनुकूलित परीक्षण सेवा का उपयोग कर रहे हैं और कई लाखों पंक्तियों की क्वेरी कर रहे हैं, इसलिए यह प्रदर्शन सर्वोत्तम नहीं है। लेकिन डेटा को संपीड़ित करने के बाद, प्रतिक्रिया समय कम होकर 77.074 मिलीसेकंड हो जाता है: आइए एक और उदाहरण साझा करें। यह क्वेरी एक निश्चित समय सीमा के भीतर एक विशिष्ट दर कोड के साथ यात्राओं की संख्या की गणना करती है: SELECT COUNT(*) FROM demo.yellow_compressed_ht WHERE tpep_pickup_datetime >= '2019-09-01' AND tpep_pickup_datetime <= '2019-12-01' AND "RatecodeID" = 99; असम्पीडित डेटा के विरुद्ध निष्पादित होने पर, इस क्वेरी को पूरा होने में 1.6 सेकंड लगेंगे। संपीड़ित डेटा के विरुद्ध चलने वाली वही क्वेरी केवल 18.953 मिलीसेकंड में समाप्त हो जाती है। एक बार फिर, हम तत्काल सुधार देखते हैं! ये केवल त्वरित उदाहरण हैं, लेकिन ये बताते हैं कि आपके प्रश्नों को तेज़ करने के लिए संपीड़न कितना शक्तिशाली हो सकता है। टाइमस्केल का संपीड़न PostgreSQL भंडारण आकार को कैसे कम करता है: वास्तविक दुनिया के उदाहरण आइए यह न भूलें कि सबसे पहले हमें यहां क्या लाया: हमें एक ऐसी रणनीति की आवश्यकता थी जो हमें अपने बड़े PostgreSQL डेटाबेस के आकार को कम करने की अनुमति दे ताकि हम PostgreSQL को और अधिक बढ़ा सकें। यह दिखाने के लिए कि इस कार्य के लिए टाइमस्केल संपीड़न कितना प्रभावी हो सकता है, नीचे दी गई तालिका में शामिल हैं। टाइमस्केल ग्राहकों के बीच देखी गई संपीड़न दरों के कुछ वास्तविक उदाहरण ये भंडारण बचत सीधे पैसे बचाने में तब्दील हो जाती है: टाइमस्केल प्लेटफ़ॉर्म भंडारण के लिए उपयोग-आधारित मूल्य निर्धारण का उपयोग करता है , इसलिए यदि आपका भंडारण सिकुड़ता है, तो आपका बिल भी आनुपातिक रूप से कम हो जाता है। अंततः आप जो संपीड़न दर प्राप्त करेंगे वह आपके डेटा प्रकार और एक्सेस पैटर्न सहित कई कारकों पर निर्भर करता है। लेकिन जैसा कि आप देख सकते हैं, टाइमस्केल संपीड़न बेहद कुशल हो सकता है- . हम 96% संपीड़न के साथ अपने ग्राहक-सामना वाले इनसाइट्स उत्पाद को शक्ति प्रदान करने के लिए आंतरिक रूप से भी इसका भारी उपयोग करते हैं हमारी टीम आपको यथासंभव अधिक पैसे बचाने के लिए कंप्रेशन को बेहतर बनाने में मदद कर सकती है, . इसलिए संपर्क करने में संकोच न करें "संपीड़न के साथ, हमने [डिस्क आकार में] औसतन 97 प्रतिशत की कमी देखी है।" (माइकल गाग्लियार्डो, एनडस्ट्रियल) “हमने टाइमस्केल के संपीड़न अनुपात को बिल्कुल अभूतपूर्व पाया है! वर्तमान में हम 26 से अधिक के संपीड़न अनुपात पर हैं, जिससे हमारे सभी डेटा को संग्रहीत करने के लिए आवश्यक डिस्क स्थान काफी कम हो गया है। (निकोलस क्विंटिन, ऑक्टेव) "टाइमस्केल का संपीड़न विज्ञापित जितना अच्छा था, जिससे हमें अपने अंतर्निहित हाइपरटेबल में +90% [डिस्क] स्थान की बचत हुई।" (पाओलो बर्गेंटिनो, मीटर ग्रुप) संपीड़न और स्तरीय भंडारण: टाइमस्केल भंडारण जीवनचक्र अंत में, हम टाइमस्केल के टियरड स्टोरेज का उल्लेख किए बिना इस लेख को समाप्त नहीं कर सकते, . जिसे हमने अभी सामान्य उपलब्धता में लॉन्च किया है संपीड़न के शीर्ष पर, अब आपके पास अपने PostgreSQL डेटाबेस को टाइमस्केल प्लेटफ़ॉर्म में और भी आगे बढ़ाने में मदद करने के लिए एक और उपकरण है: आप अपने पुराने, कभी-कभार एक्सेस किए गए डेटा को कम लागत वाले ऑब्जेक्ट स्टोरेज स्तर पर रख सकते हैं, जबकि अभी भी इसे मानक के माध्यम से एक्सेस करने में सक्षम हैं। एसक्यूएल. इस कम लागत वाले स्टोरेज टियर में डेटा के लिए $0.021 प्रति जीबी/माह की एक समान कीमत है - अमेज़ॅन एस 3 की तुलना में सस्ता - जिससे आप लागत के एक अंश के लिए अपने पोस्टग्रेएसक्यूएल डेटाबेस में कई टीबी रख सकते हैं। इस प्रकार हमारा टियर स्टोरेज बैकएंड टाइमस्केल प्लेटफॉर्म पर काम करता है और लो-स्टोरेज टियर कम्प्रेशन के साथ कैसे काम करता है: आपका सबसे हालिया डेटा तेज़ क्वेरी और उच्च अंतर्ग्रहण के लिए अनुकूलित में लिखा गया है। इस स्तर में, आप अपने डेटाबेस आकार को छोटा करने और अपने विश्लेषणात्मक प्रश्नों को तेज़ करने के लिए टाइमस्केल कॉलमर संपीड़न को सक्षम कर सकते हैं, जैसा कि हम इस लेख में चर्चा कर रहे हैं। उदाहरण के लिए, आप एक संपीड़न नीति परिभाषित कर सकते हैं जो 1 सप्ताह के बाद आपके डेटा को संपीड़ित करती है। उच्च-प्रदर्शन भंडारण स्तर एक बार जब आपका एप्लिकेशन बार-बार उस डेटा तक नहीं पहुंच पाता है, तो आप टियरिंग पॉलिसी सेट करके स्वचालित रूप से इसे में टियर कर सकते हैं। कम लागत वाले स्टोरेज टियर में डेटा आपके डेटाबेस में पूरी तरह से क्वेरी करने योग्य रहता है, और आपके द्वारा संग्रहीत डेटा की मात्रा की कोई सीमा नहीं है - सैकड़ों टीबी या उससे अधिक तक। उदाहरण के लिए, आप एक स्तरीय नीति को परिभाषित कर सकते हैं जो आपके छह महीने से अधिक पुराने सभी डेटा को कम लागत वाले भंडारण स्तर पर ले जाती है। कम लागत वाली ऑब्जेक्ट स्टोरेज टियर एक बार जब आपको इस डेटा को अपने डेटाबेस में रखने की आवश्यकता नहीं रह जाती है, तो आप इसे अवधारण नीति के माध्यम से छोड़ सकते हैं। उदाहरण के लिए, आप पांच साल के बाद सारा डेटा हटा सकते हैं। PostgreSQL के साथ बने रहें हमने स्तंभ संपीड़न क्षमताओं को जोड़कर पोस्टग्रेज को एक प्रभावी डेटाबेस संपीड़न तंत्र दिया। आज की डेटा-गहन दुनिया में PostgreSQL डेटाबेस को स्केल करने के लिए यह एक आवश्यक सुविधा है: संपीड़न डिस्क उपयोग में भारी बचत (सस्ते में अधिक डेटा संग्रहीत करना) और प्रदर्शन में सुधार (मिलीसेकंड में बड़ी मात्रा में विश्लेषणात्मक क्वेरी चलाना) की अनुमति देता है। टाइमस्केल का संपीड़न डिज़ाइन PostgreSQL के भीतर हाइब्रिड पंक्ति/स्तंभ भंडारण बनाने के लिए एक उपन्यास विधि के साथ-साथ सर्वोत्तम-इन-क्लास संपीड़न एल्गोरिदम के संयोजन से प्रभावशाली संपीड़न दर प्राप्त करता है। यह क्षमता टाइमस्केल (और इस प्रकार PostgreSQL) के स्टोरेज फ़ुटप्रिंट को कस्टम-निर्मित, अधिक सीमित स्तंभ डेटाबेस के बराबर बनाती है। लेकिन कई स्तंभ इंजनों के विपरीत, टाइमस्केल संपीड़ित स्तंभ डेटा पर ACID लेनदेन संबंधी शब्दार्थ और संशोधनों (INSERTs, UPDATEs, UPSERTs, DELETEs) के लिए प्रत्यक्ष समर्थन का समर्थन करता है। चूँकि "लेन-देन संबंधी कार्यभार के लिए एक डेटाबेस, विश्लेषणात्मक के लिए दूसरा" का पुराना मॉडल अप्रचलित है, कई आधुनिक अनुप्रयोग ऐसे कार्यभार चलाते हैं जो दोनों पैटर्न में फिट होते हैं। तो जब आप यह सब PostgreSQL में कर सकते हैं तो दो अलग-अलग डेटाबेस क्यों बनाए रखें? टाइमस्केल आपको PostgreSQL पर शुरुआत करने, PostgreSQL के साथ स्केल करने, PostgreSQL के साथ बने रहने की अनुमति देता है। और आज ही टाइमस्केल आज़माएं—इसमें केवल कुछ सेकंड लगते हैं, किसी क्रेडिट कार्ड की आवश्यकता नहीं है। एक नि: शुल्क खाता बनाएं - द्वारा लिखित। कार्लोटा सोटो और माइक फ्रीडमैन यहाँ भी प्रकाशित किया गया।