🧀 🏌️ 👩‍🍳 एक रिलेशनल डीबीएमएस में समय श्रृंखला डेटा। PostgreSQL के लिए एक्सटेंशन्स TimescaleDB और PipelineDB 🤽🏿 🚪 👉🏻

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

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

समय श्रृंखला डेटा या समय श्रृंखला क्या है?

यह उस प्रक्रिया के बारे में डेटा है जिसे उसके जीवन में विभिन्न बिंदुओं पर एकत्र किया गया है।

उदाहरण के लिए, कार का स्थान: सीपीयू, लोड रैम और फ्री डिस्क स्थान पर डेटा के साथ सर्वर पर गति, निर्देशांक, दिशा या संसाधनों का उपयोग।

समय श्रृंखला में कई विशेषताएं हैं।

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

समय श्रृंखला डेटा के लिए लोकप्रिय भंडारण समाधान

ग्राफ समय श्रृंखला डेटा संग्रहीत करने के लिए विशेष समाधान दिखाता है। पैमाना लघुगणक है।

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

PostgreSQL न केवल एक अच्छा डेटाबेस है, बल्कि विशेष समाधान विकसित करने के लिए एक एक्स्टेंसिबल प्लेटफॉर्म भी है।

Postgres, Postgis, और TimescaleDB

फर्स्ट मॉनिटरिंग कंपनी उपग्रहों के इस्तेमाल से वाहनों की आवाजाही पर नज़र रखती है। हम 20,000 वाहनों को ट्रैक करते हैं और दो साल के लिए आंदोलन डेटा संग्रहीत करते हैं। कुल मिलाकर, हमारे पास वर्तमान टेलीमेट्री डेटा के 10 टीबी हैं। औसतन, प्रत्येक वाहन चलाते समय प्रति मिनट 5 टेलीमेट्री रिकॉर्ड भेजता है। डेटा हमारे टेलीमेटिक सर्वरों को नेविगेशन उपकरण के माध्यम से भेजा जाता है। वे प्रति सेकंड 500 नेविगेशन पैकेट प्राप्त करते हैं।

कुछ समय पहले, हमने विश्व स्तर पर बुनियादी ढाँचे को उन्नत करने और एक मोनोलिथ से माइक्रोसर्विस में स्थानांतरित करने का निर्णय लिया। हमने नई प्रणाली वलियट को बुलाया, और यह पहले से ही उत्पादन में है - सभी वाहनों का 90% इसे स्थानांतरित कर दिया गया है।

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

क्यों PostgreSQL?

हम इस डेटा प्रकार के लिए ~~ClickHouse~~ विशेष समाधानों के बजाय समय श्रृंखला को संग्रहीत करने के लिए एक संबंधपरक डेटाबेस का उपयोग करने की कोशिश क्यों कर रहे हैं? क्योंकि PostgreSQL के साथ काम करने की विशेषज्ञता और छापों की पृष्ठभूमि के खिलाफ, हम मुख्य भंडारण के रूप में एक अज्ञात समाधान का उपयोग नहीं करना चाहते हैं।

एक नए समाधान पर स्विच करना एक जोखिम है।

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

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

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

लेकिन लेख स्वयं दिलचस्प नहीं है, लेकिन हैकर समाचार पर विषय , जिसमें यह चर्चा की गई है। विषय के लेखक लिखते हैं कि, लेख के आधार पर, उन्होंने लगभग सभी विचारों को PostgreSQL 11 पर लागू किया। उन्होंने क्षैतिज स्केलिंग और पैनापन के लिए CitusDB एक्सटेंशन का उपयोग किया, स्ट्रीम कंप्यूटिंग और भौतिक विचारों के लिए PipelineDB, टाइम सीरीज डेटा और सेक्शनिंग के लिए TimescaleDB। वह कई विदेशी डेटा रैपर्स का भी उपयोग करता है।

PostgreSQL और उसके एक्सटेंशन का एक पागल मिश्रण एक बार फिर से पुष्टि करता है कि PostgreSQL सिर्फ एक DBMS नहीं है - यह एक मंच है।

और जब प्लग करने योग्य भंडारण दिया जाएगा ... ऊ!

विडंबना यह है कि जब समाधानों पर शोध करते हैं, तो हमें आउटफ्लक्स मिला, जो टाइम्सक्लबीडीबी टीम का विकास था, जिसे उन्होंने 1 अप्रैल को प्रकाशित किया था। आपको क्या लगता है वह क्या करती है? यह एक कमांड में InfluxDB से TimescaleDB पर माइग्रेट करने के लिए एक उपयोगिता है ...

