OLTP বনাম রিপোর্টিং স্কিমা: ডেনরমালাইজ করবেন না কী সারসংক্ষেপ টেবিল যোগ করবেন?

কেন OLTP এবং রিপোর্টিং তোমার স্কিমাকে ভিন্ন দিকে টানবে

OLTP (online transaction processing) হলো সেই কাজ যা তোমার অ্যাপ সারাদিন করে: অনেক ছোট ছোট অপারেশন যা দ্রুত এবং নিরাপদ হতে হবে। একটি অর্ডার তৈরি করা, স্ট্যাটাস আপডেট করা, পেমেন্ট যোগ করা, একটি লগ মেসেজ রাখা—এসব। ডাটাবেসটি দ্রুত ইনসার্ট এবং আপডেটের জন্য অপ্টিমাইজ করা থাকে, কড়া নিয়ম (যেমন foreign keys) থাকে, এবং সাধারণত এমন কুয়েরিগুলির জন্য যা কয়েকটি রোই স্পর্শ করে।

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

এটাই মূল টান: যা স্ট্রাকচার লেখাকে পরিষ্কার ও সঠিক রাখে (normalized টেবিল, বহু রিলেশন) তা প্রায়ই অ্যানালিটিক্সে ধীর বা ব্যয়বহুল করে তোলে যখন ডেটা বাড়ে।

একটি একক স্কিমা কখনও কখনও উভয়ের কাজ চালাতে পারে, বিশেষ করে শুরুতে। কিন্তু ডেটা বাড়ার সাথে সাথে তুমি সাধারণত এমন ট্রেডঅফ অনুভব করবে:

• ট্রানজ্যাকশন স্ক্রিন দ্রুত থাকে, কিন্তু ড্যাশবোর্ড মাসে মাসে ধীর হয়ে যায়।
• “একটি সহজ চার্ট” অনেক জয়েন নিয়ে জটিল কুয়েরি হয়ে যায়।
• একই মেট্রিক একাধিক জায়গায় গণনা করা হয় এবং মেলেনা।
• নতুন ফিল্টার যোগ করলে ঝুঁকিপূর্ণ কুয়েরি পরিবর্তন প্রয়োজন হয়।

এই কারণেই টিমগুলো সাধারণত একটি বা একাধিক কৌশল বেছে নেয়: সাধারণ স্লাইসের জন্য নির্দিষ্ট ফিল্ড ডেনরমালাইজ করা, পুনরাবৃত্ত মোটের জন্য summary টেবিল যুক্ত করা, বা রিপোর্টিং ভিউ আলাদা করা (কখনও কখনও আলাদা রিপোর্টিং স্কিমাও) যাতে OLTP পারফর্মেন্স রক্ষা পায় এবং সংখ্যাগুলো সঙ্গত থাকে।

ট্রানজ্যাকশন স্ক্রিন এবং BI স্ক্রিনের মধ্যে কী বদলায়

ট্রানজ্যাকশন স্ক্রিন এবং BI স্ক্রিন একই ব্যাবসায়িক অনুচ্ছেদ দেখাতে পারে, কিন্তু তারা ডাটাবেসকে উল্টোভাবে ব্যবহার করতে বলে। এই টানটাই OLTP বনাম রিপোর্টিং স্কিমা সিদ্ধান্তের মূল।

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

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

কুয়েরি কিভাবে বদলায়

OLTP-তে normalized টেবিল এবং পরিষ্কার সম্পর্ক তোমার পক্ষে কাজ করে। ডেটা কনসিস্টেন্ট থাকে, নকল এড়ায়, এবং একটি সত্য এক জায়গায় আপডেট করা যায়।

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

একটি দ্রুত উপায় পার্থক্য চিহ্নিত করার:

• ট্রানজ্যাকশন স্ক্রিন: অনেক ছোট লেখাপড়া, দ্রুত পয়েন্ট রিড
• BI স্ক্রিন: কম রিকোয়েস্ট, কিন্তু গ্রুপিং ও ফিল্টারসহ ভারি পড়া
• OLTP ডেটা: কনসিস্টেন্সি রক্ষার জন্য normalized
• BI ডেটা: প্রায়শই জয়েন ও স্ক্যান কমাতে রূপান্তরিত

তালতলি ও ফ্রেশনেস

OLTP-তে উচ্চ concurrency দরকার আপডেটের জন্য। দীর্ঘ চলমান রিপোর্টিং কুয়েরি এই আপডেটগুলিকে ব্লক বা ধীর করতে পারে, বিশেষ করে যখন সেগুলো বড় রেঞ্জ স্ক্যান করে।

ফ্রেশনেসের প্রত্যাশাও বদলে যায়। কিছু ড্যাশবোর্ড প্রায় রিয়েল-টাইম হতে হবে (সাপোর্ট কিউ), অন্যগুলো ঘণ্টা বা দৈনিক ঠিক আছে (ফাইন্যান্স, পারফরম্যান্স)। যদি তুমি শিডিউলে রিফ্রেশ করতে পারো, তাহলে summary টেবিল, materialized view, বা আলাদা রিপোর্টিং স্কিমা ব্যবহার করার স্বাধীনতা বাড়ে।

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

রিপোর্টিং-এর জন্য অ্যাডজাস্ট করার সিগন্যালগুলো

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

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

সর্বাধিক সাধারণ সিগন্যালগুলো:

• একটি প্রশ্নের উত্তর দিতে বহু টেবিল জয়েন লাগে।
• একই হিসাব (revenue, active users, average handle time) বহু চার্টে পুনরাবৃত্তি হয়।
• মানুষ একই টোটালগুলো দিন/সপ্তাহ/মাস অনুযায়ী বারবার চাইছে, এবং প্রতিটি রিকোয়েস্ট ভারি কুয়েরি চালায়।
• BI কুয়েরি ধীরে যায় বা টাইমআউট করে যখন রেগুলার ইউজাররা রেকর্ড তৈরি বা এডিট করে।
• ডাটাবেস CPU স্থিরভাবে বাড়ে যখন OLTP ট্রাফিক ও লেখার ভলিউম স্থির থাকে।

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

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

কখন ডেনরমালাইজ করা ঠিক সিদ্ধান্ত

ডেনরমালাইজেশন তখনই যুক্তিসংগত যখন তোমার রিপোর্টিং চাহিদা পূর্বানুমেয়। যদি একই কয়েকটা ড্যাশবোর্ড প্রশ্ন প্রতি সপ্তাহে উঠে এবং সেগুলো খুব কম বদলায়, তাহলে ডেটাকে সেই প্রশ্নগুলোর জন্য রূপান্তর করা যায্য—বরং প্রতিটি চার্টকে অনেক টেবিল থেকে উত্তর জোড়া করতে বাধ্য করার চেয়ে।

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

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

ভাল প্রার্থী হল এমন ফিল্ডগুলো যা:

• ড্যাশবোর্ডে বারবার পড়া হয় কিন্তু খুব কম এডিট করা হয় (customer name, product category)
• বারবার জয়েন করা ব্যয়বহুল (many-to-many সম্পর্ক, গভীর চেইন)
• দ্রুত ফিল্টার এবং গ্রুপিংয়ের জন্য প্রয়োজন (region, team, plan tier)
• ভ্যালিডেট করা সহজ (trusted table থেকে কপি, ফ্রি টেক্সট নয়)

মালিকানা গুরুত্বপূর্ণ। কেউ (বা কোনো জব) নকলগুলো সঙ্গত রাখতে দায়িত্বশীল হতে হবে, এবং সোর্স বদলে গেলে কি হবে তার স্পষ্ট নিয়ম থাকতে হবে।

উদাহরণ: একটি সেলস ড্যাশবোর্ড অর্ডারগুলো সেলস রেপ এবং অঞ্চলে গ্রুপ করে। Orders -> Customers -> Regions প্রতিবার জয়েন করার বদলে, তুমি order তৈরির সময় region_id অর্ডারে রাখতে পারো। যদি পরে কাস্টমার অঞ্চল বদলায়, তোমার নিয়ম হতে পারে “ঐতিহাসিক অর্ডারগুলি মূল অঞ্চল রাখবে” বা “প্রতিদিন রাতে পুরনো অর্ডার ব্যাকফিল করা হবে।” একটি নিয়ম চয়ন করে ডকুমেন্ট করো এবং বাস্তবায়ন করো।

যদি তুমি AppMaster এবং PostgreSQL ব্যবহার করো, এই ধরনের ডেনরমালাইজড ফিল্ড Data Designer-এ সহজে মডেল করা যায়, যতক্ষণ তুমি কে তা লেখতে পারবে তা নিয়ন্ত্রণ করো এবং কনসিস্টেন্টভাবে আপডেট করো।

ডেনরমালাইজেশনের ফাঁদগুলো যা এড়াতে হবে

ডেনরমালাইজেশন BI স্ক্রিনকে দ্রুত করতে পারে, কিন্তু এটি সহজেই “দুইটি সত্য” তৈরি করে। সবচেয়ে সাধারণ ব্যর্থতা হল একই তথ্য বহু জায়গায় পুনরাবৃত্তি করা, কিন্তু কোন ক্ষেত্র জেতে তা স্পষ্ট না থাকা। যদি তুমি order_total এবং line items দুটোই স্টোর করো, তাহলে তোমাকে একটি নিয়ম রাখতে হবে যে order_total ক্যালকুল করা হয়, ব্যবহারকারী প্রবেশ করেছে, না কি payment provider থেকে কপি।

আরেকটি ফাঁদ হল এমন ফিল্ডগুলো ডেনরমালাইজ করা যা প্রায়শই বদলে—customer status, account owner, product category, region assignments ইত্যাদি। যদি আপনি convenience-র নামে এগুলো অনেক টেবিলে কপি করে রাখো, প্রতিটি পরিবর্তন একটি ক্লিনআপ জব হয়ে যায় এবং মিস হওয়া আপডেটগুলো ভুল ড্যাশবোর্ড স্লাইস হিসেবে দেখা দেয়।

OLTP পথেই খুব বিস্তৃত টেবিল থাকা সাবধানতার বিষয়। একই টেবিলে অনেক ডেনরমালাইজড কোলাম যোগ করা লেখাকে ধীর করতে পারে, লক সময় বাড়ায়, এবং সহজ আপডেটকে ভারী করে তোলে। এটি বিশেষত কষ্টদায়ক যখন তোমার কাছে events, order lines, বা support messages মত উচ্চ ভলিউম টেবিল থাকে।

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

একটি বাস্তব উদাহরণ: তুমি একটি “Sales by Rep” ড্যাশবোর্ড বানালে এবং প্রতিটি order-এ rep_name যোগ করলে—কোনও রেপের নাম বদলে গেলে বা পুনরায় নিয়োগ হলে গত কোয়ার্টারের সংখ্যা দুটি নামের মধ্যে বিভক্ত হয়ে যাবে। যদি তুমি নাম সত্যিই ডিসপ্লে করতে চাও, তাহলে একটি স্থায়ী rep_id রাখা বিবেচনা করো এবং রিপোর্টিং ভিউতে নাম রেজল্ভ করো, অথবা ইচ্ছাকৃতভাবে নাম স্ন্যাপশট হিসেবে rep_name_at_sale হিসেবে স্টোর করো।

ডেনরমালাইজ করার আগে এই মৌলিকগুলো নিশ্চিত করো:

• প্রতিটি পুনরাবৃত্ত মানের জন্য সত্যের সোর্স নির্ধারণ করে লিখে রাখো।
• পরিবর্তনশীল টেক্সট ফিল্ডের ওপর নয়, স্থিতিশীল ID ব্যবহার করো।
• সিদ্ধান্ত নাও তুমি current-state রিপোর্টিং চাও না point-in-time snapshot।
• একটি পরিষ্কার রক্ষণাবেক্ষণ মেকানিজম যোগ করো (trigger, job, বা workflow step) এবং একটি মালিক নির্ধারণ করো।
• মিল না হওয়ার ক্ষেত্রে পর্যবেক্ষণ যোগ করো (সহজ reconciliation কুয়েরি) যাতে ত্রুটি দ্রুত দেখা যায়।

যদি তুমি AppMaster এবং PostgreSQL ব্যবহার করো, মেইনটেন্যান্স Business Process স্টেপের সাথে টাই করা ভাল যাতে আপডেটগুলো ধারাবাহিকভাবে ঘটে, “যখন কেউ মনে করে” নয়।

কখন summary বা aggregate টেবিল যোগ করা উচিত

Summary টেবিল তখনই যুক্তিসংগত যখন BI-স্টাইল স্ক্রিনগুলো একই টোটালগুলো বারবার চায়: দৈনিক সাইনআপ, প্ল্যান অনুযায়ী আয়, সক্রিয় ব্যবহারকারী, রিফান্ড, ক্লোজড টিকিট—এমন KPI-গুলো।

একটি সুস্পষ্ট সিগন্যাল হলো পুনরাবৃত্তি। যদি বহু ড্যাশবোর্ড কার্ড প্রায় একই GROUP BY কুয়েরি চালায়, তোমার ডাটাবেস বারবার একই কাজ করে। এটা 1,000 রোতে ঠিক থাকতে পারে কিন্তু 10 মিলিয়নে কষ্টদায়ক হয়। OLTP বনাম রিপোর্টিং স্কিমা আলোচনা প্রায়ই তখনই পৌঁছায় যখন তুমি ইনডেক্স ছেঁকে বারবার চেষ্টা করা বন্ধ করে প্রি-কম্পিউট করা শুরু করো।

তুমি summary টেবিল তখনই যোগ করো যখন তুমি দৃঢ়গতির গতি চাই। চার্টগুলো সেকেন্ডে লোড হওয়া উচিত, কখনও কখনও দ্রুত নয়। একটি summary টেবিল ব্যয়বহুল স্ক্যানকে ছোট লুকআপে বদলে দেয়।

প্র típico ট্রিগারগুলো:

• তোমার ড্যাশবোর্ড একই GROUP BY বহু স্ক্রিনে বা ফিল্টারে পুনরাবৃত্তি করে।
• তুমি প্রায়ই সময়ের বাকেট (দৈনিক/সাপ্তাহিক/মাসিক) এবং টপ-এন তালিকা কুয়েরি করো।
• বেস টেবিলগুলো append-heavy (events, transactions, logs)।
• স্টেকহোল্ডাররা একটি নির্দিষ্ট কাটঅফে স্থিতিশীল KPI সংখ্যা প্রত্যাশা করে (উদাহরণ: "midnight অনুযায়ী")।

রিফ্রেশ স্ট্র্যাটেজিও সিদ্ধান্তের অপর অংশ। কয়েকটি ব্যবহারিক অপশন আছে, নির্ভর করে সংখ্যাগুলি কতটা ফ্রেশ হতে হবে:

• নির্ধারিত রিফ্রেশ (প্রতি 5 মিনিট, ঘণ্টায়, বা রাত্রীকালীন) ভবন-ওয়ার্কলোড পূর্বানুমেয় করে।
• ইভেন্ট-ভিত্তিক রিফ্রেশ মূল ক্রিয়ার পরে (নতুন অর্ডার, সাবস্ক্রিপশন পরিবর্তন) যখন নিকট-রিয়েল-টাইম দরকার।
• হাইব্রিড: নির্ধারিত ব্যাকফিল প্লাস ছোট ইনক্রিমেন্টাল আপডেট।

টেবিলকে ফোকাসড এবং সরল রাখো: গ্রেইন স্পষ্ট হওয়া উচিত (উদাহরণ: প্রতিদিন প্রতি প্ল্যান এক রো), এবং কলামগুলো হলো যেসব মেট্রিক চার্ট পড়ে। যদি তুমি AppMaster-এ তৈরি করো, একচ্ছত্র ফিট হলো: aggregates PostgreSQL-এ স্টোর করো এবং Business Process দিয়ে সেগুলো রিফ্রেশ করো শিডিউলে বা ইভেন্টে।

ধাপে ধাপে summary টেবিল ডিজাইন করা

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

1) প্রথমে গ্রেইন ঠিক করো

শুরু করার আগে ঠিক করো একটি রো কী বোঝাবে। যদি তুমি এটা ভুল করো, পরবর্তীতে প্রতিটি মেট্রিক ব্যাখ্যা করা কঠিন হয়ে পড়ে। সাধারণ গ্রেইনগুলো: per day per customer, per order, বা per agent per day।

একটি সহজ পরীক্ষা: একটি একক রো কি অনিশ্চয়তা ছাড়া অনন্যভাবে শনাক্ত করা যায়? যদি না, গ্রেইন অস্পষ্ট।

2) কুয়েরিগুলোর চারপাশে টেবিল ডিজাইন করো, কাঁচা ডেটার চারপাশে নয়

তোমার BI স্ক্রীনগুলো আসলেই কোন সংখ্যাগুলো প্রদর্শন করে তা বাছো। দরকারি মাত্রই স্টোর করো: sums এবং counts সাধারণত সবচেয়ে দরকারী, min/max যখন রেঞ্জ দরকার। যদি “unique customers” দেখাতে হয়, সিদ্ধান্ত নাও তুমি সঠিক distinct count চাও (ভারী) না approximation (হালকা), এবং সেই পছন্দ স্পষ্টভাবে ডকুমেন্ট করো।

প্রায়োগিক ধাপগুলো:

• 5-10 টি ড্যাশবোর্ড প্রশ্ন লিখো (উদাহরণ: “sales per agent per day”)
• বেশিরভাগ প্রশ্ন এক রোতেই উত্তর দেওয়ার গ্রেইন বেছে নাও
• কলামগুলো কেবল aggregated মান রাখো (sum, count, min, max, সম্ভব হলে distinct)
• date, agent_id, customer_id মত ফিল্টার ম্যাচ করে কীগুলো এবং ইনডেক্স যোগ করো
• লেট-আরাইভিং পরিবর্তন (রিফান্ড, এডিট, ক্যানসেল) কিভাবে হ্যান্ডেল করবে তা নির্ধারণ করো

3) এমন একটি রিফ্রেশ পদ্ধতি বেছে নাও যা তুমি বিশ্বাস করতে পারো

ব্যাচ রিফ্রেশ ব্যাখ্যা করা সহজ (রাত্রীকালীন, ঘণ্টায়)। ইনক্রিমেন্টাল দ্রুত কিন্তু “কি বদলেছে” লজিক প্রয়োজন। ট্রিগার-স্টাইল আপডেট নিকট-রিয়েল-টাইম দিতে পারে, কিন্তু যদি নিয়ন্ত্রিত না করা হয় তাহলে লেখার পারফর্মেন্সের উপর ঝুঁকি বাড়ে।

AppMaster-এ নির্মাণ করলে একটি সাধারণ প্যাটার্ন হলো একটি নির্ধারিত জব যা একটি Business Process চালায় যা গতকাল এবং আজ পুনঃগণনা করে, যখন পুরনো দিনগুলো স্থির রাখা হয়।

4) মিল তদারকি চেক যোগ করো

Summary টেবিলে নির্ভর করার আগে কয়েকটি বেসিক চেক যোগ করো যা এটিকে রাউ টেবিলের সাথে তুলনা করে:

• একটি তারিখ রেঞ্জের জন্য টোটালস গ্রহণযোগ্য সহনশীলতার মধ্যে মেলে কিনা
• একই ফিল্টারের জন্য কाउंटস (orders, users, tickets) মেলে কিনা
• কয়েকটি এন্ড-টু-এন্ড স্পট-চেক (একজন এজেন্ট, এক কাস্টমার) করা
• গ্যাপ (মিসিং দিন) এবং ডুপলিকেট (একই কী বারবার) সনাক্ত করা

যদি চেকগুলো ফেল করে, লজিক ঠিক না করা পর্যন্ত আরো মেট্রিক যোগ কোরো না। একটি দ্রুত কিন্তু ভুল ড্যাশবোর্ড ধীরটির চেয়েও খারাপ।

আলাদা রিপোর্টিং ভিউ এবং স্কিমা: তারা কি সমাধান করে

তোমার OLTP টেবিলগুলো পরিষ্কার রাখা মূলত সঠিকতার ব্যাপার। তুমি দৃঢ় নিয়ম, শক্ত কন্সট্রেইন্ট, এবং এমন একটি স্ট্রাকচার চাও যা খারাপ ডেটা তৈরি করা কঠিন করে। রিপোর্টিং স্ক্রিনগুলো অন্য কিছু চায়: কম জয়েন, বন্ধুত্বপূর্ণ নাম, এবং মেট্রিকগুলো যা সরাসরি পড়ার জন্য প্রস্তুত। এই অমিলেই টিমগুলো প্রায়ই একটি রিপোর্টিং লেয়ার যোগ করে কোর টেবিল পরিবর্তন না করে সমস্যা সমাধান করে।

একটি রিপোর্টিং ভিউ (বা আলাদা রিপোর্টিং স্কিমা) অনুবাদ লেয়ারের মতো কাজ করে। তোমার অ্যাপ normalized টেবিলে লেখা চালায়, আর BI-স্টাইল স্ক্রিনগুলো এমন অবজেক্ট থেকে পড়ে যেগুলো “by month”, “by region” বা “top 10 products” মত প্রশ্নের জন্য ডিজাইন করা। এটি সাধারণত OLTP বনাম রিপোর্টিং স্কিমা টান কমাতে সহজ উপায়।

ভিউ বনাম materialized কপি

লজিক্যাল ভিউগুলি দুর্দান্ত যখন ডেটা পরিমাণ মাঝারি এবং কুয়েরি পূর্বানুমেয় থাকে। তারা একটি সোর্স অফ ট্রুথ রাখে এবং ড্যাশবোর্ড কুয়েরিগুলিতে লজিক পুনরাবৃত্তি কমায়।

Materialized কপি (materialized views, summary টেবিল, বা রেপ্লিকেটেড টেবিল) তখন sinnvoll যখন রিপোর্টিং লোড ভারি, ক্যালকুলেশন ব্যয়বহুল, বা পিক ঘণ্টায় স্থিতিশীল পারফর্মেন্স দরকার।

পছন্দ করার দ্রুত নিয়ম:

• পাঠযোগ্যতা এবং নির্দিষ্ট সংজ্ঞার জন্য logical views ব্যবহার করো।
• ড্যাশবোর্ড ধীর হলে বা কোর লেখার সঙ্গে প্রতিযোগিতা করলে materialized copies ব্যবহার করো।
• ক্লিয়ার বাউন্ডারি ও মালিকানার জন্য আলাদা রিপোর্টিং স্কিমা ব্যবহার করো।
• রিপোর্টিং ওয়ার্কলোড লেখার ল্যাটেন্সি প্রভাবিত করলে রেপ্লিকা বা আলাদা ডাটাবেস ব্যবহার করো।

যখন রিপোর্টিং লেখার সঙ্গে প্রতিযোগিতা করে

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

উদাহরণ: সাপোর্ট টিমের একটি ড্যাশবোর্ড প্রতি কয়েক সেকেন্ডে “open tickets by SLA status” দেখায়। OLTP সিস্টেম সারাক্ষণ টিকিট আপডেট করে। রিপোর্টিং ভিউ বা প্রিকম্পিউটেড স্ট্যাটাস কাউন্টকে একটি রেপ্লিকায় রাখা ড্যাশবোর্ডকে দ্রুত রাখে এবং টিকিট আপডেট ধীর করে না। AppMaster প্রজেক্টগুলোতেও এই প্যাটার্ন ভালো কাজ করে: ট্রানজ্যাকশনাল ডেটা মডেল পরিষ্কার রাখা এবং রিপোর্টিং-ফ্রেন্ডলি অবজেক্ট ড্যাশবোর্ড স্ক্রীনগুলিকে প্রদান করা।

একটি বাস্তবসম্মত উদাহরণ: সেলস পারফরম্যান্স ড্যাশবোর্ড বানানো

ব্যবসা চায় একটি Sales ড্যাশবোর্ড যা দৈনিক আয়, দৈনিক রিফান্ড, এবং গত 30 দিনের জন্য “top products” তালিকা দেখায়। ট্রানজ্যাকশন স্ক্রিনে OLTP ডাটাবেস normalized: orders, payments, refunds, এবং line items আলাদা টেবিলে আছে। এটা আপডেট ও সঠিকতার জন্য চমৎকার, কিন্তু ড্যাশবোর্ডকে অনেক রো স্ক্যান, জয়েন করে, তারপর দৈনিক গ্রুপিং করতে হবে।

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

অপশন A: দ্রুত ফিল্টারিংয়ের জন্য ডেনরমালাইজ

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

ভালো প্রার্থী হল প্রোডাক্ট ক্যাটাগরি বা সেলস রিজিয়ন—যে সময়ের ক্রয়ের সময় সাধারণত বদলে না। সোর্স অব ট্রুথ normalized টেবিলে রাখো, কিন্তু BI-স্টাইল স্ক্রিনগুলো দ্রুত করার জন্য query-friendly কপি রাখো।

অপশন B: চার্ট এবং র‍্যাংকিংয়ের জন্য দৈনিক summary টেবিল

যদি ড্যাশবোর্ড চার্ট ও টপ লিস্টে ভারি হয়, summary টেবিল সাধারণত জয়ী। একটি দৈনিক fact টেবিল তৈরি করো যেমন daily_sales যার কলাম হতে পারে date, gross_revenue, refunds, net_revenue, orders_count। “top products” এর জন্য একটি daily_product_sales টেবিল যোগ করো যা date এবং product_id দ্বারা কী করা।

নার্স ও খরচ কিভাবে বদলে অপরিবর্তনীয় করে বেছে নেওয়া প্রয়োজন:

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

AppMaster-এর মত টুলে এটিকে ক্লিয়ার কাটে ট্রানজ্যাকশনাল মডেল + একটি নির্ধারিত প্রসেসের মাধ্যমে summary টেবিল ভরাট হিসেবে প্রতিচ্ছবি করা যায়।

ধীর ড্যাশবোর্ড এবং ভুল সংখ্যার সাধারণ ভুলসমূহ

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

আরেকটি নিঃশব্দ সমস্যা হলো একটি “ভালো” রিপোর্টিং ভিউ যা ব্যয়বহুল কাজ লুকিয়ে রাখে। ভিউ একটি কুয়েরিকে সহজ দেখাতে পারে, কিন্তু ডাটাবেস প্রতিবারই জয়েন, ফিল্টার, এবং ক্যালকুলেশন চালায়। সপ্তাহ পরে কেউ আর একটি জয়েন যোগ করলে ড্যাশবোর্ড রাতারাতি ধীর হয়ে যায়—ভিউ কাজের পরিমাণ বাড়ায় না, কেবল তা লুকায়।

Summary টেবিল গতি দেয়, কিন্তু একটি নতুন ঝুঁকি তৈরি করে: drift। যদি তোমার aggregates নির্ধারিত সময়ে পুনর্নির্মাণ করা হয়, সেগুলো পিছিয়ে পড়তে পারে। ইনক্রিমেন্টাল আপডেটে একটি মিসড জব বা বাগ থাকলে টোটাল ভুল থাকতে পারে দিনগুলো ধরে। এজন্য টিমরা আশ্চর্য হয় যখন “সংখ্যাগুলো মিলছে না” রিপোর্ট এবং ট্রানজ্যাকশনের মধ্যে।

মেট্রিক সংজ্ঞার পরিবর্তন সবচেয়ে বিভ্রান্তি তৈরি করে। “Revenue” শুরুতে paid invoices হিসাবে থাকতে পারে, পরে paid minus refunds হয়ে যায়, তারপর recognized revenue হয়ে যায়। যদি তুমি লজিক পরিবর্তন করে পুরনো ডেটা ওভাররাইট করো, গত মাসের চার্ট বদলে যাবে এবং কেউ ড্যাশবোর্ডে বিশ্বাস রাখবে না।

এখানে ব্যবহারিক গার্ডরেইলস যা অধিকাংশ সমস্যা প্রতিরোধ করে:

• যেখানে সম্ভব, ভারি ড্যাশবোর্ড কুয়েরি এবং write-heavy ট্রানজ্যাকশন পথ আলাদা রাখো (এমনকি যদি সেটা কেবল আলাদা রিপোর্টিং টেবিলই হয়)।
• ভিউকে কোড হিসেবে বিবেচনা করো: পরিবর্তন রিভিউ করো, পারফরম্যান্স টেস্ট করো, এবং ডকুমেন্ট করো কি জয়েন করে।
• summary টেবিলের জন্য freshness চেক যোগ করো (last updated time, row counts, sanity totals) এবং ব্রেক হলে অ্যালার্ট করো।
• মূল মেট্রিকগুলো ভার্সন করো, এবং ঐতিহাসিক রিপোর্টের জন্য পুরনো সংজ্ঞা রাখো।

যদি তুমি AppMaster-এ PostgreSQL ব্যবহার করে BI-স্টাইল স্ক্রিন বানাও, এই নিয়মগুলো আরও গুরুত্বপূর্ণ কারণ দ্রুত iteration সহজ। গতি ভালো, কিন্তু সংখ্যাগুলো সঠিক থাকলেই ভালো।

স্কিমা বদলের আগে দ্রুত চেকলিস্ট

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

পরের ধাপে ম্যাথটিকে স্যানিটি-চেক করো। কোন মেট্রিকগুলো additive (safe to sum) এবং কোনগুলো বিশেষ লজিক চাইবে তা চিহ্ন করো। Revenue, quantity, total calls সাধারণত additive। Conversion rate, average order value, distinct customers নয়। এই এক ধাপই সবচেয়ে সাধারণ রিপোর্টিং ভুল প্রতিরোধ করে: দ্রুত ড্যাশবোর্ড কিন্তু ভুল সংখ্যাগুলো।

এখন প্রতিটি কুয়েরি টাইপ অনুযায়ী ডিজাইন বেছে নাও। OLTP বনাম রিপোর্টিং স্কিমা সিদ্ধান্তে তোমাকে একটি গ্লোবাল উত্তর লাগবে না—প্রতিটি access pattern অনুযায়ী করো:

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

প্রতিটি মেট্রিকের জন্য “ফ্রেশ নাও” কি মানে তা ঠিক করো, তারপর একটি সহজ ভ্যালিডেশন নিয়ম সেট করো। উদাহরণ: “ড্যাশবোর্ডে দৈনিক অর্ডার গণনা ঐ তারিখের অর্ডার টেবিল কন্টের সাথে 0.5% এর মধ্যে মিলতে হবে,” বা “টোটাল রেভেন্যু কেবল পোস্টেড ইনভয়েস স্ট্যাটাসের সাথে মিলবে।”

সবশেষে, মালিকানায় সম্মত হও। কাউকে নাম দাও যিনি স্কিমা পরিবর্তন অনুমোদন করবেন এবং কাউকে মেট্রিক সংজ্ঞার মালিক রাখো। AppMaster-এ কাজ করলে এই সংজ্ঞাগুলো ডেটা মডেল এবং Business Processes-এর পাশে ক্যাপচার করো যাতে একই লজিক সব স্ক্রীন ও রিপোর্টে ব্যবহৃত হয়।

পরবর্তী ধাপ: একটি পথ বেছে নিয়ে নিরাপদে বাস্তবায়ন করো

OLTP বনাম রিপোর্টিং স্কিমা সিদ্ধান্তকে একটি পারফরম্যান্স বাগ হিসেবে আচরণ করো, পুনর্বিন্যাস প্রকল্প হিসেবে নয়। মাপ থেকে শুরু করো। 2-3টা ধীরতম ড্যাশবোর্ড কুয়েরি খুঁজে বের করো, এগুলো কতবার চলে তা নোট করো, এবং তাদের আকৃতি ধরো: বড় জয়েন, সময় ফিল্টার, “টপ N” তালিকা, এবং পুনরাবৃত্ত টোটাল।

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

নিম্নলিখিত নিরাপদ বাস্তবায়ন ফ্লো অনুসরণ করো যা সংখ্যাগুলো বিশ্বাসযোগ্য রাখে:

• ড্যাশবোর্ড লক্ষ্য নির্ধারণ করো (সময় সীমা, গ্রুপিং, রিফ্রেশ চাহিদা) এবং একটি গ্রহণযোগ্যতা মেট্রিক সেট করো (উদাহরণ: লোড 2 সেকেন্ডের মধ্যে)।
• একবারে একটি পরিবর্তন করো (একটি ডেনরমালাইজড ফিল্ড, একটি summary টেবিল, বা একটি রিপোর্টিং ভিউ)।
• একটি নির্ধারিত টেস্ট উইন্ডো (গতকাল, গত 7 দিন, পূর্ণ গত মাস) ব্যবহার করে টোটালস OLTP সোর্সের সাথে যাচাই করো।
• ধীরে ধীরে রোলআউট করো এবং এক পূর্ণ সপ্তাহ পারফরম্যান্স ও সঠিকতা পর্যবেক্ষণ করো।
• “কুয়েরি সময়” এবং “রো কাউন্ট” এর জন্য অ্যালার্ট যোগ করো যাতে সাইলেন্ট drift দ্রুত ধরা পড়ে।

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

এক সপ্তাহের বাস্তব ব্যবহারের পরে সিদ্ধান্ত নাও: দ্রুত ফিক্স কাজ করলে পুনরায় iterate করো। যদি টোটালগুলো এখনও ব্যয়বহুল হয়, summary টেবিলে বিনিয়োগ করো এবং একটি স্পষ্ট রিফ্রেশ প্ল্যান রাখো। যদি রিপোর্টিং গুরুত্বপূর্ণ ও ভারি হয়ে যায়, রিপোর্টিং ওয়ার্কলোডকে আলাদা স্টোরে সরানোর কথা ভাবো, আর OLTP কে দ্রুত, নিরাপদ লেখার দিকে রাখো।