PostgreSQL डेटाबेस को स्केल करना अब सस्ता हो गया है: टाइमस्केल का टियर स्टोरेज सामान्य उपलब्धता को प्रभावित करता है

PostgreSQL के लिए Amazon RDS जैसे उत्पाद छोटी तैनाती के लिए ठीक हैं, लेकिन PostgreSQL को स्केल करना एक अलग कहानी है। एक बार जब प्रोजेक्ट कई टेराबाइट्स तक बढ़ जाता है, तो ये प्रबंधित डेटाबेस धीमे और महंगे हो जाते हैं, जिससे डेटा प्रबंधन अधिक जटिल हो जाता है।

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

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

ऐसा तब होता है जब आप हमारे नए बहु-स्तरीय स्टोरेज बैकएंड के साथ टाइमस्केल टाइम-सीरीज़ डेटाबेस में डेटा डालते हैं:

1. आपका सबसे हालिया डेटा तेज़ क्वेरी और उच्च अंतर्ग्रहण के लिए अनुकूलित उच्च-प्रदर्शन भंडारण स्तर में लिखा जाएगा।

   
   

2. एक बार जब आप उस डेटा तक बार-बार पहुंच नहीं पाते हैं, तो आप टियरिंग पॉलिसी सेट करके स्वचालित रूप से इसे कम लागत वाली ऑब्जेक्ट स्टोरेज टियर में टियर कर सकते हैं। कम लागत वाले स्टोरेज टियर में डेटा आपके डेटाबेस में पूरी तरह से क्वेरी करने योग्य रहता है, और आपके द्वारा संग्रहीत डेटा की मात्रा की कोई सीमा नहीं है - सैकड़ों टीबी या उससे अधिक तक। हमारे कम लागत वाले स्टोरेज टियर में डेटा के लिए $0.021 प्रति जीबी/माह की एक समान कीमत है - अमेज़ॅन एस3 से सस्ता।

डेवलपर्स को प्रदर्शन से समझौता किए बिना AWS में अपने बड़े PostgreSQL डेटाबेस को स्केल करने का एक सस्ता तरीका चाहिए। जबकि ऑब्जेक्ट स्टोर आश्चर्यजनक रूप से स्केलेबल और किफायती हैं, वे सबसे तेज़ नहीं हैं, और डेवलपर्स को भी अपने अनुप्रयोगों के लिए मिलीसेकंड क्वेरी प्रतिक्रिया प्राप्त करने की आवश्यकता होती है।

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

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

टियर स्टोरेज के साथ पोस्टग्रेएसक्यूएल डेटा प्रबंधन: आपको क्या जानना चाहिए

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

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

यह इनसाइट्स डेटाबेस हमारे ग्राहक बेड़े से लगातार क्वेरी आँकड़े एकत्र और विश्लेषण कर रहा है, और आज यह 350 टीबी से अधिक हो गया है और तेजी से बढ़ रहा है। उन 350 टीबी में से 250 टीबी को कम लागत वाले भंडारण में वर्गीकृत किया गया है।

आइए गणित करें:

• हम संपीड़न के बाद अपने उच्च-प्रदर्शन भंडारण स्तर में 5 टीबी संग्रहीत करते हैं। बेशक, हमारे पास संपीड़न सक्षम है, और हमें 20x का संपीड़न अनुपात मिल रहा है - जिसका अर्थ है कि मूल रूप से 100 टीबी का पोस्टग्रेज डेटा अब संपीड़न के कारण 5 टीबी डिस्क में फिट बैठता है (!)

  
  

• शेष 250 टीबी डेटा कम लागत वाले स्टोरेज टियर में संग्रहीत किया जाता है। एक बार जब डेटा एक निश्चित आयु तक पहुंच जाता है, जो वर्तमान में कई सप्ताह पुराना है, तो यह टियरिंग स्वचालित रूप से होती है।

  
  

बड़ी तैनाती वाले हमारे ग्राहक भी पहले से ही टियरड स्टोरेज का उपयोग कर रहे हैं:

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

