SQL বনাম NoSQL — key-value, document, wide-column আর graph database

১ · Relational database যা দেয় — schema, join, transaction আর SQL

পাড়ার মুদি দোকানের খাতার কথা ভাবুন। ভালো দোকানির খাতায় আলাদা পাতা: এক পাতায় ক্রেতার তালিকা (ক্রমিক নম্বর, নাম, ফোন), এক পাতায় দাম, আর বাকির পাতায় শুধু “ক্রেতা ৭, চাল ২ বস্তা, ১২ তারিখ”. নাম-ফোন বারবার লেখা হয় না, তাই ফোন বদলালে এক জায়গায় কাটলেই চলে। “রহিম সাহেবের মোট বাকি?” জানতে দোকানি দুই পাতা মিলিয়ে দেখেন।

এটিই relational database-এর মূল চিন্তা। ডেটা থাকে টেবিলের সারি আর কলামে; প্রতিটি তথ্য এক জায়গায় (normalization), সম্পর্ক বোঝানো হয় id দিয়ে। প্রতিটি সারিকে আলাদা করে চেনায় primary key; অন্য টেবিলের সারির দিকে নির্দেশ করে foreign key. প্রশ্ন করার সময় পাতাগুলো জোড়া দেওয়ার নাম join. সিস্টেম ডিজাইনে relational database বলতে সাধারণত PostgreSQL, MySQL বা ছোট কাজে SQLite-এর কথা ভাবা হয়।

পাঁচটি জিনিস, যা relational database বিনা পরিশ্রমে দেয়

৫ · পরিণত টুল আর মানুষ: backup, replication, monitoring, migration টুল, ORM আর অভিজ্ঞ প্রকৌশলী — কয়েক দশকের জমা অভিজ্ঞতা। রাত ৩টার সমস্যায় পড়া মানুষ আগেও ছিলেন; এই “বিরক্তিকর” সুবিধার মূল্য প্রায়ই সবচেয়ে বেশি।

নিচের এডিটরে একটি কাল্পনিক অনলাইন দোকানের চারটি টেবিল। “চালান” চাপুন: একটি অর্ডারের পাতা join দিয়ে, একটি transaction, আর টেবিল বানানোর সময় কেউ ভাবেনি এমন একটি প্রশ্ন:

-- একটি কাল্পনিক অনলাইন দোকান: প্রতিটি তথ্য এক জায়গায়, সম্পর্ক id দিয়ে
CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT NOT NULL, city TEXT NOT NULL, phone TEXT NOT NULL);
CREATE TABLE products (id INTEGER PRIMARY KEY, name TEXT NOT NULL, price INTEGER NOT NULL,
                       stock INTEGER NOT NULL CHECK (stock >= 0));
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER NOT NULL REFERENCES customers(id),
                     placed_at TEXT NOT NULL);
CREATE TABLE order_items (order_id INTEGER NOT NULL REFERENCES orders(id),
                          product_id INTEGER NOT NULL REFERENCES products(id),
                          qty INTEGER NOT NULL, unit_price INTEGER NOT NULL,
                          PRIMARY KEY (order_id, product_id));
INSERT INTO customers VALUES (1, 'Rina', 'Dhaka', '01700-000001'), (2, 'Arif', 'Rajshahi', '01800-000002'),
                             (3, 'Mitu', 'Khulna', '01900-000003');
INSERT INTO products VALUES (10, 'Rice 5kg', 450, 40), (11, 'Lentils 1kg', 140, 25), (12, 'Tea 400g', 260, 15);
INSERT INTO orders VALUES (1001, 1, '2026-10-01'), (1002, 2, '2026-10-02'), (1003, 1, '2026-10-05');
INSERT INTO order_items VALUES (1001, 10, 1, 450), (1001, 11, 2, 140), (1002, 12, 1, 260),
                               (1003, 10, 2, 450), (1003, 12, 1, 260);
-- 1) অর্ডার 1003-এর পাতা: চারটি টেবিল join করে
SELECT o.id, c.name, c.phone, p.name AS product, i.qty, i.qty * i.unit_price AS line_total
FROM orders o JOIN customers c ON c.id = o.customer_id
JOIN order_items i ON i.order_id = o.id JOIN products p ON p.id = i.product_id
WHERE o.id = 1003;
-- 2) নতুন অর্ডার আর stock কমানো একটি transaction-এ: হয় সব, নয় কিছুই না
BEGIN;
INSERT INTO orders VALUES (1004, 3, '2026-10-06');
INSERT INTO order_items VALUES (1004, 12, 2, 260);
UPDATE products SET stock = stock - 2 WHERE id = 12;
COMMIT;
-- 3) আগে না ভাবা একটি প্রশ্ন: শহরভিত্তিক বিক্রি, schema না বদলেই
SELECT c.city, COUNT(DISTINCT o.id) AS orders, SUM(i.qty * i.unit_price) AS revenue
FROM customers c JOIN orders o ON o.customer_id = c.id JOIN order_items i ON i.order_id = o.id
GROUP BY c.city ORDER BY revenue DESC;
SELECT id, name, stock FROM products;