प्रचार के बाद!

प्रचार की शक्ति को कम मत समझो! हम अक्सर मजाक करते हैं कि "विकास प्रचार से प्रेरित है," क्योंकि यह ट्यूनिंग और बुनियादी ढांचे के घटकों की हमारी धारणा को प्रभावित करता है। HighLoad ++ पर, हम PostgreSQL पर बहुत चर्चा करते हैं, ClickHouse, Tarantool - ये प्रचार कार्यक्रम हैं। बस यह मत कहो कि यह आपकी प्राथमिकताओं और बुनियादी ढांचे के लिए समाधानों की पसंद को प्रभावित नहीं करता है ... बेशक, यह मुख्य कारक नहीं है, लेकिन क्या कोई प्रभाव है?

मैं 5 साल से PostgreSQL के साथ काम कर रहा हूं। मुझे यह समाधान पसंद है। वह लगभग सभी कार्यों को एक धमाके के साथ हल करता है। इस आधार के साथ हर बार कुछ गलत हुआ, मेरे कुटिल हाथों को दोष देना था। इसलिए, चुनाव पूर्व निर्धारित था।

TimescaleDB VS पाइपलाइनलाइन

चलिए TimescaleDB और PipelineDB एक्सटेंशन पर चलते हैं। एक्सटेंशन के बारे में उनके निर्माता क्या कहते हैं?

TimescaleDB एक ओपन सोर्स टाइम सीरीज़ डेटाबेस है जो त्वरित प्रविष्टि और जटिल प्रश्नों के लिए अनुकूलित है।

PipelineDB एक उच्च-प्रदर्शन एक्सटेंशन है जो समय श्रृंखला डेटा के लिए निरंतर SQL क्वेरी चलाने के लिए डिज़ाइन किया गया है।

समय श्रृंखला डेटा के साथ काम करने के अलावा, उनके पास एक समान कहानी है। Timescale की स्थापना 2015 में हुई थी, और 2013 में Pipeline। पहले काम करने वाले संस्करण क्रमशः 2017 और 2015 में दिखाई दिए। टीमों को न्यूनतम कार्यक्षमता जारी करने में दो साल लग गए। दोनों एक्सटेंशन के प्रोडक्शन रिलीज पिछले अक्टूबर में एक सप्ताह के अंतर के साथ हुए। जाहिरा तौर पर, एक दूसरे के बाद जल्दी में।

GitHub में सितारों और कांटों का एक समूह है, जो हमेशा की तरह, एक भी प्रतिबद्ध नहीं हैं। यह कैसे खुला स्रोत काम करता है, वहाँ कुछ भी नहीं किया जाना है। लेकिन कई सितारे हैं, TimescaleDB में PipelineDB से अधिक है, और यहां तक कि खुद PostgreSQL से भी अधिक है।

एक्सटेंशन समान लगते हैं, लेकिन वे खुद को अलग तरह से रखते हैं।

TimescaleDB का दावा है कि प्रति सेकंड लाखों रिकॉर्ड डाले गए हैं और सैकड़ों अरबों पंक्तियों और दसियों डेटा के टेराबाइट्स को संग्रहीत किया है। यह एक्सटेंशन इन्फ्लक्सडीबी, कैसेंड्रा, मोंगोडीबी या वेनिला पोस्टग्रेक्सेल की तुलना में तेज है। स्ट्रीमिंग प्रतिकृति और बैकअप उपकरण का समर्थन करता है। TimescaleDB एक एक्सटेंशन है, PostgreSQL का कांटा नहीं।

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

TimescaleDB

अब विस्तार के बारे में विस्तार से। शुरुआत करते हैं TimescaleDB से। मैं उसके साथ लगभग 2 साल से काम कर रहा हूं। रिलीज संस्करण से पहले इसे उत्पादन तक खींच लिया। आइए इसे कैसे लागू करें, इसके उदाहरण देखें।

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

