বস্তুগত দৃষ্টিভঙ্গি থেকে ক্রমাগত সমষ্টি: রিয়েল-টাইম অ্যানালিটিক্সের সাথে PostgreSQL উন্নত করা

ব্যবহারকারীদের রিয়েল-টাইম ডেটা অ্যানালিটিক্স অ্যাক্সেস করতে সক্ষম করা অনেক আধুনিক অ্যাপ্লিকেশনের একটি মূল ক্ষমতা। আপনার প্রিয় SaaS প্ল্যাটফর্ম ব্যবহার করে নিজেকে চিত্রিত করুন - সম্ভবত একটি স্বজ্ঞাত ড্যাশবোর্ড রয়েছে যা রিয়েল-টাইম ডেটা এবং ঐতিহাসিক অন্তর্দৃষ্টি উপস্থাপন করে। আপনি সম্ভবত প্ল্যাটফর্মের সাথে ইন্টারঅ্যাক্ট করতে পারেন, কাস্টমাইজড রিপোর্ট তৈরি করতে পারেন, বিশদ মেট্রিক্স অন্বেষণ করতে পারেন এবং সপ্তাহ বা মাসব্যাপী প্রবণতাগুলি কল্পনা করতে পারেন।

আপনি অবশ্যই এই প্ল্যাটফর্মটি একজন ব্যবহারকারী হিসাবে ধীর হতে চান না। এর মানে হল যে এই পণ্যগুলিকে চালিত করা ডেটাবেসকে জটিল, বিশ্লেষণাত্মক প্রশ্নগুলি সহ প্রচুর পরিমাণে ডেটার উপর কোয়েরি চালানোর ক্ষেত্রে দ্রুত হতে হবে।

যখন PostgreSQL আজ ডেভেলপারদের মধ্যে সবচেয়ে প্রিয় ডাটাবেস , এটি বৃহৎ ভলিউম ডেটা অনুসন্ধানে দ্রুত হওয়ার জন্য পরিচিত নয়। কিন্তু চিন্তা করবেন না: Postgres এর টুলবক্সে সবসময় একটি টুল থাকে। সেরা এক বস্তুগত দৃশ্য.

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 এক্সটেনশনের মাধ্যমে এবং Timescale প্ল্যাটফর্মের মাধ্যমে AWS-এ সমস্ত 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 s এবং 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);

PS ক্রমাগত সমষ্টি সংজ্ঞায়িত করার অভিজ্ঞতাকে আরও দক্ষ করে তুলতে, টাইমস্কেল অনুক্রমিক ক্রমাগত সমষ্টি চালু করেছে TimescaleDB 2.9-এ। একবার আপনি ক্রমাগত সমষ্টির সাথে পরিচিত হয়ে গেলে, আপনি সেগুলিকে অন্যান্য ক্রমাগত সমষ্টির উপরে তৈরি করা শুরু করতে পারেন—যেমন, পূর্ববর্তী উদাহরণে, আপনি বাই-মিনিট সমষ্টির উপরে ঘন্টাভিত্তিক সমষ্টিকেও সংজ্ঞায়িত করতে পারেন।

উপসংহার

এমনকি যদি PostgreSQL মূলত এমন অ্যাপ্লিকেশনগুলির জন্য তৈরি করা হয়নি যেগুলিকে বড় লাইভ ডেটাসেটগুলি প্রক্রিয়া করতে হবে, অনুমান করুন কী—এই ধরণের কাজের চাপ এখন সর্বত্র রয়েছে৷ যাইহোক, PostgreSQL এমন বৈশিষ্ট্যগুলির সাথে আসে যা এই কাজটিতে সহায়তা করে। বস্তুগত দৃষ্টিভঙ্গিগুলি সবচেয়ে শক্তিশালী, কারণ তারা প্রাক-কম্পিউটিং ক্যোয়ারী ফলাফল এবং দ্রুত পুনরুদ্ধারের জন্য ডিস্কে সংরক্ষণ করার অনুমতি দেয়।

যাইহোক, বস্তুগত দৃষ্টিভঙ্গির তিনটি গুরুত্বপূর্ণ সীমাবদ্ধতা রয়েছে। প্রথমত, রিফ্রেশ ট্রিগার করা খুব গণনাগতভাবে অদক্ষ। দ্বিতীয়ত, এমনকি এই স্বয়ংক্রিয় রিফ্রেশ সেট আপ একটি বিরামবিহীন প্রক্রিয়া নয়। তৃতীয়ত, বাস্তবায়িত ভিউ আপ-টু-ডেট ফলাফল দেখায় না, কারণ তারা শেষ রিফ্রেশের পর থেকে যোগ করা বা পরিবর্তিত ডেটা বাদ দেয়।

এই সীমাবদ্ধতাগুলি অনেক আধুনিক অ্যাপ্লিকেশনের জন্য বস্তুগত দৃষ্টিভঙ্গিকে একটি অব্যবহারিক সমাধান করে তোলে। এটি সমাধান করার জন্য, আমরা ক্রমাগত সমষ্টি তৈরি করেছি। এইগুলি হল PostgreSQL বস্তুগত দৃষ্টিভঙ্গি যেখানে আপনি সহজেই একটি রিফ্রেশ নীতি নির্ধারণ করতে পারেন, তাই রিফ্রেশগুলি স্বয়ংক্রিয়ভাবে ঘটে। এই রিফ্রেশগুলিও ক্রমবর্ধমান এবং তাই, অনেক বেশি কার্যকর। সবশেষে, ক্রমাগত সমষ্টি আপনাকে শেষ রিফ্রেশের পর থেকে যোগ করা এবং পরিবর্তিত কাঁচা ডেটার সাথে বাস্তবায়িত করা ডেটা একত্রিত করার অনুমতি দেয়, নিশ্চিত করে যে আপনি শুধুমাত্র আপ-টু-ডেট ফলাফল পাবেন।

আপনি যদি আপনার হার্ডওয়্যারে PostgreSQL চালাচ্ছেন, আপনি এর মাধ্যমে ক্রমাগত সমষ্টি অ্যাক্সেস করতে পারেন TimescaleDB এক্সটেনশন ইনস্টল করা হচ্ছে . আপনি AWS-এ থাকলে, টাইমস্কেল প্ল্যাটফর্ম দেখুন . প্রথম 30 দিন বিনামূল্যে.

লিখেছেন Carlota Soto এবং Mat Arye.