২ · Relational-এর scaling — বড় যন্ত্র, read replica, তারপর হাতে-করা sharding

রেস্তোরাঁর রান্নাঘর ভাবুন: ভিড় বাড়লে আগে বড় চুলা আর বেশি বাবুর্চি; তারপর বাড়তি ওয়েটার, রান্না তবু এক রান্নাঘরে; শেষে দ্বিতীয় শাখা — আর তখনই ঝামেলা, অর্ডারের অর্ধেক যদি অন্য শাখার ভাঁড়ারে থাকে? Relational database-এর বেড়ে ওঠাও এমন, সাধারণত এই ক্রমে:

সাধারণ PostgreSQL বা MySQL নিজে থেকে sharding করে না; অ্যাপকে, অথবা মাঝের একটি স্তরকে, কাজগুলো হাতে করতে হয়। তখন পাঁচটি সমস্যা প্রায় নিশ্চিতভাবে আসে:

1. Routing: প্রতিটি query কোন shard-এ যাবে — সাধারণত customer_id-এর মতো key-এর hash থেকে।
2. Shard পেরিয়ে join: অ্যাপের কোডে — সব shard-এ প্রশ্ন পাঠিয়ে ফল মেলানো।
3. Shard পেরিয়ে transaction: এক shard-এর টাকা কমিয়ে অন্য shard-এ বাড়ানো আর একটি সাধারণ BEGIN … COMMIT নয় — লাগে distributed transaction বা saga (পর্ব ২৫)।
4. Resharding: shard ভরে গেলে চালু অবস্থায় ডেটা সরানো (পর্ব ১৬ আর ২৩)।
5. বাকি সব N বার: schema migration, backup, monitoring, unique ID — প্রতিটি shard-এ।

এই কাজ সহজ করতে MySQL-এর জন্য Vitess বা PostgreSQL-এর জন্য Citus-এর মতো open-source স্তর আছে (Vitess-এর শুরু YouTube-এ, প্রকল্পের প্রকাশিত ইতিহাস অনুযায়ী)। তবু shard key-এর সিদ্ধান্ত আর shard পেরোনো প্রশ্নের খরচ আপনার নকশারই অংশ থাকে।

৩ · NoSQL কেন এল — web scale, নমনীয় schema আর ভাগ করা যায় এমন data model

২০০০-এর দশকে সার্চ, বিজ্ঞাপন আর অনলাইন কেনাকাটার কয়েকটি সেবার কাছে একটি যন্ত্র যথেষ্ট ছিল না, আর হাতে-করা sharding ছিল যন্ত্রণার। তারা প্রশ্নটি উল্টে দেয়: join আর বহু-সারির transaction ছেড়ে দিলে কি ডেটা সহজে হাজারো যন্ত্রে ছড়ানো যায়?

চারটি প্রেরণা

1. ভাগ করা সহজ এমন data model: যে ডেটা সবসময় একটি key দিয়ে একসাথে পড়া হয় — একটি কার্ট, একজন ব্যবহারকারীর timeline — সেটি পুরোটা এক partition-এ রাখলে কোনো প্রশ্নেই যন্ত্র পেরোতে হয় না। তখন যন্ত্র যোগ করলে ক্ষমতা প্রায় সমানুপাতে বাড়ে (horizontal scaling). এই একসাথে-থাকা এককের নাম “aggregate” (শব্দটি Domain-Driven Design থেকে নেওয়া; NoSQL-এর আলোচনায় জনপ্রিয় করেন Sadalage ও Fowler, ২০১২)।
2. বিকল হলেও চালু থাকা: কয়েকটি data center-এ কপি, কোনো কপি না পৌঁছালেও লেখা গ্রহণ — বিনিময়ে কিছুক্ষণের অমিল (eventual consistency).
3. নমনীয় schema: বিচিত্র গঠনের ডেটায় (মোবাইল ফোন আর শাড়ির spec আলাদা) প্রতিটি বদলে ALTER TABLE ছাড়াই নতুন field.
4. কোডের সাথে মিল: নেস্টেড object আর সমতল টেবিলের অমিল — impedance mismatch — document-এ প্রায় নেই।

৪ · Key-value আর document — key দিয়ে আনা, document-এ গুছিয়ে রাখা

Key-value store

রেলস্টেশনের মালপত্রের লকারের মতো: টোকেন দিলে বাক্স ফেরত, কিন্তু “লাল ব্যাগ কোন বাক্সে?” — উত্তর কর্মচারীর কাছে নেই। Key-value store-এ প্রতিটি মান একটি key-এর নিচে; কাজ মূলত তিনটি — GET, SET, DEL, সাথে প্রায়ই মেয়াদ (TTL).

