Ingres, Postgres, এবং Vertica-র পিছনে থাকা মাইকেল স্টোনব্রেকারের মূল ধারণাগুলো অন্বেষণ করুন—কীভাবে সেগুলো SQL ডাটাবেস, অ্যানালিটিক্স ইঞ্জিন এবং আধুনিক ডেটা স্ট্যাকগুলোর আকৃতি গঠন করেছে।
মাইকেল স্টোনব্রেকার একজন কম্পিউটার বিজ্ঞানী, যাঁর প্রকল্পগুলো কেবল ডাটাবেস গবেষণাকে প্রভাবিত করেনি—এগুলো সরাসরি সেই পণ্য এবং ডিজাইন প্যাটার্নগুলোকে ধরেছে যেগুলো অনেক টিম প্রতিদিন ব্যবহার করে। যদি আপনি একটি রিলেশনাল ডাটাবেস, কোনো অ্যানালিটিক্স ওয়্যারহাউস বা স্ট্রিমিং সিস্টেম ব্যবহার করে থাকেন, তাহলে আপনি এমন ধারণাগুলি উপভোগ করেছেন যা তিনি প্রমাণ, নির্মাণ বা প্রচলিত করেছেন।
এটি কোনো জীবননীতি বা একাডেমিক থিওরির ট্যুর নয়। বরং, এটি স্টোনব্রেকারের বড় সিস্টেমগুলোর (Ingres, Postgres, Vertica ইত্যাদি) সাথে আধুনিক ডেটা স্ট্যাকগুলোতে দেখা নির্বাচনের সংযোগ করে:
একটি আধুনিক ডাটাবেস হচ্ছে এমন কোনো সিস্টেম যা নির্ভরযোগ্যভাবে করতে পারে:
বিভিন্ন ডাটাবেস আলাদা উপায়ে এই লক্ষ্যগুলোকে অপ্টিমাইজ করে—বিশেষত ট্রানজ্যাকশনাল অ্যাপ, BI ড্যাশবোর্ড এবং রিয়েল-টাইম পাইপলাইনের মধ্যে তুলনা করলে।
আমরা প্র্যাকটিক্যাল প্রভাবের ওপর ফোকাস করব: সেই ধারণাগুলো যা আজকের “ওয়্যারহাউস + লেক + স্ট্রিম + মাইক্রোসার্ভিস” জগতে দেখা যায়, এবং কীভাবে এগুলো কিনবেন, বানাবেন ও অপারেট করবেন তা প্রভাবিত করে। প্রত্যাশা করুন পরিষ্কার ব্যাখ্যা, ট্রেড-অফ এবং বাস্তব জীবনের পরিণাম—প্রমাণপত্র বা ইমপ্লিমেন্টেশন ডিটেইলে গভীর ডুব নয়।
স্টোনব্রেকারের ক্যারিয়ার বোঝা সহজতম করা যায় এক ধারা হিসেবে—নির্দিষ্ট কাজের জন্য নির্মিত সিস্টেমগুলোর ক্রম এবং তারপর সেই সেরা ধারণাগুলো কিভাবে মেইনস্ট্রিম পণ্যগুলোতে ঢুকেছে।
Ingres এক একাডেমিক প্রকল্প হিসেবে শুরু হয়েছিল যেটি প্রমাণ করেছিল রিলেশনাল ডাটাবেস কেবল সিদ্ধান্ত নয়—এগুলো দ্রুত ও ব্যবহারিক হতে পারে। এটি SQL-স্টাইল কুয়েরি এবং কস্ট-ভিত্তিক অপটিমাইজেশনের ধারণাকে প্রচলিত করতে সাহায্য করে যা পরে বাণিজ্যিক ইঞ্জিনগুলোতে স্বাভাবিক হয়ে ওঠে।
Postgres (গবেষণামূলক সিস্টেম যা PostgreSQL-এ পরিণত হয়) একটি ভিন্ন দাওবা করেছিল: ডাটাবেসগুলো স্থির-ফাংশন হওয়া উচিত না। আপনি যেন নতুন ডেটা টাইপ, নতুন ইনডেক্সিং পদ্ধতি এবং সমৃদ্ধ আচরণ যোগ করতে পারেন ইঞ্জিন পুরোপুরি পুনর্লিখন না করেই।
অনেক আধুনিক ফিচার এখান থেকেই এসেছে—এক্সটেনসিবল টাইপ, ইউজার-ডিফাইন্ড ফাংশন, এবং এমন একটি ডাটাবেস যা ওয়ার্কলোড বদলে গেলে মানানো যায়।
অ্যানালিটিক্স বাড়ার সঙ্গে, রো-অরিয়েন্টেড সিস্টেমগুলো বড় স্ক্যান ও অগ্রিগেশনে কষ্টে পড়তে শুরু করল। স্টোনব্রেকার কলামভিত্তিক স্টোরেজ এবং সংশ্লিষ্ট এক্সিকিউশন কৌশলগুলোর পক্ষে ছিলেন—এগুলো কেবল প্রয়োজনীয় কলামই পড়ে বার করা এবং সেগুলোকে ভালভাবে কমপ্রেস করার ধারণা, যা আজ অ্যানালিটিক্স ডাটাবেস ও ক্লাউড ওয়্যারহাউসে স্ট্যান্ডার্ড।
Vertica কলামার স্টোর গবেষণার ধারণাগুলোকে বাণিজ্যিকভাবে সক্ষম massively parallel processing (MPP) SQL ইঞ্জিনে পরিণত করেছিল, যা বড় অ্যানালিটিক্স কুয়েরিগুলো দ্রুত করার উদ্দেশ্যে তৈরি। গবেষণা প্রোটোটাইপ একটি কনসেপ্ট যাচাই করে; একটি পণ্য এটিকে রিলায়িবিলিটি, টুলিং ও বাস্তব কাস্টমার কন্ডিশনের জন্য শক্ত করে তোলে—এটাই শিল্পে বারবার দেখা প্যাটার্ন।
পরে কাজগুলো স্ট্রিম প্রসেসিং এবং ওয়ার্কলোড-স্পেসিফিক ইঞ্জিনে বিস্তৃত হয়—দাবি ছিল যে এক সাধারণ উদ্দেশ্যের ডাটাবেস সব জায়গায় জেতে না।
প্রোটোটাইপ দ্রুত একটি হাইপোথিসিস পরীক্ষা করার জন্য নির্মিত হয়; একটি পণ্য অপারাবিলিটির ওপর জোর দেয়: আপগ্রেড, মনিটরিং, সিকিউরিটি, পূর্বানুমেয় পারফরম্যান্স এবং সাপোর্ট। স্টোনব্রেকারের প্রভাব দেখা যায় কারণ অনেক প্রোটোটাইপ ধারণা বাণিজ্যিক ডাটাবেসে ডিফল্ট ক্ষমতায় গ্র্যাজুয়েট করেছে, বিভক্ত অপশন নয়।
Ingres (INteractive Graphics REtrieval System) ছিল স্টোনব্রেকারের প্রাথমিক প্রমাণ যে রিলেশনাল মডেল কেবল সুন্দর তত্ত্ব নয়। তখনকার সময়ে অনেক সিস্টেম কাস্টম অ্যাক্সেস মেথড ও অ্যাপ্লিকেশন-স্পেসিফিক ডেটা পাথের উপর নির্মিত ছিল।
Ingres একটি সরল ব্যবসায়িক সমস্যা সমাধান করতে নেমেছিল:
কিভাবে মানুষকে ডেটার উপর নমনীয় প্রশ্ন করার সুযোগ দিবেন, প্রতিবার সফটওয়্যার পুনর্লিখতে না হয়ে?
রিলেশনাল ডাটাবেস আপনাকে বলে আপনি কি চান সেটা বর্ণনা করতে পারবেন (উদাহরণ: “ক্যালিফোর্নিয়ার কাস্টমারদের যারা বিল শেষ তারিখ পেরিয়েছে”), কিভাবে ধাপে ধাপে তা আনতে হবে না। কিন্তু সেই প্রতিশ্রুতি বাস্তব করতে একটি সিস্টেম দরকার যা করে:
Ingres ঐ “প্রায়োগিক” রিলেশনাল কম্পিউটিংয়ের দিকে বড় পদক্ষেপ ছিল—একটি সিস্টেম যা তখনকার হার্ডওয়্যারে চলেও প্রতিক্রিয়াশীল বোধ করত।
Ingres এই ধারণা প্রচলিত করতে সাহায্য করল যে একটি ডাটাবেসকে কুয়েরি পরিকল্পনা করা কঠোর কাজটাই করা উচিত। ডেভেলপাররা প্রতিটি ডেটা এক্সেস পাথ হাত দিয়ে টিউন না করে, সিস্টেমই সিদ্ধান্ত নিতে পারে—কোন টেবিল প্রথম পড়বেন, কোন ইনডেক্স ব্যবহার করবেন, কিভাবে টেবিলগুলো জয়েন করবেন ইত্যাদি।
এটা SQL-স্টাইল চিন্তাধারাকে ছড়িয়ে দিতে সাহায্য করল: যখন আপনি ডিক্লারেটিভ কোয়েরি লিখতে পারেন, আপনি দ্রুত পুনরাবৃত্তি করতে পারেন, এবং আরও মানুষ সরাসরি প্রশ্ন করতে পারে—অ্যানালিস্ট, প্রোডাক্ট টিম, এমনকি ফাইন্যান্স—বিনা কাস্টম রিপোর্টের অপেক্ষায় থাকাও।
বড় ব্যবহারিক অন্তর্দৃষ্টি হচ্ছে কস্ট-বেসড অপটিমাইজেশন: ডেটা সম্পর্কে পরিসংখ্যান ব্যবহার করে সর্বনিম্ন প্রত্যাশিত “খরচ” (সাধারণত I/O, CPU, মেমরির মিশ্রণ) অনুযায়ী কোয়েরি প্ল্যান বেছে নাও।
এর প্রভাব প্রায়ই দেখা যায়:
Ingres প্রতিটি আধুনিক অপ্টিমাইজেশনের উপাদান আবিষ্কার করেনি, কিন্তু এটি প্যাটার্নটা প্রতিষ্ঠা করতে সাহায্য করল: SQL + একটি অপ্টিমাইজার রিলেশনাল সিস্টেমগুলোকে “ভালো ধারণা” থেকে দৈনন্দিন টুল বানায়।
প্রাথমিক রিলেশনাল ডাটাবেসগুলো সাধারণত ধার্য টাইপ সেট (নাম্বর, টেক্সট, তারিখ) এবং ধ্রুব অপারেশন (ফিল্টার, জয়েন, অ্যাগ্রিগেট) ধরে নিত। এটা ভাল কাজ করত—যতক্ষণ না টিমগুলো নতুন ধরনের তথ্য (জিওগ্রাফি, লগ, টাইম সিরিজ, ডোমেইন-স্পেসিফিক আইডেন্টিফায়ার) সংরক্ষণ শুরু করে বা বিশেষায়িত পারফরম্যান্স ফিচার দরকার হয়।
কঠোর ডিজাইনে, প্রতিটি নতুন চাহিদা একটি খারাপ বিকল্পে পরিণত হয়: ডেটাকে টেক্সট ব্লব হিসেবে ফোর্স করা, আলাদা সিস্টেম লাগানো, বা ভেন্ডারের আপডেটের জন্য অপেক্ষা করা।
Postgres ভিন্ন একটি ধারণা এগিয়ে আনল: ডাটাবেসকে এক্সটেনসিবল হওয়া উচিত—অর্থাৎ আপনি নিয়ন্ত্রিতভাবে নতুন ক্ষমতা যোগ করতে পারেন, সেই সুরক্ষা ও সঠিকতা বজায় রেখে যা আপনি SQL থেকে আশা করেন।
সরল ভাষায়, এক্সটেনসিবিলিটি মানে একটি পাওয়ার টুলে সার্টিফায়েড এটাচমেন্ট যোগ করার মত—মোটর নিজে বদলাতে হচ্ছে না। আপনি ডাটাবেসকে “নতুন ট্রিক” শেখাতে পারেন, এবং তবু ট্রানজ্যাকশন, অনুমতি ও কুয়েরি অপটিমাইজেশন একটি সমন্বিত পদ্ধতিতে কাজ করবে।
এই মানসিকতা আজকের PostgreSQL ইকোসিস্টেমে (এবং অনেক Postgres-প্রেরিত সিস্টেমে) স্পষ্টভাবে দেখা যায়। কোর ফিচারের জন্য অপেক্ষা না করে টিমগুলো ভেটেড এক্সটেনশন গ্রহণ করতে পারে যা SQL এবং অপারেশনাল টুলিংয়ের সাথে মসৃণভাবে একীভূত হয়।
উচ্চ-স্তরের সাধারণ উদাহরণগুলিঃ
কী হলো: Postgres ডিজাইন লক্ষ্য হিসেবে “ডাটাবেস কী করতে পারে তা বদলানো” নিল—এবং সেই ধারণা আজও আধুনিক ডেটা প্ল্যাটফর্মগুলোকে প্রভাবিত করে।
ডাটাবেস কেবল তথ্য রাখার বিষয়ে নয়—এগুলো নিশ্চিত করে তথ্যটি সঠিক থাকে, এমনকি অনেক কিছু একযোগে ঘটলেও। সেইটাই ট্রানজ্যাকশন ও কনকারেন্সি কন্ট্রোলের কাজ, এবং এটিই একটি বড় কারণ কেন SQL সিস্টেমগুলো বাস্তব ব্যবসায়িক কাজের জন্য বিশ্বাসযোগ্য।
একটি ট্রানজ্যাকশন হচ্ছে পরিবর্তনের এমন একটি গ্রুপ যা সফল বা ব্যর্থ—দুইটিই একসাথে হতে হবে।
যদি আপনি একাউন্ট থেকে আরেকটায় টাকা ট্রান্সফার করেন, অর্ডার রাখেন বা ইনভেন্টরি আপডেট করেন, আপনি "আকারে অসম্পূর্ণ" ফলাফলকে ভোগ করতে পারবেন না। একটি ট্রানজ্যাকশন নিশ্চিত করে আপনি এমন সমস্যায় পড়বেন না—উদাহরণস্বরূপ, একটি অর্ডার গ্রাহককে চার্জ করেছে কিন্তু স্টক রিজার্ভ করে নি—বা স্টক হ্রাস হয়েছে কিন্তু কোনো অর্ডার রেকর্ড হয়নি।
ব্যবহারিকভাবে, ট্রানজ্যাকশনগুলো দেয়:
কনকারেন্সি মানে অনেক মানুষ (এবং অ্যাপ) একই সময়ে ডেটা পড়া ও বদলানো: কাস্টমার চেকআউট, সাপোর্ট এজেন্টদের অ্যাকাউন্ট এডিট, ব্যাকগ্রাউন্ড জবগুলো স্ট্যাটাস আপডেট, অ্যানালিস্টদের রিপোর্ট চলানো।
বিনা নিয়মের, কনকারেন্সি সৃষ্টি করে সমস্যাগুলো যেমন:
একটি প্রভাবশালী পদ্ধতি হচ্ছে MVCC। ধারণাগতভাবে, MVCC কিছুক্ষণ রেকর্ডের একাধিক সংস্করণ রাখে, যাতে রিডাররা একটি স্থির স্ন্যাপশট পড়তে পারে যখন লেখকরা আপডেট করছে।
বড় সুবিধা হল যে রিডস প্রায়ই রাইটসকে ব্লক করে না, এবং লেখকরা দীর্ঘ-চলমান কুয়েরির পেছনে বারবার আটকে পড়ে না। আপনি এখনো সঠিকতা পান, কিন্তু অপেক্ষা কম থাকে।
আজকের ডাটাবেসগুলো প্রায়ই मिक্সড ওয়ার্কলোড সেবা করে: উচ্চ-ভলিউম অ্যাপ রাইটস প্লাস ড্যাশবোর্ড, কাস্টমার ভিউ এবং অপারেশনাল অ্যানালিটিক্সের জন্য ঘন ঘন রিড। আধুনিক SQL সিস্টেমগুলি MVCC, স্মার্ট লকিং এবং আইসোলেশন লেভেলগুলির মতো কৌশলের ওপর নির্ভর করে গতি এবং সঠিকতার মধ্যে ভারসাম্য রাখতে—যাতে আপনি স্কেল করতে পারেন কার্যকলাপ ছাড়াই ডেটার ওপর বিশ্বাস হারাতে।
রো-অরিয়েন্টেড ডাটাবেস ট্রানজ্যাকশন প্রসেসিংয়ের জন্য তৈরি: অনেক ছোট রিড ও রাইট, সাধারণত একটি গ্রাহক/অর্ডার/অ্যাকাউন্ট একবারে ছোঁয়া হয়। সেই ডিজাইন দারুণ যখন আপনাকে একটি পুরো রেকর্ড দ্রুত ফেচ বা আপডেট করতে হয়।
একটি স্প্রেডশীট ভাবুন। একটি রো স্টোর প্রতিটি সারিকে আলাদা ফোল্ডারে রেখে দেওয়ার মতো: যখন আপনি “অর্ডার #123 সম্পর্কে সবকিছু” চান, আপনি একটাই ফোল্ডার তোলেন। একটি কলাম স্টোর হলো কলাম অনুযায়ী ফাইলিং: এক ড্রয়ার “order_total” জন্য, আরেক ড্রয়ার “order_date” জন্য, আরেকটি “customer_region” জন্য।
অ্যানালিটিক্সে, আপনি বিরলভাবে পুরো ফোল্ডারই চান—সাধারণত প্রশ্ন থাকে “গত কোর্টারের অঞ্চন অনুযায়ী মোট রাজস্ব কত?” এই কোয়েরি মিলিয়ন রেকর্ডের বেশ কয়েকটি ফিল্ডই হবে।
অ্যানালিটিক্স কোয়েরি প্রায়ই:
কলামার স্টোরে, ইঞ্জিন শুধু কোয়েরিতে উল্লিখিত কলামগুলোই পড়ে, বাকি থেকে যায়। ডিস্ক থেকে কম ডেটা পড়া (এবং মেমরিতে কম মুভমেন্ট) প্রায়ই সবচেয়ে বড় পারফরম্যান্স লাভ।
কলামগুলোতে প্রায়ই পুনরাবৃত্তি মান থাকে (রিজিয়ন, স্ট্যাটাস, ক্যাটেগরি)। তাই এরা অত্যন্ত কম্প্রেসযোগ্য—এবং কম্প্রেশান দ্রুততার কারণও হতে পারে, কারণ সিস্টেম কম বাইট পড়ে এবং কখনও কখনও কম্প্রেসড ডেটার ওপরই অপারেট করতে পারে আরও দক্ষভাবে।
কলাম স্টোরগুলো OLTP-প্রথম ডাটাবেস থেকে অ্যানালিটিক্স-প্রথম ইঞ্জিন এ একটি বড় ধাক্কা দিয়েছে, যেখানে স্ক্যানিং, কম্প্রেশন এবং দ্রুত অ্যাগ্রিগেট এখন প্রাথমিক ডিজাইন লক্ষ্য।
Vertica হল সবচেয়ে স্পষ্ট বাস্তব উদাহরণ কিভাবে স্টোনব্রেকারের অ্যানালিটিক্স ডাটাবেস ধারণাগুলো একটি প্রোডাক্টে রূপ নিয়েছে। এটি কলামার স্টোরেজ থেকে শিক্ষা নিয়ে একটি বিতরণকৃত ডিজাইনের সাথে জোড়া দিল যা একটি নির্দিষ্ট সমস্যার জন্য—বড় পরিমাণ ডেটা থাকলে দ্রুত অ্যানালিটিক SQL কুয়েরি উত্তর দেওয়া—লক্ষ্য করে তৈরি।
MPP হল massively parallel processing। সহজভাবে ভাবুন: অনেক মেশিন মিলে এক SQL কুয়েরি নিয়ে কাজ করে।
একটি সার্ভার যাতে সব ডেটা পড়ে এবং সব গ্রুপিং ও সোর্ট করে, তার বদলে ডেটা নোডগুলিতে ভাগ করা থাকে। প্রতিটি নোড তার নিজের অংশে প্রসেস করে, এবং সিস্টেম আংশিক ফলাফলগুলো মিলিয়ে চূড়ান্ত উত্তর দেয়।
যদি ডেটা ভালভাবে বণ্টিত থাকে এবং কুয়েরি প্যারালালাইজেবল হয়, তাহলে একটি কুয়েরি যা এক বক্সে মিনিট নিত পারে, ক্লাস্টারে সেকেন্ডে নেমে যেতে পারে।
Vertica-ধাঁচের MPP অ্যানালিটিক্স সিস্টেমগুলো তখনই উজ্জ্বল যখন আপনার অনেক সারি থাকে এবং আপনি সেগুলো স্ক্যান, ফিল্টার ও অ্যাগ্রিগেট করতে চান দক্ষভাবে। সাধারণ ইউজকেসগুলিঃ
MPP অ্যানালিটিক্স ইঞ্জিনগুলো ট্রানজ্যাকশনাল (OLTP) সিস্টেমের সরাসরি বিকল্প নয়। এগুলো অপ্টিমাইজ করা হয় অনেক সারি পড়ার এবং সারাংশ হিসাব করার জন্য, ছোট আপডেটে দক্ষতা নয়।
সাধারণ ট্রেড-অফগুলোঃ
মূল ধারণা হচ্ছে ফোকাস: Vertica ও অনুরূপ সিস্টেমগুলো তাদের গতি লাভ করে স্টোরেজ, কম্প্রেশন ও প্যারালাল এক্সিকিউশনের জন্য টিউন করে—তারপর ট্রানজ্যাকশনাল সিস্টেমরা এড়িয়ে যাওয়া সীমাবদ্ধতাগুলি গ্রহণ করে।
একটি ডাটাবেস "স্টোর ও কোয়েরি" করতে পারলেও অ্যানালিটিক্সের জন্য ধীর লাগতে পারে। পার্থক্য প্রায়ই আপনি কী লিখেন না, বরং কিভাবে ইঞ্জিন সেটা এক্সিকিউট করে: কিভাবে পেজগুলো পড়ে, ডেটা CPU-তে মুভ করে, মেমরি ব্যবহার করে, এবং অনাবশ্যক কাজ কমায়।
স্টোনব্রেকারের অ্যানালিটিক্স-কেন্দ্রিক প্রকল্পগুলো এই ধারণাকে এগিয়ে নিয়েছিল যে কোয়েরি পারফরম্যান্স হচ্ছে এক্সিকিউশন সমস্যা যতটা স্টোরেজ সমস্যা। এই চিন্তা টিমগুলোকে এক-রো লুকআপ টিউন করা ছাড়িয়ে মিলিয়ন বা বিলিয়ন রো জুড়ে লম্বা স্ক্যান, জয়েন ও অ্যাগ্রিগেশন অপ্টিমাইজ করার দিকে সরিয়ে দিয়েছে।
অনেক পুরনো ইঞ্জিন কোয়েরি "টুপল-অ্যাট-এ-টাইম" (এক-কতি-এক)ভাবে প্রসেস করে, যা অনেক ফাংশন কল ও ওভারহেড তৈরি করে। ভেক্টরাইজড এক্সিকিউশন সেই মডেল উল্টো করে: ইঞ্জিন একটি ব্যাচ (ভেক্টর) মানের উপর টাইট লুপে কাজ করে।
সরলভাবে বলতে, এটা যেমন এক আইটেম করে না বলে কার্টে করে মুদি নিয়ে যাওয়া—ব্যাচিং ওভারহেড কমায় এবং আধুনিক CPU-গুলোকে তাদের শক্তিতে চালানো যায়: প্রত্যাশিত লুপ, কম ব্রাঞ্চ, ভালো ক্যাশ ব্যবহার।
দ্রুত অ্যানালিটিক্স ইঞ্জিনগুলো অতি CPU ও ক্যাশ-দক্ষ থাকতে চাই। এক্সিকিউশন উদ্ভাবনগুলো সাধারণত ফোকাস করে:
এই ধারণাগুলো গুরুত্বপূর্ণ কারণ অ্যানালিটিক্স কোয়েরিগুলো প্রায়ই মেমরি ব্যান্ডউইডথ ও ক্যাশ মিস দ্বারা সীমাবদ্ধ, কাঁচা ডিস্ক স্পিড নয়।
মডার্ন ডেটা ওয়্যারহাউস ও SQL ইঞ্জিন—ক্লাউড ওয়্যারহাউস, MPP সিস্টেম, এবং দ্রুত ইন-প্রসেস অ্যানালিটিক্স টুল—প্রায়শই ভেক্টরাইজড এক্সিকিউশন, কম্প্রেশন-অ্যাওয়্যার অপারেটর এবং ক্যাশ-ফ্রেন্ডলি পাইপলাইনগুলো স্ট্যান্ডার্ড হিসেবে ব্যবহার করে।
যদিও ভেন্ডররা "অটোস্কেলিং" বা "স্টোরেজ ও কম্পিউট আলাদা" মতো ফিচার বাজারজাত করে, দৈনন্দিন গতি আপনি অনুভব করেন তাতে এগুলোর এক্সিকিউশন মডেলই বড় ভূমিকা রাখে।
প্লাটফর্ম মূল্যায়ন করলে শুধু কি তারা স্টোর করে তা নয়, কিভাবে তারা জয়েন ও অ্যাগ্রিগেট চালায় তার ব্যাখ্যাও জিজ্ঞেস করুন—এবং তাদের এক্সিকিউশন মডেল কি অ্যানালিটিক্সের জন্য তৈরি।
স্ট্রিমিং ডেটা সহজভাবে হচ্ছে ধারাবাহিকভাবে আগত ইভেন্টসের স্রোত—যেমন একটি ক্রেডিট-কার্ড সোয়াইপ, সেন্সর রিডিং, পণ্যের পেজে ক্লিক, একটি প্যাকেজ স্ক্যান, বা লোগ লাইন। প্রতিটি ঘটনা রিয়েল-টাইমে আসে এবং থামে না।
প্রথাগত ডাটাবেস ও ব্যাচ পাইপলাইনগুলো দুর্দান্ত যখন আপনি অপেক্ষা করতে পারেন: গতকালের ডেটা লোড করুন, রিপোর্ট চালান, ড্যাশবোর্ড প্রকাশ করুন। কিন্তু রিয়েল-টাইমের চাহিদা পরের ঘণ্টার জবের জন্য অপেক্ষা করে না।
যদি আপনি কেবল ব্যাচে ডেটা প্রসেস করেন, আপনি প্রায়ই পান:
স্ট্রিমিং সিস্টেমগুলো continuous computation—ইভেন্ট আসার সঙ্গে সঙ্গে আপডেট হওয়া ফলাফল—কে কেন্দ্র করে ডিজাইন করা।
একটি কন্টিনিউয়াস কোয়েরি এমন একটি SQL-রকম কুয়েরি যা কখনো "শেষ" হয় না। বদলে এটা নতুন ইভেন্ট আসার সাথে সাথে ফলাফল আপডেট করে।
স্ট্রিমগুলো অপরিমেয় (শুধু শেষ হয় না), তাই স্ট্রিমিং সিস্টেমগুলো উইন্ডো ব্যবহার করে গণনা সীমাবদ্ধ রাখতে। উইন্ডো হতে পারে সময়ভিত্তিক ("সর্বশেষ 5 মিনিট"), প্রতি মিনিট, বা ইভেন্ট-ভিত্তিক (শেষ 1000 ইভেন্ট)। এর ফলে রোলিং কাউন্ট, অ্যাভারেজ বা টপ-এন তালিকা পরিচালনা করা যায় পুনরায় সবকিছু প্রসেস না করে।
স্টোনব্রেকার বহু দশক ধরে যুক্তি দিয়েছেন যে ডাটাবেসগুলো সবই সাধারণ-উদ্দেশ্যের না হওয়াই ভাল। কারণ সাধারণ: বিভিন্ন ওয়ার্কলোড বিভিন্ন ডিজাইন পছন্দকে পুরস্কৃত করে। যদি আপনি একজায়গায় এক কাজের জন্য কঠোরভাবে অপ্টিমাইজ করেন (যেমন ছোট ট্রানজ্যাকশান আপডেট), সাধারণত আপনি আরেক কাজকে ধীর করে ফেলবেন (যেমন রিপোর্টিংয়ের জন্য বিলিয়ন সারি স্ক্যান)।
অধিকাংশ আধুনিক স্ট্যাক একাধিক ডেটা সিস্টেম ব্যবহার করে কারণ ব্যবসা একাধিক ধরনের উত্তর চায়:
এটাই বাস্তবে "ওয়ান সাইজ ডোন্ট ফিট অল": আপনি সেই কাজের আকৃতির সাথে মেলে এমন ইঞ্জিন বেছে নেন।
নিচের দ্রুত ফিল্টার ব্যবহার করুন যখন আরেকটি সিস্টেম বাছাই (বা ন্যায্যতা দেখানো) করছেন:
একাধিক ইঞ্জিন স্বাস্থ্যকর হতে পারে, কিন্তু কেবল তখনই যখন প্রতিটির একটা স্পষ্ট ওয়ার্কলোড থাকে। নতুন টুল পায়ের জায়গা পেয়ে উঠুক না—প্রতিস্থাপন করার আগে সেটি খরচ, ল্যাটেন্সি বা ঝুঁকি কমায় কিনা তা প্রমাণ করুক।
ওপরে উল্লেখিত চেকলিস্ট মেনে কয়েকটি কম ইঞ্জিন ধরে শক্ত অপারেশনাল মালিকানা রাখুন, এবং যেসব কম্পোনেন্টের স্পষ্ট উদ্দেশ্য নেই সেগুলো অবসান করুন।
স্টোনব্রেকারের গবেষণার থ্রেডগুলো—রিলেশনাল ভিত্তি, এক্সটেনসিবিলিটি, কলাম স্টোর, MPP এক্সিকিউশন, এবং "ওয়ার্কের জন্য সঠিক টুল"—আধুনিক ডেটা প্ল্যাটফর্মগুলোর ডিফল্ট আকারে দেখা যায়।
ওয়্যারহাউস SQL অপ্টিমাইজেশন, কলামার স্টোরেজ, এবং প্যারালাল এক্সিকিউশনের বহু দশকের কাজের প্রতিফলন। যখন আপনি বড় টেবিলের ওপর দ্রুত ড্যাশবোর্ড দেখতে পান, প্রায়শই আপনি কলাম-ভিত্তিক ফরম্যাট, ভেক্টরাইজড প্রসেসিং ও MPP-স্টাইল স্কেলিং দেখেন।
লেকহাউস ওয়্যারহাউস ধারণা (স্কিমা, পরিসংখ্যান, ক্যাসিং, কস্ট-ভিত্তিক অপটিমাইজেশন) নেয় কিন্তু তা খোলা ফাইল ফরম্যাট ও অবজেক্ট স্টোরেজে রাখে। "স্টোরেজ সস্তা, কম্পিউট ইলাস্টিক" স্থানান্তর নতুন; কিন্তু কুয়েরি ও ট্রানজ্যাকশন চিন্তাভাবনা নতুন নয়।
MPP অ্যানালিটিক্স সিস্টেম (শেয়ারড-নথিং ক্লাস্টার) সরাসরি সেই গবেষণার বংশধর যা প্রমাণ করে আপনি ডেটা পার্টিশন করে, ডেটার কাছে কম্পিউটেশন পাঠিয়ে এবং জয়েন/অ্যাগ্রিগেশনের সময় ডেটা মুভমেন্ট সাবধানে ম্যানেজ করে SQL স্কেল করতে পারেন।
SQL হয়েছে ওয়্যারহাউস, MPP ইঞ্জিন এবং এমনকি "লেক" কোয়েরি স্তরের একটি সাধারণ ইন্টারফেস। টিমরা এটাকে ব্যবহার করে:
একইভাবে যখন এক্সিকিউশন বিভিন্ন ইঞ্জিনে হয় (ব্যাচ, ইন্টারঅ্যাকটিভ, স্ট্রিমিং), ব্যবহারকারী-ফেসিং ভাষা অনেক সময় SQL-ই থাকে।
ফ্লেক্সিবল স্টোরেজ স্ট্রাকচার-অবধি নয়। পরিষ্কার স্কিমা, ডাটা মিষ্ট্য ব্যাখ্যা ও নিয়ন্ত্রিত বিবর্তন ডাউনস্ট্রিম ব্রেকেজ কমায়।
ভাল গভর্ন্যান্স কাগজপত্র নয়—এটা ডেটাকে নির্ভরযোগ্য করা: ধারাবাহিক সংজ্ঞা, মালিকানা, কোয়ালিটি চেক ও অ্যাকসেস কন্ট্রোল।
প্ল্যাটফর্ম মূল্যায়ন করলে প্রশ্ন করুন:
যদি কোনও ভেন্ডর এই মৌলিকগুলোকে সাধারণ ভাষায় ম্যাচ করতে না পারে, তাহলে "ইনোভেশন" সম্ভবত প্রায়ই প্যাকেজিং।
স্টোনব্রেকারের থ্রুপ্লাইন সহজ: ডাটাবেসগুলো সবচেয়ে ভালো কাজ করে যখন সেগুলো নির্দিষ্ট কাজের জন্য ডিজাইন করা হয়—এবং যখন সেগুলো সেই কাজ বদলালে অভিযোজ্য হতে পারে।
ফিচার তুলনা করার আগে, আপনি আসলেই কী করতে চান তা লিখে রাখুন:
একটি ব্যবহারযোগ্য নিয়ম: যদি আপনি আপনার ওয়ার্কলোড কয়েক বাক্যে বর্ণনা করতে না পারেন (কুয়েরি প্যাটার্ন, ডেটা সাইজ, ল্যাটেন্সি চাহিদা, কনকারেন্সি), আপনি বাজে শব্দভাণ্ডারের ওপর কেনাকাটা করবেন।
টিমগুলো কতবার চাহিদা বদলে যায় তা হালকা অনুধাবন করে না: নতুন ডেটা টাইপ, নতুন মেট্রিক, নতুন কপ্লায়েন্স রুল, নতুন কনজিউমার।
রুটিন পরিবর্তনকে ঝুঁকিহীন করে এমন প্ল্যাটফর্ম ও ডেটা মডেল পছন্দ করুন:
দ্রুত উত্তরগুলো কেবল মূল্যবান যদি সেগুলো সঠিক। অপশন মূল্যায়ন করলে জিজ্ঞেস করুন সিস্টেম কিভাবে সামলায়:
একটি ছোট "প্রুফ উইথ আপনার ডেটা" চালান, কেবল ডেমো নয়:
অনেক গাইডেন্স কেবল "ঠিক ইঞ্জিন বেছে নাও"তে থেমে যায়, কিন্তু টিমগুলোর অ্যাপ ও ইনভেন্টরি টুলগুলোও সেই ইঞ্জিনের চারপাশে বানাতে হয়: অ্যাডমিন প্যানেল, মেট্রিকস ড্যাশবোর্ড, ইনজেশন সার্ভিস, ব্যাক-অফিস ওয়ার্কফ্লো।
আপনি যদি দ্রুত প্রোটোটাইপ করতে চান বিনা পুনর্নির্মাণের, তাহলে একটি ভাইব-কোডিং প্ল্যাটফর্ম যেমন Koder.ai আপনাকে চ্যাট-ড্রিভেন ওয়ার্কফ্লো থেকে ওয়েব অ্যাপ (React), ব্যাকএন্ড সার্ভিস (Go + PostgreSQL) এবং মোবাইল ক্লায়েন্ট (Flutter) ঝটপট স্পিন-আপ করতে সাহায্য করতে পারে। এটা প্রায়ই উপকারী যখন আপনি স্কিমা ডিজাইন নিয়ে দ্রুত ইটারেট করছেন, একটি ছোট ইন্টার্নাল “ডেটা প্রোডাক্ট” বানাচ্ছেন, বা আপনার ওয়ার্কলোড কিভাবে আচরণ করে তা লং-টার্ম ইনফ্রাসট্রাকচারে কমিট করার আগে যাচাই করছেন।
যদি আপনি গভীরতর যেতে চান, খুঁজে দেখুন কলামার স্টোরেজ, MVCC, MPP এক্সিকিউশন, এবং স্ট্রিম প্রসেসিং। আরও এক্সপ্লেইনার আছে /blog এ।
তিনি এমন এক বিরল ব্যক্তি যাঁর গবেষণায় তৈরি সিস্টেমগুলো বাস্তব পণ্যের ডিজাইনে ঢুকে গেছে। Ingres (SQL + কোয়েরি অপটিমাইজেশন), Postgres (এক্সটেন্সিবিলিটি + MVCC ধারণা), এবং Vertica (কলামার + MPP অ্যানালিটিক্স) থেকে প্রমাণিত ধারণাগুলো আজকের ওয়্যারহাউস, OLTP ডাটাবেস এবং স্ট্রিমিং প্ল্যাটফর্মগুলোর মধ্যে দেখা যায়।
SQL জিতেছে কারণ এটি আপনাকে কি চান তা বর্ণনা করতে দেয়, আর ডাটাবেস নির্ধারণ করে কিভাবে সেটা দক্ষভাবে নেওয়া হবে। এই বিচ্ছেদ ফলে মিলেছে:
কস্ট-বেসড অপ্টিমাইজার টেবিল পরিসংখ্যান ব্যবহার করে সম্ভাব্য কোয়েরি প্ল্যানগুলো তুলনা করে সর্বনিম্ন প্রত্যাশিত খরচ (I/O, CPU, মেমরি) বেছে নেয়। ব্যবহারিক ভাবে, এটা সাহায্য করে:
MVCC (Multi-Version Concurrency Control) অল্প সময়ের জন্য রেকর্ডের একাধিক সংস্করণ রাখে, যাতে রিডাররা স্থিতিশীল স্ন্যাপশট পড়তে পারে যখন লেখকরা আপডেট করছে। দৈনন্দিনভাবে:
তবে লক্ষ্য রাখুন—পুরোনো সংস্করণগুলো জমে যেতে পারে, তাই ক্লিনআপ/রক্ষণাবেক্ষণ পরিকল্পনা প্রয়োজন।
এক্সটেনশিবিলিটি মানে ডাটাবেসকে নিরাপদভাবে নতুন ক্ষমতা যোগ করার ক্ষমতা—টাইপ, ফাংশন, ইনডেক্স—বিনা ইঞ্জিন ফর্ক বা পুনর্লিখনের। এটা কাজে লাগে যখন আপনি:
অভিযোগবিহীন নিয়ম: এক্সটেনশনগুলোকে ডিপেন্ডেন্সি হিসেবে বিবেচনা করুন—ভারশনিং, আপগ্রেড টেস্ট এবং কাকে ইনস্টল করার অনুমতি আছে তা সীমাবদ্ধ করুন।
রো স্টোরগুলো চমৎকার যখন আপনি প্রায়ই পুরো রেকর্ড পড়েন/লিখেন (OLTP). কলাম স্টোরগুলো চমৎকার যখন আপনি অনেক সারি স্ক্যান করেন কিন্তু কয়েকটি ফিল্ডই ছোঁয় (অ্যানালিটিক্স).
সরল কৌশল:
MPP (massively parallel processing) ডেটাকে নোডে ভাগ করে এক SQL কোয়েরি একযোগে অনেক মেশিন চালায়। এটা মানায় যখন:
কিন্তু লক্ষ্য রাখুন: ডেটা ডিস্ট্রিবিউশন সিদ্ধান্ত, জয়েনের সময় শাফল খরচ এবং উচ্চ-ফ্রিকোয়েন্সি সিঙ্গেল-রো আপডেটের জন্য দুর্বল ইউজারফ্রেন্ডলিনেস এইগুলোর ঝুঁকি।
ভেক্টরাইজড এক্সিকিউশন ডেটাকে ব্যাচ (ভেক্টর) হিসেবে প্রক্রিয়া করে, এক-রো-প্রতি-বার মডেলের পরিবর্তে, ওভারহেড কমায় এবং CPU ক্যাশ ব্যবহার বাড়ায়। ফলাফলঃ
ব্যাচ সিস্টেমগুলো পার্মিট হলে কাজ করে; তাজা তথ্য দরকার হলে সেগুলো ধীরবেগী। স্ট্রিমিং সিস্টেমগুলো ইভেন্টকে ধারাবাহিক ইনপুট হিসেবে দেখে এবং ইনক্রিমেন্টালভাবে ফলাফল গণনা করে।
স্ট্রিমিং সাধারণত কার্যকর যখন:
স্ট্রিমিং ব্যবস্থাগুলো সীমাবদ্ধ রাখতে "উইন্ডো" (যেমন শেষ 5 মিনিট) ব্যবহার করে।
একাধিক সিস্টেম স্বাস্থ্যকর হতে পারে, কিন্তু প্রতিটিতে স্পষ্ট ওজার্কলোড থাকা উচিত এবং বিপদ/খরচ কমানোর বাস্তব সুবিধা দিতে হবে। স্প্রল কমানোর জন্য:
