শিখুন কীভাবে কলাম-কেন্দ্রিক ডাটাবেস কলাম অনুসারে ডেটা সংরক্ষণ করে, কার্যকরভাবে কম্প্রেস ও স্ক্যান করে এবং BI কুয়েরিগুলোকে দ্রুত করে। রো স্টোরের সাথে তুলনা করুন এবং উপযুক্তটি নির্বাচন করুন।
এনালিটিক্স এবং রিপোর্টিং কুয়েরিগুলো BI ড্যাশবোর্ড, সাপ্তাহিক KPI ইমেইল, “গত ত্রৈমাসিকে কেমন করেছিলাম?” রিভিউ এবং “জার্মানিতে কোন মার্কেটিং চ্যানেল সর্বোচ্চ লাইফটাইম ভ্যালু এনেছে?” মতো অন-দ-ফ্লাই প্রশ্ন চালায়। এগুলো সাধারণত রিড-হেভি এবং প্রচুর ঐতিহাসিক ডেটার সারসংক্ষেপে মনোযোগী।
একটি একক কাস্টমার রেকর্ড ফেচ করার পরিবর্তে, এনালিটিক্স কুয়েরিগুলো প্রায়ই:
দুটি সূত্রই ঐতিহ্যবাহী ডাটাবেস ইঞ্জিনকে কষ্ট দেয়:
বড় স্ক্যানগুলো ব্যয়বহুল। অনেক সারি পড়া মানে অনেক ডিস্ক ও মেমরি কার্যকলাপ, এমনকি চূড়ান্ত আউটপুট ছোট হলেও।
কনকারেন্সি বাস্তব। একটি ড্যাশবোর্ড “একটি কুয়েরি” নয়—এটি অনেক চার্ট একসাথে লোড করা, বহু ব্যবহারকারীর দ্বারা গুণিত, এছাড়াও নির্ধারিত রিপোর্ট এবং অনুসন্ধান সমান্তরালে চলছে।
কলাম-কেন্দ্রিক সিস্টেমগুলো স্ক্যান এবং এগ্রিগেটগুলোকে দ্রুত এবং পূর্বানুমেয় করে তুলতে চায়—অften কম খরচে—এবং ড্যাশবোর্ডের জন্য উচ্চ কনকারেন্সি সমর্থন করে।
সতেজতা (freshness) আলাদা দিক। অনেক এনালিটিক্স সেটআপ সাব-সেকেন্ড আপডেট ত্যাগ করে দ্রুত রিপোর্টিং পেতে ব্যাচ লোডিং করে (প্রতি কয়েক মিনিট বা ঘণ্টাভিত্তিক)। কিছু প্ল্যাটফর্ম নিকট-রিয়েল-টাইম ইনজেশন সমর্থন করে, কিন্তু আপডেট ও ডিলিট এখনও ট্রানজেকশনাল সিস্টেমের তুলনায় জটিল হতে পারে।
কলাম-কেন্দ্রিক ডাটাবেসগুলো মূলত OLAP-শৈলীর কাজের জন্য তৈরি।
কলাম-কেন্দ্রিক ডাটাবেস বোঝার সবচেয়ে সহজ উপায় হল টেবিলটি ডিস্কে কিভাবে বিন্যস্ত তা কল্পনা করা।
ধরে নিন একটি টেবিল orders:\n\n| order_id | customer_id | order_date | status | total |\n|---:|---:|---|---|---:|\n| 1001 | 77 | 2025-01-03 | shipped | 120.50 |\n| 1002 | 12 | 2025-01-03 | pending | 35.00 |\n| 1003 | 77 | 2025-01-04 | shipped | 89.99 |\n
একটি রো স্টোরে, ডাটাবেস একই সারির মানগুলো পরস্পরের পাশে রাখে। ধারণাগতভাবে এটি এরকম:
যখন আপনার অ্যাপ প্রায়ই পুরো রেকর্ড দরকার (যেমন “order 1002 নাও এবং তার status আপডেট কর”), তখন এটি উপযুক্ত।
একটি কলাম স্টোরে, একই কলামের মানগুলো একসাথে রাখা হয়:
order_id: 1001, 1002, 1003, …status: shipped, pending, shipped, …total: 120.50, 35.00, 89.99, …এনালিটিক্স কুয়েরি প্রায়ই কয়েকটি কলামই স্পর্শ করে কিন্তু অনেক সারি স্ক্যান করে। উদাহরণস্বরূপ:
SUM(total) প্রতি দিনের জন্যAVG(total) প্রতি কাস্টমারGROUP BY status করে অর্ডার কটি আছে গোনাকলামার স্টোরে, “এক্সে-রেভিনিউ পার ডে” মত কুয়েরি শুধু order_date এবং total পড়তে পারে, পুরো সারি টেনে আনার বদলে। কম ডেটা পড়া মানে দ্রুত স্ক্যান—এটিই কলাম স্টোরের মূল সুবিধা।
কলামার স্টোরেজ দ্রুত কারণ বেশিরভাগ রিপোর্ট আপনার ডেটার অধিকাংশ অংশ প্রয়োজন করে না। যদি একটি কুয়েরি কেবলি কয়েকটি ফিল্ড ব্যবহার করে, কলাম-কেন্দ্রিক ডাটাবেস শুধু সেই কলামগুলোই ডিস্ক থেকে পড়তে পারে—সম্পূর্ণ সারি টেনে আনার পরিবর্তে।
ডেটা স্ক্যান করা প্রায়ই সীমাবদ্ধ হয় কত দ্রুত আপনি স্টোরেজ থেকে মেমোরিতে বাইট সরাতে পারেন (এবং তারপর CPU-তে)। একটি রো স্টোর সাধারণত পুরো সারি পড়ে, যার মানে আপনি অনেক “অতিরিক্ত” মান লোড করেন যা আপনি চাননি।
কলামার স্টোরেজে, প্রতিটি কলাম তার নিজস্ব ধারাবাহিক এলাকায় থাকে। তাই “total revenue by day” কুয়েরি কেবল:
পড়বে। বাকি সব (নাম, ঠিকানা, নোট, ডজনখানেক বিরল বৈশিষ্ট্য) ডিস্কে থাকবে।
এনালিটিক্স টেবিল সময়ের সাথে চওড়া হয়ে যায়: নতুন প্রোডাক্ট অ্যাট্রিবিউট, মার্কেটিং ট্যাগ, অপারেশনাল ফ্ল্যাগ ইত্যাদি। রিপোর্টগুলো সাধারণত ছোট সাবসেটই স্পর্শ করে—প্রায়ই 5–20 কলাম 100+ থেকে।
কলামার স্টোরেজ সেই বাস্তবতার সাথে মানানসই। এটি অনবশ্যক কলামগুলো টেনে নিয়ে আসা এড়ায় যা চওড়া টেবিলকে ব্যয়বহুল করে।
“Column pruning” মানে ডাটাবেস কুয়েরি যে কলামগুলো রেফার করে না সেগুলো স্কিপ করে। এটা কমায়:
ফলশ্রুতিতে বড় ডেটাসেটে স্ক্যান দ্রুত হয়, যেখানে অনাবশ্যক ডেটা পড়ার খরচ কুয়েরি সময়কে প্রাধান্য দেয়।
কম্প্রেশন হল কলাম-কেন্দ্রিক ডাটাবেসের একটি শান্ত সুপারপাওয়ার। কলাম-আধারিত স্টোরেজে প্রতিটি কলাম সাধারণত একই ধরনের মান ধারণ করে (তারিখ, দেশ, স্ট্যাটাস কোড), এবং একই ধরনের মানগুলো খুব ভাল কম্প্রেস হয়—প্রায়শই রো-ভিত্তিক স্টোরেজের তুলনায় অনেক বেশি।
ধরুন order_status কলামে প্রায়শই "shipped", "processing" বা "returned" আছে, মিলিয়নবার পুনরাবৃত্তি। বা একটি টাইমস্ট্যাম্প কলাম যেখানে মান ক্রমান্বয়ে বাড়ে। কলাম স্টোরে সেই পুনরাবৃত্তি বা পূর্বানুমেয় প্যাটার্নগুলো একসঙ্গে গ্রুপ করা হয়, তাই ডাটাবেস কম বিটে সেগুলো উপস্থাপন করতে পারে।
একাধিক কৌশল একসাথে ব্যবহার করা হয়, উদাহরণ:
ছোট ডেটা মানে ডিস্ক বা অবজেক্ট স্টোরেজ থেকে কম বাইট টানা এবং মেমোরি ও CPU ক্যাশে কম ডেটা চলমান। রিপোর্টিং কুয়েরিগুলো যেগুলো অনেক সারি স্ক্যান করে কিন্তু কয়েকটি কলামই ব্যবহার করে, সেখানে কম্প্রেশন I/O অনেক হারে কমাতে পারে—অften এনালিটিক্সে এটি সবচেয়ে ধীর অংশ।
একটি ভালো বোনাস: অনেক সিস্টেম কম্প্রেসড ডেটাতে কার্যকরভাবে কাজ করতে পারে (বা বড় ব্যাচে ডিকম্প্রেস করে), ফলে এগ্রিগেট যেমন SUM, COUNT, GROUP-BY ইত্যাদি চালাতে উচ্চ থ্রুপুট বজায় থাকে।
কম্প্রেশন বিনামূল্যে নয়। ইঞ্জিন ইনজেসশনের সময় ডেটা কম্প্রেস করতে এবং কুয়েরি এক্সিকিউশনের সময় ডিকম্প্রেস করতে CPU সাইকেল ব্যয় করে। বাস্তবে, এনালিটিক্স ওয়ার্কলোডগুলি প্রায়শই I/O সেভিংয়ের কারণে জিতে যায়—কিন্তু খুব CPU-বন্ধ ওয়ার্কলোড বা অত্যন্ত সতেজ ডেটার ক্ষেত্রে ভারসাম্য বদলে যেতে পারে।
কলামার স্টোরেজ আপনাকে কমবাইট পড়তে সাহায্য করে। ভেক্টরাইজড প্রসেসিং পড়া হওয়া বাইটগুলো মেমোরিতে থাকা অবস্থায় দ্রুত গণনা করতে সাহায্য করে।
প্রচলিত ইঞ্জিনগুলি প্রায়শই এক সারি করে মূল্যায়ন করে: একটি সারি লোড করা, শর্ত পরীক্ষা করা, একটি এগ্রিগেট আপডেট করা, পরবর্তী সারি। এই পদ্ধতি ছোট অপারেশনের অনেক তৈরি করে এবং ক্রমাগত শাখা সৃষ্টি করে, যা CPU কে অবাঞ্ছিত ওভারহেড করায়।
ভেক্টরাইজড এক্সিকিউশন মডেল উল্টে দেয়: ডাটাবেস মানগুলোকে বৃহৎ ব্যাচে (প্রায়শই হাজার হাজার মান এক কলাম থেকে একসাথে) প্রক্রিয়াকরণ করে। একই লজিক বারবার প্রতি সারির জন্য কল করার বদলে ইঞ্জিন tight loops চালায় অ্যারে-গুলোর উপর।
ব্যাচ প্রসেসিং উন্নত করে:
ভাবুন: “2025-এ category = 'Books' এর অর্ডারগুলোর মোট রাজস্ব।”
একটি ভেক্টরাইজড ইঞ্জিন করতে পারে:
category মানের একটি ব্যাচ লোড করে একটি বুলিয়ান মাস্ক তৈরি করবে যেখানে category = “Books”.order_date মানের সংশ্লিষ্ট ব্যাচ লোড করে মাস্কটিকে 2025 ধরে সীমাবদ্ধ করবে।revenue মানের ব্যাচ লোড করে মাস্কের সাহায্যে সেগুলো যোগ করবে—প্রায়শই SIMD ব্যবহার করে একাধিক সংখ্যার যোগ একসাথে করে।কলাম ও ব্যাচে কাজ করার কারণে ইঞ্জিন অনাবশ্যক ফিল্ড স্পর্শ করা বাঁচায় এবং প্রতি-সারি ওভারহেড এড়ায়—এটি কলাম-অরিয়েন্টেড সিস্টেমগুলোকে এনালিটিক্সে খুব দ্রুত করে তোলে।
এনালিটিক্যাল কুয়েরিগুলো প্রায়শই অনেক সারি স্পর্শ করে: “মাস অনুযায়ী রাজস্ব দেখাও”, “দেশ অনুযায়ী ইভেন্ট কাটা”, “শীর্ষ 100 প্রোডাক্ট খোঁজো।” OLTP সিস্টেমে, ইনডেক্স হলো প্রধান হাতিয়ার কারণ কুয়েরিগুলো সাধারণত ছোট সংখ্যক সারি আনে (প্রাইমারি কী, ইমেইল, order_id দিয়ে)। এনালিটিক্সে অনেক ইনডেক্স গঠন ও রক্ষণ রাখা ব্যয়বহুল হতে পারে, এবং অনেক কুয়েরিই বড় অংশ স্ক্যান করে—তাই কলাম স্টোরগুলো স্ক্যানকে স্মার্ট ও দ্রুত করতে মনোযোগ দেয়।
অনেক কলাম-অরিয়েন্টেড ডাটাবেস প্রতিটি ডেটা ব্লকের জন্য সহজ মেটাডেটা ট্র্যাক করে (কখনও কখনও এটিকে “stripe”, “row group” বা “segment” বলা হয়), যেমন সেই ব্লকের সর্বনিম্ন ও সর্বোচ্চ মান।
যদি আপনার কুয়েরি ফিল্টার করে amount > 100, এবং একটি ব্লকের মেটাডেটা বলে max(amount) = 80, ইঞ্জিন সেই সম্পূর্ণ ব্লকটি amount কলামের জন্য পড়বে না—ঐতিহ্যবাহী ইনডেক্স ছাড়াই। এই "zone maps" সল্প স্টোরেজ নিয়েও দ্রুত পরীক্ষা করা যায় এবং বিশেষত সেই কলামগুলোর ক্ষেত্রে ভালো কাজ করে যেগুলো স্বাভাবিকভাবেই সর্টেড।
পার্টিশনিং একটি টেবিলকে আলাদা অংশে ভাগ করে, প্রায়ই তারিখ অনুযায়ী। ধরুন ইভেন্টগুলো দিনে পার্টিশন করা আছে এবং আপনার রিপোর্ট জিজ্ঞাসা করে WHERE event_date BETWEEN '2025-10-01' AND '2025-10-31'। ডাটাবেস অক্টোবর ছাড়া সব পার্টিশন উপেক্ষা করে এবং শুধুমাত্র প্রাসঙ্গিক পার্টিশনগুলো স্ক্যান করবে।
এতে I/O র নাটকীয়ভাবে কমে কারণ আপনি কেবল ব্লকগুলোই স্কিপ করছেন না—আপনি ফাইল বা টেবিলের বড় শারীরিক অংশই স্কিপ করছেন।
যদি ডেটা সাধারণত event_date, customer_id বা country-এর মতো সাধারণ ফিল্টার কী দিয়ে সাজানো থাকে (বা ক্লাস্টার করা), তাহলে মিলযুক্ত মানগুলো একসাথে থাকার প্রবণতা বেশি। এতে পার্টিশন প্রুনিং ও জোন-ম্যাপের কার্যকারিতা বাড়ে, কারণ অপ্রাসঙ্গিক ব্লকগুলো দ্রুত min/max চেকে ফেলাযায় এবং বাদ পড়ে।
কলাম-অরিয়েন্টেড ডাটাবেস দ্রুত হয় কেবল কম ডেটা পড়ার কারণে নয়—ওই কাজটি তারা প্যারালেল করে পড়ে।
একটি কুয়েরি (যেমন “মাস অনুযায়ী রাজস্ব যোগ”) প্রায়ই মিলিয়ন বা বিলিয়ন মান স্ক্যান করে। কলাম স্টোরগুলো সাধারণত কাজটিকে CPU কোর জুড়ে ভাগ করে: প্রতিটি কোর একই কলামের বিভিন্ন চাংক স্ক্যান করে (বা পার্টিশনগুলোর বিভিন্ন সেট)। একটি দীর্ঘ লাইন না খুলে, আপনি অনেক লেন খুলেছেন।
কারণ কলামার ডেটা বড়, ধারাবাহিক ব্লকে রাখা হয়, প্রতিটি কোর তার ব্লক দক্ষভাবে স্ট্রিম করতে পারে—ক্যাশ ও ডিস্ক ব্যান্ডউইথ ভালভাবে ব্যবহার করে।
যখন ডেটা এক মেশিনের ক্ষমতার বাইরে, ডাটাবেস এটি একাধিক সার্ভারে ছড়ায়। কুয়েরিটি তখন প্রতিটি নোডে পাঠানো হয় এবং প্রতিটি নোড লোকালি স্ক্যান ও আংশিক গণনা করে।
এখানে ডেটা লোকালিটি গুরুত্বপূর্ণ: সাধারণত “কম্পিউটকে ডেটার কাছে নিয়ে যাওয়া” দ্রুত—কারণ নেটওয়ার্ক মেমোরি থেকেও ধীর এবং মাঝেমধ্যে জটিল হয়ে যায় যদি কুয়েরি অনেক মধ্যবর্তী ফলাফল নেটওয়ার্কে স্থানান্তর করে।
অনেক এগ্রিগেশন স্বভাবতই প্যারালেলযোগ্য:
ড্যাশবোর্ডগুলো একই সময়ে অনেক অনুরূপ কুয়েরি ট্রিগার করতে পারে—বিশেষত ঘন্টার শুরুতে বা মিটিংয়ের সময়। কলাম স্টোরগুলো প্রায়ই প্যারালেলিজমকে স্মার্ট শিডিউলিং (এবং কখনও কখনও ফলাফল ক্যাশিং) সঙ্গে মিশিয়ে ল্যাটেন্সি পূর্বানুমেয় রাখে যখন ডজন বা শত শত ব্যবহারকারী চার্ট রিফ্রেশ করে।
কলাম-কেন্দ্রিক ডাটাবেসে আপনি যখন অনেক সারি পড়েন কিন্তু কেবল কিছু কলাম পড়েন, তখন তারা চমৎকার কাজ করে। ট্রেড-অফ হল বারবার একক সারি পরিবর্তন হলে তারা তুলনামূলকভাবে কম আরামদায়ক।
রো স্টোরে, একটি কাস্টমার রেকর্ড আপডেট করা সাধারণত একটি ছোট, ধারাবাহিক অংশ পুনরায় লেখার মতন। কলাম স্টোরে, সেই "এক সারি" বহু আলাদা কলাম ফাইল/সেগমেন্ট জুড়ে ছড়িয়ে থাকে। আপডেট করতে হলে অনেক জায়গায় টাচ করতে হতে পারে, এবং—কারণ কলাম স্টোর কম্প্রেশন ও ঘন-packed ব্লকের উপর নির্ভর করে—একটি ইন-প্লেস পরিবর্তন বড় চাঙ্ক রিরাইট করতে বাধ্য করতে পারে।
বেশিরভাগ বিশ্লেষণাত্মক কলাম স্টোর ব্যবহার করে দুই-ফেজ পদ্ধতি:
এ কারণেই আপনি প্রায়শই “delta + main”, “ingestion buffer”, “compaction” বা “merge” ধরনের শব্দ দেখবেন।
যদি আপনাকে ড্যাশবোর্ডে পরিবর্তনটা সাথে সাথেই দেখাতে হয়, একটি শুদ্ধ কলাম স্টোর ধীর বা ব্যয়বহুল মনে হতে পারে। বহু টিম নিকট-রিয়েল-টাইম রিপোর্টিং (উদাহরণ: 1–5 মিনিট বিলম্ব) গ্রহণ করে যাতে মার্জগুলো দক্ষভাবে ঘটতে পারে এবং কুয়েরিগুলো দ্রুত থাকে।
ঘনঘন আপডেট ও ডিলিট “টোম্বস্টোন” তৈরি করতে পারে (অপসারিত/পুরানো মানের মার্কার) এবং সেগমেন্টগুলো ফ্র্যাগমেন্টেড করে। এটা স্টোরেজ বাড়ায় এবং যতক্ষণ না ভ্যাকুয়াম/কম্প্যাকশন মেইনটেন্যান্স চলে ততক্ষণ কুয়েরি ধীর করে। মেইনটেন্যান্স—সময় নির্ধারণ, রিসোর্স সীমা ও রিটেনশন নীতি পরিকল্পনা—রিপোর্টিং পারফরম্যান্স পূর্বানুমেয় রাখার একটি মূল অংশ।
ভালো মডেলিং ইঞ্জিনের চেয়ে কম গুরুত্বপূর্ণ নয়। কলামার স্টোরেজ দ্রুত স্ক্যান ও এগ্রিগেট করতে পারে, কিন্তু আপনি কিভাবে টেবিল গঠন করেন তা নির্ধারণ করে যে ডাটাবেস কতবার অনাবশ্যক কলাম এড়াতে পারে, ডেটার অংশগুলো স্কিপ করতে পারে, এবং দক্ষ GROUP BY চালাতে পারে।
একটি স্টার স্কিমা একটি কেন্দ্রীয় fact table এবং তার চারপাশে ছোট dimension table গুলি সাজায়। এটি এনালিটিক্স ওয়ার্কলোডের সাথে মানানসই কারণ বেশিরভাগ রিপোর্ট:
কলামার সিস্টেমগুলো উপকৃত হয় কারণ কুয়েরিগুলো সাধারণত চওড়া fact টেবিলের ছোট সাবসেট কলাম স্পর্শ করে।
উদাহরণ:
fact_orders: order_id, order_date_id, customer_id, product_id, quantity, net_revenuedim_customer: customer_id, region, segmentdim_product: product_id, category, branddim_date: date_id, month, quarter, year“মাস ও অঞ্চল অনুযায়ী নেট রাজস্ব” রিপোর্টটি fact_orders থেকে net_revenue এগ্রিগেট করে এবং dim_date ও dim_customer থেকে গ্রুপিং অ্যাট্রিবিউট নেবে।
স্টার স্কিমা জয়েনের উপর নির্ভর করে। অনেক কলাম-অরিয়েন্টেড ডাটাবেস জয়েন ভালোভাবে হ্যান্ডেল করে, কিন্তু জয়েনের খরচ ডেটার আকার এবং কুয়েরি কনকারেন্সির সাথে বাড়তে থাকে।
যদি কোনো ডাইমেনশন অ্যাট্রিবিউট প্রায়ই ব্যবহৃত হয়, তাহলে ডিনর্মালাইজেশন সাহায্য করতে পারে (উদাহরণ: region কে fact_orders-এ কপি করা)। ট্রেড-অফ হল বড় ফ্যাক্ট পংক্তি, মানের ডুপ্লিকেশন ও অ্যাট্রিবিউট পরিবর্তনের সময় অতিরিক্ত কাজ। সাধারণ সমাধান হল ডাইমেনশন রাখুন নর্মালাইজড কিন্তু হট অ্যাট্রিবিউটগুলো কেবল তখনই ফ্যাক্টে কপি করুন যখন এটি প্রকৃতপক্ষে মূল ড্যাশবোর্ডগুলিকে উন্নতি করে।
region, category) এবং সম্ভব হলে সেগুলো কম থেকে মাঝারি কর্ডিনালিটি রাখুন।date_id, তারপর customer_id) যাতে ফিল্টার ও GROUP BY সস্তায় হয়।কলাম-অরিয়েন্টেড ডাটাবেস তখন জিততে অভিলাষী যখন আপনার প্রশ্নগুলো অনেক সারি স্পর্শ করে কিন্তু শুধু একটি কলাম সাবসেট—বিশেষত যখন উত্তরটি একটি এগ্রিগেট (যোগ, গড়, পার্সেন্টাইল) বা গ্রুপেড রিপোর্ট (প্রতি দিন, প্রতি অঞ্চল, প্রতি কাস্টমার সেগমেন্ট) হয়।
টাইম-সিরিজ মেট্রিক্স: CPU ব্যবহার, অ্যাপ ল্যাটেন্সি, IoT সেন্সর রিডিং—এগুলোতে এক সারি প্রতি টাইম-ইন্টারভাল ডেটা থাকে। কুয়েরিগুলো প্রায়ই সময় পরিসর স্ক্যান করে এবং ঘণ্টাভিত্তিক গড় বা সাপ্তাহিক ট্রেন্ড রোলআপ করে।
ইভেন্ট লগ ও ক্লিকস্ট্রিম: পেজ ভিউ, সার্চ, পারচেস—অ্যনালিস্টরা প্রায়শই তারিখ, ক্যাম্পেইন বা ইউজার সেগমেন্ট দিয়ে ফিল্টার করে, তারপর মিলিয়ন বা বিলিয়ন ইভেন্ট জুড়ে কাউন্ট, ফানেল ও কনভার্সন রেট এগ্রিগেট করে।
ফাইনান্স ও ব্যবসায়িক রিপোর্টিং: মাসিক রাজস্ব, কোহর্ট রিটেনশন, বাজেট বনাম বাস্তব ইত্যাদি—ওয়াইড টেবিল থাকলেও কলামার স্টোরেজ স্ক্যানকে কার্যকরি রাখে।
যদি আপনার ওয়ার্কলোড উচ্চ-রেট পয়েন্ট লুকআপ (ID দিয়ে এক ইউজার রেকর্ড ফেচ) বা ছোট ট্রানজেকশনাল আপডেট (একটি অর্ডারের status প্রতি মিনিটে বহু বার আপডেট) দ্বারা প্রাধান্য পায়, তবে রো-অরিয়েন্টেড OLTP ডাটাবেস সাধারণত ভালো ফিট।
কলাম স্টোর ইনসার্ট ও কিছু আপডেট সাপোর্ট করে, কিন্তু ঘনঘন সারি-স্তরের পরিবর্তন ধীর বা অপারেশনালি জটিল হতে পারে (উদাহরণ: মার্জ প্রক্রিয়া, রাইট অ্যামপ্লিফিকেশন, বা দে-ভিউ বিচারে বিলম্বিত দৃশ্যমানতা)।
কমিট করার আগে বেঞ্চমার্ক করুন:
একটি দ্রুত PoC প্রোডাকশন-আকৃতির ডেটা নিয়ে আপনাকে সিন্থেটিক টেস্ট বা ভেন্ডর বেঞ্চমার্কের চেয়ে বেশী তথ্য দেবে।
একটি কলাম-কেন্দ্রিক ডাটাবেস বেছে নেওয়া মানে বেঞ্চমার্ক অনুসরণ করা নয়—বরং সিস্টেমটাকে আপনার রিপোর্টিং বাস্তবতার সাথে মিলানো: কে তা কুয়েরি করবে, কত ঘন ঘন, এবং প্রশ্নগুলো কতটা পূর্বানুমেয়।
কয়েকটি সংকেতের উপর ফোকাস করুন যা সাধারণত সাফল্য নির্ধারণ করে:
সংক্ষিপ্ত উত্তরগুলো আপনার অপশনগুলো দ্রুত সংকুচিত করবে:
অধিকাংশ টিম ডাটাবেস সরাসরি কুয়েরি করে না। নিশ্চিত করুন সামঞ্জস্য:
ছোট কিন্তু বাস্তবসম্মত রাখুন:
যদি একটি প্রার্থী এই মেট্রিকগুলোতে জয়ী হয় এবং অপারেশনাল সুবিধার সঙ্গে মানানসই হয়, সাধারণত সেটাই সঠিক পছন্দ।
কলাম-কেন্দ্রিক সিস্টেমগুলো দ্রুত লাগে কারণ তারা অনাবশ্যক কাজ এড়ায়। তারা কম বাইট পড়ে (শুধু রেফার করা কলামগুলো), সেই বাইটগুলো অত্যন্ত ভালো কম্প্রেস করে (অতএব কম ডিস্ক ও মেমোরি ট্রাফিক), এবং ব্যাচ-ভিত্তিক এক্সিকিউশন করে যা CPU ক্যাশে উপযোগী। কোর ও নোড জুড়ে প্যারালেলিজম যোগ করুন, এবং পুরোনোতে ধীর চালানো রিপোর্টিং কুয়েরিগুলো সেকেন্ডেই শেষ হতে পারে।
গ্রহণের আগে (বা সময়ে) এই লাইটওয়েট প্ল্যানটি ব্যবহার করুন:
কয়েকটি সিগন্যাল ধারাবাহিকভাবে দেখুন:
যদি স্ক্যানগুলো বিশাল হয়, অতিরিক্ত হার্ডওয়্যার যোগ করার আগে কলাম নির্বাচন, পার্টিশন ও সাজানো পুনর্বিবেচনা করুন।
প্রথমে "রিড-মোস্টলি" ওয়ার্কলোডগুলো অফলোড করুন: নাইটলি রিপোর্ট, BI ড্যাশবোর্ড, এবং অ্যাড-হক এক্সপ্লোরেশন। আপনার লেনদেন সিস্টেম থেকে কলাম স্টোরে ডেটা রিপ্লিকেট করুন, সাইড-বাই-সাইড ফলাফল যাচাই করুন, তারপর গ্রাহকগুলোকে এক গ্রুপ করে কনসিউমার সুইচ করুন। একটি রোলব্যাক পথ রাখুন (সংক্ষিপ্ত ডুয়াল-রান), এবং মনিটরিং স্টেবল স্ক্যান ভলিউম ও পূর্বানুমেয় পারফরম্যান্স না দেখালে স্কোপ বাড়াবেন না।
একটি কলাম স্টোর কুয়েরি পারফরম্যান্স উন্নত করে, কিন্তু টিমগুলি প্রায়ই reporting-সামগ্রিক অভিজ্ঞতা তৈরিতে সময় হারায়: একটি অভ্যন্তরীণ মেট্রিক্স পোর্টাল, রোল-বিশেষ অ্যাক্সেস, নির্ধারিত রিপোর্ট ডেলিভারি, এবং এক-অফ বিশ্লেষণ টুল যা পরবর্তীতে স্থায়ী হয়ে যায়।
যদি আপনি সেই অ্যাপ্লিকেশন লেয়ারে দ্রুত এগোতে চান, Koder.ai আপনাকে একটি কাজকরা ওয়েব অ্যাপ (React), ব্যাকএন্ড সার্ভিস (Go) এবং PostgreSQL ইন্টিগ্রেশন একজন চ্যাট-ভিত্তিক প্ল্যান ফ্লো থেকে জেনারেট করতে সাহায্য করতে পারে। বাস্তবে, এটা দ্রুত প্রোটোটাইপ তৈরিতে কাজে লাগে:
Koder.ai সোর্স কোড এক্সপোর্ট, ডিপ্লয়/হোস্টিং, এবং স্ন্যাপশটসহ রোলব্যাক সাপোর্ট করে, তাই আপনি রিপোর্টিং ফিচার Iterate করতে পারেন এবং পরিবর্তনগুলো নিয়ন্ত্রিত রাখতে পারেন—বিশেষত যখন অনেক স্টেকহোল্ডার একই ড্যাশবোর্ডের উপর নির্ভরশীল।
বিশ্লেষণ ও রিপোর্টিং কুয়েরিগুলো হল এমন পাঠ-ভিত্তিক প্রশ্ন যা অনেক ঐতিহাসিক ডেটার সারসংক্ষেপ তৈরি করে—যেমন মাসিক রাজস্ব, ক্যাম্পেইন অনুযায়ী কনভারশন, বা কহর্ট রিটেনশন। এগুলো সাধারণত অনেক সারি স্ক্যান করে, কলামের একটি উপসেট ব্যবহার করে, সংক্ষেপনিক মান (aggregates) হিসাব করে এবং চার্ট বা টেবিলের জন্য ছোট রেজাল্ট সেট রিটার্ন করে।
এগুলো ডাটাবেসকে মূলত দুই কারণে চাপ দেয়:
রো-অরিয়েন্টেড OLTP ইঞ্জিনগুলো এসব করতে পারে, কিন্তু মাত্রা বাড়লে খরচ ও ল্য়েটেন্স অনির্দেশ্য হয়ে উঠতে পারে।
রো স্টোরে একই সারির মানগুলো ডিস্কে পাশাপাশি থাকে, যা এক রেকর্ড ফেচ/আপডেট করার জন্য উপযুক্ত। কলাম স্টোরে একই কলামের মানগুলো পাশাপাশি থাকে, যা সেই কলামগুলো ব্যাপকভাবে স্ক্যান করার ক্ষেত্রে উপযুক্ত।
উদাহরণস্বরূপ, যদি রিপোর্টটিতে শুধু order_date এবং total লাগে, তাহলে কলাম স্টোরটি অনারক্ত কলামগুলো (যেমন status বা customer_id) পড়া এড়িয়ে যেতে পারে।
কারণ বেশিরভাগ এনালিটিক্স কুয়েরি কেবল কলামের ছোট একটি সাবসেট পড়ে। কলাম স্টোরগুলো column pruning প্রয়োগ করে (যা কুয়েরি ব্যবহার করে না সে কলামগুলো এড়িয়ে যায়), ফলে তারা কম বাইট পড়ে।
কম I/O সাধারণত মানে:
কলাম লেআউট সমজাতীয় মানগুলো একসঙ্গে রাখে (তারিখ তারিখের সাথে, দেশ দেশার সাথে), যা খুব ভালো কম্প্রেস হয়।
সাধারণ প্যাটার্নগুলোর মধ্যে আছে:
কম্প্রেশন স্টোরেজ কমায় এবং স্ক্যান দ্রুত করে কারণ I/O কমে, যদিও কম্প্রেস/ডিকম্প্রেসে কিছু CPU ওভারহেড যোগ হয়।
ভেক্টরাইজড এক্সিকিউশন ডেটাকে ব্যাচ হিসেবে প্রসেস করে, সারি-ভিত্তিক একেরপরএক অপারেশনের বদলে।
এর সুবিধা:
ফলত: বড় রেঞ্জ স্ক্যান করলেও দ্রুত গণনা সম্ভব হয়।
অনেক ইঞ্জিন প্রতিটি ডেটা ব্লকের জন্য হালকা মেটাডেটা রাখে (যেমন min/max)। যদি একটি কুয়েরি ফিল্টার কোনো ব্লকের সাথে মিলবে না (উদাহরণ: max(amount) < 100 যখন ফিল্টার amount > 100), ইঞ্জিন সেই ব্লকটি পড়াই বাদ দিতে পারে।
এটি ভালোভাবে কাজ করে যখন এটিকে সংযুক্ত করা হয়:
প্যারালেলিজম দুইভাবে দেখা যায়:
এই "split-and-merge" প্যাটার্নটি গ্রুপ-বাই ও এগ্রিগেশনকে স্কেল করার সময় নেটওয়ার্কে কাঁচা সারি পাঠানোর চেয়ে কার্যকর করে।
একটি “সারি” কলাম সেগমেন্ট জুড়ে ছড়িয়ে থাকার কারণে একক সারি আপডেট করা কঠিন—প্রায়ই বড় কলাম ব্লকগুলো রিরাইট করতে হয়।
সাধারণ কৌশলগুলি:
এই কারণে অনেক টিম near-real-time (উদাহরণ: 1–5 মিনিট) সতেজতা গ্রহণ করে, যেটা দ্রুত কিন্তু ইনস্ট্যান্ট নয়।
প্রোডাকশন-সদৃশ ডেটা ও বাস্তব কুয়েরি নিয়ে বেঞ্চমার্ক করুন:
একটি ছোট PoC (10–20 বাস্তব কুয়েরি) সাধারণত ভেন্ডর বেঞ্চমার্কের চেয়ে বেশি তথ্য দেয়।