রিপোর্টিংয়ের জন্য PostgreSQL রিড রেপ্লিকা: ড্যাশবোর্ডগুলোকে দ্রুত রাখুন

কেন রিপোর্টিং আপনার প্রাইমারি ডাটাবেস ধীর করতে পারে

একটি সাধারণ দৃশ্য দেখা যায়: দিনের বেশিরভাগ সময় অ্যাপ ঠিকঠাক কাজ করে, তারপর কেউ একটি ড্যাশবোর্ড খুললে হঠাৎ চেকআউট, লগইন বা সাপোর্ট টুলগুলো ধীর হতে শুরু করে। কিছুই “ডাউন” থাকে না, কিন্তু সবকিছু ধীর। এটি সাধারণত আপনার প্রাইমারি ডাটাবেস একসাথে দুইটি দিক থেকে টানপোড়েনে পড়ার ফল।

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

ড্যাশবোর্ডগুলো OLTP ডাটাবেসে ক্ষতি করে এমন সাধারণ উপায়গুলো:

• ভারী রিড CPU, মেমরি এবং ডিস্ক I/O-এর সঙ্গে প্রতিদ্বন্দ্বিতা করে
• বড় স্ক্যান ক্যাশ থেকে "হট" পেজগুলো ঠেলে দেয়, ফলে সাধারণ কুয়েরিগুলো ধীর হয়
• বড় SORT ও GROUP BY ডিস্কে স্পিল করে এবং লোডের হঠাৎ বাড়তি চাপ তৈরি করে
• দীর্ঘস্থায়ী কুয়েরি কনটেনশন বাড়ায় এবং স্পাইকগুলোকে দীর্ঘ করে তোলে
• অ্যাড-হক ফিল্টার (তারিখ রেঞ্জ, সেগমেন্ট) লোড অনির্দেশ্য করে

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

শুরুতেই প্রত্যাশা স্থাপন করা জরুরি: রেপ্লিকা রিডের জন্য সহায়তা করে, রাইটের জন্য নয়। একটি স্ট্যান্ডার্ড রেপ্লিকাতে ইনসার্ট/আপডেট নিরাপদভাবে পাঠানো যায় না, এবং ফলাফল প্রাইমারির থেকে একটু পিছিয়ে থাকতে পারে কারণ রেপ্লিকেশন সময় নেয়। অনেক ড্যাশবোর্ডের জন্য এটি একটি ভালো ট্রেডঅফ: সামান্য কম "তাজা" সংখ্যা বিনিময়ে ধারাবাহিক অ্যাপ পারফরম্যান্স।

আপনি যদি অভ্যন্তরীণ ড্যাশবোর্ড (উদাহরণস্বরূপ AppMaster-এ) বানান, এই বিভাজন সাধারণত সুন্দরভাবে মানায়: অ্যাপ প্রাইমারিতে লিখতে থাকে, আর রিপোর্টিং স্ক্রিনগুলো রেপ্লিকা থেকে প্রশ্ন করে।

PostgreSQL-এ রিড রেপ্লিকা কীভাবে কাজ করে (সহজ ভাষায়)

একটি PostgreSQL রিড রেপ্লিকা হল আপনার মূল (প্রাইমারি) ডাটাবেসের নিকট-রিয়েল-টাইম কপি রাখে এমন দ্বিতীয় একটি সার্ভার। প্রাইমারি লেখাগুলো (INSERT, UPDATE, DELETE) হ্যান্ডল করে। রেপ্লিকা প্রধানত রিড সার্ভ করে (SELECT), তাই রিপোর্টিং কুয়েরিগুলো দিনের-প্রতিদিনের ট্রানজেকশনের সঙ্গে প্রতিদ্বন্দ্বিতা করে না।

এক মিনিটে প্রাইমারি বনাম রেপ্লিকা

প্রাইমারিকে একটি ব্যস্ত দোকানের ক্যাশিয়ার হিসেবে ভাবুন: এটি প্রতিটি বিক্রয় আপডেট করে স্টক, পেমেন্ট এবং অর্ডার, তাই তা দ্রুত প্রতিক্রিয়াশীল থাকতে হয়। রেপ্লিকা হল একটি ডিসপ্লে স্ক্রিন যা মোট ও ট্রেন্ড দেখায়। এটি ক্যাশিয়ার যা করে তা দেখে এবং কিছুক্ষণ পরে নিজে আপডেট করে।

হ্যান্ডসে, PostgreSQL পরিবর্তনগুলো কপি করে প্রাইমারিতে কী বদলেছে তার একটি স্ট্রীম পাঠিয়ে এবং তা রেপ্লিকায় রেপ্লে করে। অর্থাৎ রেপ্লিকায় একই ডাটাবেস স্ট্রাকচার ও ডাটা থাকে, শুধু সামান্য পিছনে থাকে।

প্রায়োগিকভাবে, রেপ্লিকেশন কপি করে:

• টেবিল ডাটা (রো)
• ইনডেক্স পরিবর্তন (তখন কুয়েরি একই ইনডেক্স ব্যবহার করতে পারে)
• স্কিমা পরিবর্তন (নতুন কলাম, নতুন টেবিল, এবং অনেক ধরনের মাইগ্রেশন)
• সাধারণ SQL-র মাধ্যমে হওয়া অন্যান্য অধিকাংশ ডাটাবেস পরিবর্তন

রেপ্লিকা যা সমাধান করে না: এটি ভারি রাইটকে সস্তা করে দেবে না, এবং খারাপ স্কিমা বা অভাবিত ইনডেক্স থেকে সৃষ্ট ধীর কুয়েরি ঠিক করবে না। যদি আপনার ড্যাশবোর্ড কুয়েরি রেপ্লিকায় একটি বিশাল টেবিল স্ক্যান করে, তা এখনও ধীর হতে পারে। কেবল এটি একই সময়ে চেকআউটকে ধীর করে দেবে না।

এটি কারণেই রিপোর্টিংয়ের জন্য PostgreSQL রিড রেপ্লিকা জনপ্রিয়: তারা OLTP কাজ (দ্রুত, ঘন ট্রানজেকশন) আলাদা করে OLAP-শৈলীর কাজ (দীর্ঘতর রিড, গ্রুপিং, মোট) থেকে। যদি আপনি অভ্যন্তরীণ ড্যাশবোর্ড বা অ্যাডমিন প্যানেল বানান (উদাহরণস্বরূপ AppMaster-এ), রিপোর্টিং পৃষ্ঠাগুলোকে রেপ্লিকাতে পয়েন্ট করা প্রায়শই সহজতম উপায় যাতে উভয় পাশই সুখী থাকে।

কোন রিপোর্টিং ওয়ার্কলোডগুলি রেপ্লিকায় চলে ভাল

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

সবচেয়ে সাধারণ ড্যাশবোর্ড প্যাটার্ন হল একটি বিস্তৃত তারিখ রেঞ্জ প্লাস কিছু ফিল্টার। “গত ৯০ দিন অঞ্চল, প্রোডাক্ট, ও চ্যানেল অনুযায়ী” সহজেই মিলিয়ন রো স্পর্শ করতে পারে, যদিও চূড়ান্ত চার্ট মাত্র ১২টি বার দেখায়। এই ধরনের স্ক্যান প্রাইমারি ডাটাবেসের ডিস্ক রিড ও ক্যাশ স্পেসের সঙ্গে প্রতিদ্বন্দ্বিতা করে।

কোন ওয়ার্কলোডগুলো রেপ্লিকায় ভালো বসে

বেশিরভাগ দল শুরুতে রিপোর্টিং ডাটাবেসে এগুলো সরায়:

• একাধিক টেবিল জোড়া বড় JOIN (orders + items + customers + refunds)
• SUM, COUNT DISTINCT, পারসেন্টাইল হিসাব, কোহর্ট বিশ্লেষণের মত অ্যাগ্রেগেশন
• বড় রেজাল্ট সেটকে সাজানো ও গ্রুপ করে দীর্ঘস্থায়ী কুয়েরি
• প্রতি ঘন্টা/প্রতি দিন চলা শিডিউলড রিপোর্ট যা একই ভারী কাজ বারবার করে
• এক্সপ্লোরেটরি BI সেশান যেখানে মানুষ ক্লিক করে ও ভ্যারিয়েশন পুনরায় চালায়

একটি কুয়েরি “রিড-ওনলি” হলেও তা CPU, মেমরি এবং I/O পুড়ে ফেলতে পারে। বড় GROUP BY অপারেশন অন্য কুয়েরিগুলোকে মেমরি থেকে ঠেলে দিতে পারে। বারবার স্ক্যান বাফার ক্যাশকে ঘুরে দেয়, ফলে আপনার প্রাইমারি ডিস্ক থেকে বেশি পড়তে শুরু করে।

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

একটি সহজ উদাহরণ: আপনার অপারেশন ড্যাশবোর্ড ৯:০০ AM-এ লোড হয় এবং ৫০ জন একসাথে খুলে। প্রতিটি পেজভিউ কয়েকটি উইজেট ট্রিগার করে, আর প্রতিটি উইজেট আলাদা ফিল্টারসহ একটি কুয়েরি চালায়। প্রাইমারিতে সেই বিস্ফোরণ অর্ডার ক্রিয়েশন ধীর করে দিতে পারে। রেপ্লিকায়, ড্যাশবোর্ড ধীর বা সামান্য পেছানো হতে পারে, কিন্তু আপনার ট্রানজেকশনগুলো দ্রুত থাকে।

আপনি যদি AppMaster-এর মত প্ল্যাটফর্মে অভ্যন্তরীণ ড্যাশবোর্ড বানান, রিপোর্টিং স্ক্রিনগুলোকে রেপ্লিকা কানেকশনে পয়েন্ট করা সাধারণত সহজ জিত, যতক্ষণ সবাই বুঝে ডাটা কয়েক সেকেন্ড (অথবা মিনিট) পেছানো থাকতে পারে।

ট্রেড-অফ: তাজা ডাটা বনাম গতি (রেপ্লিকেশন ল্যাগ)

রিপ্লিকা ড্যাশবোর্ডগুলোকে দ্রুত রাখে কারণ এটি রিপোর্টিং কুয়েরি প্রাইমারি থেকে তুলে নেয়। খরচ হল যে রেপ্লিকা সাধারণত সামান্য পিছিয়ে থাকে। এই ডিলে-টিকেই রেপ্লিকেশন ল্যাগ বলে এবং এটি রিপোর্টিংয়ের জন্য PostgreSQL রিড রেপ্লিকার মূল ট্রেড-অফ।

ব্যবহারকারীরা সহজভাবে লক্ষ্য করে: “আজকের” সংখ্যা একটু কম, সাম্প্রতিক অর্ডারগুলি অনুপস্থিত, বা একটি চার্ট কয়েক মিনিট পরে আপডেট হয়। বেশিরভাগ মানুষ উদ্বেগ করে না যদি সাপ্তাহিক ট্রেন্ড ২ মিনিট পুরনো হয়, কিন্তু তারা উদ্বিগ্ন হবে যদি "পেমেন্ট এখনই সফল হয়েছে" ভিউ ভুল দেখায়।

ল্যাগ ঘটে যখন প্রাইমারি রেপ্লিকা থেকে দ্রুত পরিবর্তন তৈরি করে যেটি রেপ্লিকা গ্রহন করে এবং রেপ্লে করতে পারে না। সাধারণ কারণগুলোর মধ্যে রয়েছে লেখার আগমন বৃদ্ধি (ফ্ল্যাশ সেলস, ইম্পোর্ট), সীমিত নেটওয়ার্ক ব্যান্ডউইথ, রেপ্লিকার ধীর ডিস্ক, অথবা দীর্ঘ চলমান কুয়েরি যা রেপ্লিকা পরিবর্তনগুলো প্রয়োগ করার সময় CPU ও I/O-র সঙ্গে প্রতিদ্বন্দ্বিতা করে।

গ্রহণযোগ্য ল্যাগ নির্ধারণের একটি ব্যবহারিক উপায় হলো এটি সেই সিদ্ধান্তের অনুরূপ করা যেটা ড্যাশবোর্ড সমর্থন করে:

• এক্সিকিউটিভ KPI ড্যাশবোর্ড: সেকেন্ড থেকে কয়েক মিনিট সাধারণত ঠিক আছে।
• অপারেশনাল কিউ (শিপিং, সাপোর্ট): নিকট-রিয়েল টাইম লক্ষ্য করুন, সাধারণত সেকেন্ড পর্যায়ে।
• ফাইনান্সিয়াল ক্লোজ বা অডিট: নিয়ন্ত্রণকৃত স্ন্যাপশটে চালান, "লাইভ" নয়।
• কাস্টমার-ফেসিং "আমার সাম্প্রতিক অর্ডার": নিকট-রিয়েল টাইম বা প্রাইমারি ব্যবহার করুন।

সরল নিয়ম: যদি একটি রিপোর্ট অবশ্যই সর্বশেষ কমিটেড ট্রানজেকশন অন্তর্ভুক্ত করতে হবে, তবে এটি প্রাইমারি (অথবা নিশ্চিত তাজা থাকা সিস্টেম) এ পড়তে হবে। সাধারণ উদাহরণ: চেকআউট সময় ইনভেন্টরি উপলব্ধতা, প্রতারণা চেক, এবং এমন কিছু যা অবিলম্বে একটি কার্য সম্পাদন করে।

উদাহরণ: একটি সেলস টিমের ড্যাশবোর্ড রেপ্লিকায় নিরাপদে পড়তে পারে এবং প্রতি মিনিটে রিফ্রেশ করে। কিন্তু "অর্ডার কনফার্মেশন" পেজটি প্রাইমারি থেকে পড়া উচিত, কারণ ঠিকই স্থাপন হওয়া অর্ডারের জন্য "অর্ডার পাওয়া যায়নি" দেখানো সাপোর্ট টিকিটের কারণ হবে।

যদি আপনার অ্যাপ বা কোনো কোডবিহীন টুল আপনাকে একটি ডাটাবেস কানেকশন বেছে নিতে দেয় (উদাহরণস্বরূপ AppMaster-এ রিড-ওনলি স্ক্রিনকে রেপ্লিকায় পয়েন্ট করা), আপনি UI কিভাবে বানানো হয় তা বদল না করে এই বিভাজন প্রয়োগ করতে পারেন।

ধাপে ধাপে: ড্যাশবোর্ডের জন্য রিড রেপ্লিকা সেট আপ করা

ড্যাশবোর্ডের জন্য একটি রেপ্লিকা সেট আপ করা বেশিরভাগই কিছু স্পষ্ট সিদ্ধান্ত নেওয়া এবং রিপোর্টিং ট্রাফিককে প্রাইমারি ডাটাবেস থেকে দূরে রাখা সম্পর্কে।

1) সঠিক টোপোলজি নির্ধারণ করুন

টোপোলজি থেকে শুরু করুন। একটি রেপ্লিকা একাধিক BI টুল ও কিছু ড্যাশবোর্ডের জন্য প্রায়ই যথেষ্ট। যখন অনেক বিশ্লেষক বা একাধিক টুল সারাদিন ডাটায় আঘাত করে তখন একাধিক রেপ্লিকা সহায়ক। যদি আপনার ব্যবহারকারীরা প্রধান রিজিয়নের বাইরে থাকে, একটি আঞ্চলিক রেপ্লিকা ড্যাশবোর্ডের জন্য লেটেন্সি কমাতে পারে, কিন্তু এটি আরও মনিটরিং যোগ করে।

পরবর্তী ধাপ: synchronous না asynchronous রেপ্লিকেশন নির্বাচন করুন। synchronous সর্বোত্তম তাজা ডাটা দেয় কিন্তু লেখাগুলোকে ধীর করে দিতে পারে, যা অনেক দলের উদ্দেশ্য নষ্ট করে। ড্যাশবোর্ডের জন্য asynchronous সাধারণত পছন্দ, যতক্ষণ সবাই মেনে নেয় যে ডাটা একটু পিছিয়ে থাকতে পারে।

2) রেপ্লিকা যেন রিপোর্টিং সার্ভারের মতো গড়ুন

রেপ্লিকা একটি সস্তা প্রডাকশন কপির মতো নয়। রিপোর্টিং কুয়েরির জন্য বেশি CPU, বড় সোর্টের জন্য বেশি মেমরি, এবং স্ক্যানের জন্য দ্রুত ডিস্ক প্রায়শই প্রয়োজন।

PostgreSQL রিপোর্টিং রেপ্লিকাগুলোর জন্য একটি ব্যবহারিক সেটআপ ফ্লো:

• নির্ধারণ করুন কতটি রেপ্লিকা প্রয়োজন এবং তারা কোথায় থাকবে (একই রিজিয়ন নাকি ব্যবহারকারীদের কাছে কাছে)।
• আপনার ড্যাশবোর্ড কতটা ডিলে সহ্য করতে পারে তাতে ভিত্তি করে async বনাম sync চয়ন করুন।
• রিড-হেভি কাজের জন্য রিসোর্স প্রোভিশন করুন (CPU, RAM, এবং ডিস্ক IOPS, স্টোরেজ সাইজের চেয়ে এগুলো বেশি গুরুত্বপূর্ণ)।
• রিপোর্টিং ব্যবহারকারী ও টুলগুলোর জন্য আলাদা, রিড-ওনলি ক্রেডেনশিয়াল তৈরি করুন।
• ড্যাশবোর্ড কুয়েরিগুলোকে রেপ্লিকায় রাউট করুন (আপনার অ্যাপ, BI টুল, বা একটি ছোট রিপোর্টিং সার্ভিসে রেপ্লিকা কানেকশন কনফিগার করুন)।

রাউট করার পরে একটি সরল টেস্ট দিয়ে যাচাই করুন: একটি পরিচিত ভারি ড্যাশবোর্ড কুয়েরি চালান এবং নিশ্চিত করুন এটি আর প্রাইমারি ডাটাবেস অ্যাক্টিভিটিতে প্রদর্শিত হচ্ছে না।

আপনি যদি AppMaster দিয়ে অ্যাপ তৈরি করেন, এটি সাধারণত রিপোর্টিংয়ের জন্য আলাদা ডাটাবেস কানেকশন সংজ্ঞায়িত করা এবং কেবল ড্যাশবোর্ড এন্ডপয়েন্টগুলোর জন্য ব্যবহার করার মানে দাঁড়ায়, যাতে চেকআউট ও অন্যান্য ট্রানজেকশনাল ফ্লো আলাদা দ্রুত পথ রাখে।

রিপোর্টিং ব্যবহারকারীদের জন্য অ্যাক্সেস কন্ট্রোল ও সুরক্ষা

রিপ্লিকা ড্যাশবোর্ডের জন্য দুর্দান্ত, কিন্তু এটাতেও নিরাপত্তা প্রয়োজন। এটিকে একটি শেয়ার্ড রিসোর্স হিসেবে বিবেচনা করুন: রিপোর্টিং টুলগুলোকে তাদের কাজ করার জন্য যথেষ্ট অ্যাক্সেস দিন, এবং একটি খারাপ কুয়েরি কতো ক্ষতি করতে পারে তা সীমিত করুন।

প্রথমে রিপোর্টিংয়ের জন্য আলাদা ডাটাবেস ইউজার দিয়ে শুরু করুন। অ্যাপের প্রধান ক্রেডেনশিয়াল পুনঃব্যবহার করা এড়ান, এমনকি আপনি রেপ্লিকাতে পয়েন্ট করলেও। এটি অ্যাক্টিভিটি অডিট করা, পাসওয়ার্ড রটেশন এবং প্রিভিলেজ সীমিত রাখা সহজ করে।

বেশিরভাগ দলের জন্য একটি সরল পন্থা:

-- Create a dedicated login
CREATE ROLE report_user LOGIN PASSWORD '...';

-- Allow read-only access to a schema
GRANT CONNECT ON DATABASE yourdb TO report_user;
GRANT USAGE ON SCHEMA public TO report_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO report_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO report_user;

-- Put safety limits on the role
ALTER ROLE report_user SET statement_timeout = '30s';
ALTER ROLE report_user SET idle_in_transaction_session_timeout = '15s';

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

একটি ব্যবহারিক চেকলিস্ট:

• একটি রিড-ওনলি ইউজার ব্যবহার করুন (কোনো INSERT/UPDATE/DELETE না, স্কিমা পরিবর্তন না)।
• লং কুয়েরি ও আইডল সেশন প্রতিরোধে প্রতিটি রোলের জন্য টাইমআউট সেট করুন।
• রিপোর্টিং ইউজারদের জন্য সর্বোচ্চ কনেকশন সীমা নির্ধারণ করুন।
• শুধুমাত্র প্রয়োজনীয় স্কিমা ও টেবিলগুলোর অ্যাক্সেস দিন।
• সংবেদনশীল কলাম (PII, সিক্রেট, টোকেন) মাস্ক বা বাদ দিন রিপোর্টিং ভিউ-তে।

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

এই নিয়ন্ত্রণগুলো PostgreSQL রিড রেপ্লিকাগুলোকে দ্রুত, পূর্বানুমেয় এবং অপব্যবহারের জন্য কঠিন করে তোলে।

মনিটরিং যা আপনার ড্যাশবোর্ডকে অপ্রত্যাশিততায় থেকে রক্ষা করে

একটি রেপ্লিকা কেবল তখনই সহায়ক যদি এটি পূর্বানুমেয়ভাবে আচরণ করে। দুটি জিনিস যা সাধারণত দলগুলোকে অপ্রত্যাশিতভাবে überras করে হচ্ছে: নীরব রেপ্লিকেশন ল্যাগ (ড্যাশবোর্ড "ভুল" দেখায়) এবং রেপ্লিকায় রিসোর্স স্পাইক (ড্যাশবোর্ড ধীর হয়)। মনিটরিং উভয়কেই ব্যবহারকারীর আগে ধরতে পারে।

শুরুতেই ল্যাগ পরিমাপ করুন এবং আপনার ব্যবসার জন্য "প suficient তাজা" মানে কী তা নির্ধারণ করুন। অনেক রিপোর্টিং ড্যাশবোর্ডের জন্য 30 থেকে 120 সেকেন্ডই ঠিক থাকে। অন্যগুলোর জন্য (যেমন ইনভেন্টরি বা প্রতারণা) এমনকি 5 সেকেন্ডও বেশি হতে পারে। যা নির্বাচন করুন, সেটিকে দৃশ্যমান একটি সংখ্যা রাখুন এবং সেটি অতিক্রম করলে অ্যালার্ট করুন।

PostgreSQL রিপোর্টিং রেপ্লিকাগুলোর জন্য কিছু ব্যবহারিক সিগন্যাল:

• রেপ্লিকেশন ল্যাগ (সময় ও বাইট)। আপনার থ্রেশহোল্ড অতিক্রম করলে কয়েক মিনিট ধরে অ্যালার্ট করুন, কেবল একটি স্পাইক নয়।
• রেপ্লিকা হেলথ: প্রতি-পিক রিপোর্টিং সময় CPU, মেমরি প্রেসার, এবং ডিস্ক রিড I/O।
• রেপ্লিকায় কনেকশন স্যাচুরেশন (অনেক ড্যাশবোর্ড সেশন ডাটাবেসকে ধীর করে দিতে পারে)।
• রেপ্লিকায় ধীর কুয়েরি, রেপ্লিকার নিজের স্ট্যাটস ও লগ ব্যবহার করে (প্রাইমারি সম্পূর্ণ গল্প বলে না)।
• অটোভ্যাকুয়াম ও টেবিল/ইনডেক্স বুলেটন; টেবিল বা ইনডেক্স ব্লোট হলে রিডও ধীর হতে পারে।

ধীর-কুয়েরি ট্র্যাকিংকে বিশেষ মনোযোগ দিন। একটি সাধারণ ব্যর্থতা হচ্ছে: একটি ড্যাশবোর্ড পরীক্ষায় ঠিক ছিল কিন্তু প্রোডাকশনে "পুরো টেবিল স্ক্যান উৎসব" হয়ে ওঠে। নিশ্চিত করুন রেপ্লিকায় এমন একই মনিটরিং আছে যা আপনি প্রাইমারিতে করেন, যেমন মোট সময় এবং গড় সময় অনুযায়ী শীর্ষ কুয়েরি।

শেষে, আগে থেকেই নির্ধারণ করুন আপনার অ্যাপ কী করবে যখন রেপ্লিকা অনুপলব্ধ বা খুব পিছিয়ে যাবে। একটি আচরণ বেছে নিন এবং ধারাবাহিকভাবে তা প্রয়োগ করুন:

• ল্যাগ থ্রেশহোল্ড অতিক্রম করলে "ডেটা বিলম্বিত" ব্যানার দেখান।
• সাময়িকভাবে সবচেয়ে ভারী চার্টগুলো অক্ষম করুন এবং হালকা সারাংশ দেখান।
• নির্দিষ্ট উইন্ডোর জন্য ক্যাশ করা ফলাফলে fallback করুন (উদাহরণ: সর্বশেষ 15 মিনিট)।
• নির্দিষ্ট পৃষ্ঠার জন্য ক্রিটিকাল রিডগুলো প্রাইমারিতে ফিরিয়ে দিন।
• রেপ্লিকা পুনরুদ্ধার না হওয়া পর্যন্ত ড্যাশবোর্ডকে রিড-ওনলি মেন্টেন্যান্স মোডে রাখুন।

আপনি যদি AppMaster-এ অভ্যন্তরীণ ড্যাশবোর্ড তৈরি করেন, রেপ্লিকাকে আলাদা ডেটা সোর্স হিসেবে গ্রহণ করুন: আলাদা করে মনিটর করুন, এবং freshness বা পারফরম্যান্স কমে গেলে ড্যাশবোর্ডকে সুন্দরভাবে degrade করার মতো ডিজাইন করুন।

সাধারণ ভুল ও ফাঁদ যা এড়িয়ে চলবেন

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

একটি সহজ মিস: রেপ্লিকাও ওভারলোড হতে পারে। কিছু বিস্তৃত টেবিল স্ক্যান, ভারি JOIN, বা "SELECT *" এক্সপোর্ট CPU ও ডিস্ককে কড়া চাপ দিতে পারে এবং টাইমআউট ঘটাতে পারে। যদি রেপ্লিকা প্রাইমারির চেয়ে ছোট হার্ডওয়্যারে থাকে (সাশ্রয়ী করার জন্য সাধারণ), তবে ধীরতা আরও দ্রুত দেখা যাবে।

যেই ফাঁদগুলো সবচেয়ে বেশি ব্যথা দেয়:

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

একটি বাস্তবধর্মী উদাহরণ: আপনার BI টুল প্রতি মিনিটে "আজকের অর্ডার" পেজ রিফ্রেশ করে। যদি প্রতিটি রিফ্রেশে পাঁচটি ভারি কুয়েরি চলে এবং ২০ জন তা খোলে, সেটি মিনিটে ১০০ ভারি কুয়েরি বর্ধিত করে। প্রাইমারি সুরক্ষিত থাকতে পারে, কিন্তু রেপ্লিকা এখনও নতম করতে পারে।

আপনি যদি AppMaster-এ আভ্যন্তরীণ ড্যাশবোর্ড তৈরি করেন, রিপোর্টিং ডাটাবেসকে আলাদা লক্ষ্য হিসেবে বিবেচনা করুন যার নিজস্ব কনেকশন সীমা ও "পছন্দনীয় freshness" নিয়ম রয়েছে, যাতে ব্যবহারকারীরা দুর্ঘটনাক্রমে ল্যাগিং ডাটার উপর নির্ভর না করে।

ডিজাইন প্যাটার্ন যা রেপ্লিকায় রিপোর্টিংকে দ্রুত করে

রিপ্লিকা আপনাকে প্রশ্বাস দেয়, কিন্তু এটি স্বয়ংক্রিয়ভাবে প্রতিটি ড্যাশবোর্ডকে দ্রুত করে না। সেরা ফল আসে যখন আপনি রিপোর্টিং কুয়েরিগুলোকে এমনভাবে গঠন করেন যাতে তারা কম কাজ করে এবং বেশি পূর্বানুমেয় হয়। এই প্যাটার্নগুলো PostgreSQL রিড রেপ্লিকাগুলোর জন্য ভাল কাজ করে কারণ সেগুলো ভারি স্ক্যান ও পুনরাবৃত্তি অ্যাগ্রিগেশন কমায়।

রিপোর্টিং লেয়ার আলাদা করুন

একটি ডেডিকেটেড রিপোর্টিং স্কিমা (উদাহরণ: reporting) বিবেচনা করুন যাতে স্থির ভিউ ও হেল্পার টেবিল থাকে। এটি BI টুল ও ড্যাশবোর্ডগুলোকে কাঁচা ট্রানজেকশনাল টেবিল সরাসরি আঘাত করা থেকে বিরত রাখে, এবং অপ্টিমাইজ করার একটি একক স্থান দেয়। একটি ভালো রিপোর্টিং ভিউ বিশৃঙ্খল JOIN গুলো লুকিয়ে দেয় যাতে ড্যাশবোর্ড কুয়েরি সহজ থাকে।

ব্যয়বহুল জিনিসগুলো প্রি-অ্যাগ্রেগেট করুন

যদি একটি ড্যাশবোর্ড সারাদিন একই মোটগুলো বারবার গণনা করে (দৈনিক আয়, স্ট্যাটাস অনুযায়ী অর্ডার), প্রতিটি পেজ লোডে শূন্য থেকে হিসাব করা বন্ধ করুন। সারাংশ টেবিল বা materialized view বানান যা ইতোমধ্যে গ্রুপ করা সংখ্যাগুলো সংরক্ষণ করে।

সাধারণ পছন্দগুলো:

• দৈনিক বা ঘন্টার রোলআপ (তারিখ, অঞ্চল, চ্যানেল অনুযায়ী)
• "সর্বশেষ জানা" স্ন্যাপশট টেবিল (ইনভেন্টরি, অ্যাকাউন্ট ব্যালান্স)
• টপ-এন টেবিল (শীর্ষ পণ্য, শীর্ষ গ্রাহক)
• ফ্যাক্ট টেবিলগুলিতে ডিনরমালাইজড কলাম দ্রুত ফিল্টারিংয়ের জন্য

ভারী মেট্রিকগুলো শিডিউল করে রিফ্রেশ করুন

প্রি-অ্যাগ্রিগেশনগুলো শিডিউলড জবে রিফ্রেশ করুন, আদর্শভাবে অফ-পিক সময়ে। যদি বিজনেস ৫ মিনিটে আপডেট নিয়ে থাকতে পারে, আপনি সামান্য বিলম্ব বদলে তুলনামূলকভাবে দ্রুত ড্যাশবোর্ড পাবেন। অনেক বড় ডাটাসেটে ইঙ্ক্রিমেন্টাল আপডেট (শুধুমাত্র গত শেষ রান থেকে নতুন রো) পুরো রিফ্রেশের চেয়ে সস্তা।

বারবার ক্লিক করা জিনিসগুলো ক্যাশ করুন

যদি একই ড্যাশবোর্ড উইজেট বারবার অনুরোধ করা হয়, অ্যাপ লেয়ারে ফলাফলগুলো সংক্ষিপ্ত সময় (৩০ থেকে ১২০ সেকেন্ড) ক্যাশ করুন। উদাহরণস্বরূপ, একটি "আজকের বিক্রয়" টাইল কোম্পানি বা স্টোর অনুযায়ী ক্যাশ করা যেতে পারে। AppMaster-এ এই ধরনের ক্যাশিং API এন্ডপয়েন্টের চারপাশে যোগ করা সহজ।

একটি সরল নিয়ম: একটি কুয়েরি ধীর এবং জনপ্রিয় হলে, তাকে বা প্রি-অ্যাগ্রেগেট করুন, অথবা ক্যাশ করুন, অথবা উভয়ই।

বাস্তবধর্মী উদাহরণ: চেকআউট ধীর না করে সেলস রিপোর্টিং

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

পরিবর্তনের আগে, ড্যাশবোর্ড প্রাইমারি ডাটাবেসে ভারী কুয়েরি চালায়। মাসের শেষের দিকে কেউ "গত ৩০ দিন পণ্য অনুযায়ী" চার্ট খুললে সেটি orders টেবিলের বড় অংশ স্ক্যান করে। চেকআউট ধীর লাগতে শুরু করে কারণ রিপোর্টিং কুয়েরিগুলো একই CPU, মেমরি ও ডিস্ক রিডের জন্য প্রতিদ্বন্দ্বিতা করছে।

ফিক্স সোজা: ড্যাশবোর্ড রিডগুলো রেপ্লিকায় নিয়ে যান। রিপোর্টিংয়ের জন্য PostgreSQL রিড রেপ্লিকা থাকলে প্রাইমারি দ্রুত লেখা চালিয়ে যাবে, আর রেপ্লিকা দীর্ঘ রিডের উত্তর দেবে। ড্যাশবোর্ড প্রাইমারির পরিবর্তে রেপ্লিকা কানেকশন স্ট্রিংকে পয়েন্ট করবে।

টিম স্পষ্ট freshness নিয়মও স্থাপন করে যাতে কেউ নিখুঁত রিয়েল-টাইম আশা না করে:

• ড্যাশবোর্ডে "ডেটা X মিনিট আগে আপডেট" দেখান
• স্বাভাবিক সময়ে ৫ মিনিট পর্যন্ত বিলম্ব অনুমোদন করুন
• যদি ল্যাগ ১০ মিনিট ছাড়িয়ে যায়, ড্যাশবোর্ডকে "ডিলে মোড"-এ নিয়ে গিয়ে সবচেয়ে ভারী চার্টগুলো থামান
• চেকআউট ও অর্ডার আপডেট সবসময় প্রাইমারিতে রাখুন

পরিবর্তনের পরে ফলাফল লক্ষণীয়: রিপোর্ট স্পাইক থাকলেও চেকআউট স্থিতিশীল থাকে, এবং চার্ট দ্রুত লোড হয় কারণ তারা আর ট্রানজেকশনের সঙ্গে লড়াই করছে না।

ব্যবহারকারীদের যা বলা দরকার তা সরল: ড্যাশবোর্ড "নিকটতম-রিয়েল টাইম", কিন্তু শেষ ১০ সেকেন্ডের সোর্স-অফ-ট্রুথ নয়। যদি কেউ রিকনসিলিয়েশনের জন্য সঠিক টোটাল চাই, তারা একটি শিডিউলড এক্সপোর্ট বা ইন্ড-অফ-ডে রিপোর্ট চালাবেন।

আপনি যদি AppMaster-এর মতো প্ল্যাটফর্মে অ্যাপ বানান, দিনের শুরু থেকেই রিপোর্টিংকে একটি আলাদা রিড-ওনলি কানেকশনে ট্রিট করলে আপনার ট্রানজেকশনাল ফ্লোগুলো পূর্বানুমেয় থাকবে।

দ্রুত চেকগুলো ও পরবর্তী পদক্ষেপ

ড্যাশবোর্ডগুলো রেপ্লিকাতে পয়েন্ট করার আগে একটি দ্রুত স্যানিটি-পাস করুন। কয়েকটি ছোট সেটিংস ও অভ্যাস সবচেয়ে সাধারণ অপ্রত্যাশ্যতা প্রতিহত করে: মহামতি সংখ্যা, টাইমআউট, ও দুর্ঘটনাক্রমে লেখা পাঠানো।

এখানে একটি দ্রুত চেকলিস্ট যেটা কনফিগার করা উচিত রেপ্লিকাতে ট্রাফিক পাঠানোর আগে:

• রিপোর্টিং কানেকশনগুলো রিড-ওনলি করুন (অ্যালাদা ইউজার ব্যবহার করুন এবং রিড-ওনলি ট্রানজেকশন জোরদার করুন)।
• রিপোর্টিংকে অ্যাপ ট্রাফিক থেকে আলাদা করুন (এটির নিজস্ব কনেকশন পুল ও যথার্থ কনেকশন সীমা)।
• নিশ্চিত করুন রেপ্লিকায় সেই ইনডেক্সগুলো আছে যেগুলো আপনার ড্যাশবোর্ড ভরসা করে (রেপ্লিকা ইনডেক্স কপি করে, কিন্তু সাম্প্রতিক পরিবর্তন মিস হলে চেক করুন)।
• রিপোর্টিং কুয়েরিগুলোর জন্য স্টেটমেন্ট ও লক টাইমআউট সেট করুন যাতে একটি খারাপ চার্ট সবকিছু hängen না করে।
• নিশ্চিত করুন চার্টগুলো সামান্য বিলম্ব সহ্য করে (প্রয়োজনে "as of" টাইমস্ট্যাম্প দেখান বা মিনিটে রাউন্ড করুন)।

ট্রাফিক প্রবাহ শুরু হলে মনিটরিংকে একটি হালকা সাপ্তাহিক রুটিন হিসেবে ব্যবহার করুন, ফায়ার ড্রিল হিসেবে নয়। এটা বিশেষভাবে গুরুত্বপূর্ণ রিপোর্টিং রেপ্লিকাগুলোর জন্য, যেখানে "কাল ঠিক ছিল" আজ দ্রুত বদলে যেতে পারে যখন ডাটা বাড়ে।

সাপ্তাহিক মনিটরিং চেকলিস্ট (১০ মিনিট):

• রেপ্লিকেশন ল্যাগ: সাধারণ ল্যাগ ও পিক স্পাইক দেখুন।
• ধীর কুয়েরি: মোট সময় অনুযায়ী শীর্ষ অপরাধীদের ট্র্যাক করুন, কেবল একটি ধীর রানের উপর নির্ভর করবেন না।
• কনেকশন: সর্বোচ্চ কনেকশন, পুল স্যাচুরেশন, এবং আইডল কনেকশনের জমা পরীক্ষা করুন।
• ডিস্ক ও CPU: ভারী স্ক্যানের সময় রেপ্লিকাগুলো স্টোরেজে বটলনেক করতে পারে।
• ব্যর্থ কুয়েরি: টাইমআউট, ক্যানসেল করা স্টেটমেন্ট, বা পারমিশন এরর খুঁজুন।

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

আপনি যদি অভ্যন্তরীণ ড্যাশবোর্ড বা অ্যাডমিন টুল বানান, AppMaster প্র্যাকটিক্যাল উপায় হতে পারে দ্রুত শিপ করার জন্য, যখন রিপোর্টিং স্ক্রিনগুলোকে রেপ্লিকায় পয়েন্ট করে যাতে আপনার কোর ট্রানজেকশনাল অ্যাপ মসৃণভাবে চলতে থাকে।