• শক্তি: দ্রুত আর অনুমেয় latency (memory-তে এক মিলিসেকেন্ডেরও কম); key-এর hash দিয়ে সহজে ভাগ।
• দুর্বলতা: মান দিয়ে খোঁজা, সম্পর্ক বা (key সাজানো না থাকলে) পরিসর ধরে প্রশ্ন — কোনোটিই নেই।
• উদাহরণ: Redis আর Memcached (cache, session, counter), etcd (ছোট config), RocksDB (অ্যাপের ভেতরে বসানো engine), আর DynamoDB-ধাঁচের store — partition key-এর সাথে sort key, তাই partition-এর ভেতরে সাজানো প্রশ্নও চলে।
• সিস্টেম ডিজাইনে কোথায়: session (পর্ব ১৫), cache (পর্ব ২৮ আর ৩০), rate limit-এর counter (পর্ব ৪৯), আসনের ১০ মিনিটের hold. Memory-ভিত্তিক store-কে টাকার হিসাবের একমাত্র ঠিকানা বানাবেন না (DBMS কোর্সের Redis পর্ব)।

Document database

Document database-এ প্রতিটি রেকর্ড একটি স্বয়ংসম্পূর্ণ JSON-ধাঁচের document (MongoDB-তে binary রূপ BSON), গঠন একেকটির একেক রকম হতে পারে। Key-value-এর সাথে বড় পার্থক্য: ডেটাবেস ভেতরটা দেখে — field ধরে secondary index, আর একটি document-এর ভেতরের বদল atomic. উদাহরণ: MongoDB, Couchbase, CouchDB; আর relational-এর ভেতরেই document রাখার উপায় PostgreSQL-এর JSONB.

নকশার সবচেয়ে বড় সিদ্ধান্ত: সম্পর্কিত ডেটা ভেতরে রাখবেন (embedding), নাকি আলাদা document-এ রেখে id দিয়ে নির্দেশ করবেন (referencing)?

এবার একই অর্ডার দুই মডেলে, ধাপে ধাপে। খেয়াল করুন কোন প্রশ্ন কোথায় সস্তা, আর কোথায় দামি:

customers    1 │ Rina │ Dhaka │ 01700-000001
orders    1003 │ customer_id 1 │ 2026-10-05
order_items 1003 │ product 10 │ qty 2 │ 450
            1003 │ product 12 │ qty 1 │ 260
products    10 │ Rice 5kg │ 450
            12 │ Tea 400g │ 260

SEARCH o USING INTEGER PRIMARY KEY (rowid=?)      → 1003
SEARCH c USING INTEGER PRIMARY KEY (rowid=?)      → Rina
SEARCH i USING INDEX sqlite_autoindex_order_items_1 (order_id=?)
SEARCH p USING INTEGER PRIMARY KEY (rowid=?)      → Rice, Tea

{ _id: 1003, placed_at: "2026-10-05",
  customer: { id: 1, name: "Rina", phone: "01700-000001" },
  items: [ { product_id: 10, name: "Rice 5kg", qty: 2, unit_price: 450 },
           { product_id: 12, name: "Tea 400g", qty: 1, unit_price: 260 } ],
  total: 1160 }

db.orders.findOne({ _id: 1003 })      // shard key _id → এক node-এ পুরো অর্ডার

ক) পণ্য 10 মোট কতটি বিক্রি হলো?
   relational: SELECT SUM(qty) FROM order_items WHERE product_id = 10
   document  : সব অর্ডারের items খুলে aggregation,
               নয়তো "items.product_id"-এ নতুন index
খ) Rina ফোন নম্বর বদলালেন
   relational: customers-এ একটি সারি
   document  : তাঁর প্রতিটি অর্ডারে কপি — বদলাবেন, না ইতিহাস হিসেবে রাখবেন?

Embed না reference — সংখ্যায় দেখুন

একটি কাল্পনিক বাস-যাত্রীদের ফোরাম: ২০০টি পোস্ট, ৫০ জন ব্যবহারকারী, মন্তব্য ভারী-লেজের বণ্টনে, পোস্ট ০ ভাইরাল — ৩,০০০টি মন্তব্য (সব ধরা যাক)। তিন মডেল: সব মন্তব্য পোস্টের ভেতরে (embed), আলাদা collection-এ (reference), আর পোস্টে শুধু সর্বশেষ ১০টি, পুরোটা আলাদা (subset). প্রশ্ন দুটি: Q1 পোস্ট ০ আর তার সর্বশেষ ১০টি মন্তব্য; Q2 u7-এর সব মন্তব্য (user field-এ index ধরে)। আকার = JSON লেখার দৈর্ঘ্য:

// Document store: embed a post's comments, reference them, or embed only the latest 10 (seeded)
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rand = mulberry32(20), POSTS = 200, USERS = 50, W = "bus seat route trip fare late ac good bad".split(" ");
const words = n => Array.from({ length: n }, () => W[Math.floor(rand() * W.length)]).join(" ");
const size = doc => JSON.stringify(doc).length;            // ASCII only, so characters = bytes
// ধরা যাক: comments per post are heavy-tailed (Pareto), and post 0 went viral with 3000
const posts = [], comments = [];
for (let p = 0; p < POSTS; p++) {
  posts.push({ _id: p, title: words(6), author: "u" + (p % USERS), body: words(120) });
  const k = p === 0 ? 3000 : Math.floor(6 / (1 - rand()) ** (1 / 1.6)) - 6;
  for (let j = 0; j < k; j++)
    comments.push({ _id: comments.length, post: p, user: "u" + Math.floor(rand() * USERS), t: j, text: words(5 + Math.floor(rand() * 20)) });
}
const byPost = p => comments.filter(c => c.post === p);
const strip = ({ post, ...c }) => c;                          // an embedded comment needs no post id
const embed = posts.map(p => ({ ...p, comments: byPost(p._id).map(strip) }));
const subset = posts.map(p => ({ ...p, latest: byPost(p._id).slice(-10).map(strip) }));
const sum = a => a.reduce((s, x) => s + x, 0), kb = b => (b / 1024).toFixed(1) + " KB";
const sizes = embed.map(size).sort((a, b) => b - a);
console.log("comments " + comments.length + " | embedded post sizes: viral " + kb(size(embed[0])) +
  ", next " + kb(sizes[1]) + ", median " + kb(sizes[POSTS / 2]));
// Q1: post 0 with its latest 10 comments.  Q2: every comment written by user u7 (index on user)
const mine = comments.filter(c => c.user === "u7"), hit = [...new Set(mine.map(c => c.post))];
const rows = [
  ["embed",     1, 1,  size(embed[0]),                                       hit.length,  sum(hit.map(p => size(embed[p]))), 1],
  ["reference", 2, 11, size(posts[0]) + sum(byPost(0).slice(-10).map(size)), mine.length, sum(mine.map(size)), 1],
  ["subset",    1, 1,  size(subset[0]),                                      mine.length, sum(mine.map(size)), 2]];
console.log("model      Q1 queries  docs      bytes | Q2 docs      bytes | writes per comment");
for (const [m, q, d1, b1, d2, b2, w] of rows)
  console.log(m.padEnd(10) + String(q).padStart(11) + String(d1).padStart(6) + kb(b1).padStart(11) + " |" +
    String(d2).padStart(8) + kb(b2).padStart(11) + " |" + String(w).padStart(8));
const avg = sum(comments.map(c => size(strip(c)))) / comments.length;
console.log("avg embedded comment " + avg.toFixed(0) + " B: a 16 MiB document is full after ~" + Math.floor(16 * 1024 * 1024 / avg) + " comments");

comments 4523 | embedded post sizes: viral 323.5 KB, next 16.7 KB, median 1.0 KB
model      Q1 queries  docs      bytes | Q2 docs      bytes | writes per comment
embed               1     1   323.5 KB |      27   410.2 KB |       1
reference           2    11     1.8 KB |     102    11.9 KB |       1
subset              1     1     1.7 KB |     102    11.9 KB |       2
avg embedded comment 109 B: a 16 MiB document is full after ~154126 comments

৫ · Wide-column আর graph — আগে প্রশ্ন, পরে টেবিল; আর যেখানে সম্পর্কই তথ্য

Wide-column store

ডাকঘরে চিঠি বাছাইয়ের কথা ভাবুন: আগে জেলা ধরে বস্তায় ভাগ, প্রতিটি বস্তা নির্দিষ্ট ট্রাকে; বস্তার ভেতরে চিঠি থানা আর বাড়ির নম্বরের ক্রমে, তাই একটি এলাকার চিঠি এক টানে ওঠে। কিন্তু “লাল খামের সব চিঠি” খুঁজতে সব ট্রাকের সব বস্তা খুলতে হবে।

Wide-column store-এ বস্তাটি partition, জেলাটি partition key — এর hash ঠিক করে সারি কোন node-এ যাবে (Cassandra-তে consistent hashing-এর ring, পর্ব ১৬); বস্তার ভেতরের ক্রম clustering key. লেখা সস্তা, কারণ ভেতরে সাধারণত LSM-tree: লেখা memory-তে জমে, পরে disk-এ একটানা (পর্ব ১৯)। উদাহরণ: Apache Cassandra, ScyllaDB, HBase, আর managed সেবা হিসেবে Google-এর Bigtable.