- एक मालिकाना डिजिटल एसेट्स ट्रेडिंग कंपनी में मुख्य प्रौद्योगिकी अधिकारी

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

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

 SELECT add_tiering_policy('events', INTERVAL '1 month');

आपको बस इतना ही चाहिए! बाकी सब कुछ स्वचालित रूप से होता है, जिसमें बुद्धिमान क्वेरी योजना भी शामिल है जो केवल उचित स्तर पर किसी भी SQL क्वेरी को निष्पादित करती है।

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

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

 -- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk');

आप टाइमस्केल कंसोल में ट्रैक कर सकते हैं कि कितना डेटा स्तरित किया गया है (और महीने के अंत में इसकी लागत कितनी होगी):

और बिलिंग अनुमानों की बात करें तो...

मैं टियरड स्टोरेज से कितनी बचत कर सकता हूँ?

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

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

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

लागत प्रभावी डेटा प्रबंधन रणनीति के रूप में, आप एक महीने से अधिक पुराने सभी टुकड़ों को कम लागत वाले स्तर पर रख सकते हैं और 5 टीबी डेटा को संग्रहीत करने की लागत को लगभग $478/माह से घटाकर लगभग $105/माह कर सकते हैं, जो कि 78% की कमी है। आपके भंडारण बिल में. ( इस अनुमान के लिए, हम मानते हैं कि आपने अपने हाइपरटेबल के लिए संपीड़न सक्षम किया है और सभी टाइमस्केल सेवाओं में औसत समग्र संपीड़न पर विचार करते हैं)।

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

तुम समझ गए!

टियरड स्टोरेज का बचत गुणन प्रभाव

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

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

इसे बिल्कुल स्पष्ट करने के लिए, आइए एक उदाहरण प्रस्तुत करें। कल्पना करें कि आपके पास 6.5 टीबी डेटा वाली एक प्राथमिक सेवा है और आपने यह भी सेट किया है:

• विफलताओं के कारण डाउनटाइम और डेटा हानि के जोखिम को काफी कम करने के लिए एक उच्च उपलब्धता प्रतिकृति

  
  

• आपके पढ़े गए प्रश्नों को पूरा करने के लिए एक पढ़ी गई प्रतिकृति और प्राथमिक को खुद को पूरी तरह से लिखने के लिए समर्पित करने की अनुमति देती है

  
  

• विकास और परीक्षण उद्देश्यों के लिए उस सेवा का एक कांटा

  
  

बिलिंग परिप्रेक्ष्य से, यदि आपने अपनी प्राथमिक सेवा में 6.5 टीबी डेटा को उच्च-प्रदर्शन भंडारण स्तर में रखा है, तो आप दो प्रतिकृतियों, कांटा, और के लिए अपने भंडारण बिल में [6.5 टीबी x 4] प्रतिबिंबित देखेंगे। प्राथमिक सेवा—कुल 26 टीबी। हमारी औसत संपीड़न दर को मानते हुए, यह महंगा होगा: लगभग $4,602/माह।

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

• [500 जीबी x 4] = उच्च-प्रदर्शन भंडारण में 2 टीबी (26 टीबी के बजाय)

  
  

• [6 टीबी x 1] कम लागत वाले भंडारण स्तर में

  
  

उपरोक्त भंडारण बिल लगभग $480/माह आएगा: आप $4,000/माह से अधिक की बचत करेंगे! यह टियरड स्टोरेज का बचत गुणन प्रभाव है। विशेष रूप से यदि आप प्रतिकृतियां या कांटे चला रहे हैं, तो कम लागत वाले भंडारण स्तर का लाभ उठाना एक अच्छा विचार है - जो बचत आप अपने समग्र बिल में देखेंगे वह बहुत महत्वपूर्ण होगी।

हमारी स्तरीय भंडारण यात्रा

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

