NoSQL — key-value, document, wide-column আর graph

১ · NoSQL মানে কী — একটি পরিবার, একটি ডেটাবেস নয়

পর্ব ৪-এ (ডেটা মডেল) NoSQL-কে এক নজরে দেখেছিলেন। এবার ভেতরে ঢোকার পালা। প্রথমে নামটি। NoSQL শুনে মনে হয় “SQL নেই”, কিন্তু আজকের প্রচলিত অর্থ “Not only SQL” — শুধু টেবিল আর SQL নয়, অন্য আকারেও ডেটা রাখা যায়। নামটি কোনো একটি প্রযুক্তির নয়। এটি একটি ছাতা, যার নিচে খুব আলাদা আলাদা ডেটাবেস দাঁড়িয়ে আছে: Redis আর Neo4j-এর মধ্যে মিল প্রায় ততটুকু, যতটুকু রিকশা আর লঞ্চের মধ্যে — দুটোই যাত্রী বহন করে।

নামটি কোথা থেকে এল

ইতিহাসের প্রচলিত বর্ণনা এরকম। ১৯৯৮ সালে Carlo Strozzi নিজের একটি ছোট relational ডেটাবেসের নাম দেন NoSQL, কারণ সেটি SQL ভাষা ব্যবহার করত না — আজকের অর্থের সাথে এর সম্পর্ক সামান্য। আজকের অর্থে শব্দটি ছড়ায় ২০০৯ সালে, যখন San Francisco-তে Johan Oskarsson খোলা-উৎসের distributed, non-relational ডেটাবেস নিয়ে একটি meetup আয়োজন করেন, আর তার নাম (বা hashtag) হিসেবে “NoSQL” বেছে নেওয়া হয়। নামটি নাকি ছিল তাৎক্ষণিক একটি বাছাই — পরে এটি পুরো একটি আন্দোলনের নাম হয়ে যায়।

প্রযুক্তির দিক থেকে দুটি গবেষণা-প্রবন্ধকে সাধারণত প্রধান অনুপ্রেরণা ধরা হয়। Google-এর Bigtable (OSDI ২০০৬): হাজার হাজার সার্ভারে ছড়ানো একটি বিশাল, sorted map — row key, column family আর timestamp দিয়ে ঠিকানা। এ থেকে এসেছে HBase আর wide-column ধারণা। Amazon-এর Dynamo (SOSP ২০০৭): শপিং কার্টের মতো সেবা, যা কখনো “লেখা যাবে না” বলবে না — key দিয়ে পড়া-লেখা, অনেক কপি, আর মাঝে মাঝে কপিগুলোর অমিল মেনে নেওয়া। Cassandra (Facebook-এ শুরু, পরে Apache প্রকল্প) এই দুটির মিশ্রণ: ডেটার আকার Bigtable-ধাঁচের, কপি ছড়ানোর কৌশল Dynamo-ধাঁচের।

২ · কেন এল — চারটি প্রেরণা আর তার দাম

২০০০-এর দশকের শেষে বড় ওয়েব কোম্পানিগুলোর সমস্যা ছিল একটাই: ডেটা আর ব্যবহারকারী এত বেশি যে একটি সার্ভারে আঁটে না। সমাধানের চেষ্টা থেকে চারটি প্রেরণা দাঁড়ায়।

কিন্তু প্রতিটি সুবিধার একটি দাম আছে, আর সেগুলো প্রায়ই পরে চোখে পড়ে:

• দুর্বল transaction (অন্তত শুরুতে): অনেক সার্ভার জুড়ে ACID নিশ্চয়তা দেওয়া ব্যয়বহুল, তাই প্রথম দিকের বহু NoSQL সিস্টেম শুধু একটি key বা একটি document-এর ভেতরে atomic লেখা দিত। দুটি document একসাথে বদলানো অ্যাপের দায়িত্ব।
• ডেটার কপি: JOIN নেই বা দুর্বল, তাই একই তথ্য কয়েক জায়গায় রাখতে হয় — আর বদলালে সব জায়গায় বদলাতে হয়।
• কোয়েরির সীমা: যে প্রশ্নের জন্য ডেটা সাজানো হয়নি, সেটি হয় খুব ধীর, নয়তো একেবারে অসম্ভব। নতুন রিপোর্ট চাইলে প্রায়ই নতুন টেবিল বা নতুন pipeline.
• লুকোনো schema: ডেটাবেস যাচাই না করলেও অ্যাপ ঠিকই ধরে নেয় যে name ঘরটি আছে। নিয়ম তখন কোডের ভেতরে ছড়ানো।

Schema-on-write বনাম schema-on-read

শেষ কথাটির একটি নাম আছে। relational টেবিলে লেখার সময়েই যাচাই হয় — কলাম আছে কি না, টাইপ ঠিক কি না, NOT NULL মানা হলো কি না। এটি schema-on-write. বেশিরভাগ document আর key-value সিস্টেমে লেখার সময় যাচাই নেই বা ঐচ্ছিক; পড়ার সময় প্রোগ্রাম ঠিক করে কোন ঘরের কী মানে — schema-on-read. তাই “schemaless” কথাটি বিভ্রান্তিকর: schema থাকে, শুধু সেটি ডেটাবেসের বদলে কোডে। পুরোনো document-এ phone নেই আর নতুনটিতে আছে — পড়ার প্রতিটি কোডকে দুটি রূপই সামলাতে হয়।

মাঝামাঝি পথও আছে: MongoDB-তে collection-এ $jsonSchema দিয়ে যাচাইয়ের নিয়ম দেওয়া যায়, আর PostgreSQL-এর JSONB কলামে CHECK constraint (পর্ব ৩০)। অর্থাৎ পছন্দটি ডেটাবেসের পরিবার নয়, প্রতিটি সংগ্রহের নকশার সিদ্ধান্ত।

৩ · একই দোকান, চারটি মডেলে

তুলনাটি ন্যায্য করতে পুরো পর্বে একই ডেটা ব্যবহার করব — কোর্সের দোকান (ই-কমার্স) ডেটাবেস। এর টেবিল: customers (customer_id, name, city, phone, joined_on), products (product_id, name, category_id, price, stock), orders (order_id, customer_id, order_date, status) আর order_items (order_id, product_id, quantity, unit_price) — কোন অর্ডারে কোন পণ্য কয়টি, কত দামে। আমাদের নায়ক গ্রাহক 1, Rahim Uddin (ঢাকা): তাঁর তিনটি অর্ডার 1001, 1003 আর 1009, মোট ছয়টি লাইন। relational মডেলে এই তথ্য চারটি টেবিলে ছড়ানো, আর জোড়া লাগে JOIN দিয়ে। নিচের চারটি ট্যাবে একই তথ্য চারটি NoSQL আকারে (এগুলো চালানোর কোড নয়, শুধু আকার দেখানো):

customer:1        → {"name":"Rahim Uddin","city":"Dhaka"}
customer:1:orders → [1001, 1003, 1009]
order:1009        → {"date":"2025-10-08","status":"pending",
                     "items":[[101,1,14500],[110,1,3500]]}
cart:1            → {"102": 2}

{
  "_id": 1, "name": "Rahim Uddin", "city": "Dhaka",
  "orders": [
    { "order_id": 1001, "date": "2025-09-01", "status": "delivered",
      "items": [ { "product_id": 101, "qty": 1, "price": 15000 },
                 { "product_id": 102, "qty": 2, "price": 1200 } ] },
    { "order_id": 1003, "date": "2025-09-10", "status": "shipped", "items": [ … ] },
    { "order_id": 1009, "date": "2025-10-08", "status": "pending", "items": [ … ] }
  ]
}

partition customer_id = 1
  ┌ order_date ─┬ order_id ┬ status ────┬ total ┐
  │ 2025-10-08  │ 1009     │ pending    │ 18000 │
  │ 2025-09-10  │ 1003     │ shipped    │  1780 │
  │ 2025-09-01  │ 1001     │ delivered  │ 17400 │
  └─────────────┴──────────┴────────────┴───────┘
partition customer_id = 2   …

(Rahim:Customer)-[:PLACED]->(1001:Order)-[:CONTAINS {qty:1}]->(Mobile Phone:Product)
                                    └-[:CONTAINS {qty:2}]->(Headphone:Product)
(Rahim)-[:FRIEND]-(Karima:Customer)-[:PLACED]->(1007:Order)-[:CONTAINS]->(Headphone)

একটি শব্দ মনে রাখুন: aggregate. key-value, document আর wide-column — তিনটিই ডেটাকে এমন “গোছা”-য় রাখে যা সাধারণত একসাথে পড়া-লেখা হয় (একজন গ্রাহক আর তাঁর অর্ডার)। এই গোছাই একটি সার্ভারে থাকে, এর ভেতরে লেখা atomic, আর একে ধরেই ডেটা ভাগ হয়। তাই এদের বলা হয় aggregate-oriented — আর graph ব্যতিক্রম, কারণ তার মূল জিনিস গোছা নয়, সম্পর্ক।

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

সবচেয়ে সরল মডেল: একটি বিশাল dictionary বা hash table. অপারেশন তিনটি — GET key, PUT key value, DELETE key. সরলতাই শক্তি: key-এর hash দেখে সরাসরি সঠিক সার্ভার আর সঠিক জায়গা, তাই পড়া-লেখা গড়ে O(১)। Redis সব ডেটা RAM-এ রাখে বলে একটি GET সাধারণত এক মিলিসেকেন্ডেরও অনেক কম সময়ে ফেরে। সাধারণ কাজ: লগইনের session, শপিং cart, cache, rate limit (এক মিনিটে কতবার OTP চাওয়া হলো), লিডারবোর্ড।

SET session:a9f3 '{"customer_id":1}' EX 1800   # ৩০ মিনিট পর নিজে মুছে যাবে
GET session:a9f3
TTL session:a9f3                               # আর কত সেকেন্ড বাকি
HSET cart:1 101 1 102 2                        # cart একটি hash: পণ্য → সংখ্যা
HINCRBY cart:1 102 1                           # Headphone আরও একটি
HGETALL cart:1
EXPIRE cart:1 604800                           # ৭ দিন কেউ না ছুঁলে cart মুছে যাবে