নিয়মটি কঠোর: একটি প্রশ্ন যেন একটি partition-এ শেষ হয়. তাই নকশা শুরু হয় প্রশ্নের তালিকা থেকে, আর প্রতিটি বড় প্রশ্নের জন্য আলাদা টেবিল। একটি কাল্পনিক বাস-টিকিট সেবায় ধাপে ধাপে দেখুন:

Q1  একটি রুটে একটি দিনের trip, ছাড়ার সময়ের ক্রমে   — খুব ঘনঘন
Q2  একটি trip-এর সব আসনের অবস্থা                — খুব ঘনঘন
Q3  একজন যাত্রীর সাম্প্রতিক টিকিট, নতুনটি আগে      — মাঝারি

CREATE TABLE trips_by_route_date (
  route text, travel_date date, dep_time text, trip_id uuid,
  operator text, bus_type text, fare int,
  PRIMARY KEY ((route, travel_date), dep_time, trip_id)
);   -- ( partition key ), clustering key

SELECT dep_time, operator, fare FROM trips_by_route_date
WHERE route = 'DHK-RAJ' AND travel_date = '2026-12-10'
  AND dep_time >= '08:00' AND dep_time < '12:00';

CREATE TABLE seats_by_trip (
  trip_id uuid, seat_no text, status text, held_until timestamp,
  PRIMARY KEY ((trip_id), seat_no)
);

CREATE TABLE tickets_by_passenger (
  passenger_id uuid, booked_at timestamp, ticket_id uuid,
  route text, travel_date date, dep_time text, seat_no text,  -- কপি
  PRIMARY KEY ((passenger_id), booked_at, ticket_id)
) WITH CLUSTERING ORDER BY (booked_at DESC, ticket_id ASC);

-- একটি বুকিং = দুই টেবিলে লেখা
UPDATE seats_by_trip SET status = 'booked'
  WHERE trip_id = ? AND seat_no = 'B4' IF status = 'free';
INSERT INTO tickets_by_passenger (...) VALUES (...);

SELECT * FROM trips_by_route_date WHERE operator = 'OP-7';
-- Cassandra চালায় না: ALLOW FILTERING চায়, মানে সব node-এর সব partition পড়া

CREATE TABLE trips_by_operator_date (
  operator text, travel_date date, dep_time text, trip_id uuid, route text,
  PRIMARY KEY ((operator, travel_date), dep_time, trip_id)
);   -- আর পুরোনো সব trip এখানে ভরাট (backfill)

এবার সংখ্যায়: আটটি রুট, ডিসেম্বরের ৩০ দিন, দিনে ২০–৪০টি trip (ধরা যাক), চারটি node; partition-এর node ঠিক হয় partition key-এর FNV-1a hash থেকে। প্রতিটি প্রশ্নে গোনা হলো ছোঁয়া partition আর node, পড়া সারি আর ফেরত সারি:

// Wide-column model: partition key (route, date), clustering key dep — which partitions does a query touch?
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
function fnv1a(s) { let h = 0x811c9dc5;
  for (let i = 0; i < s.length; i++) { h ^= s.charCodeAt(i); h = Math.imul(h, 0x01000193) >>> 0; } return h; }
const rand = mulberry32(23), NODES = 4, pad = n => String(n).padStart(2, "0"), home = pk => fnv1a(pk) % NODES;
const routes = ["DHK-RAJ", "DHK-CTG", "DHK-SYL", "DHK-KHL", "DHK-BSL", "DHK-RNG", "CTG-SYL", "DHK-CXB"];
const nodes = Array.from({ length: NODES }, () => new Map());   // node -> (partition key -> sorted rows)
for (const r of routes) for (let d = 1; d <= 30; d++) {         // ধরা যাক: 20-40 trips per route per day
  const pk = r + "|2026-12-" + pad(d), rows = [];
  for (let k = 20 + Math.floor(rand() * 21); k > 0; k--)
    rows.push({ dep: pad(5 + Math.floor(rand() * 19)) + ":" + pad(5 * Math.floor(rand() * 12)), op: "OP-" + (1 + Math.floor(rand() * 12)) });
  rows.sort((a, b) => a.dep < b.dep ? -1 : a.dep > b.dep ? 1 : 0);  // clustering key keeps rows in order
  nodes[home(pk)].set(pk, rows);
}
const total = nodes.reduce((s, m) => s + [...m.values()].reduce((t, r) => t + r.length, 0), 0), A = "DHK-RAJ|2026-12-10";
console.log("partitions per node: " + nodes.map(m => m.size).join(" / ") + "   rows in total: " + total);
console.log("partition " + A + " lives on node " + home(A) + " with " + nodes[home(A)].get(A).length + " rows, sorted by dep");
function query(label, plan) {
  const touched = new Set(), s = { parts: 0, read: 0, out: 0 };
  plan((pk, n) => { touched.add(n); s.parts++; return nodes[n].get(pk) || []; }, s);
  console.log(label.padEnd(38) + String(s.parts).padStart(6) + String(touched.size).padStart(7) + String(s.read).padStart(7) + String(s.out).padStart(6));
}
console.log("query".padEnd(38) + " parts  nodes   read   out");
query("A: route+date, 08:00 <= dep < 12:00", (get, s) => {       // full partition key known: one partition, a slice
  const rows = get(A, home(A)); let i = 0;
  while (i < rows.length && rows[i].dep < "08:00") i++;          // a real store binary-searches the sorted rows
  for (; i < rows.length && rows[i].dep < "12:00"; i++) { s.read++; s.out++; }
});
query("B: op = 'OP-7' (not in the key)", (get, s) =>             // ALLOW FILTERING: every partition on every node
  nodes.forEach((m, n) => m.forEach((_, pk) => get(pk, n).forEach(r => { s.read++; if (r.op === "OP-7") s.out++; }))));