SELECT time_bucket('10 seconds', time) AS period, container_id, avg(free_mem) FROM metrics WHERE time < now() - interval '10 minutes' GROUP BY period, container_id ORDER BY period DESC, container_id;

 period | container_id | avg -----------------------+--------------+--- 2019-06-24 12:01:00+00 | 16 | 72202 2019-06-24 12:01:00+00 | 73 | 837725 2019-06-24 12:01:00+00 | 96 | 412237 2019-06-24 12:00:50+00 | 16 | 1173393 2019-06-24 12:00:50+00 | 73 | 90104 2019-06-24 12:00:50+00 | 96 | 784596

गणना के लिए । हमें उन ट्रकों की संख्या की गणना करने की आवश्यकता है जो दिनों के द्वारा क्रास्नोडार और उनके कुल टन भार को छोड़ देते हैं।

 SELECT time_bucket('1 day', time) AS day, count(*) AS trucks_exiting, sum(weight) / 1000 AS tonnage FROM vehicles INNER JOIN cities ON cities.name = 'Krasnodar' WHERE ST_Within(last_location, ST_Polygon(cities.geom, 4326)) AND NOT ST_Within(current_location, ST_Polygon(cities.geom, 4326)) GROUP BY day ORDER BY day DESC LIMIT 3;

यह पोस्टगिस एक्सटेंशन के कार्यों का भी उपयोग करता है, जो शहर को छोड़ने के बजाय बस उसमें जाने के लिए परिवहन की गणना करता है।

मुद्रा दर की निगरानी । तीसरा उदाहरण क्रिप्टोकरेंसी के बारे में है। अनुरोध आपको यह दिखाने की अनुमति देता है कि पिछले 2 सप्ताह में बिटकॉइन और अमेरिकी डॉलर के सापेक्ष इथेरियम की कीमत कैसे बदल गई है।

 SELECT time_bucket('14 days', c.time) AS period, last(c.closing_price, c.time) AS closing_price_btc, last(c.closing_price, c.time) * last(b.closing_price, c.time) filter (WHERE b.currency_code = 'USD') AS closing_price_usd FROM crypto_prices c JOIN btc_prices b ON time_bucket('1 day', c.time) = time_bucket('1 day', b.time) WHERE c.currency_code = 'ETH' GROUP BY period ORDER BY period DESC;

यह हमारे लिए SQL के समान ही स्पष्ट और सुविधाजनक है।

TimescaleDB के बारे में इतना अच्छा क्या है?

अंतर्निहित तालिका विभाजन टूल का उपयोग क्यों नहीं किया जाता है? और टेबल तोड़ने से क्यों परेशान? स्पष्ट उत्तर ऐसे डेटाबेस में प्रविष्टि गति है । ग्राफ नियमित रूप से वेनिला टेबल पोस्टग्रेक्यूएल 10 के बीच अनुभागों के बिना पंक्तियों की संख्या के सम्मिलन की दर और TimescaleDB हाइपरटेबल के वास्तविक माप को दर्शाता है।

यह बेंचमार्क एक मशीन पर 1 बिलियन लाइनें लिखता है, जो कि बुनियादी ढांचे से मैट्रिक्स इकट्ठा करने के लिए एक परिदृश्य का अनुकरण करता है। रिकॉर्ड में समय, बुनियादी ढांचे के घटक की पहचानकर्ता और 10 मैट्रिक्स शामिल हैं। बेंचमार्क अज़ुरे वीएम पर 8 कोर और 28 गीगाबाइट रैम के साथ-साथ नेटवर्क एसएसडी ड्राइव पर चलाया गया था। सम्मिलन 10 हजार रिकॉर्ड के बैचों में किया गया था।

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

आइए निम्नलिखित चार्ट को देखें। यह PostgreSQL 10 और TimescaleDB हाइपर टेबल में निर्मित घोषित विभाजन विभाजन की तुलना करता है। क्षैतिज अक्ष पर, वर्गों की संख्या।

TimescaleDB में, बढ़ते वर्गों के साथ गिरावट नगण्य है। एक्सटेंशन डेवलपर्स का दावा है कि वे एक सिंगल पोस्टग्रेसीक्यू उदाहरण में 10,000 सेक्शन के साथ अच्छा कर रहे हैं।

PostgreSQL में, मूल कार्यान्वयन 3,000 के बाद काफी कम हो जाता है। सामान्य तौर पर, PostgreSQL में घोषणात्मक विभाजन एक बड़ा कदम है, लेकिन यह केवल कम लोड वाले तालिकाओं के लिए अच्छी तरह से काम करता है। उदाहरण के लिए, माल, खरीदारों और अन्य डोमेन संस्थाओं के लिए जो सिस्टम में तेजी से मेट्रिक्स के रूप में प्रवेश नहीं करते हैं।