हमने अपने मूल्य निर्धारण मॉडल के बारे में भी लंबे समय तक सोचा और अपने कम लागत वाले भंडारण स्तर की कीमत निर्धारित करने के कई तरीकों पर लगातार विचार किया। अंत में, हम सबसे सरल की ओर झुक गए: डेटा वॉल्यूम पूर्व-संपीड़न पर एक फ्लैट दर। हमने पहले ही उल्लेख किया है कि हम कैसे सरल और पूर्वानुमानित मूल्य निर्धारण को महत्व देते हैं, लेकिन हमारे लिए यह भी महत्वपूर्ण था कि हम प्रति जीबी/माह जितना संभव हो उतना कम मूल्य प्रदान करें। हमारी कीमत $0.021 पर पहुँची - तुलनात्मक रूप से, अमेज़न S3 पर फ़ाइलें संग्रहीत करने की लागत $0.023 प्रति जीबी/माह .

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

टाइमस्केल में, हमारा मानना है कि डेटाबेस सेवा चलाने या स्टोरेज लेयर्स के बारे में सूचित विकल्प चुनने में सक्षम होने के लिए आपको एक जटिल स्प्रेडशीट नहीं बनानी चाहिए।

डेवलपर्स के जीवन को आसान बनाने की हमारी प्रतिबद्धता ने हमें $0.021 प्रति जीबी/माह की एकसमान दर तक पहुँचाया - कोई अनुमान, छिपी हुई लागत या प्रति क्वेरी या डेटा रीड शुल्क नहीं।

स्तरीय भंडारण कैसे काम करता है: पर्दे के पीछे

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

इसके विपरीत, कम लागत वाला स्टोरेज स्तर अमेज़न S3 पर निर्मित एक ऑब्जेक्ट स्टोर है। हालाँकि, यह ऑब्जेक्ट स्टोर आपके डेटा को संग्रहीत करने के लिए एक बाहरी बकेट से कहीं अधिक है: यह आपके डेटाबेस का एक अभिन्न अंग है। जब आप डेटा को इस ऑब्जेक्ट स्टोरेज स्तर पर ले जाते हैं, तो आपका डेटाबेस सभी शब्दार्थ और मेटाडेटा से पूरी तरह अवगत रहेगा, और आप मानक SQL के साथ हमेशा की तरह क्वेरी करना जारी रख सकते हैं (यद्यपि धीमे प्रदर्शन के साथ)।

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

जब आप अपनी SQL क्वेरी चलाते हैं, तो यह आवश्यकतानुसार उच्च-प्रदर्शन स्टोरेज टियर, ऑब्जेक्ट स्टोरेज टियर या दोनों से डेटा को पारदर्शी रूप से खींच लेगा। जब हम पारदर्शी कहते हैं, तो हमारा मतलब पारदर्शी होता है: टाइमस्केल अपने मानक और स्तरीय डेटा में मनमाने ढंग से जटिल प्रश्नों का समर्थन करता है, जिसमें जटिल विधेय, जॉइन, सीटीई, विंडोिंग, हाइपरफंक्शन और बहुत कुछ शामिल हैं।

नीचे दिए गए उदाहरण क्वेरी में ( EXPLAIN क्लॉज के साथ), आप देख सकते हैं कि जब डेटाबेस ऑब्जेक्ट स्टोरेज टियर से डेटा तक पहुंच रहा है तो क्वेरी प्लान में Foreign Scan कैसे शामिल होता है। इस उदाहरण में, devices और sites मानक पोस्टग्रेज टेबल हैं (केवल उच्च-प्रदर्शन स्टोरेज में रहते हैं), जबकि metrics एक हाइपरटेबल है जो दोनों स्टोरेज स्तरों तक फैला हुआ है। metrics हाइपरटेबल के विरुद्ध इस क्वेरी को निष्पादित करते समय, इसके तीन हिस्से मानक स्टोरेज से पढ़े गए थे, और पांच हिस्से ऑब्जेक्ट स्टोरेज से पढ़े गए थे।

 EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text)

उपरोक्त क्वेरी योजना में, Foreign Scan on osm_chunk_3334 अथाह ऑब्जेक्ट स्टोरेज स्तर से डेटा लाने से मेल खाता है।

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

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

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

टियरड स्टोरेज को आज़माएं

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

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

- यानिस रूसोस, कार्लोटा सोटो और एना तवारेस द्वारा लिखित।