query("C: route only, IN (30 dates)", (get, s) => {              // a partition is found only from its full key
  for (let d = 1; d <= 30; d++) { const pk = "DHK-RAJ|2026-12-" + pad(d); get(pk, home(pk)).forEach(() => { s.read++; s.out++; }); }
});

partitions per node: 60 / 62 / 64 / 54   rows in total: 7178
partition DHK-RAJ|2026-12-10 lives on node 2 with 34 rows, sorted by dep
query                                  parts  nodes   read   out
A: route+date, 08:00 <= dep < 12:00        1      1      8     8
B: op = 'OP-7' (not in the key)          240      4   7178   566
C: route only, IN (30 dates)              30      4    878   878

Graph database

কিছু প্রশ্নে সম্পর্কই মূল তথ্য: “বন্ধুর বন্ধুদের মধ্যে কে এই এলাকায়?”, “এই পাঁচটি অ্যাকাউন্ট কি একই ডিভাইসে জোড়া?” Graph database-এ ডেটা node (সত্তা) আর edge (সম্পর্ক), দুটোতেই property; প্রশ্ন মানে graph traversal — edge ধরে হাঁটা। Neo4j-ধাঁচের ডেটাবেসে প্রতিটি node নিজের edge-গুলোর সরাসরি ঠিকানা রাখে (index-free adjacency), তাই এক ধাপ হাঁটার খরচ নির্ভর করে প্রতিবেশীর সংখ্যায়, পুরো টেবিলের আকারে নয়। Relational-এ প্রতি ধাপে একটি join, আর ধাপ বাড়লে খরচ দ্রুত বাড়ে।

দুর্বলতা: graph ভাগ করা কঠিন — যন্ত্র পেরোনো প্রতিটি edge এক network hop; বিশাল সমষ্টিতেও সুবিধা নেই। তাই অনেক দল edge টেবিল relational-এই রাখে। উদাহরণ: Neo4j (Cypher), JanusGraph; গভীরে DBMS কোর্সের Graph, search আর time-series পর্ব।

আরও দুটি বিশেষ store — time-series আর search engine

• Time-series database: CPU-র মাপ, sensor-এর রিডিং — সময়-চিহ্নিত, প্রায় শুধু নতুন লেখা, প্রশ্ন সময়ের সীমা ধরে; compression, পুরোনো ডেটার গড় (downsampling) আর মেয়াদে মোছা। উদাহরণ: InfluxDB, TimescaleDB (PostgreSQL-এর extension), আর metric-এর জন্য Prometheus-এর নিজস্ব storage (পর্ব ৫০)।
• Search engine: শব্দ থেকে নথির তালিকা — search index — দিয়ে পূর্ণ লেখায় খোঁজা, প্রাসঙ্গিকতা আর বানান-ভুল সহ্য করা; Lucene-এর ওপর Elasticsearch, OpenSearch, Solr. সাধারণত মূল ডেটার দ্বিতীয় কপি, একটু দেরিতে হালনাগাদ। বিস্তারিত পর্ব ২৭-এ।

৬ · NoSQL-এ data modelling — প্রশ্ন ধরে নকশা, পড়ার জন্য কপি আর তার দাম

Relational-এ আপনি আগে ডেটাকে normalise করেন, তারপর যেকোনো প্রশ্ন করেন। NoSQL-এ, বিশেষ করে key-value আর wide-column-এ, ক্রম উল্টো — যে প্রশ্ন, সেই আকার. অভিজ্ঞ দলগুলো মোটামুটি এই পাঁচ ধাপ মানে:

1. Access pattern-এর তালিকা: প্রশ্ন, সেকেন্ডে কতবার, latency-লক্ষ্য (পর্ব ২)।
2. প্রশ্নপিছু একটি partition: উত্তর যেন এক জায়গায় থাকে।
3. Denormalise আর কপি: denormalization — পড়ার পথে join না রেখে তথ্য কপি।
4. কপি কে হালনাগাদ করবে: একই অনুরোধে, নাকি পরে event বা CDC দিয়ে — তখন কিছুক্ষণ কপিগুলো আলাদা।
5. Partition-এর আকার আর hot key: কোনো partition সীমাহীন বাড়বে না তো? (অনুশীলন ৩)

Single-table design — এক টেবিলে কয়েক রকম সত্তা

DynamoDB-কে ঘিরে একটি প্রচলিত নকশা-রীতি আছে — single-table design. ভিন্ন ধরনের সত্তা একই টেবিলে থাকে, সাধারণ নামের দুটি key দিয়ে: PK (partition key) আর SK (sort key). যেগুলো একসাথে লাগে, সেগুলোর PK এক, তাই একটি query-তেই সব আসে — যেন আগে থেকে join করা:

PK = CUST#1-এর একটি query-তে Rina-র profile আর সব অর্ডার, তারিখের ক্রমে; SK-এর শুরু ORDER#2026-10 হলে শুধু অক্টোবরের। দাম — টেবিলটি পড়া কঠিন, নতুন access pattern-এ বদলানো কঠিন, বিশ্লেষণে ডেটা রপ্তানি লাগে। অনেকে বেশিরভাগ দলকে প্রশ্নপিছু সহজ আলাদা টেবিলের পরামর্শ দেন — এটি কৌশল, সবার জন্য নিয়ম নয়।

কপির দাম — হাতে-কলমে

Denormalisation শুধু NoSQL-এর নয়; relational-এও আগে থেকে join করা টেবিল বা materialized view রাখা হয়। নিচের এডিটরে অংশ ১-এর চারটি টেবিল আছে; বানানো হবে join-করা orders_view, তারপর দেখা হবে পড়া কতটা সহজ হয় — আর একটি ফোন নম্বর বদলালে কী ঘটে:

-- denormalise: অর্ডারের পাতার জন্য আগে থেকে join করে রাখা একটি টেবিল
CREATE TABLE orders_view AS
SELECT o.id AS order_id, c.id AS customer_id, c.name AS customer_name, c.phone AS customer_phone,
       p.name AS product, i.qty, i.qty * i.unit_price AS line_total
FROM orders o JOIN customers c ON c.id = o.customer_id
JOIN order_items i ON i.order_id = o.id JOIN products p ON p.id = i.product_id;
CREATE INDEX idx_view_order ON orders_view(order_id);
-- পড়ার পথ: join-এ চারটি টেবিলে খোঁজ, view-তে একটিতে
EXPLAIN QUERY PLAN
SELECT c.name, c.phone, p.name, i.qty FROM orders o JOIN customers c ON c.id = o.customer_id
JOIN order_items i ON i.order_id = o.id JOIN products p ON p.id = i.product_id WHERE o.id = 1003;
EXPLAIN QUERY PLAN
SELECT customer_name, customer_phone, product, qty FROM orders_view WHERE order_id = 1003;
-- দাম ১: একই নাম আর ফোন নম্বর কয়েক জায়গায় কপি
SELECT customer_name, COUNT(*) AS copies FROM orders_view GROUP BY customer_id;
-- দাম ২: Rina ফোন বদলালেন, কিন্তু লেখা হলো শুধু customers-এ (update anomaly)
UPDATE customers SET phone = '01700-999999' WHERE id = 1;
SELECT v.order_id, v.product, v.customer_phone AS copy, c.phone AS truth
FROM orders_view v JOIN customers c ON c.id = v.customer_id
WHERE v.customer_phone <> c.phone;
-- সারাতে প্রতিটি কপিতে লেখা: একটি বদল, অনেক লেখা (write fan-out)
UPDATE orders_view SET customer_phone = '01700-999999' WHERE customer_id = 1;

৭ · Distributed SQL, consistency আর প্রচলিত ভুল ধারণা

NewSQL আর distributed SQL — SQL রেখেই ছড়ানো

SQL, join আর ACID রেখেও কি ডেটাবেস নিজেই ডেটা ভাগ আর কপি করতে পারে? এর উত্তর NewSQL বা distributed SQL: ডেটা নিজে থেকে খণ্ডে (range) ভাগ হয়, প্রতিটি খণ্ডের কপিগুলো consensus-এ (Raft বা Paxos, পর্ব ৪২) একমত থাকে, আর খণ্ড পেরোনো transaction ডেটাবেস নিজেই সমন্বয় করে। অ্যাপের কাছে এটি প্রায় সাধারণ SQL database.

দাম? প্রতিটি commit-এ কপিগুলোর সংখ্যাগরিষ্ঠের সম্মতি — এক data center-এ সামান্য, region পেরোলে দূরত্বভেদে কয়েক দশ থেকে কয়েকশো মিলিসেকেন্ড; খণ্ড পেরোনো transaction আরও ধীর; কিছু PostgreSQL বা MySQL বৈশিষ্ট্য ভিন্নভাবে চলে; চালানোও জটিল। এটি বিনা মূল্যের scaling নয় — ভিন্ন একটি trade-off.