PostgreSQL के 11 और 12 संस्करणों में, मूल विभाजन समर्थन दिखाई देगा और आप नए संस्करणों के लिए समय श्रृंखला डेटा के लिए तुलनात्मक परीक्षण चलाने का प्रयास कर सकते हैं। लेकिन, मुझे लगता है कि TimescaleDB अभी भी बेहतर है। TimescaleDB के सभी बेंचमार्क उनके गिथब पर पाए जा सकते हैं और कोशिश कर सकते हैं।

मुख्य विशेषताएं

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

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

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

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

अतिरिक्त उपयोगी सुविधाएँ समय श्रृंखला डेटा के लिए विशिष्ट:

"Time_bucket" - एक स्वस्थ व्यक्ति का "date_trun";
हिस्टोग्राम - इंटरपोलेशन या अंतिम ज्ञात मूल्य का उपयोग करते हुए मिस्ड अंतराल में भरना;
पृष्ठभूमि कार्यकर्ता - सेवाएं जो आपको पृष्ठभूमि संचालन करने की अनुमति देती हैं: पुराने वर्गों की सफाई, पुनर्गठन।

TimescaleDB आपको शक्तिशाली PostgreSQL पारिस्थितिकी तंत्र में रहने की अनुमति देता है । यह एक्सटेंशन PostgreSQL को नहीं तोड़ता है, इसलिए सभी उच्च उपलब्धता समाधान, बैकअप सिस्टम, निगरानी उपकरण काम करना जारी रखेंगे। TimescaleDB Grafana, Periscope, Prometheus, Telegraf, Zabbix, Kubernetes, Kafka, Seeq, JackDB के साथ दोस्त हैं।

ग्राफाना को पहले से ही डेटा स्रोत के रूप में TimescaleDB का मूल समर्थन प्राप्त है। Grafana उस बॉक्स से बाहर समझते हैं, जो PostcreSQL में TimescaleDB है। डैशबोर्ड पर Grafana में क्वेरी बिल्डर अतिरिक्त TimescaleDB फ़ंक्शन को समझता है, जैसे कि "time_bucket", "first", "last"। आप इन प्रश्नों के साथ श्रृंखला डेटाबेस कार्यों से सीधे रेखांकन का निर्माण कर सकते हैं बिना विशाल प्रश्नों के।

प्रोमेथियस के पास एक एडेप्टर है जो आपको इससे डेटा मर्ज करने और एक विश्वसनीय डेटा वेयरहाउस के रूप में TimescaleDB का उपयोग करने की अनुमति देता है। वर्षों से प्रोमेथियस में डेटा को स्टोर न करने के लिए एक एडेप्टर का उपयोग करें।

टेलीग्राफ प्लगइन भी है। समाधान आपको प्रोमेथियस को पूरी तरह से हटाने की अनुमति देता है। इन्फ्रास्ट्रक्चर डेटा तुरंत TimescaleDB पर स्थानांतरित कर दिया जाता है और टेलीग्राफ के माध्यम से पढ़ा जाता है।

लाइसेंस और समाचार

इतना समय पहले नहीं, कंपनी ने एक नए लाइसेंसिंग मॉडल पर स्विच किया। अधिकांश कोड Apache 2.0 के तहत लाइसेंस प्राप्त है। एक छोटा हिस्सा उपयोग करने के लिए स्वतंत्र है, लेकिन टीएसएल के तहत लाइसेंस प्राप्त है।

एक वाणिज्यिक लाइसेंस के साथ एक एंटरप्राइज़ संस्करण है। चिंता न करें, एंटरप्राइज संस्करण में सभी अच्छाइयों को नहीं। मूल रूप से ऑटोमेशन हैं जैसे कि अप्रचलित विखंडू का स्वचालित निष्कासन, जिसे एक सरल "क्रोन" और इसी तरह की चीजों के माध्यम से किया जा सकता है।

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

खबर से:

पिछले एक साल में एक लाख डाउनलोड और एक आधा;
$ 31 मिलियन का निवेश;
IoT समाधान के बारे में MS Azure के साथ सक्रिय सहयोग।

संक्षेप में देना

