भौतिक दृश्यों से सतत समुच्चय तक: वास्तविक समय विश्लेषण के साथ PostgreSQL को बढ़ाना

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

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

जबकि PostgreSQL आज डेवलपर्स के बीच सबसे पसंदीदा डेटाबेस है , यह बड़ी मात्रा में डेटा की क्वेरी करने में तेज़ होने के लिए नहीं जाना जाता है। लेकिन चिंता न करें: पोस्टग्रेज़ के टूलबॉक्स में हमेशा एक टूल होता है। सर्वोत्तम में से एक भौतिकीकृत दृश्य है।

PostgreSQL भौतिकीकृत दृश्य क्या हैं?

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

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

भौतिक विचारों के साथ काम करना अत्यंत सरल है। एक दृश्य बनाने के लिए, आप CREATE MATERIALIZED VIEW स्टेटमेंट और अपनी पसंद की क्वेरी का उपयोग करेंगे।

एक बार जब आपका भौतिक दृश्य बन जाता है, तो आप इसे नियमित PostgreSQL तालिका के रूप में क्वेरी कर सकते हैं:

 CREATE MATERIALIZED VIEW customer_orders AS SELECT customer_id, COUNT(*) as total_orders FROM orders GROUP BY customer_id;

 -- Query the materialized view SELECT * FROM customer_orders;

जब तक आप इसे ताज़ा नहीं करते, यह भौतिक दृश्य जल्दी ही पुराना हो जाएगा: भले ही आप आधार तालिका में नया डेटा जोड़ रहे हों (या डेटा को अपडेट कर रहे हों या हटा रहे हों), भौतिक दृश्य में वे परिवर्तन स्वचालित रूप से शामिल नहीं होते हैं; यह उस समय का एक स्नैपशॉट है जब इसे बनाया गया था। भौतिकीकृत दृश्य को अद्यतन करने के लिए, आपको REFRESH MATERIALIZED VIEW चलाने की आवश्यकता है।

 REFRESH MATERIALIZED VIEW customer_orders;

यह अंतिम बिंदु (रिफ्रेश कैसे प्रबंधित किया जाता है) भौतिक विचारों का अकिलीस हील है, जैसा कि हम अगले भाग में चर्चा करेंगे।

रीयल-टाइम एनालिटिक्स के बारे में क्या? PostgreSQL भौतिक दृश्यों की सीमाएँ

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

यह एकल समस्या तीन महत्वपूर्ण सीमाएँ पैदा करती है:

रिफ्रेश अप्रभावी और कम्प्यूटेशनल रूप से महंगे हैं

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

रिफ्रेश स्वचालित रूप से नहीं चलते हैं

जैसा कि पहले भी उल्लेख किया गया है, भौतिक दृश्य स्वचालित रूप से नवीनतम डेटा को शामिल नहीं करेंगे। उन्हें REFRESH MATERIALIZED VIEW चलाकर रिफ्रेश करना होगा। उत्पादन सेटिंग में मैन्युअल रिफ्रेश चलाना संभव नहीं है: रिफ्रेश को स्वचालित करना अधिक यथार्थवादी सेटअप होगा।

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

भौतिक दृश्य अद्यतन परिणाम नहीं दिखाते हैं

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

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

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

निरंतर समुच्चय से मिलें: रीयल-टाइम एनालिटिक्स के लिए स्वचालित रिफ्रेश के साथ भौतिक दृश्य

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

निरंतर समुच्चय (TimescaleDB एक्सटेंशन के माध्यम से और AWS में Timescale प्लेटफ़ॉर्म के माध्यम से सभी PostgreSQL डेटाबेस के लिए उपलब्ध) कुशल, स्वचालित ताज़ा क्षमताओं और एक वास्तविक समय तत्व के साथ बढ़ाए गए भौतिक दृश्य हैं। वे देखने और महसूस करने में बिल्कुल भौतिक दृश्यों की तरह लगते हैं लेकिन निम्नलिखित की अनुमति देते हैं:

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

रिफ्रेश को स्वचालित और संसाधन-कुशल बनाना

एक सतत समुच्चय बनाना एक भौतिक दृश्य बनाने के समान है (और इसे नियमित PostgreSQL तालिका के रूप में भी पूछा जा सकता है):

 CREATE MATERIALIZED VIEW hourly_sales WITH (timescaledb.continuous) AS SELECT time_bucket(INTERVAL '1 hour', sale_time) as hour, product_id, SUM(units_sold) as total_units_sold FROM sales_data GROUP BY hour, product_id;

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

नीचे दिया गया उदाहरण प्रत्येक 30 मिनट में निरंतर समुच्चय को अद्यतन करने के लिए एक ताज़ा नीति स्थापित करता है। end_offset पैरामीटर ताज़ा किए जाने वाले डेटा की समय सीमा को परिभाषित करता है और schedule_interval सेट करता है कि निरंतर समुच्चय कितनी बार ताज़ा किया जाएगा:

 -- Setting up a refresh policy SELECT add_continuous_aggregate_policy('hourly_sales', end_offset => INTERVAL '1 minute', schedule_interval => INTERVAL '30 minutes');

जब यह ताज़ा नीति लागू होगी, तो यह प्रक्रिया उस स्थिति की तुलना में कहीं अधिक कुशल होगी जब हम एक सादे भौतिक दृश्य का उपयोग कर रहे थे। REFRESH MATERIALIZED VIEW चलाने के विपरीत, जब एक निरंतर समुच्चय को ताज़ा किया जाता है, तो टाइमस्केल सभी पुराने डेटा को नहीं हटाता है और इसके विरुद्ध समुच्चय की पुन: गणना नहीं करता है: इंजन केवल सबसे हालिया ताज़ा अवधि (उदाहरण के लिए, 30 मिनट) के विरुद्ध क्वेरी चलाता है और इसे जोड़ता है मूर्तीकरण के लिए.

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

वास्तविक समय विश्लेषण के लिए नवीनतम परिणाम दिखा रहा है

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

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

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

यह कार्यक्षमता स्थिर स्नैपशॉट से भौतिक दृश्यों को गतिशील संस्थाओं में बदल देती है, यह सुनिश्चित करती है कि संग्रहीत डेटा केवल एक ऐतिहासिक प्रतिबिंब नहीं है बल्कि अंतर्निहित डेटासेट का एक अद्यतित प्रतिनिधित्व है।

सतत समुच्चय का उपयोग करना: उदाहरण

भले ही यह सब अच्छा लगता हो, (उम्मीद है) यह एक उदाहरण के साथ बहुत बेहतर तरीके से सामने आएगा।

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

इस एप्लिकेशन को पावर देने के लिए, हमारे पास सबसे पहले एक हाइपरटेबल होगा जिसमें सवारी के बारे में डेटा लगातार डाला जाता है। हाइपरटेबल कुछ इस तरह दिख सकता है:

 CREATE TABLE rides ( ride_id SERIAL PRIMARY KEY, vehicle_id INT, start_time TIMESTAMPTZ NOT NULL, end_time TIMESTAMPTZ NOT NULL, distance FLOAT NOT NULL, price_paid FLOAT NOT NULL ); SELECT create_hypertable('rides', 'start_time');

हाइपरटेबल्स बहुत तेज़ और बहुत स्केलेबल हैं - यह तालिका अरबों पंक्तियाँ होने पर भी प्रदर्शनशील बनी रहेगी।

लाइव अवलोकन प्रदान करके तालिका को सशक्त बनाने के लिए, हम डेटा को 30 मिनट तक बकेट करने के लिए एक सतत समुच्चय का उपयोग करेंगे। इससे प्रक्रिया तेज़ और प्रतिक्रियाशील बनी रहेगी:

 -- Create continuous aggregate for live overview CREATE MATERIALIZED VIEW live_dashboard WITH (timescaledb.continuous, timescaledb.materialized_only=false)) AS SELECT vehicle_id, time_bucket(INTERVAL '30 minute', start_time) as minute, COUNT(ride_id) as number_of_rides, AVG(price_paid) as average_price FROM rides GROUP BY vehicle_id, minute;

 -- Set up a refresh policy SELECT add_continuous_aggregate_policy('live_dashboard', end_offset => INTERVAL '10 minutes', schedule_interval => INTERVAL '15 minute');

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

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

 -- Create continuous aggregate for daily overview CREATE MATERIALIZED VIEW hourly_metrics WITH (timescaledb.continuous, timescaledb.materialized_only=false) AS SELECT vehicle_id, time_bucket(INTERVAL '1 hour', start_time) as hour, COUNT(ride_id) as number_of_rides, SUM(price_paid) as total_revenue FROM rides WHERE start_time > NOW() - INTERVAL '1 day' GROUP BY vehicle_id, hour;

 -- Define refresh policy SELECT add_continuous_aggregate_policy('hourly_metrics', end_offset => INTERVAL '10 minutes', schedule_interval => INTERVAL `1 hour`);

अंत में, साप्ताहिक दृश्य पेश करने वाले चार्ट को सशक्त बनाने के लिए, हम एक और निरंतर समुच्चय बनाएंगे, इस बार डेटा को दिन के अनुसार एकत्रित करेंगे:

 -- Create continuous aggregate to power chart with weekly overview CREATE MATERIALIZED VIEW daily_metrics WITH (timescaledb.continuous, timescaledb.materialized_only=false) AS SELECT vehicle_id, time_bucket(INTERVAL '1 day', start_time) as day, COUNT(ride_id) as number_of_rides, SUM(price_paid) as total_revenue FROM rides WHERE start_time > NOW() - INTERVAL '1 week' GROUP BY vehicle_id, day;

 -- Define refresh policy SELECT add_continuous_aggregate_policy('daily_metrics', end_offset => INTERVAL '10 minutes', schedule_interval => INTERVAL '1 day);

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

निष्कर्ष

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

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

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

यदि आप अपने हार्डवेयर पर PostgreSQL चला रहे हैं, तो आप निरंतर समुच्चय तक पहुंच सकते हैं TimescaleDB एक्सटेंशन इंस्टॉल करना . यदि आप AWS में हैं, तो टाइमस्केल प्लेटफ़ॉर्म देखें . पहले 30 दिन निःशुल्क हैं।

कार्लोटा सोटो और मैट आर्ये द्वारा लिखित।