১৪ মে, ২০২৫·8 মিনিট
কেন OLTP এবং OLAP ওয়ার্কলোডগুলো সাধারণত একই ডাটাবেসে থাকে না
একই ডাটাবেসে ট্রানজেকশনাল (OLTP) ও অ্যানালিটিক্যাল (OLAP) কাজ একসঙ্গে রাখলে কেন অ্যাপ ধীর হয়, খরচ বেড়ে, অপারেশন জটিল হয়—এবং বিকল্প কি তা জানুন।
OLTP বনাম OLAP: সরল ভাষায় পার্থক্য
যখন মানুষ “OLTP” এবং “OLAP” বলে, তারা ডাটাবেস ব্যবহারের দুইটি ভিন্ন রকমের বরাত দেয়।
OLTP: ব্যবসা চালানোর ডাটাবেস
OLTP (Online Transaction Processing) হলো সেই ওয়ার্কলোড যা দৈনন্দিন কার্যক্রম দ্রুত এবং সঠিকভাবে সম্পন্ন করে—ভাবুন: “এই পরিবর্তনটি এখনই সংরক্ষণ কর।”
সাধারণ OLTP কাজের উদাহরণ: অর্ডার তৈরি করা, স্টক আপডেট করা, পেমেন্ট রেকর্ড করা, গ্রাহকের ঠিকানা বদলানো। এগুলো সাধারণত ছোট (কয়েকটি সারি), ঘনঘন, এবং মিলিসেকেন্ডে সাড়া দেওয়া দরকার কারণ একজন ব্যবহারকারী বা অন্য কোনো সিস্টেম অপেক্ষা করছে।
OLAP: ব্যবসাকে ব্যাখ্যা করে এমন ডাটাবেস
OLAP (Online Analytical Processing) হলো সেই ওয়ার্কলোড যা বোঝার কাজে লাগে—কী ঘটেছে এবং কেন তা ঘটল। ভাবুন: “বেশি ডেটা স্ক্যান করে সংক্ষেপ কর। ”
সাধারণ OLAP কাজের উদাহরণ: ড্যাশবোর্ড, ট্রেন্ড রিপোর্ট, কোহর্ট বিশ্লেষণ, পূর্বাভাস, এবং “slice-and-dice” প্রশ্নগুলি যেমন: “গত ১৮ মাসে অঞ্চল ও পণ্যের শ্রেণি অনুযায়ী রাজস্ব কিভাবে পরিবর্তিত হয়েছে?” এই কুয়েরিগুলো সাধারণত বহু সারি পড়ে, ভারী অ্যাগ্রিগেশন করে, এবং সেকেন্ড (বা মিনিট) ধরে চললেও ভুল বলা হয় না।
একই ডেটা, ভিন্ন লক্ষ্য—এবং ভিন্ন চাহিদা
মুখ্য ধারণা সহজ: OLTP দ্রুত, কনসিসটেন্ট রাইট ও ছোট রিডের জন্য অপ্টিমাইজ করে, যেখানে OLAP বড় রিড ও জটিল গণনার জন্য অপ্টিমাইজ করে। লক্ষ্যগুলো আলাদা হওয়ায় সেরা ডাটাবেস সেটিং, ইনডেক্স, স্টোরেজ লেআউট, এবং স্কেলিং পন্থাও প্রায়শই আলাদা হয়।
এখানেই লক্ষ্য থাকা দরকার: প্রায়ই নয়, কখনও নয় নয়। কিছু ছোট দলের জন্য একটি ডাটাবেস শেয়ার করা সাময়িকভাবে সম্ভব হতে পারে, বিশেষত যখন ডেটা পরিমাণ কম এবং কুয়েরি শৃঙ্খলাবদ্ধ থাকে। পরে কোনটুকু আগে ভেঙে পড়ে, বিভক্ত করার প্রচলিত প্যাটার্ন, এবং কীভাবে রিপোর্টিং প্রোডাকশনের বাইরে সরানো যায়—এইসব পরের অংশগুলোতে আলোচনা করা হয়েছে।
দ্রুত উদাহরণ
- চেকআউট (OLTP): গ্রাহক "Pay" ক্লিক করে, আপনার অ্যাপ অর্ডার, পেমেন্ট স্ট্যাটাস এবং স্টক আপডেট লিখে।
- রিপোর্টিং ড্যাশবোর্ড (OLAP): ম্যানেজার একটি ড্যাশবোর্ড খুলে হাজার হাজার (বা মিলিয়ন) অর্ডারকে অ্যাগ্রিগেট করে কনভার্সন রেট, অ্যাভারেজ অর্ডার ভ্যালু, এবং সাপ্তাহিক ট্রেন্ড দেখেন।
লক্ষ্য ভিন্ন, সফলতার মেট্রিক ভিন্ন
OLTP এবং OLAP উভয়ই "SQL ব্যবহার করে"—তবুও এগুলো ভিন্ন কাজের জন্য অপ্টিমাইজ করা হয়—এবং সেটাই সফলতা পরিমাপের ধরণে প্রকাশ পায়।
OLTP: গতি, কনকারেন্সি, এবং সঠিকতা
OLTP (ট্রানজেকশনাল) সিস্টেমগুলি দৈনন্দিন অপারেশন চালায়: চেকআউট ফ্লো, অ্যাকাউন্ট আপডেট, রিজার্ভেশন, সাপোর্ট টুল। অগ্রাধিক্যগুলো সরল:
- ছোট রিড/রাইটের দ্রুত রেসপন্স (মিলিসেকেন্ডের মধ্যে)
- অনেক কনকারেন্ট ইউজার যাতে ধীরতা না হয়
- সঠিকতা ও কনসিসটেন্সি, কারণ ভুল ব্যালান্স বা ডুপ্লিকেট অর্ডার বাস্তব ব্যবসায়িক সমস্যা
সাফল্য প্রায়ই ল্যাটেন্সি মেট্রিক দিয়ে মাপা হয়—যেমন p95/p99 রিকোয়েস্ট টাইম, এরর রেট, এবং পিক কনকারেন্সির সময় সিস্টেম কেমন আচরণ করে।
OLAP: স্ক্যান, অ্যাগ্রিগেট, এবং নমনীয়তা
OLAP (অ্যানালিটিক্স) সিস্টেমগুলো জিজ্ঞাসা করে "এই ত্রৈমাসিকে কী বদলেছে?" বা "নতুন প্রাইসিং পরে কোন সেগমেন্ট চর্ন করল?" এই কুয়েরিগুলো সাধারণত:
- বহু ডেটা স্ক্যান করে বহু সারির ওপর
- অ্যাগ্রিগেশন (SUM, COUNT, পারসেন্টাইল) এবং জয়েন করে
- বিশ্লেষকরা অনুসন্ধান করেই প্রশ্ন পরিবর্তন করে বারবার
এখানে সফলতা দেখতে পাওয়া যায় কুয়েরি থ্রুপুট, ইনসাইট পেতে সময়, এবং জটিল কুয়েরি চালানোর ক্ষমতা ছাড়া প্রতিটি রিপোর্ট ম্যানুয়ালি টিউন না করা।
কেন "সবকিছুর জন্য এক সিস্টেম" কখনই সমস্যা করে
যখন আপনি দুই ওয়ার্কলোডকে এক ডাটাবেসে চাপ দেন, আপনি সেটিকে একই সময়ে ছোট, উচ্চ-ভলিউম ট্রানজেকশন এবং বড়, এক্সপ্লোরেটরি স্ক্যান উভয়ের জন্য শ্রেষ্ঠ হতে বলছেন। ফলাফল সাধারণত আপোষ: OLTP অনিশ্চিত লেটেন্সি পায়, OLAP-কে প্রোডাকশন রক্ষা করতে থ্রটল করা হয়, এবং দলগুলো মারামারি শুরু করে কার কুয়েরি "চালানো যাবে"। ভিন্ন লক্ষ্যগুলো আলাদা সফলতার মেট্রিক দাবি করে—আর সাধারণত আলাদা সিস্টেম।
রিসোর্স কনটেনশন: যখন অ্যানালিটিক্স ট্রানজেকশনকে চুরি করে
যখন OLTP (আপনার অ্যাপের দৈনন্দিক ট্রানজেকশন) এবং OLAP (রিপোর্টিং ও বিশ্লেষণ) একই ডাটাবেসে চলে, তারা একই সীমিত রিসোর্স নিয়ে লড়াই করে। ফলাফল কেবল "রিপোর্ট ধীর" নয়—এটি প্রায়ই ধীর চেকআউট, আটকে থাকা লগইন, এবং অনিশ্চিত অ্যাপ হিকে।
CPU ও মেমরি: দীর্ঘ কুয়েরি বনাম ছোট কুয়েরি
অ্যানালিটিক্যাল কুয়েরিগুলো দীর্ঘ-চলমান এবং ভারী হয়: বড় টেবিল জয়েন, অ্যাগ্রিগেশন, সাজানো এবং গ্রুপিং। এগুলো CPU কোর ও মেমরি (হ্যাশ জয়েন, সর্ট বাফার) দখল করে রাখতে পারে।
অন্যদিকে, ট্রানজেকশনাল কুয়েরি সাধারণত ছোট কিন্তু লেটেন্সি-সংবেদনশীল। যদি CPU স্যাচুরেটেড হয় বা মেমরি প্রেসার ফায়ার করায় ফ্রিকোয়েন্ট ইভিকশন ঘটে, তখন ছোট কুয়েরিগুলোরও বড় কুয়েরিগুলোর পিছনে অপেক্ষা করতে হয়—ভিত্তি হিসেবে যেখানে প্রতিটি ট্রানজেকশন মাত্র কয়েক মিলিসেকেন্ড কাজ চায়।
ডিস্ক I/O: বড় স্ক্যান বনাম বহু ছোট রিড/রাইট
অ্যানালিটিক্স প্রায়ই বড় টেবিল স্ক্যান করে এবং অনেক পেজ ধারাবাহিকভাবে পড়ে। OLTP কর্মভারটি সাধারণত বিপরীত: বহু ছোট, র্যান্ডম রিড এবং ইনডেক্স ও লগে ধারাবাহিক রাইট।
দুটি মিলিয়ে দিলে ডাটাবেস স্টোরেজ সাবসিস্টেমকে মিশ্র অ্যাকসেস প্যাটার্নের সাথে সামঞ্জস্য রাখতে হয়। OLTP-তে সাহায্য করা ক্যাশগুলো অ্যানালিটিক্স স্ক্যান দ্বারা "ওয়াশ আউট" হয়ে যেতে পারে, এবং রিপোর্টিংয়ের জন্য ডিস্ক স্ট্রিমিং ব্যস্ত হলে রাইট লেটেন্সি বাড়তে পারে।
কানেকশন পুল চাপ ও কিউয়িং
কিছু বিশ্লেষক বড় কুয়েরি চালালে কয়েক মিনিট পর্যন্ত কানেকশন দখল করতে পারে। যদি আপনার অ্যাপ একটি নির্দিষ্ট সাইজের পুল ব্যবহার করে, অনুরোধগুলো ফ্রি কানেকশনের জন্য কিউতেই দাঁড়ায়। সেই কিউয়িং ইফেক্ট একটি সুস্থ সিস্টেমকেও ভাঙা মনে করায়: গড় লেটেন্সি ঠিক থাকতে পারে, কিন্তু টেইল লেটেন্সি (p95/p99) অস্বস্তিকর হয়ে ওঠে।
ব্যবহারকারীরা আসলে কী লক্ষ্য করে
বাইরোয়, এটি টাইমআউট, ধীর চেকআউট ফ্লো, বিলম্বিত সার্চ রেজাল্ট, এবং সাধারণত ফ্লাকী আচরণ হিসাবে প্রকাশ পায়—প্রায়ই "শুধু রিপোর্ট চালালে" বা "পূজির মাসে" ঘটে। অ্যাপ টিম ত্রুটি দেখে; অ্যানালিটিক্স টিম ধীর কুয়েরি দেখে; কিন্তু সমস্যার আসল কারণ হল শেয়ার্ড কনটেনশন।
ডেটা লেআউট ও ইনডেক্সিং চাহিদা বিপরীত দিকে টেনে নেয়
OLTP এবং OLAP কেবল ডাটাবেস "ভিন্নভাবে ব্যবহার করে" না—তারা শারীরিক ডিজাইনের বিপরীত পুরস্কৃত করে। এক জায়গায় উভয়কে সন্তুষ্ট করার চেষ্টা করলে সাধারণত এমন একটি আপোষ দাঁড়ায় যা খরচবহুল এবং তবুও পারফরম্যান্সে পিছিয়ে।
OLTP: দ্রুত, সিলেকটিভ লুকআপের জন্য অপ্টিমাইজড
ট্রানজেকশনাল ওয়ার্কলোড ছোট প্রশ্ন দ্বারা আধিপত্য বিস্তার করে: একটি অর্ডার আনা, একটি স্টক সারি আপডেট, এক নির্দিষ্ট ব্যবহারকারীকে ২০টি ইভেন্ট দেখানো।
এটি OLTP স্কিমাগুলোকে রো-অরিয়েন্টেড স্টোরেজ এবং পয়েন্ট লুকআপ/ছোট রেঞ্জ স্ক্যান সমর্থনকারী ইনডেক্সের দিকে ঠেলে (প্রাইমারি কী, ফরেন কী, এবং কয়েকটি উচ্চ-মূল্যের সেকেন্ডারি ইনডেক্স)। লক্ষ্য হচ্ছে পূর্বানুমেয়, নিম্ন ল্যাটেন্সি—বিশেষত রাইটের জন্য।
OLAP: স্ক্যান, গ্রুপ, এবং সারাংশ করার জন্য অপ্টিমাইজড
অ্যানালিটিক্স প্রায়ই অনেক সারি পড়ে এবং কেবল কয়েকটি কলাম ব্যবহার করে: “সপ্তাহ অনুযায়ী অঞ্চলভিত্তিক রাজস্ব,” “ক্যাম্পেইন অনুযায়ী কনভার্সন রেট,” “মার্জিন অনুযায়ী শীর্ষ পণ্য।”
OLAP সিস্টেমগুলো কলাম-ভিত্তিক স্টোরেজ (শুধু প্রয়োজনীয় কলাম পড়তে), পার্টিশনিং (পুরনো বা অনাগ্রহী ডেটা দ্রুত বাদ দেয়া), এবং প্রি-অ্যাগ্রিগেশন (materialized views, rollups, summary tables) থেকে সুবিধা পায় যাতে রিপোর্টগুলোর বারবার একই মোট গণনা না করতে হয়।
কেন "সবকিছুর জন্য ইনডেক্স" ব্যর্থ হয়
একটি সাধারণ প্রতিক্রিয়া হলো প্রতিটি ড্যাশবোর্ড দ্রুত করতে ইনডেক্স বাড়ানো। কিন্তু প্রতিটি অতিরিক্ত ইনডেক্স লিখনের খরচ বাড়ায়: ইনসার্ট/আপডেট/ডিলিটে আরও স্ট্রাকচার আপডেট করতে হয়। এটি স্টোরেজ বাড়ায় এবং মেইনটেন্যান্স টাস্ক (vacuuming, reindexing, backup) ধীর করে।
কুয়েরি প্ল্যানার ও স্ট্যাটিস্টিক্স ড্রিফট (সহজ কথায়)
ডাটাবেস কুয়েরি প্ল্যানগুলো স্ট্যাটিস্টিক্সের ওপর ভিত্তি করে চয়েস করে—কত সারি একটি ফিল্টার ম্যাচ করবে, একটি ইনডেক্স কতটা সিলেকটিভ, ডেটা কীভাবে বিতরণ। OLTP ডেটা ক্রমাগত বদলে যায়। বিতরণ বদলালে স্ট্যাটিস্টিক্স ড্রিফট হয়, এবং প্ল্যানার এমন পরিকল্পনা বেছে নেবে যা গতকালের ডেটার জন্য উপযুক্ত ছিল কিন্তু আজ ধীর।
ভারী OLAP কুয়েরি মেশালে পরিবর্তনশীলতা আরও বাড়ে: “সেরা প্ল্যান” পূর্বাভাস করা কঠিন হয়, এবং একটি ওয়ার্কলোড জন্য টিউন করলে অন্যটি খারাপ হতে পারে।
লকিং, MVCC, এবং মেইনটেন্যান্স সাইড-এফেক্ট
যদি আপনার ডাটাবেস "কনকারেন্সি সাপোর্ট করে" বলে থাকলেও, ভারী রিপোর্টিং ও জীবন্ত ট্রানজেকশন মিশালে সূক্ষ্ম মন্থরতা তৈরি হয় যা ভবিষ্যদ্বাণী করা কঠিন—আর গ্রাহককে একটি স্পিনিং চেকআউট দেখালে বোঝানো কঠিন।
দীর্ঘ-চলমান কুয়েরিও লক সমস্যা তৈরি করে
OLAP-শৈলীর কুয়েরিগুলো সাধারণত বহু সারি স্ক্যান করে, একাধিক টেবিল জয়েন করে, এবং সেকেন্ড বা মিনিট ধরে চলতে পারে। সে সময় তারা লক ধরে রাখতে পারে (উদাহরণ: স্কিমা অবজেক্টে লক, বা টেম্প স্ট্রাকচারে সাজানো/অ্যাগ্রিগেট করার সময়), এবং অনেক সময় তারা পরোক্ষভাবে লক কনটেনশন বাড়ায় কারণ বহু সারি “ইন প্লে” রাখে।
MVCC থাকলেও, ডাটাবেসকে একাধিক row-version ট্র্যাক করতে হয় যাতে রিডার ও রাইটার ব্লক না করে। তা সাহায্য করে, কিন্তু কনটেনশন পুরোপুরি দূর করে না—বিশেষত যখন কুয়েরিগুলো এমন হট টেবিলগুলো স্পর্শ করে যেগুলো ট্রানজেকশন দ্বারা ক্রমাগত আপডেট হয়।
MVCC-এর একটি গোপন খরচ: ক্লিনআপ কঠিন হয়ে যায়
MVCC মানে পুরনো row-versionগুলো সুরক্ষিতভাবে অপসারণের আগে লেগে থাকে। একটি দীর্ঘ-চলমান রিপোর্ট একটি পুরনো স্ন্যাপশট ওপেন রেখে দিতে পারে, ফলে ক্লিনআপ সেই স্পেস আদায় করতে পারে না।
এটি প্রভাব ফেলে:
- Vacuum/garbage collection: ডেড টিউপল/ভার্সন দ্রুত মুছে ফেলা যায় না।
- ব্লট/ফ্র্যাগমেন্টেশন: স্টোরেজ বাড়ে, ইনডেক্স কম কার্যকর হয়, এবং ক্যাশ কম উপকারী হয়।
- কম্প্যাকশন চাপ: কিছু ইঞ্জিন বেশি ব্যাকগ্রাউন্ড কাজ করে, যা ট্রানজেকশন থেকে I/O ও CPU চুরি করে।
ফলাফল হলো দ্বৈত আঘাত: রিপোর্টিং ডাটাবেসকে বেশি কাজ করায় এবং সময়ের সাথে সিস্টেমকে ধীর করে দেয়।
আইসোলেশন লেভেল লেটেন্সি ভ্যারিয়েবিলিটি বাড়ায়
রিপোর্টিং টুল প্রায়ই শক্ততর আইসোলেশন চায় (বা ভুলবশত দীর্ঘ ট্রানজেকশনে চলে)। উচ্চ আইসোলেশন লক অপেক্ষা বাড়ায় এবং ইঞ্জিনকে আরও বেশি ভার্সনিং পরিচালনা করতে বাধ্য করে। OLTP দিক থেকে আপনি এটি অনিয়মিত স্পাইক হিসেবে দেখেন: বেশিরভাগ অর্ডার দ্রুত লেখেন, তারপর কয়েকটি আচমকা আটকে যায়।
বাস্তব উদাহরণ: মাসের শেষের রিপোর্ট অর্ডার ধীর করে
মাস শেষে, ফাইন্যান্স "পণ্যের নিরিখে রাজস্ব" কুয়েরি চালায় যা পুরো মাসের অর্ডার ও লাইন আইটেম স্ক্যান করে। যখন এটি চলে, নতুন অর্ডার রাইট এখনও গ্রহণ করা হয়, কিন্তু vacuum পুরনো ভার্সনগুলি মুছে ফেলতে পারে না এবং ইনডেক্স ঘষা পড়ে। অর্ডার API মাঝে মাঝে টাইমআউট দেখতে পায়—কেননা এটি "ডাউন" নয়, বরং কনটেনশন ও ক্লিনআপ ওভারহেড চুপচাপ আপনার ল্যাটেন্সিকে আপনার সীমার ওপরে ঠেলে দেয়।
ওয়ার্কলোড স্পাইক ও অনিয়ন্ত্রিত লেটেন্সি
স্কিমা পরিবর্তনে দ্রুত পুনরুদ্ধার করুন
মাইগ্রেশন বা কোয়েরি পরিবর্তনে সমস্যা হলে স্ন্যাপশট ও রোলব্যাক ব্যবহার করুন।
OLTP সিস্টেম পূর্বানুমেয়তার ওপর বাঁচে। একটি চেকআউট, সাপোর্ট টিকিট, বা ব্যালান্স আপডেট "মোটামুটি ঠিক আছে" হলে যদি 95% সময় দ্রুত হয়, ব্যবহারকারী ধীর মুহূর্তগুলো নজরে রাখে। OLAP-ই সাধারণত ব্রাস্টি: কয়েকটি ভারী কুয়েরি ঘণ্টাখানিক নিঃশব্দ থাকতে পারে এবং হঠাৎ অনেক CPU, মেমরি, ও I/O নেয়।
স্পাইকগুলো স্বাভাবিক ব্যবসায়িক কারণেও ঘটে
অ্যানালিটিক্স ট্র্যাফিকগুলো সাধারণত রুটিন ঘিরে বেঁধে যায়:
- সকালের "স্ট্যান্ডআপ ড্যাশবোর্ড" যেখানে বহু মানুষ একই চার্ট রিফ্রেশ করে
- নির্ধারিত রিপোর্টগুলো যা ঘন্টার শুরুতে একসাথে চালু হয়
- মাস/ত্রৈমাসিক ক্লোজ যেগুলো বড় স্ক্যান ও জয়েন ট্রিগার করে
অন্যদিকে OLTP ট্র্যাফিক সাধারণত ধীর বা ধারাবাহিক থাকে। যখন উভয়ই একই ডাটাবেস শেয়ার করে, সেই অ্যানালিটিক্স স্পাইকগুলো ট্রানজেকশনের জন্য অনিয়ন্ত্রিত লেটেন্সি হয়ে ফিরে আসে—টাইমআউট, ধীর পেজ লোড, এবং রিট্রাই যা আরও লোড বাড়ায়।
সীমা ও শিডিউল সহায়ক, কিন্তু মিল-মেরামত করে না
আপনি ক্ষতি কমাতে পারেন রিপোর্টগুলো রাতের বেলা চালিয়ে, কনকারেন্সি সীমা বসিয়ে, স্টেটমেন্ট টাইমআউট জারি করে, বা কুয়েরি কস্ট ক্যাপ সেট করে। এগুলো রিপোর্টিং অন প্রোডাকশনের জন্য ভালো গার্ডরেইল।
কিন্তু এগুলো মৌলিক টেনশন দূর করে না: OLAP কুয়েরি বড় রিসোর্স ব্যবহার করার জন্য ডিজাইন করা, আর OLTP সারাদিন ছোট, দ্রুত রিসোর্স টুকরা চায়। কোন অপ্রত্যাশিত ড্যাশবোর্ড রিফ্রেশ, অ্যাড-হক কুয়েরি, বা ব্যাকফিল স্লিপ করলে শেয়ার্ড ডাটাবেস আবারও বিপজ্জনক হয়ে ওঠে।
noisy neighbor সমস্যা
শেয়ার্ড ইনফ্রাস্ট্রাকচারে একটি “নয়সি” অ্যানালিটিক্স ইউজার বা জব ক্যাশ একচেটিয়া করতে পারে, ডিস্ক স্যাচুরেট করতে পারে, বা CPU শিডিউলিং চাপাতে পারে—কর্ম করার কোন ভুল না করেই। OLTP ওয়ার্কলোড কল্যাটারাল ক্ষতিগ্রস্ত হয়, এবং সবচেয়ে কঠিন ব্যাপার হলো ব্যর্থতাগুলো র্যান্ডম স্পাইক হিসেবে দেখা যায়: পরিষ্কার, পুনরাবৃত্তি ত্রুটি নয়।
অপারেশনাল জটিলতা: ব্যাকআপ, সিকিউরিটি, ও ক্যাপাসিটি প্ল্যানিং
OLTP (ট্রানজেকশন) ও OLAP (অ্যানালিটিক্স) একসাথে রাখা কেবল পারফরম্যান্সের মাথাব্যথা নয়—এটি দৈনন্দিন অপারেশনকেও জটিল করে। ডাটাবেসটি হয়ে ওঠে একটি একক “সবকিছু বাক্স”, এবং প্রতিটি অপারেশনাল টাস্ক উভয় ওয়ার্কলোডের ঝুঁকি পায়।
ব্যাকআপ, রিস্টোর, ও ডিজাস্টার রিকভারি ধীর হয়
অ্যানালিটিক্স টেবিলগুলো সাধারণত দ্রুত বড় হয় (আরও ইতিহাস, আরও কলাম, আরও অ্যাগ্রিগেট)। সেই অতিরিক্ত ভলিউম আপনার রিকভারি গল্প বদলে দেয়।
পূর্ণ ব্যাকআপ বেশি সময় নেয়, বেশি স্টোরেজ নেয়, এবং ব্যাকআপ উইন্ডো মিস করার সম্ভাবনা বাড়ায়। রিস্টোর আরও খারাপ: দ্রুত রিকভার করতে গেলে আপনি কেবল ট্রানজেকশনাল ডেটাই নয় বরং বড় অ্যানালিটিকাল ডেটাসেটও রিস্টোর করছেন—যা ব্যবসাকে দ্রুত চালু রাখার জন্য প্রয়োজনীয় নয়। ডিজাস্টার রিকভারি টেস্টও লম্বা হয়, তাই কম হয়—ঠিক তার বিপরীত যা দরকার।
ক্যাপাসিটি প্ল্যানিং অনুমানভিত্তিক হয়ে যায়
ট্রানজেকশনাল গ্রোথ সাধারণত পূর্বানুমেয়: আরও গ্রাহক, আরও অর্ডার, আরও সারি। অ্যানালিটিক্স গ্রোথ প্রায়ই লাম্পি: নতুন ড্যাশবোর্ড, নতুন রিটেনশন পলিসি, বা একটি টিম কাঁচা ইভেন্ট “আরেক বছর” রাখতে সিদ্ধান্ত নেওয়া।
যখন উভয় একসাথে থাকে, আপনি সহজে উত্তর দিতে পারবেন না:
- আমরা বড় হচ্ছি কি প্রোডাক্ট সফল হবার কারণে, নাকি রিপোর্টগুলো বেশি ইতিহাস রাখছে বলে?
- আমাদের কি ট্রানজেকশনের জন্য দ্রুত স্টোরেজ দরকার, নাকি অ্যানালিটিক্সের জন্য সস্তা স্টোরেজ বেশি দরকার?
অপ্রত্যাশ্যতা ওভারপ্রোভিশনিং (অপ্রয়োজনীয় হেডরুমের জন্য অর্থ দেয়া) বা আন্ডারপ্রোভিশনিং (হঠাৎ আউটেজ) নিয়ে যায়।
গার্ডরেইলগুলি ন্যায়সংগতভাবে প্রয়োগ করা কঠিন
একটি শেয়ার্ড ডাটাবেসে একটি “নির্দোষ” কুয়েরিই একটি ইনসিডেন্ট হয়ে উঠতে পারে। আপনি স্টেটমেন্ট টাইমআউট, ওয়ার্কলোড কোটা, নির্ধারিত রিপোর্টিং উইন্ডো, বা ওয়ার্কলোড ম্যানেজমেন্ট রুল যুক্ত করবেন। এগুলো সাহায্য করে, কিন্তু ভঙ্গুর: অ্যাপ ও বিশ্লেষকরা একই সীমার জন্য প্রতিযোগিতা করে, এবং একটি গ্রুপের নীতির পরিবর্তন অন্যটিকে ভাঙতে পারে।
সিকিউরিটি ও অ্যাক্সেস কন্ট্রোল জটিল হয়ে যায়
অ্যাপ্লিকেশনগুলো সাধারণত সঙ্কীর্ণ, উদ্দেশ্যমূলক পারমিশন চায়। বিশ্লেষকরা প্রায়ই বহুভাগ টেবিল জুড়ে বিস্তৃত রিড এক্সেস চায়, যাচাই ও এক্সপ্লোর করার জন্য। দুটোই এক ডাটাবেসে রাখলে রিপোর্ট কাজ করতে "প্রায়শই" বেশি বিস্তৃত অনুমতি দিতে চাপ পড়ে, যা ভুলের বিস্তারকে বাড়ায় এবং সংবেদনশীল অপারেশনাল ডেটা দেখার সুযোগ বাড়ায়।
স্কেলিং ও খরচ: আপনি প্রায়ই দুইবার (বা তারও বেশি) অর্থ দিচ্ছেন
ড্যাশবোর্ড থেকে প্রোডাকশন সুরক্ষিত রাখুন
স্পষ্ট রিপোর্টিং সীমা নির্ধারণ করুন যাতে ড্যাশবোর্ড চেকআউট ধীর না করে।
একই ডাটাবেসে OLTP ও OLAP চালানোর চেষ্টা করা প্রাথমিকভাবে সস্তা মনে হতে পারে—কিন্তু স্কেলিং শুরু হলে তা বদলে যায়। সমস্যা কেবল পারফরম্যান্স নয়। প্রতিটি ওয়ার্কলোডকে সঠিকভাবে স্কেল করার পথ আলাদা ইনফ্রা দিকেই ঠেলে, এবং একসাথে চালালে আপনাকে ব্যয়বহুল আপোষ করতে হবে।
OLTP স্কেলিং রাইট-ড্রিভেন (এবং প্রায়শই কষ্টসাধ্য)
ট্রানজেকশনাল সিস্টেমগুলো লিখনের দ্বারা সীমিত: বহু ছোট আপডেট, কঠোর ল্যাটেন্সি, এবং সেজন্য হওয়া বুর্সগুলি অবিলম্বে হজম করতে হবে। OLTP স্কেল করা সাধারণত ভার্টিকাল স্কেলিং (বড় CPU, দ্রুত ডিস্ক, বেশি মেমরি) দ্বারা হয় কারণ রাইট-হেভি ওয়ার্কলোড সহজে ফ্যান আউট করা যায় না।
যখন ভার্টিক্যাল সীমা পৌঁছে যায়, আপনি শার্ডিং বা অন্য রাইট-স্কেলিং প্যাটার্ন দেখতে পাবেন—যা ইঞ্জিনিয়ারিং ওভারহেড বাড়ায় এবং অ্যাপ পরিবর্তন প্রয়োজন করে।
OLAP স্কেলিং কম্পিউট-ড্রিভেন (এবং প্রায়ই ইলাস্টিক)
অ্যানালিটিক্স ওয়ার্কলোড আলাদা ভাবে স্কেল করে: দীর্ঘ স্ক্যান, ভারী অ্যাগ্রিগেশন, এবং বেশি রিড থ্রুপুট। OLAP সিস্টেমগুলো সাধারণত ডিসট্রিবিউটেড কম্পিউট যোগ করে এবং অনেক আধুনিক সেটআপে কম্পিউট ও স্টোরেজ আলাদা করে যাতে আপনি কুয়েরি হর্সপাওয়ার বাড়াতে পারেন স্টোরেজ নকল না করে।
যদি OLAP OLTP ডাটাবেস শেয়ার করে, আপনি অ্যানালিটিক্স আলাদাভাবে স্কেল করতে পারবেন না। তখন পুরো ডাটাবেসই স্কেল করতে হয়—যদিও ট্রানজেকশনগুলো ঠিক আছে।
লুকানো বিল: অ্যানালিটিক্সের জন্য OLTP-গ্রেড রিসোর্স কেনা
ট্রানজেকশনগুলো দ্রুত রাখতে রিপোর্ট চালাতে গেলে দলগুলো প্রোডাকশন ডাটাবেস ওভার-প্রোভিশন করে: অতিরিক্ত CPU হেডরুম, হাই-এন্ড স্টোরেজ, ও বড় ইনস্ট্যান্স। অর্থাৎ আপনি OLTP-দর দামেই OLAP ব্যবস্থার ব্যয় বহন করছেন।
বিভাগ করলে প্রতিটি সিস্টেমকে তার কাজ অনুযায়ী সাইজ করা যায়: OLTP-কে পূর্বানুমেয় লো-ল্যাটেন্সি রাইটের জন্য, OLAP-কে ব্রাস্টি হেভি রিডের জন্য। ফলাফল প্রায়ই মোটামুটি সস্তা হয়—যদিও এটি "দুই সিস্টেম", কারণ আপনি প্রোডাকশনের প্রিমিয়াম ট্রানজেকশনাল সক্ষমতা আরোপ করে রিপোর্ট চালানোর খরচ বন্ধ করে দেন।
প্রচলিত আর্কিটেকচার যা OLTP ও OLAP আলাদা রাখে
বেশিরভাগ টিম OLTP (ট্রানজেকশনাল ওয়ার্কলোড) ও OLAP (অ্যানালিটিক্স) আলাদা রাখে একটি দ্বিতীয় "রিড-অরিয়েন্টেড" সিস্টেম যোগ করে, পরিবর্তে একটি ডাটাবেসকে উভয় করাতে বাধ্য করার।
প্যাটার্ন ১: রিপোর্টিংয়ের জন্য রিড রেপ্লিকা
প্রথম ধাপে সাধারণভাবে একটি রিড রেপ্লিকা (বা follower) থাকে OLTP ডাটাবেসের, যেখানে BI টুলগুলো কুয়েরি চালায়।
Pros: অ্যাপ পরিবর্তনে অল্প কাজ, পরিচিত SQL, দ্রুত সেটআপ।
Cons: এটি এখনও একই ইঞ্জিন ও স্কিমা, তাই ভারী রিপোর্টগুলো রেপ্লিকা CPU/I/O স্যাচুরেট করতে পারে; কিছু রিপোর্ট রেপ্লিকায় লাগতে থাকা ফিচার না পেতে পারে; এবং রেপ্লিকেশন ল্যাগ মানগুলিকে মিনিট (বা বেশি) পিছিয়ে দিতে পারে। ল্যাগ ইনসিডেন্টে বিভ্রান্তি সৃষ্টি করে।
Best fit: ছোট দল, সীমিত ডেটা পরিমাণ, "নিয়ার-রিয়েল-টাইম" ভালো কিন্তু অপরিহার্য না, এবং রিপোর্টিং কুয়েরিগুলো নিয়ন্ত্রিত থাকে।
প্যাটার্ন ২: ডেডিকেটেড ডেটা ওয়্যারহাউস / অ্যানালিটিক্স ডাটাবেস
এখানে OLTP রাইট ও পয়েন্ট রিডের জন্য অপ্টিমাইজ রাখা হয়, আর অ্যানালিটিক্স চলে একটি ডেটা ওয়ারহাউসে (বা কলামার এনালিটিক্স DB) যা স্ক্যান, কম্প্রেশন, এবং বড় অ্যাগ্রিগেশনের জন্য ডিজাইন করা।
Pros: OLTP পারফরম্যান্স পূর্বানুমেয় থাকে, ড্যাশবোর্ড দ্রুত, বিশ্লেষকদের জন্য ভালো কনকারেন্সি, এবং কষ্টসমাধান/কস্ট টিউনিং স্পষ্ট।
Cons: এখন আরেকটি সিস্টেম অপারেট করতে হয় এবং একটি এনালিটিক্স-ফ্রেন্ডলি ডেটা মডেল (প্রায়ই স্টার স্কিমা) দরকার হয়।
Best fit: ডেটা বৃদ্ধি, বহু স্টেকহোল্ডার, জটিল রিপোর্টিং, অথবা কঠোর OLTP ল্যাটেন্সি প্রয়োজন হলে।
প্যাটার্ন ৩: CDC-ভিত্তিক পাইপলাইন অনালিটিক্সে
পর্বিক ETL-এর বদলে আপনি OLTP লগ থেকে CDC (চেঞ্জ ডেটা ক্যাপচার) ব্যবহার করে ওয়ারহাউসে স্ট্রিম করতে পারেন (প্রায়ই ELT সহ)।
Pros: পরীক্ষার মতো ডেটা আরো তাজা হয়, OLTP-তে কম লোড, ইনक्रিমেন্টাল প্রসেসিং সহজ, এবং অডিটযোগ্যতা ভালো হয়।
Cons: আরও বেশি চলন্ত অংশ এবং স্কিমা চেঞ্জ সাবধানে হ্যান্ডেল করতে হয়।
Best fit: বড় ভলিউম, উচ্চ ফ্রেশনেস চাহিদা, এবং ডেটা পাইপলাইন পরিচালনার প্রস্তুতি থাকা টিম।
OLTP থেকে OLAP-এ ডেটা নিরাপদভাবে নেওয়া
আপনার ট্রানজেকশনাল ডাটাবেস থেকে অ্যানালিটিক্স সিস্টেমে ডেটা সরানো হল "টেবিল কপি করা"-র বেশি—এটা নির্ভরযোগ্য, কম-প্রভাবশালী পাইপলাইন তৈরি করা। লক্ষ্য সহজ: অ্যানালিটিক্স পায় যা প্রয়োজন, প্রোডাকশন ট্রাফিকে ঝুঁকি না নিয়ে।
ETL বনাম ELT (সহজ ভাষায়)
ETL (Extract, Transform, Load) মানে আপনি ডেটা লোড করার আগে পরিষ্কার ও রিশেপ করেন। এটা তখন উপযোগী যখন ওয়ারহাউসের কম্পিউট ব্যয় বেশি বা আপনি সংরক্ষণে কড়া নিয়ন্ত্রণ চান।
ELT (Extract, Load, Transform) প্রথমে কাঁচা-রূপ ডেটা লোড করে, পরে ওয়ারহাউসে পরিবর্তন করেন। এটি সাধারণত দ্রুত সেটআপ হয় এবং সহজে বিবর্তনশীল: আপনি সুত্র-তথ্যের ইতিহাস রাখেন এবং প্রয়োজন বদলে গেলে ট্রান্সফর্ম সমন্বয় করতে পারেন।
একটি ব্যবহারিক নিয়ম: ব্যবসায়িক লজিক ঘনঘন বদলে গেলে ELT পুনরায় কাজ কমায়; যদি প্রশাসনিকভাবে কেবল কিউরেটেড ডেটা রাখতে চান, ETL ভাল হতে পারে।
CDC বেসিক: ভারী কুয়েরি না চালিয়ে পরিবর্তন ধরুন
Change Data Capture (CDC) OLTP-এ হওয়া ইনসার্ট/আপডেট/ডিলিটকে স্ট্রিম করে (প্রায়ই DB লগ থেকে) আপনার অ্যানালিটিক্স সিস্টেমে। বড় টেবিল বারবার স্ক্যান করার বদলে CDC দিয়ে শুধু বদলে যাওয়া অংশটুকুই নেয়া যায়।
এটি যা সক্ষম করে:
- নিয়ার-রিয়েল-টাইম রিপোর্টিং প্রোডাকশনে বড় রিড না চালিয়েই
- রিপ্লে ও ব্যাকফিল সহজ যখন অ্যানালিটিক টেবিল পুনর্নির্মাণ করতে হয়
- হিস্টরি ট্র্যাকিং (কে কখন কী বদলিয়েছে) যদি আপনি চেঞ্জ ইভেন্ট সংরক্ষণ করেন
ডেটা ফ্রেশনেস: রিয়েল-টাইম বনাম নিয়ার-রিয়েল-টাইম বনাম দৈনিক
ফ্রেশনেস একটি ব্যবসায়িক সিদ্ধান্ত এবং এর কারিগরি খরচ আছে।
- রিয়েল-টাইম (সেকেন্ড): অপারেশনাল ড্যাশবোর্ডের জন্য শ্রেষ্ঠ, কিন্তু স্থিতিশীল রাখা কঠিন; পাইপলাইনের ছোট সমস্যা দ্রুত চোখে পড়ে।
- নিয়ার-রিয়েল-টাইম (মিনিট): একটি সাধারণ সোনার লক্ষ্য—যুক্তিসঙ্গত সিদ্ধান্ত নেওয়ার সময় এবং অতিরিক্ত জটিলতা না বাড়িয়ে।
- দৈনিক ব্যাচ: সহজ ও সস্তায়মত, ফাইনান্স-ধাঁচের রিপোর্টিং যেখানে "গতকাল" গ্রহণযোগ্য।
স্পষ্ট SLA লিখে রাখুন (উদাহরণ: "ডেটা 15 মিনিটের মধ্যে আপডেট থাকে") যাতে স্টেকহোল্ডাররা জানে "ফ্রেশ" মানে কী।
ডেটা কোয়ালিটি চেক যা সাইলেন্ট ফেইল রুখে
পাইপলাইনগুলো সাধারণত নীরবে ভেঙে—যতক্ষণ না কেউ সংখ্যার তফাৎ দেখে। হালকা চেক যোগ করুন:
- স্কিমা চেঞ্জ: নতুন কলাম, নাম পরিবর্তন, টাইপ চেঞ্জ যা ডেটা নাল করে দিতে পারে।
- লেন-আ্যরাইভিং ইভেন্ট: অর্ডার বা পেমেন্ট যেগুলো ঘণ্টা পরে আসে; "লুকব্যাক উইন্ডো" রাখুন।
- ডুপ্লিকেশন হ্যান্ডেলিং: রিট্রাই ও রিপ্লেতে ডাবল-কাউন্টিং এড়াতে স্থিতিশীল ID ও idempotent লোড ব্যবহার করুন।
এই নিরাপত্তা ব্যবস্থা OLAP-কে বিশ্বাসযোগ্য রাখে এবং OLTP-কে সুরক্ষিত রাখে।
কখন এক ডাটাবেস শেয়ার করা গ্রহণযোগ্য হতে পারে
প্রস্তুত হলে CDC-তে অগ্রসর করুন
সহজভাবে শুরু করুন, তারপর ELT মডেল ও অ্যানালিটিক্স সার্ভিস যোগ করলে কোড এক্সপোর্ট করুন।
OLTP ও OLAP একসাথে রাখা স্বয়ংক্রিয় ভাবে ভুল নয়। এটি যুক্তিযুক্ত অস্থায়ী পছন্দ হতে পারে যখন অ্যাপ ছোট, রিপোর্টিং সীমিত, এবং আপনি কঠোর সীমা আরোপ করতে পারেন যাতে অ্যানালিটিক্স আপনার গ্রাহকদের ধীর চেকআউট বা টাইমআউটে না ফেলেই ক্রিয়াশীল থাকে।
কখন কাজ করবে
ছোট অ্যাপ যেখানে হালকা অ্যানালিটিক্স ও কঠোর কুয়েরি সীমা আছে সাধারণত একটি ডাটাবেসেই ভালো চলে—বিশেষত আরম্ভে। কীভাবে "হালকা" সংজ্ঞায়িত করবেন তা স্পষ্ট রাখা দরকার: কয়েকটি ড্যাশবোর্ড, সীমিত সারি সংখ্যা, এবং কুয়েরি রানটাইম ও কনকারেন্সির পরিষ্কার ছাদের উপরে।
নির্দিষ্ট পুনরাবৃত্তি রিপোর্টের জন্য materialized views বা summary tables ব্যবহার করলে অ্যানালিটিক্সের ব্যয় কমে। কাঁচা ট্রানজেকশন স্ক্যান না করে আপনি দৈনিক মোট, টপ ক্যাটাগরি, বা কাস্টমার-ভিত্তিক রোলআপ আগে থেকে গণনা করে রাখুন—এতে বেশিরভাগ কুয়েরি ছোট ও পূর্বানুমেয় থাকে।
ডিলেইড নম্বর মানতে পারলে, অফ-পিক রিপোর্টিং উইন্ডো কাজে লাগে। রাত বা কম-ট্রাফিক সময়ে ভারী জব স্কেজিউল করুন, এবং স্পষ্ট পারমিশন ও রিসোর্স সীমা থাকা একটি ডেডিকেটেড রিপোর্টিং রোল বিবেচনা করুন।
যোগ করার মতো গার্ডরেইল
- স্টেটমেন্ট টাইমআউট সেট করুন এবং রানঅ্যাওয়ে কুয়েরি বাতিল করুন।
- রিপোর্টিং ব্যবহারকারীদের জন্য কনকারেন্সি ক্যাপ বসান।
- কোর ট্রানজেকশনের p95/p99 আলাদাভাবে মনিটর করুন।
স্পষ্ট সতর্কতা যে আলাদা করার সময় এসেছে
যদি আপনি দেখেন ট্রানজেকশন লেটেন্সি বাড়ছে, রিপোর্ট চালানোর সময় পুনরায় ইনসিডেন্ট, কানেকশন পুল এক্সহস্টশন, বা "একটি কুয়েরি প্রোডাকশন ডাউন করে দিয়েছে" গল্প — আপনি নিরাপদ অঞ্চলের বাইরে চলে এসেছেন। সেই মুহূর্তে ডাটাবেস আলাদা করা কেবল অপ্টিমাইজেশন নয় বরং বেসিক অপারেশনাল হাইজিন হয়ে যায়।
বাস্তবমুখী মাইগ্রেশন চেকলিস্ট: শেয়ার্ড থেকে আলাদা করার দিকে
অ্যানালিটিক্স প্রোডাকশন ডাটাবেস থেকে সরানো একটি বড় রিরাইট নয়—এটি কাজকে দৃশ্যমান করা, লক্ষ্য স্থির করা, এবং নিয়ন্ত্রিত ধাপে মাইগ্রেট করার ব্যাপার।
1) আজ বাস্তবে কি হচ্ছে তার ইনভেন্টরি করুন
অনুমান নয়, প্রমাণ দিয়ে শুরু করুন। তালিকা বানান:
- ফ্রিকোয়েন্সি ও p95/p99 ল্যাটেন্সি অনুযায়ী টপ OLTP এন্ডপয়েন্ট/কুয়েরি (চেকআউট, লগইন, অর্ডার তৈরি ইত্যাদি)
- রানটাইম, স্ক্যান ভলিউম, এবং বিজনেস ইমপোর্ট্যান্স অনুযায়ী টপ OLAP রিপোর্ট/ড্যাশবোর্ড
লুক-হোটেন অ্যানালিটিক্সও অন্তর্ভুক্ত করুন: BI টুলের অ্যাড-হক SQL, নির্ধারিত এক্সপোর্ট, এবং CSV ডাউনলোড।
2) লক্ষ্য নির্ধারণ: OLTP SLO ও অ্যানালিটিক্স ফ্রেশনেস
আপনি কী জন্য অপ্টিমাইজ করবেন তা লিখে রাখুন:
- OLTP SLO: p95/p99 ল্যাটেন্সি, এরর রেট, এবং ধরে রাখতে হবে এমন পিক থ্রুপুট
- অ্যানালিটিক্স ফ্রেশনেস: কতটা স্টেল থাকতে হবে (5 মিনিট, 1 ঘণ্টা, পরের দিন), এবং পাইপলাইন ভাঙলে পুনর্নির্মাণের সময়
এটা বিতর্ক এড়ায় "এটা ধীর" বনাম "এটা ঠিক আছে" এবং সঠিক আর্কিটেকচার বেছে নিতে সাহায্য করে।
3) আলাদা করার পথ চয়ন করুন
টার্গেট পূরণ করার জন্য সহজতম অপশন বেছে নিন:
- রিড রেপ্লিকা: রিড-হেভি রিপোর্টিং জন্য দ্রুত গ্রহণযোগ্য, তবে রেপ্লিকা ল্যাগ ও CPU/I/O সীমা থাকে
- ওয়ারহাউস: বড় স্ক্যান, বহু জয়েন, দীর্ঘ ইতিহাসের জন্য শ্রেষ্ঠ; BI-এর সঠিক বাস
- CDC পাইপলাইন (ETL/ELT): প্রোডাকশনে চাপ না দিয়ে নিয়ার-রিয়েল-টাইম দরকার হলে সেরা
4) নিরাপদভাবে রোলআউট (প্রথমে প্যারালাল)
- সংজ্ঞাগুলি যাচাই করুন (টাইমজোন, রিফান্ড, “অ্যাকটিভ ইউজার” ইত্যাদি) যাতে সংখ্যাগুলি মেলে।
- পুরনো ও নতুন ড্যাশবোর্ড পুরো ব্যবসায়িক সাইকেলে প্যারালেল চালান।
- রিপোর্ট-বাই-রিপোর্ট কাটওভার করুন, শুরুতে সবচেয়ে কষ্টদায়ক কুয়েরিগুলো দিয়ে।
- স্টেকহোল্ডাররা নতুন সোর্সে বিশ্বাস করলে প্রোডাকশনে সরাসরি রিপোর্টিং অ্যাক্সেস বন্ধ করুন।
5) পিছনে ফিরে যাওয়ার প্রতিরোধ যোগ করুন
রেপ্লিকা ল্যাগ/পাইপলাইন ডিলেই/ড্যাশবোর্ড রানটাইম/ওয়ারহাউস খরচ মনিটর করুন। কুয়েরি বাজেট (টাইমআউট, কনকারেন্সি লিমিট), এবং ইনসিডেন্ট প্লেবুক রাখুন: ফ্রেশনেস স্লিপ করলে, লোড spike হলে, বা কী-মেট্রিক বিচ্যুত হলে কী করবেন।
যদি আপনি অ্যাপ নিজেই তৈরি করেন তাহলে বাস্তব নোট
প্রোডাক্টের শুরুতে দ্রুত গড়ানোর সময় সবচেয়ে বড় ঝুঁকি হচ্ছে ভাসমানভাবে অ্যানালিটিক্সকে একই ডাটাবেস পথের মধ্যে বানানো (উদাহরণ: ড্যাশবোর্ড কুয়েরি যা নীরবে “প্রোডাকশন-ক্রিটিকাল” হয়ে যায়)। একরকম এড়ানোর উপায় হল আলাদা করার পরিকল্পনা শুরু থেকেই করা—যদিও আপনি একটি সামান্য রিড রেপ্লিকা দিয়ে শুরু করেন—এবং এটিকে আর্কিটেকচার চেকলিস্টে ঢুকিয়ে রাখা।
কিছু প্ল্যাটফর্ম যেমন Koder.ai এখানে সাহায্য করতে পারে কারণ আপনি OLTP পাশে প্রোটোটাইপ করতে (React অ্যাপ + Go সার্ভিস + PostgreSQL) এবং রিপোর্টিং/ওয়ারহাউস সীমানা প্ল্যানিং মোডে স্কেচ করতে পারেন শিপ করার আগে। প্রোডাক্ট বাড়লে আপনি সোর্স কোড এক্সপোর্ট করতে, স্কিমা বিবর্তন করতে, এবং CDC/ELT উপাদান যোগ করতে পারবেন যাতে "প্রোডাকশনে রিপোর্টিং" প্রকৃত অভ্যাসে কামড় না বসায়।
সাধারণ প্রশ্ন
What’s the simplest way to explain OLTP vs OLAP?
OLTP (Online Transaction Processing) দৈনন্দিন অপারেশন যেমন অর্ডার তৈরি করা, স্টক আপডেট এবং পেমেন্ট রেকর্ড করার কাজ করে। এটি কম লেটেন্সি, উচ্চ কনকারেন্সি, এবং সঠিকতার ওপর গুরুত্ব দেয়।
OLAP (Online Analytical Processing) বড় স্ক্যান ও অ্যাগ্রিগেশন ব্যবহার করে ব্যবসায়িক প্রশ্নের উত্তর দেয় (ড্যাশবোর্ড, ট্রেন্ড, কোহর্ট বিশ্লেষণ)। এটি থ্রুপুট, নমনীয় কুয়েরি, এবং দ্রুত সংক্ষিপ্তসারকে প্রাধান্য দেয়—মিলিসেকেন্ড রেসপন্স টাইম নয়।
Why does running analytics on the same database hurt transactional performance?
কারণ দুটো ওয়ার্কলোড একই রিসোর্সের জন্য প্রতিদ্বন্দ্বিতা করে:
- CPU \u0026 memory: দীর্ঘ অ্যাগ্রিগেশন ও জয়েনগুলো ছোট ট্রানজেকশনাল কুয়েরিগুলোর জায়গা নেবে।
- ডিস্ক I/O: অ্যানালিটিক্স স্ক্যানগুলো OLTP-এর ছোট র্যান্ডম রিড/রাইট এবং লগ/ইনডেক্স লেখাকে ব্যাহত করে।
- ক্যাশ চর্ন: বড় স্ক্যানগুলো হট OLTP পেজগুলোকে ক্যাশ থেকে প্রান্তে ঠেলে দিতে পারে, ফলে অ্যাপ আচমকাই ধীর হয়ে যায়।
- কানেকশন পুল চাপ: কয়েকটি দীর্ঘ BI কুয়েরি কানেকশনগুলো দখল করে রেখে অ্যাপের রিকোয়েস্টগুলোকে অপেক্ষা করাতে পারে।
ফলাফল হিসেবে প্রায়ই আপনার কোর ইউজার অ্যাকশনগুলোর p95/p99 লেটেন্সি অনিয়মিত হয়ে পড়ে।
Can’t we just add more indexes to make both OLTP and OLAP fast?
সাধারণত নয়। ড্যাশবোর্ডগুলোকে দ্রুত করতে ইনডেক্স বাড়ালে অনেক সময় বিপর্যয় ঘটে কারণ:
- প্রতিটি অতিরিক্ত ইনডেক্স লিখন লক্ষ্যে write cost বাড়ায় (insert/update/delete-এ আরও স্ট্রাকচার আপডেট করতে হয়)।
- ইনডেক্সগুলো স্টোরেজ বাড়ায় এবং মেইনটেন্যান্স (vacuum/reindex/backup) ধীর করে।
- এক এক ইনডেক্সকে টিউন করলে আপনি একটি রিপোর্ট দ্রুত করতে পারেন কিন্তু অন্য কুয়েরি বা OLTP লিখনকে খারাপ করে ফেলতে পারেন।
অ্যানালিটিক্সের জন্য সাধারণত ভালো ফল মেলে (materialized views, rollups) ব্যবহার করলে।
How do MVCC and long-running queries make shared databases slower over time?
MVCC পাঠক ও লেখককে ব্লক না করাতে সহায়তা করে, কিন্তু মিশ্র ওয়ার্কলোডকে বিনামূল্যে করে না। বাস্তব সমস্যা:
- দীর্ঘ চলমান রিপোর্টগুলো পুরনো স্ন্যাপশট ওপেন রাখে, ফলে পুরনো row-versionগুলো অপসারণ করা যায় না।
- ক্লিনআপ দেরি ব্লট/ফ্র্যাগমেন্টেশন সৃষ্টি করে, যা কুয়েরি ধীর করে এবং ক্যাশের কার্যকারিতা কমায়।
- পেছনে চলা ক্লিনআপ/কম্প্যাকশন কাজগুলো CPU ও I/O চুরি করতে পারে, যা OLTP-কে ক্ষতিগ্রস্ত করে।
অতএব, দৃশ্যমান ব্লকিং না থাকলেও ভারী অ্যানালিটিক্স ধীরে ধীরে পারফরম্যান্স নষ্ট করে।
What are the warning signs that it’s time to separate OLTP and OLAP?
সাধারণ সংকেতগুলো:
- চেকআউট/লগইন/আপডেট এন্ডপয়েন্টগুলোর p95/p99 লেটেন্সি বৃদ্ধি।
- রিপোর্টিং উইন্ডোতে টাইমআউট বা রিট্রাই বেড়ে যাওয়া।
- কানেকশন পুল এক্সহস্টশন (অ্যাপ অনুরোধগুলো ফ্রি DB কানেকশনের জন্য অপেক্ষা করা)।
- মাস-শেষ/ত্রৈমাসিক-শেষ রিপোর্ট চালানোর সঙ্গে সম্পর্কিত ইনসিডেন্ট।
যদি ড্যাশবোর্ড রিফ্রেশ করার সময় সিস্টেম 'র্যান্ডমলি স্লো' মনে হয়, সেটাই মিশ্র-ওয়ার্কলোডের ক্লাসিক লক্ষণ।
When does a read replica make sense for reporting?
রিড রেপ্লিকা সাধারণত প্রথম ধাপ হিসেবে উপযোগী:
- Pros: অ্যাপ পরিবর্তনে কম কাজ, পরিচিত SQL/স্কিমা, প্রোডাকশন লেখাকে আলাদা করে।
- Cons: ভারী রিপোর্টগুলো এখনও রেপ্লিকা CPU/I/O স্যাচুরেট করতে পারে; রেপ্লিকেশন ল্যাগ মেট্রিকে বিভ্রান্তি আনতে পারে; এটা এখনও রো-স্টোর OLTP প্রযুক্তি।
ডেটা ভলিউম সামান্য এবং "মিনিটদের পিছনে" থাকা গ্রহণযোগ্য হলে এটি ভাল ব্রিজ।
When should we use a dedicated data warehouse instead of a replica?
ওয়্যারহাউস ভালো যখন আপনি চান:
- বড় স্ক্যান, জয়েন, এবং অ্যাগ্রিগেশনে দ্রুত পারফরম্যান্স
- অনেক বিশ্লেষক একই সাথে কুয়েরি চালাচ্ছে
- দীর্ঘ ইতিহাস রক্ষণ যাতে OLTP-কে দীর্ঘ মেয়াদি ব্যয় না বাড়ায়
- টিউনিং এবং কস্টকে আলাদা করে পরিচালনা (OLTP ল্যাটেন্সি, OLAP থ্রুপুট)
এটি সাধারণত একটি এনালিটিক্স-ফ্রেন্ডলি মডেল (স্টার/স্নোফ্লেক) এবং ডেটা লোড করার জন্য একটি পাইপলাইন দরকার করে।
What is CDC, and why is it often better than running big ETL queries on production?
CDC (Change Data Capture) OLTP ডাটাবেস থেকে ইনসার্ট/আপডেট/ডিলিটগুলো (প্রায়ই লগ থেকে) স্ট্রিম করে analytics-এ পাঠায়।
এটি উপকার করে কারণ:
- আপনি মাত্র যা বদলেছে তা সরান, বড় টেবিল পুনরায় স্ক্যান করা লাগে না।
- কম OLTP ইমপ্যাক্টে নিকট-রিয়েল-টাইম ফ্রেশনেস পাওয়া যায়।
- রেপ্লে/ব্যাকফিল সহজ হয় যখন আপনার কাছে চেঞ্জ স্ট্রিম থাকে।
Trade-off হলো আরও বেশি মোভিং পার্টস এবং স্কিমা চেঞ্জ ও অর্ডারিং সাবধানে হ্যান্ডেল করার প্রয়োজন।
How do I choose between ETL and ELT for moving OLTP data into OLAP?
নিচের ভিত্তিতে পছন্দ করুন:
- ELT: প্রথমে কাঁচা-রূপে ডেটা লোড করে, পরে ওয়্যারহাউসে ট্রান্সফর্ম। সংজ্ঞা বদলে গেলে সহজে অভিযোজিত হওয়ার জন্য দ্রুত সেটআপ করা যায়।
- ETL: লোডের আগে ট্রান্সফর্ম করা হয়। যখন আপনি শুধু কিউরেটেড আউটপুটই রাখতে চান বা কঠোর নিয়ন্ত্রণ চান তখন এটি যুক্তিযুক্ত।
বাস্তব প্রয়োগে ELT দিয়ে শুরু করা দ্রুত হয়; পরে গভার্নেন্স (টেস্ট, কিউরেটেড মডেল) যোগ করুন যখন ক্রিটিক্যাল মেট্রিক স্থির হয়ে যায়।
Is it ever acceptable to keep OLTP and OLAP on the same database?
হ্যাঁ—অস্থায়ীভাবে—যদি আপনি অ্যানালিটিক্সকে সত্যিই হালকা রাখেন এবং কঠোর গার্ডরেইল যোগ করেন:
- স্টেটমেন্ট টাইমআউট সেট করুন এবং রানঅ্যাওয়ে কুয়েরি বাতিল করুন।
- রিপোর্টিং কনকারেন্সি ক্যাপ করুন (অলাদা রোল/পুল)।
- প্রি-অ্যাগ্রিগেশন ব্যবহার করুন (materialized views/summary tables)।
- OLTP p95/p99 আলাদা করে মনিটর করুন।
এই নিয়মগুলো প্রয়োগ করা হয়েই এটাকে কার্যকর রাখা যায়, কিন্তু যখন রিপোর্টিং নিয়মিত লেটেন্সি স্পাইক বা প্রোডাকশন ইনসিডেন্ট তৈরি করে, তখন আলাদা করা অপরিহার্য।