TimescaleDB समय श्रृंखला डेटा संग्रहीत करने के लिए डिज़ाइन किया गया है। यह PostgreSQL में मूल लोगों की तुलना में न्यूनतम प्रतिबंधों के साथ एक शक्तिशाली विभाजन प्रणाली है।

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

PipelineDB

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

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

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

 CREATE CONTINUOUS VIEW v AS SELECT url::text, count(*) AS total_count, count(DISTINCT cookie::text) AS uniques, percentile_cont(0.99) WITHIN GROUP (ORDER BY latency::integer) AS p99_latency FROM page_views GROUP BY url;

 url | total_count | uniques | p99_latency -----------+-------------+---------+------------ some/url/0 | 633 | 51 | 178 some/url/1 | 688 | 37 | 139 some/url/2 | 508 | 88 | 121 some/url/3 | 848 | 36 | 59 some/url/4 | 126 | 64 | 159

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

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

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

 CREATE STREAM ab_event_stream ( name text, ab_group text, event_type varchar(1), cookie varchar(32) ); CREATE CONTINUOUS VIEW ab_test_monitor AS SELECT name, ab_group, sum(CASE WHENevent_type = 'v' THEN 1 ELSE 0 END) AS view_count, sum(CASE WHENevent_type = 'c' THEN 1 ELSE 0 END) AS conversion_count, count(DISTINCT cookie) AS uniques FROM ab_event_stream GROUP BY name, ab_group;

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

स्ट्रीम कंप्यूटिंग हमने डेटा स्ट्रीम और निरंतर दृश्य बनाने के बाद, हम स्ट्रीम कंप्यूटिंग के साथ काम कर सकते हैं। ऐसा दिखता है।

 INSERT INTO ab_event_stream (name, ab_group, event_type, cookie) SELECT round(random() * 2) AS name, round(random() * 4) AS ab_group, (CASE WHENrandom() > 0.4 THEN 'v' ELSE 'c' END) AS event_type, md5(random()::text) AS cookie FROM generate_series(0, 100000); SELECT ab_group, uniques FROM ab_test_monitor; SELECT ab_group, view_count * 100 / (conversion_count + view_count) AS conversion_rate FROM ab_test_monitor;

पहला "Select" समूह "ab" और अद्वितीय आगंतुकों की संख्या देता है। दूसरा - समूहों के बीच अनुपात देता है - रूपांतरण। यह एक संबंधपरक डेटाबेस में पांच एसक्यूएल कॉल पर ए / बी परीक्षण है।

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

टोपोलॉजी

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

PostgreSQL के अंदर पाइपलाइनलाइन घटकों के टोपोलॉजी का एक उदाहरण। सर्किट को डेरेक नेल्सन की एक प्रस्तुति से उधार लिया गया है।

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

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

मुख्य विशेषताएं

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

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

TimescaleDB की तरह, PipelineDB एक्सटेंशन PostgreSQL में SQL प्रतिबंध नहीं लगाता है । कई विशेषताएं हैं, उदाहरण के लिए, आप दो धाराओं को संयोजित नहीं कर सकते हैं, लेकिन यह आवश्यक नहीं है।

संभाव्य डेटा संरचनाओं और एल्गोरिदम के लिए समर्थन । विस्तार "ब्लूम फ़िल्टर" का उपयोग करता है "SELECT DISTINCT" के लिए, "COUNT (DISTINCT)" के लिए HyperLogLog, और SQL में सीधे "centile_count ()" के लिए T-Digest। इससे उत्पादकता में सुधार होता है।

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

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

लाइसेंस और समाचार

सभी कोड Apache 2.0 के तहत लाइसेंस प्राप्त है। विभिन्न शूटिंग दीर्घाओं के समर्थन के लिए एक सशुल्क सदस्यता है, साथ ही एक वाणिज्यिक लाइसेंस के साथ क्लस्टर संस्करण भी है। PipelineDB के आधार पर, कंपनी स्ट्राइड एनालिटिक्स सेवा प्रदान करती है।

इससे पहले कि मैं विस्तार के बारे में बात करना शुरू करूं, मैंने कहा कि एक "लेकिन" है। उसके बारे में बात करने का समय आ गया है। 1 मई, 2019 को, पाइपलाइनलाइन टीम ने घोषणा की कि यह अब कंफ्लुएंट का हिस्सा है। यह कंपनी है जो केएसक्यूएल को विकसित करती है - एसक्यूएल सिंटैक्स के साथ काफ्का में डेटा स्ट्रीमिंग के लिए एक इंजन। अब पॉडकास्ट डेब्रिंगिंग के सह-संस्थापक विक्टर गामोव वहां काम कर रहे हैं।