উল্টো দিক থেকেও দুই জগৎ কাছে এসেছে: PostgreSQL ৯.৪ (২০১৪)-এ JSONB, MongoDB ৪.০ (২০১৮)-তে কয়েকটি document জুড়ে transaction, DynamoDB-তেও ২০১৮ সালে transaction-এর API — প্রতিটির নিজের সীমাসহ। রেখাটি আজ অনেক ঝাপসা।

“NoSQL মানে consistency নেই” — কথাটি ভুল

অনেক NoSQL ডেটাবেসে প্রতিটি অনুরোধে ঠিক করা যায় কতগুলো কপির উত্তর লাগবে — tunable consistency. Cassandra-ধাঁচের store-এ consistency level ONE, QUORUM বা ALL; ৩টি কপির মধ্যে লেখা আর পড়া দুটোই quorum-এ (২টি করে) হলে ২ + ২ > ৩, তাই প্রতিটি পড়া অন্তত একটি সর্বশেষ লেখা পাওয়া কপি ছোঁয় (প্রমাণ আর ব্যতিক্রম পর্ব ৪১-এ)। MongoDB-তে write concern majority; DynamoDB-তে “strongly consistent read”. দাম একই — বেশি কপির অপেক্ষা মানে বেশি latency, কপি বিকল হলে কম availability.

ভুল ধারণা আর বাস্তব

৮ · কীভাবে বাছবেন — চেকলিস্ট, polyglot persistence আর একটি পূর্ণ উদাহরণ

ঈদের আগে বাড়ি ফেরার পথ বাছাইয়ের মতো: বাস, ট্রেন, লঞ্চ — কোনোটিই “সেরা” নয়; কতজন, কত মালপত্র, কত সময়, কত ভাড়া — এসব দেখে ঠিক হয়। Database বাছাইয়ে সাতটি প্রশ্ন:

Polyglot persistence — আর তার খরচ

একই সিস্টেমে কাজভেদে ভিন্ন database — polyglot persistence. প্রতিটি ডেটা পায় মানানসই store, কিন্তু বিল আসে তিন জায়গা থেকে:

• মিলিয়ে রাখা: অ্যাপ নিজে দুই জায়গায় লিখলে (dual write) একটি ব্যর্থ হলেই দুই store চিরকাল আলাদা। নির্ভরযোগ্য পথ — মূল database-এর log থেকে CDC, বা একই transaction-এ outbox (পর্ব ২৫), তারপর event stream (পর্ব ৩৩)।
• সাময়িক অমিল: search-এ পুরোনো দাম — কতক্ষণ চলবে, আগে ঠিক করুন।
• চালানো আর মানুষ: প্রতিটি store-এর নিজের backup, upgrade, monitoring, failure mode (পর্ব ৫) আর দক্ষতা।

পূর্ণ উদাহরণ — একটি কাল্পনিক অনলাইন বাজারের ডেটা কোথায় যাবে

ধরা যাক একটি অনলাইন বাজার: চাল-ডাল থেকে মোবাইল ফোন আর শাড়ি, পিকে সেকেন্ডে কয়েকশো অর্ডার, লাখো পণ্য, session, সুপারিশ আর খোঁজার বাক্স। পাঁচ ধরনের ডেটা, পাঁচটি সিদ্ধান্ত, তারপর মেলানোর দাম:

৯ · AI-এর যুগে database বাছাই যাচাই

অনলাইন বাজারের database নকশা চাইলে AI প্রায়ই বলবে: “scale-এর জন্য MongoDB, cache-এ Redis, event-এ Kafka, analytics-এ Cassandra.” নামগুলো বাস্তব, কিন্তু access pattern, সংখ্যা বা failure mode ছাড়া। খুঁজুন এই ভুলগুলো:

AI-এর দেওয়া database নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি store-এর পাশে তার প্রধান প্রশ্ন, key আর আনুমানিক QPS লেখা আছে; কোনো প্রশ্ন scan বা ALLOW FILTERING-এ নির্ভর করছে না
• টাকা, মজুদ আর আসনের মতো নিয়ম (invariant) কোথায় রক্ষা হয় — transaction না শর্তযুক্ত লেখা — চিহ্নিত করেছি
• Storage, partition-এর আকার আর লেখার হার নিজে আবার হিসাব করেছি; একক আর গুণ মিলিয়ে দেখেছি
• পণ্যের সীমা, consistency-র মোড আর দাম অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি; ছোট load test বা simulation চালিয়েছি
• Failure-mode review করেছি — কোন store বিকল হলে কী থামে, কপি কতক্ষণ পুরোনো — আর প্রয়োজন প্রমাণহীন store বাদ দিয়েছি