TTL (time to live) key-value store-এর একটি বিশেষ সুবিধা: মেয়াদ শেষে key নিজেই মুছে যায়, তাই পুরোনো session পরিষ্কারের আলাদা কাজ লাগে না। Redis শুধু স্ট্রিং নয়, hash, list, set, sorted set-এর মতো গঠনও রাখে (বিস্তারিত পর্ব ৫৮)। Amazon DynamoDB-ও key দিয়ে পড়ার জন্য তৈরি — প্রতিটি item-এর একটি partition key (ঐচ্ছিকভাবে সাথে একটি sort key):

aws dynamodb put-item --table-name Carts \
  --item '{"customer_id": {"N": "1"}, "items": {"M": {"102": {"N": "2"}}}}'
aws dynamodb get-item --table-name Carts --key '{"customer_id": {"N": "1"}}'

SQLite-এ এই মডেলের অনুকরণ খুব সহজ: দুই কলামের একটি টেবিল, key-তে PRIMARY KEY. “PUT” মানে নেই থাকলে ঢোকানো, থাকলে বদলানো — অর্থাৎ UPSERT (পর্ব ১৪)। টেবিল kv: k (key), v (মান, JSON স্ট্রিং), expires_at (মেয়াদ; NULL মানে চিরকাল)। শুরুতে দুটি key আছে: session:a9f3 আর cart:3.

INSERT INTO kv (k, v) VALUES ('cart:1', '{"101":1}')
  ON CONFLICT(k) DO UPDATE SET v = excluded.v;
INSERT INTO kv (k, v) VALUES ('cart:1', '{"101":1,"102":2}')
  ON CONFLICT(k) DO UPDATE SET v = excluded.v;
SELECT v FROM kv WHERE k = 'cart:1';
SELECT k, v FROM kv
WHERE k = 'session:a9f3'
  AND (expires_at IS NULL OR expires_at > '2025-10-10 15:10:00');
EXPLAIN QUERY PLAN SELECT v FROM kv WHERE k = 'cart:1';
EXPLAIN QUERY PLAN SELECT k FROM kv WHERE v LIKE '%"102"%';

key-value store-এর আরেকটি চেনা সমস্যা: মান একটি গোটা বস্তা, তাই বদলাতে হলে পড়া → বদলানো → পুরোটা লেখা। দুটি browser tab একসাথে এটি করলে একটির বদল হারায় (lost update, পর্ব ৪৭)। প্রতিকার optimistic locking: প্রতিটি মানের সাথে একটি version, আর লেখার শর্ত “version এখনো আমার পড়াটিই”. নিচের ছোট Python প্রোগ্রাম (শুধু stdlib) একটি খেলনা key-value store বানায় — TTL আর version-সহ:

import json
store, now = {}, 0                     # key -> (value as text, version, expires_at)
def get(key):
    e = store.get(key)
    if e and e[2] is not None and e[2] <= now:
        del store[key]; e = None       # expired: behaves as if it never existed
    return (json.loads(e[0]), e[1]) if e else (None, 0)
def put(key, value, ttl=None, if_version=None):
    old_version = get(key)[1]
    if if_version is not None and old_version != if_version:
        return False                   # someone wrote first: reject (compare-and-set)
    store[key] = (json.dumps(value), old_version + 1, now + ttl if ttl else None); return True
put("session:a9f3", {"customer_id": 1}, ttl=1800)        # 30 minutes
put("cart:1", {"101": 1}); put("cart:2", {"104": 1}); put("cart:3", {"102": 1})
cart, v = get("cart:1"); print("GET cart:1 ->", cart, "version", v)
cart["102"] = 2; print("tab A put:", put("cart:1", cart, if_version=v))
print("tab B put:", put("cart:1", {"101": 1, "110": 1}, if_version=v))  # still holds v1
print("GET cart:1 ->", get("cart:1"))
now = 1799; print("t=1799 session:", get("session:a9f3")[0])
now = 1800; print("t=1800 session:", get("session:a9f3")[0])
print("carts with 102 (scan", len(store), "keys):",
      [k for k, e in store.items() if k.startswith("cart:") and "102" in json.loads(e[0])])

GET cart:1 -> {'101': 1} version 1
tab A put: True
tab B put: False
GET cart:1 -> ({'101': 1, '102': 2}, 2)
t=1799 session: {'customer_id': 1}
t=1800 session: None
carts with 102 (scan 3 keys): ['cart:1', 'cart:3']

৫ · Document — embedding না referencing

document ডেটাবেস key-value-এর পরের ধাপ: মান এখন আর অন্ধ বস্তা নয়, একটি গঠনওয়ালা JSON-ধাঁচের document (MongoDB ভেতরে রাখে BSON নামের binary রূপে)। তাই ভেতরের যেকোনো ঘর ধরে খোঁজা, index আর আংশিক বদল সম্ভব। MongoDB-র shell mongosh-এ:

db.customers.insertOne({
  _id: 1, name: "Rahim Uddin", city: "Dhaka",
  orders: [
    { order_id: 1009, date: ISODate("2025-10-08"), status: "pending",
      items: [ { product_id: 101, qty: 1, price: 14500 },
               { product_id: 110, qty: 1, price: 3500 } ] }
  ]
})
db.customers.find({ "orders.items.product_id": 101 }, { name: 1 })
db.customers.createIndex({ "orders.items.product_id": 1 })      // array-র ভেতরেও index
db.customers.updateOne({ _id: 1, "orders.order_id": 1009 },
                       { $set: { "orders.$.status": "shipped" } })  // শুধু একটি ঘর বদল

এখানে অর্ডারগুলো গ্রাহকের ভেতরে embed করা (embedding). বিকল্প হলো অর্ডারকে আলাদা collection-এ রাখা আর তাতে customer_id লেখা — referencing, অনেকটা foreign key-র মতো (তবে ডেটাবেস সাধারণত referential integrity যাচাই করে না)। দরকার হলে MongoDB-র aggregation-এ $lookup দুটি collection জোড়া দেয়, কিন্তু সেটি relational JOIN-এর মতো স্বাভাবিক বা সস্তা নয়।

db.orders.insertOne({ _id: 1009, customer_id: 1, date: ISODate("2025-10-08"),
                      status: "pending", items: [ /* লাইনগুলো এখানেই embed */ ] })
db.orders.createIndex({ customer_id: 1, date: -1 })
db.orders.find({ customer_id: 1 }).sort({ date: -1 })
db.customers.aggregate([
  { $match: { _id: 1 } },
  { $lookup: { from: "orders", localField: "_id", foreignField: "customer_id", as: "orders" } }
])

লক্ষ করুন, referencing-এর নকশাতেও অর্ডারের লাইনগুলো অর্ডারের ভেতরে embed করা। একই ডেটাবেসে দুটি পথই চলে; প্রতিটি সম্পর্কের জন্য আলাদা সিদ্ধান্ত। কীভাবে নেবেন, ধাপে ধাপে:

এবার SQLite-এ document store বানাই। নিচের এডিটর দোকানের চারটি relational টেবিল থেকে customers_doc টেবিল তৈরি করে: id আর doc — প্রতিটি গ্রাহকের একটি JSON document, অর্ডারগুলো তার ভেতরে embed, আর প্রতিটি অর্ডারের ভেতরে তার লাইন। json_object একটি object বানায়, json_group_array অনেক সারিকে একটি array-তে জড়ো করে (পর্ব ৩০); ভেতরের subquery-র ফল যাতে স্ট্রিং না হয়ে JSON হিসেবেই বসে, তাই json(…) দিয়ে মোড়ানো।

CREATE TABLE customers_doc (id INTEGER PRIMARY KEY, doc TEXT NOT NULL);
INSERT INTO customers_doc
SELECT c.customer_id, json_object('name', c.name, 'city', c.city,
  'orders', json((SELECT json_group_array(json_object(
      'order_id', o.order_id, 'date', o.order_date, 'status', o.status,
      'items', json((SELECT json_group_array(json_object('product_id', i.product_id,
                'qty', i.quantity, 'price', CAST(i.unit_price AS INTEGER)))
               FROM order_items i WHERE i.order_id = o.order_id))))
    FROM orders o WHERE o.customer_id = c.customer_id)))
FROM customers c;
SELECT doc FROM customers_doc WHERE id = 1;
SELECT id, length(doc) AS bytes FROM customers_doc ORDER BY id;

document-এর ভেতরে প্রশ্ন করতে json_each: এটি একটি table-valued ফাংশন, যা একটি JSON array-র প্রতিটি উপাদানকে একটি সারি বানায় (value কলামে)। একটির ভেতরে আরেকটি json_each দিয়ে অর্ডার, তারপর লাইন — MongoDB-র $unwind-এর মতো:

SELECT json_extract(d.doc, '$.name') AS name,
       json_array_length(d.doc, '$.orders') AS n_orders,
       SUM(json_extract(it.value, '$.qty') * json_extract(it.value, '$.price')) AS spent
FROM customers_doc d
LEFT JOIN json_each(d.doc, '$.orders') o
LEFT JOIN json_each(o.value, '$.items') it
GROUP BY d.id ORDER BY d.id;
SELECT DISTINCT json_extract(d.doc, '$.name') AS bought_101
FROM customers_doc d, json_each(d.doc, '$.orders') o, json_each(o.value, '$.items') it
WHERE json_extract(it.value, '$.product_id') = 101;

৬ · Wide-column — আগে প্রশ্ন, পরে টেবিল

Cassandra-র টেবিল দেখতে SQL টেবিলের মতো, আর তার ভাষা CQL দেখতে SQL-এর মতো — এই মিলই নতুনদের সবচেয়ে বড় ফাঁদ। ভেতরে এটি একটি distributed, sorted map. মূল ধারণা দুটি। Partition key: এর hash ঠিক করে সারিটি কোন সার্ভারে (আর তার কপিগুলো কোন কোন সার্ভারে) থাকবে; একটি partition-এর সব সারি একসাথে থাকে। Clustering key: partition-এর ভেতরে সারিগুলো কোন ক্রমে সাজানো থাকবে। JOIN নেই, আর partition key ছাড়া কোয়েরি সাধারণত চলেই না। তাই নকশার নিয়ম উল্টে যায় — query-first design: আগে প্রশ্নের তালিকা, তারপর প্রতিটি প্রশ্নের জন্য একটি টেবিল।

CREATE KEYSPACE shop WITH replication =
  {'class': 'NetworkTopologyStrategy', 'dhaka': 3};   -- প্রতিটি সারির ৩টি কপি
CREATE TABLE shop.orders_by_customer (
  customer_id   int,
  order_date    date,
  order_id      int,
  status        text,
  total         decimal,
  customer_name text,
  PRIMARY KEY ((customer_id), order_date, order_id)   -- (partition), clustering…
) WITH CLUSTERING ORDER BY (order_date DESC, order_id ASC);

SELECT order_date, order_id, status, total
FROM shop.orders_by_customer WHERE customer_id = 1;    -- একটি partition: দ্রুত
SELECT * FROM shop.orders_by_customer WHERE status = 'pending';
-- ত্রুটি: partition key নেই; ALLOW FILTERING দিলে চলবে, কিন্তু সব সার্ভার ঘুরে

SQLite-এ এর কাছাকাছি অনুকরণ: composite PRIMARY KEY-ওয়ালা একটি WITHOUT ROWID টেবিল। এমন টেবিলে সারিগুলো primary key-র B-tree-তেই সাজানো থাকে (পর্ব ৪০-এর clustered index), ঠিক Cassandra partition-এর ভেতরের সারির মতো। orders_by_customer-এ প্রতি অর্ডারে একটি সারি: customer_id, order_date, order_id, status, total (লাইনগুলোর যোগফল, আগে থেকে হিসাব করে রাখা) আর customer_name (গ্রাহকের নামের কপি)।

CREATE TABLE orders_by_customer (
  customer_id INTEGER, order_date TEXT, order_id INTEGER,
  status TEXT, total INTEGER, customer_name TEXT,
  PRIMARY KEY (customer_id, order_date DESC, order_id)
) WITHOUT ROWID;
INSERT INTO orders_by_customer
SELECT o.customer_id, o.order_date, o.order_id, o.status,
       (SELECT CAST(SUM(quantity * unit_price) AS INTEGER) FROM order_items i
        WHERE i.order_id = o.order_id), c.name
FROM orders o JOIN customers c ON c.customer_id = o.customer_id;
SELECT order_date, order_id, status, total
FROM orders_by_customer WHERE customer_id = 1;
SELECT * FROM orders_by_customer WHERE customer_id = 1 AND order_date >= '2025-10-01';

এবার “কঠিন” প্রশ্নটি — সব pending অর্ডার — আর তার query-first সমাধান। EXPLAIN QUERY PLAN দেখাবে কোনটি এক জায়গায় যায় আর কোনটি পুরো টেবিল ঘোরে:

EXPLAIN QUERY PLAN
SELECT * FROM orders_by_customer WHERE customer_id = 1;
EXPLAIN QUERY PLAN
SELECT * FROM orders_by_customer WHERE status = 'pending';
CREATE TABLE orders_by_status (
  status TEXT, order_date TEXT, order_id INTEGER, customer_id INTEGER,
  PRIMARY KEY (status, order_date, order_id)) WITHOUT ROWID;
INSERT INTO orders_by_status
SELECT status, order_date, order_id, customer_id FROM orders_by_customer;
SELECT order_date, order_id, customer_id FROM orders_by_status WHERE status = 'pending';
EXPLAIN QUERY PLAN
SELECT * FROM orders_by_status WHERE status = 'pending';

৭ · Graph — সম্পর্কই প্রধান তথ্য

graph ডেটাবেসে দুটি মৌলিক জিনিস: node (গ্রাহক, পণ্য, অর্ডার) আর relationship বা edge (FRIEND, BOUGHT, PLACED). দুটিরই label আর বৈশিষ্ট্য (property) থাকতে পারে — এই নকশার নাম property graph. Neo4j-এর কোয়েরি ভাষা Cypher ছবি আঁকার মতো: (a)-[:FRIEND]->(b) মানে “a থেকে b-তে একটি FRIEND সম্পর্ক”. গ্রাফের মৌলিক ধারণা (BFS, adjacency list) DSA কোর্সের graph পর্বে আছে।

// node আর সম্পর্ক তৈরি
CREATE (r:Customer {id: 1, name: 'Rahim Uddin'}),
       (k:Customer {id: 2, name: 'Karima Begum'}),
       (p:Product {id: 102, name: 'Headphone'}),
       (r)-[:FRIEND]->(k),
       (r)-[:BOUGHT {order_id: 1001, qty: 2}]->(p);

// বন্ধুর বন্ধু, যাঁরা এখনো সরাসরি বন্ধু নন — "যাঁদের চিনতে পারেন"
MATCH (me:Customer {id: 1})-[:FRIEND]-(f)-[:FRIEND]-(fof)
WHERE fof <> me AND NOT (me)-[:FRIEND]-(fof)
RETURN DISTINCT fof.name;

// Headphone যাঁরা কিনেছেন, তাঁরা আর কী কিনেছেন
MATCH (:Product {id: 102})<-[:BOUGHT]-(c:Customer)-[:BOUGHT]->(other:Product)
WHERE other.id <> 102
RETURN other.name, count(DISTINCT c) AS customers
ORDER BY customers DESC;

relational-এ একই প্রশ্ন করা যায় — একটি edge টেবিল আর recursive CTE (পর্ব ২৫)। পার্থক্য খরচে। relational-এ প্রতিটি ধাপ একটি JOIN, আর প্রতিটি JOIN একটি index lookup — O(log n) — যা পুরো টেবিলের আকারের ওপর নির্ভর করে। native graph ডেটাবেসে (যেমন Neo4j) প্রতিটি node নিজের সম্পর্কগুলোর সরাসরি ঠিকানা রাখে — “index-free adjacency” — তাই এক ধাপ এগোনোর খরচ মোটামুটি সেই node-এর সম্পর্কের সংখ্যার সমান, গোটা গ্রাফ কত বড় তার ওপর নয়। দোকানের গ্রাহকদের মধ্যে বন্ধুত্ব ধরা যাক: Rahim(1)–Karima(2), Rahim–Sabbir(3), Karima–Nusrat(4), Sabbir–Nusrat, Sabbir–Tanvir(5), Nusrat–Farhana(6), Tanvir–Imran(7), Farhana–Mitu(8). Rahim থেকে দুই ধাপ পর্যন্ত হাঁটা, ধাপে ধাপে:

এবার আসল কোয়েরি। friends টেবিলে (a, b) — a-র বন্ধু b; প্রতিটি বন্ধুত্ব দুই দিক থেকে দুটি সারিতে রাখা, যাতে JOIN-এ দিক নিয়ে ভাবতে না হয়। নাম আসছে দোকানের customers টেবিল থেকে:

WITH RECURSIVE reach(person, hops, path) AS (
  SELECT 1, 0, ',1,'
  UNION ALL
  SELECT f.b, r.hops + 1, r.path || f.b || ','
  FROM reach r JOIN friends f ON f.a = r.person
  WHERE r.hops < 2 AND instr(r.path, ',' || f.b || ',') = 0
)
SELECT c.name, MIN(r.hops) AS hops, COUNT(*) AS paths
FROM reach r JOIN customers c ON c.customer_id = r.person
WHERE r.hops > 0
GROUP BY r.person
ORDER BY hops, r.person;

সুপারিশের প্রশ্ন — “যাঁরা Headphone (102) কিনেছেন, তাঁরা আর কী কিনেছেন” — relational-এ চারটি টেবিলের JOIN. Cypher-এর ছবির মতো pattern-টি এখানে order_items → orders → (একই গ্রাহক) → orders → order_items পথ ধরে হাঁটে:

SELECT p.name, COUNT(DISTINCT o2.customer_id) AS customers
FROM order_items i1
JOIN orders o1 ON o1.order_id = i1.order_id
JOIN orders o2 ON o2.customer_id = o1.customer_id
JOIN order_items i2 ON i2.order_id = o2.order_id
JOIN products p ON p.product_id = i2.product_id
WHERE i1.product_id = 102 AND i2.product_id <> 102
GROUP BY p.product_id
ORDER BY customers DESC, p.name;

৮ · কপি রাখা, BASE বনাম ACID আর tunable consistency

চারটি মডেলের তিনটিতেই একটি জিনিস বারবার এসেছে: একই তথ্যের কপি। relational জগতে denormalization (পর্ব ৩৮) একটি সচেতন ব্যতিক্রম; NoSQL-এ এটিই স্বাভাবিক নিয়ম, কারণ JOIN নেই বা ব্যয়বহুল। কিন্তু কপির দাম সবসময় একই — বদলের সময় সব কপি খুঁজে বদলাতে হয়। Rahim নাম বদলালেন:

UPDATE customers SET name = 'Rahim Uddin Khan' WHERE customer_id = 1;
SELECT o.order_id, o.customer_name AS copy, c.name AS source
FROM orders_by_customer o JOIN customers c ON c.customer_id = o.customer_id
WHERE o.customer_name <> c.name;
UPDATE orders_by_customer
SET customer_name = (SELECT name FROM customers WHERE customer_id = 1)
WHERE customer_id = 1;
SELECT COUNT(*) AS stale_copies FROM orders_by_customer o
JOIN customers c ON c.customer_id = o.customer_id WHERE o.customer_name <> c.name;

BASE — ACID-এর উল্টো দিকের নকশা

অনেক সার্ভারে কপি থাকলে আর নেটওয়ার্ক ভাগ হলে (পর্ব ৫৪-এর CAP) সিস্টেমকে বাছতে হয়: সব কপি মিল না হওয়া পর্যন্ত উত্তর দেওয়া বন্ধ, নাকি হাতের কপি থেকে উত্তর দেওয়া। দ্বিতীয় পথের দর্শনের নাম BASE: Basically Available (প্রায় সবসময় সাড়া দেয়), Soft state (অবস্থা কিছুক্ষণ অস্থির থাকতে পারে), Eventually consistent (নতুন লেখা থামলে সব কপি একসময় মিলবে — eventual consistency). শব্দটি রসায়নের অম্ল-ক্ষারের খেলা — ACID-এর বিপরীতে BASE; ধারণাটি ১৯৯০-এর দশকের শেষে Eric Brewer-দের গবেষণায় দেখা যায়, আর ২০০৮ সালে eBay-এর Dan Pritchett-এর একটি প্রবন্ধে জনপ্রিয় হয় বলে সাধারণত বলা হয়।

তবে ২০২০-এর দশকে বিভাজনটি আর সাদা-কালো নয়। MongoDB প্রথম থেকেই একটি document-এর লেখা atomic রাখত; ৪.০ সংস্করণ (২০১৮) replica set-এ multi-document transaction আনে, আর ৪.২ (২০১৯) sharded cluster-এও। DynamoDB ২০১৮ সালের শেষে transaction API যোগ করে। আবার উল্টো দিকে Google Spanner, CockroachDB-র মতো distributed SQL ডেটাবেস বহু সার্ভারে ছড়িয়েও ACID দেয়। তাই আজ প্রশ্নটি “NoSQL মানে transaction নেই” নয়, বরং: কোন পরিসরে (একটি document, একটি partition, পুরো cluster) কোন নিশ্চয়তা, কত দামে?

Tunable consistency — প্রতিটি কোয়েরিতে বাছাই

Dynamo-ধাঁচের সিস্টেমে (Cassandra, ScyllaDB, Riak) প্রতিটি key-র N-টি কপি। লেখায় কয়টি কপির “পেয়েছি” লাগবে (W), পড়ায় কয়টি কপির উত্তর লাগবে (R) — দুটিই প্রতিটি কোয়েরিতে বাছা যায়: tunable consistency. মূল নিয়মটি পর্ব ৫২ আর ৫৪-এর quorum-এর আত্মীয়: R + W > N হলে পড়ার কপিগুলো আর লেখার কপিগুলো অন্তত একটিতে মিলবেই (pigeonhole নীতি: দুটি দলের মোট সদস্য N-এর বেশি হলে N জনের মধ্যে অন্তত একজন দুই দলেই)। সেই কপিতে সর্বশেষ লেখা আছে, আর timestamp দেখে নতুনটি বেছে নেওয়া হয়।

CONSISTENCY QUORUM;      -- N = 3 হলে ২টি কপি: লেখায় W = 2, পড়ায় R = 2
SELECT * FROM shop.orders_by_customer WHERE customer_id = 1;
CONSISTENCY ONE;         -- দ্রুততম, কিন্তু পুরোনো মান ফিরতে পারে
-- একাধিক ডেটা সেন্টারে: LOCAL_QUORUM = শুধু নিজের সেন্টারের majority

নিচের simulation-এ N = ৩. লেখার সময় কপি ৩ নাগালের বাইরে; পড়ার সময় কপি ১ বন্ধ আর ৩ ফিরে এসেছে — সবচেয়ে খারাপ সময়ে সবচেয়ে খারাপ কপি। প্রতিটি (W, R) জোড়ায় পড়া কী ফেরত দেয়?

N = 3                                         # every key is stored on 3 replicas
def run(W, R):
    replicas = [{"cart:1": (1, "old")} for _ in range(N)]   # (timestamp, value)
    up = [True, True, False]                  # replica 3 is unreachable during the write
    acks = 0
    for i in range(N):
        if up[i] and acks < W:                # simplified: stop after W acks;
            replicas[i]["cart:1"] = (2, "new"); acks += 1   # others get it later (repair)
    ok = acks >= W
    up = [False, True, True]                  # now replica 1 is down, 3 is back
    asked = [i for i in range(N) if up[i]][:R]
    answers = [replicas[i]["cart:1"] for i in asked]
    ts, value = max(answers)                  # newest timestamp wins
    overlap = "R+W>N" if R + W > N else "R+W<=N"
    print(f"W={W} R={R} ({overlap}): write {'OK' if ok else 'FAILED'}, "
          f"read from {[i + 1 for i in asked]} saw {[a[1] for a in answers]} -> returns '{value}'")
for W, R in [(1, 1), (2, 1), (1, 2), (2, 2), (3, 1)]:
    run(W, R)

W=1 R=1 (R+W<=N): write OK, read from [2] saw ['old'] -> returns 'old'
W=2 R=1 (R+W<=N): write OK, read from [2] saw ['new'] -> returns 'new'
W=1 R=2 (R+W<=N): write OK, read from [2, 3] saw ['old', 'old'] -> returns 'old'
W=2 R=2 (R+W>N): write OK, read from [2, 3] saw ['new', 'old'] -> returns 'new'
W=3 R=1 (R+W>N): write FAILED, read from [2] saw ['new'] -> returns 'new'

৯ · তুলনা, polyglot persistence আর কীভাবে বাছবেন

Polyglot persistence — একটি দোকানে কয়েকটি ডেটাবেস

বড় সিস্টেমে প্রায়ই একটি ডেটাবেস সব কাজ করে না। প্রতিটি কাজে সবচেয়ে উপযুক্ত যন্ত্র — polyglot persistence. ধরুন দেশের একটি বড় অনলাইন দোকান:

ক্রেতা ── খোঁজেন "panjabi" ──► Elasticsearch (পণ্য খোঁজা)
   │
   ├─ cart-এ যোগ ───────────► Redis (cart, session, TTL)
   │
   ├─ checkout ─────────────► PostgreSQL (orders, payments
   │                           ACID transaction, মজুদ কমানো)
   │                                │ CDC / event stream
   │                                ▼
   │                     ┌─ Elasticsearch-এ stock হালনাগাদ
   │                     └─ graph DB-তে BOUGHT সম্পর্ক
   └─ "আরও যা পছন্দ হতে পারে" ◄── graph DB (সুপারিশ)

সত্যের উৎস (source of truth) একটিই — অর্ডার আর টাকা PostgreSQL-এ। বাকিরা তার থেকে তৈরি কপি, যা CDC বা event stream দিয়ে হালনাগাদ হয়। অ্যাপ নিজে দুই জায়গায় লিখলে (dual write) মাঝপথের crash-এ কপিগুলো চুপচাপ আলাদা হয়ে যায়। খোঁজার ইঞ্জিন Elasticsearch Lucene-এর inverted index-এর ওপর গড়া — শব্দ থেকে document-এর তালিকা (পর্ব ৫৯)। দাম মনে রাখুন: প্রতিটি নতুন ডেটাবেস মানে নতুন backup, monitoring, নিরাপত্তা, আপগ্রেড আর দক্ষ মানুষ। ছোট দল আর ছোট অ্যাপের জন্য এই বোঝা প্রায়ই সুবিধার চেয়ে বড়।

কীভাবে বাছবেন — চেকলিস্ট

1. relational দিয়ে শুরু করুন, যদি নিচের কোনো স্পষ্ট কারণ না থাকে। একটি PostgreSQL বা MySQL সার্ভার বেশিরভাগ অ্যাপের জন্য বহু বছর যথেষ্ট, আর ভুল ডিজাইন পরে সারানোও সহজ।
2. আগে access pattern লিখুন: প্রতিটি পাতা কোন প্রশ্ন করে, সেকেন্ডে কতবার, কত লেখা, কত পড়া। প্রশ্নগুলো অজানা বা ঘনঘন বদলায় (রিপোর্ট, analytics) — relational-এর ad-hoc SQL জেতে।
3. মাপ সত্যিই কি একটি সার্ভার ছাড়ায়? সেকেন্ডে লাখো লেখা, বহু TB, বহু অঞ্চলে একসাথে লেখা — wide-column বা distributed ডেটাবেস ভাবুন।
4. কোন নিশ্চয়তা লাগবে? টাকা, মজুদ, আসন সংরক্ষণে কঠোর transaction; like-এর সংখ্যায় eventual consistency চলে।
5. ডেটার আকার কেমন? একসাথে পড়া স্বয়ংসম্পূর্ণ গোছা — document; বহু ধাপের সম্পর্ক — graph; শুধু key দিয়ে অতি দ্রুত — key-value.
6. দল আর পরিচালনা: কে চালাবে, backup কীভাবে, managed সেবা (পর্ব ৬১) আছে কি না।

Multi-model — সীমানা মুছে যাচ্ছে

প্রবণতাটি স্পষ্ট: প্রতিটি পক্ষ অন্যের ভালো দিক নিজের ভেতরে নিচ্ছে। PostgreSQL-এ hstore (একটি কলামে key-value জোড়া) অনেক পুরোনো, আর ৯.৪ সংস্করণ (২০১৪) থেকে JSONB, যার ওপর GIN index দিয়ে document-এর ভেতরে দ্রুত খোঁজা যায় (পর্ব ৩০)। SQL:2023 standard-এ SQL/PGQ যোগ হয়েছে — SQL-এর ভেতরে property graph-এর pattern কোয়েরি — আর ২০২৪ সালে graph কোয়েরির আলাদা ISO ভাষা GQL প্রকাশিত হয়েছে। অন্য দিকে Redis-এ module দিয়ে JSON document আর খোঁজার সুবিধা যোগ হয়েছে, Cassandra দিয়েছে SQL-ধাঁচের CQL, আর Azure Cosmos DB বা ArangoDB-র মতো multi-model ডেটাবেস একই ইঞ্জিনে কয়েকটি মডেল দেয়। তাই সিদ্ধান্ত ক্রমশ “কোন পরিবার” থেকে সরে “এই কাজের জন্য কোন আকার আর কোন নিশ্চয়তা”-য় আসছে।

১০ · AI-এর যুগে NoSQL ডিজাইন

AI-কে “আমার অ্যাপের জন্য MongoDB schema দাও” বললে সে সুন্দর JSON লিখে দেয়। সমস্যা হলো, NoSQL ডিজাইন নির্ভর করে আপনার প্রশ্ন আর মাপের ওপর — যা AI জানে না, আর না জানলেও আত্মবিশ্বাসী উত্তর দেয়। সাধারণ ভুল:

AI-এর ডিজাইন মানার আগে — চেকলিস্ট

• সব access pattern লিখেছি, আর প্রতিটির জন্য দেখিয়েছি কোন টেবিল/collection আর কোন key বা index উত্তর দেবে
• প্রতিটি embed করা array-র সর্বোচ্চ আকার জানি, আর সীমাহীন কিছু embed করিনি
• প্রতিটি কপি করা ঘর কে, কখন, কীভাবে হালনাগাদ করবে, আর মাঝপথে ব্যর্থ হলে কী হবে — লেখা আছে
• টাকা আর মজুদের লেখায় কোন নিশ্চয়তা (transaction, quorum, write concern) — যাচাই করেছি
• নমুনা ডেটায় কোয়েরি চালিয়ে ফল আর plan দেখেছি (EXPLAIN, explain(), TRACING), আর relational সমাধানের সাথে তুলনা করেছি