इससे क्या होता है? PipelineDB संस्करण 1.0.0 पर जम गया। महत्वपूर्ण बग को ठीक करने के अलावा, इसमें कुछ भी योजनाबद्ध नहीं है। अधिग्रहण के कारण, हमें उम्मीद है कि PostgreSQL के साथ काफ्का का उबेर एकीकरण। शायद यह प्लग -ेबल स्टोरेज पर आधारित कंफ्लुएंट है जो कुछ शांत करेगा।

क्या करें? TimescaleDB पर जाएं। नवीनतम संस्करण में उन्होंने लाठी के साथ अपना "CONTINUOUS VIEW" बनाया। बेशक, अब कार्यक्षमता पाइपलाइनलाइन की तरह शांत नहीं है, लेकिन यह समय की बात है।

संक्षेप में देना

PipelineDB उच्च प्रदर्शन स्ट्रीमिंग डेटा प्रोसेसिंग के लिए डिज़ाइन किया गया है। यह आपको डेटा को बचाने के लिए बिना बड़े डेटा सेट पर गणना करने की अनुमति देता है।

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

यदि किसी कारण से TimescaleDB से "CONTINUOUS VIEW" आपके लिए पर्याप्त नहीं है, तो PipelineDB प्रयास करें। यह अपाचे लाइसेंस के तहत एक ओपन सोर्स प्रोजेक्ट है। यह कहीं भी नहीं जाएगा, हालांकि अब इसे सक्रिय रूप से विकसित नहीं किया जा रहा है। लेकिन चीजें बदल सकती हैं, कॉन्फ्लुएंट ने अभी तक विस्तार की योजनाओं के बारे में नहीं लिखा है।

TimescaleDB और PipelineDB का उपयोग करना

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

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

एक्सटेंशन के साथ, हमारे पास तीन फायदे हैं।

वास्तविक समय विश्लेषण।
भंडारण समय श्रृंखला डेटा।
संग्रहीत टेलीमेट्री की मात्रा में कमी। PipelineDB म्यूटेटर का उपयोग करके, हम उदाहरण के लिए, औसत मूल्यों की गणना करते हुए, एक मिनट के लिए डेटा एकत्र करते हैं।

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

अपने आप को सब कुछ "टच" करने के लिए, GitHub पर डेमो देखें और डॉकटर छवि को चलाएं - असेंबली के अंदर नवीनतम PostgreSQL, TimescaleDB और PipelineDB से।

कुल मिलाकर

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

ये एक्सटेंशन व्यावहारिक रूप से PostgreSQL के आसपास के इकोसिस्टम पर प्रतिबंध नहीं लगाते हैं, जैसे कि उच्च उपलब्धता समाधान, बैकअप सिस्टम, निगरानी और लॉग विश्लेषण उपकरण। अगर JSONB कॉलम हैं, तो हमें MongoDB की आवश्यकता नहीं है और अगर TimescaleDB है तो हमें InfluxDB की आवश्यकता नहीं है।

क्या आपको इवान की कहानी पसंद है और कुछ इसी तरह से साझा करना चाहते हैं? 7 सितंबर से पहले मास्को में हाईलाड ++ पर आवेदन करें । कार्यक्रम धीरे-धीरे भर रहा है। , , , , . , !

एक रिलेशनल डीबीएमएस में समय श्रृंखला डेटा। PostgreSQL के लिए एक्सटेंशन्स TimescaleDB और PipelineDB

समय श्रृंखला डेटा या समय श्रृंखला क्या है?

लोकप्रिय भंडारण समाधान

समय श्रृंखला डेटा के लिए लोकप्रिय भंडारण समाधान

Postgres, Postgis, और TimescaleDB

क्यों PostgreSQL?

प्रचार के बाद!

TimescaleDB VS पाइपलाइनलाइन

TimescaleDB

TimescaleDB के बारे में इतना अच्छा क्या है?

मुख्य विशेषताएं

लाइसेंस और समाचार

संक्षेप में देना

PipelineDB

टोपोलॉजी

मुख्य विशेषताएं

लाइसेंस और समाचार

संक्षेप में देना

TimescaleDB और PipelineDB का उपयोग करना

कुल मिलाकर

More articles: