MongoDB — document ডেটাবেস হাতে-কলমে

১ · Document মডেল — BSON, collection আর _id

পর্ব ৫৬-এ চার ধরনের NoSQL ডেটাবেসের ছবি দেখেছেন। এই পর্বে সবচেয়ে প্রচলিত document database, MongoDB, নিয়ে হাতে-কলমে কাজ। MongoDB-র প্রথম সংস্করণ আসে ২০০৯ সালে, 10gen নামের একটি কোম্পানি থেকে (২০১৩ সালে নাম বদলে MongoDB Inc.)। নামটি এসেছে ইংরেজি “humongous” — বিশাল — থেকে।

একটি document দেখতে JSON-এর মতো (পর্ব ৩০): নাম-মানের জোড়া, যার মান হতে পারে আরেকটি document (embedded) বা একটি array. একই ধরনের document থাকে একটি collection-এ (টেবিলের মতো), আর কয়েকটি collection মিলে একটি database. কিন্তু দুটি বড় পার্থক্য আছে। এক, একই collection-এর document-গুলোর কাঠামো এক হতে হবে, এমন বাধ্যবাধকতা নেই — যদি না আপনি নিজে নিয়ম দেন (অংশ ৮)। দুই, ডিস্কে JSON লেখা থাকে না; থাকে BSON — Binary JSON, যাতে JSON-এর চেয়ে বেশি টাইপ আছে আর পড়তে পার্স করতে হয় না।

BSON-এর টাইপ — বিশেষ করে তিনটি

JSON-এ সংখ্যা মাত্র এক রকম, তারিখের কোনো টাইপ নেই। BSON-এ আছে 32-bit ও 64-bit integer, double, string (UTF-8), boolean, null, array, object, binary — আর তিনটি টাইপ, যা প্রতিদিন লাগবে:

এই পর্বের শুরুতে কোর্সের পরিচিত db-shop ডেটাবেস — customers (customer_id, name, city, phone, joined_on), categories, 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). MongoDB এই পাতায় চলে না, কিন্তু SQLite-এর JSON ফাংশন দিয়ে ঠিক MongoDB-র মতো document বানানো যায়। নিচের এডিটরগুলোয় একটি বাড়তি টেবিল order_docs(id, doc) আগে থেকে তৈরি: প্রতিটি অর্ডার একটি JSON document — গ্রাহকের সংক্ষিপ্ত তথ্য আর সব item ভেতরে বসানো। দেখুন অর্ডার 1001 কেমন দেখায়:

-- তিনটি টেবিলের তথ্য, একটি document-এ
SELECT json_pretty(doc) AS doc FROM order_docs WHERE id = 1001;

-- document-এর আকার (byte)
SELECT id, length(doc) AS bytes FROM order_docs WHERE id IN (1001, 1010);

{
    "_id": 1001,
    "customer": { "_id": 1, "name": "Rahim Uddin", "city": "Dhaka" },
    "order_date": "2025-09-01",
    "status": "delivered",
    "items": [
        { "product_id": 101, "qty": 1, "unit_price": 15000.0 },
        { "product_id": 102, "qty": 2, "unit_price": 1200.0 }
    ]
}
id   │ bytes
1001 │ 221
1010 │ 171

২ · MongoDB চালানো — Atlas, Community Server, mongosh আর Compass

শেখা আর ছোট প্রকল্পের জন্য তিনটি প্রচলিত পথ। কোনটি “সেরা”, তা নির্ভর করে আপনার ইন্টারনেট, কম্পিউটার আর কাজের ধরনের ওপর:

# Atlas-এর "Connect" বোতাম থেকে পাওয়া ঠিকানা; password শেল নিজে জিজ্ঞেস করবে
mongosh "mongodb+srv://cluster0.example.mongodb.net/shop" --username rahim

# mongo.env ফাইলে: MONGO_INITDB_ROOT_USERNAME=admin আর MONGO_INITDB_ROOT_PASSWORD=...
docker run -d --name shopdb -p 127.0.0.1:27017:27017 \
  -v shopdb-data:/data/db --env-file mongo.env mongo:8.0

mongosh "mongodb://127.0.0.1:27017" --username admin --authenticationDatabase admin

৩ · তৈরি আর খোঁজা — insert, find, filter আর projection

mongosh-এ use shop লিখলে database বাছাই হয় (প্রথম লেখার সময় তৈরি হয়)। তারপর db.<collection>.<method>() — collection-ও প্রথম insert-এ নিজে থেকে তৈরি হয়। এই পর্বের কোডে relational আইডিগুলো (1, 101, 1001) _id হিসেবে রাখা হলো, যাতে SQL-এর সাথে মেলানো সহজ হয়। সংখ্যা, string — যেকোনো অনন্য মানই _id হতে পারে। নিচের কোড এই পাতায় চলবে না; mongosh-এ চালানোর জন্য:

use shop

db.customers.insertOne({
  _id: 1, name: "Rahim Uddin", phone: "01711000001",
  joined_on: ISODate("2025-01-15"),
  addresses: [                                   // embedded, সীমিত সংখ্যক
    { label: "home",   city: "Dhaka", area: "Mirpur" },
    { label: "office", city: "Dhaka", area: "Motijheel" }
  ]
})
// { acknowledged: true, insertedId: 1 }

db.products.insertMany([
  { _id: 101, name: "Mobile Phone", category: "Electronics", price: NumberDecimal("15000"),
    stock: 12, attrs: { ram_gb: 8, colors: ["black", "blue"] } },
  { _id: 102, name: "Headphone", category: "Electronics", price: NumberDecimal("1200"), stock: 40 }
])

db.orders.insertOne({
  _id: 1001,
  customer: { _id: 1, name: "Rahim Uddin", city: "Dhaka" },   // extended reference
  order_date: ISODate("2025-09-01"), status: "delivered",
  items: [
    { product_id: 101, name: "Mobile Phone", qty: 1, unit_price: NumberDecimal("15000") },
    { product_id: 102, name: "Headphone",    qty: 2, unit_price: NumberDecimal("1200") }
  ],
  total: NumberDecimal("17400")                               // computed pattern
})

db.reviews.insertOne({ product_id: 101, rating: 5, body: "Battery lasts two days" })
// { acknowledged: true, insertedId: ObjectId('...') }   ← _id দিইনি, তাই ObjectId

ধরে নিন বাকি সাতজন গ্রাহক, দশটি পণ্য আর দশটি অর্ডার একইভাবে ঢোকানো হয়েছে (db-shop-এর মানগুলোই)। insertMany ডিফল্টে ক্রমানুসারে (ordered: true) ঢোকায় আর প্রথম error-এ থেমে যায়; আগের document-গুলো থেকে যায় — পুরো ব্যাচ মিলে একটি transaction নয়।

find আর query operator

find(filter, projection) ফেরত দেয় একটি cursor — mongosh প্রথম ২০টি দেখায়, বাকিটা দেখতে it. Filter নিজেই একটি document: { status: "delivered" } মানে status = 'delivered'. তুলনার জন্য query operator — $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin; একাধিক শর্ত একসাথে লিখলে নিজে থেকে AND, আর OR-এর জন্য $or. Embedded document-এর ভেতরে ঢুকতে dot notation — "customer.city" (উদ্ধৃতিচিহ্ন বাধ্যতামূলক)।

db.orders.find({ status: "delivered" })                     // WHERE status = 'delivered'
db.orders.find({ total: { $gt: 3000 } })                    // WHERE total > 3000
db.orders.find({ status: { $in: ["shipped", "pending"] },   // IN (...) AND
                 "customer.city": "Dhaka" })                 //   customer.city = 'Dhaka'
db.orders.find({ $or: [ { status: "pending" },
                        { total: { $gte: 10000 } } ] })      // 1001, 1006, 1009
db.customers.find({ "addresses.city": "Chattogram" })      // array-র যেকোনো ঠিকানায়
db.products.find({ "attrs.colors": "blue" })               // array-তে "blue" থাকলেই
db.orders.countDocuments({ status: "delivered" })          // 5

filter কীভাবে একটি document-এর সাথে মেলানো হয়, তা বোঝার সবচেয়ে ভালো উপায় নিজে একটি ছোট মিলানোর যন্ত্র লেখা। নিচের JavaScript কোডটি এই পাতাতেই চলে — ছয়টি অর্ডারের একটি array-র ওপর $eq, $gt, $gte, $lt, $in আর dot notation মানে এমন একটি খুদে find(). শর্ত বদলে চালিয়ে দেখুন:

const orders = [
  { _id: 1001, status: "delivered", total: 17400, customer: { city: "Dhaka" } },
  { _id: 1002, status: "delivered", total: 1750,  customer: { city: "Chattogram" } },
  { _id: 1003, status: "shipped",   total: 1780,  customer: { city: "Dhaka" } },
  { _id: 1004, status: "cancelled", total: 4500,  customer: { city: "Dhaka" } },
  { _id: 1005, status: "delivered", total: 5050,  customer: { city: "Rajshahi" } },
  { _id: 1006, status: "pending",   total: 3500,  customer: { city: "Sylhet" } },
];
const get = (doc, path) => path.split(".").reduce((v, k) => (v == null ? undefined : v[k]), doc);
const ops = { $eq: (a, b) => a === b, $gt: (a, b) => a > b, $gte: (a, b) => a >= b,
              $lt: (a, b) => a < b, $in: (a, list) => list.includes(a) };
const matches = (doc, filter) => Object.entries(filter).every(([path, cond]) => {
  const v = get(doc, path);                       // "customer.city" = dot notation
  if (cond === null || typeof cond !== "object") return v === cond;   // {f: x} মানে {f: {$eq: x}}
  return Object.entries(cond).every(([op, arg]) => ops[op](v, arg)); // একাধিক অপারেটর = AND
});
const find = (filter) => orders.filter((d) => matches(d, filter)).map((d) => d._id);
console.log(find({ status: "delivered" }));
console.log(find({ total: { $gt: 3000 } }));
console.log(find({ status: { $in: ["shipped", "pending"] }, "customer.city": "Dhaka" }));
console.log(find({ total: { $gte: 1000, $lt: 5000 }, "customer.city": { $eq: "Dhaka" } }));

[ 1001, 1002, 1005 ]
[ 1001, 1004, 1005, 1006 ]
[ 1003 ]
[ 1003, 1004 ]

একই প্রশ্ন SQL-এ, JSON document-এর ওপর — dot notation হয়ে যায় JSON path ('$.customer.city'), আর ->> দেয় SQL মান (পর্ব ৩০):

-- find({ status: "delivered", "customer.city": "Dhaka" })
SELECT id FROM order_docs
WHERE doc ->> '$.status' = 'delivered'
  AND doc ->> '$.customer.city' = 'Dhaka';

-- find({ status: { $in: ["shipped", "pending"] } })
SELECT id, doc ->> '$.status' AS status FROM order_docs
WHERE doc ->> '$.status' IN ('shipped', 'pending');

-- find({ "customer.city": null })
SELECT id, doc -> '$.customer' AS customer FROM order_docs
WHERE doc ->> '$.customer.city' IS NULL;

id
1001

id   │ status
1003 │ shipped
1006 │ pending
1008 │ shipped
1009 │ pending

id   │ customer
1010 │ {"_id":7,"name":"Imran Hossain","city":null}

Array-র ফাঁদ — dot notation বনাম $elemMatch

প্রশ্ন: “কোন অর্ডারে Headphone (102) অন্তত ২টি কেনা হয়েছে?” স্বাভাবিকভাবে লেখা যায় { "items.product_id": 102, "items.qty": { $gte: 2 } }. কিন্তু array-তে প্রতিটি শর্ত আলাদাভাবে যেকোনো উপাদানে মিললেই চলে — একটি item-এ 102, আর অন্য কোনো item-এ qty ≥ 2 থাকলেও document মিলে যাবে। একই উপাদানে দুটি শর্ত চাইলে $elemMatch:

db.orders.find({ "items.product_id": 102, "items.qty": { $gte: 2 } })        // 1001, 1007 (!)
db.orders.find({ items: { $elemMatch: { product_id: 102, qty: { $gte: 2 } } } })  // 1001

-- dot notation-এর অর্থ: দুটি আলাদা EXISTS, দুটি আলাদা item হতে পারে
SELECT d.id FROM order_docs d
WHERE EXISTS (SELECT 1 FROM json_each(d.doc, '$.items') j WHERE j.value ->> 'product_id' = 102)
  AND EXISTS (SELECT 1 FROM json_each(d.doc, '$.items') j WHERE j.value ->> 'qty' >= 2);

-- $elemMatch-এর অর্থ: একটিই EXISTS, একই item-এ দুই শর্ত
SELECT d.id FROM order_docs d
WHERE EXISTS (SELECT 1 FROM json_each(d.doc, '$.items') j
              WHERE j.value ->> 'product_id' = 102 AND j.value ->> 'qty' >= 2);

id          id
1001        1001
1007

Projection, sort, skip আর limit

db.orders.find(
  { status: { $in: ["delivered", "shipped"] } },
  { _id: 1, "customer.name": 1, total: 1 }        // projection: শুধু এই field-গুলো
).sort({ total: -1, _id: 1 }).skip(0).limit(3)    // -1 = বড় থেকে ছোট
// 1001 (17400), 1005 (5050), 1007 (3250)

Projection-এ 1 মানে রাখা, 0 মানে বাদ দেওয়া; দুটি মেশানো যায় না, শুধু _id: 0 ব্যতিক্রম (_id ডিফল্টে সবসময় আসে)। লেখার ক্রম যা-ই হোক, সার্ভার সবসময় আগে sort, তারপর skip, তারপর limit করে। পর্ব ১৫-এর মতো এখানেও sort-এ একটি অনন্য field (_id) যোগ করুন, নইলে সমান total-এর document-গুলোর ক্রম নিশ্চিত নয়, আর পাতাভিত্তিক (pagination) ফলে ডুপ্লিকেট বা বাদ পড়া দেখা দেবে। বড় skip ধীর — বাদ দেওয়া document-গুলোও পড়তে হয়; তাই keyset pagination (“শেষ দেখা total ও _id-এর পরে”) এখানেও ভালো।

৪ · বদলানো আর মোছা — update operator, upsert আর delete

updateOne(filter, update, options) প্রথম মিলে যাওয়া document বদলায়, updateMany সবগুলো। দ্বিতীয় argument-টি নতুন document নয়, বরং কী বদলাতে হবে তার নির্দেশ — update operator দিয়ে লেখা:

// $set — field বসানো/বদলানো (না থাকলে যোগ হয়)
db.orders.updateOne({ _id: 1006 }, { $set: { status: "shipped", shipped_at: new Date() } })
// { acknowledged: true, insertedId: null, matchedCount: 1, modifiedCount: 1, upsertedCount: 0 }

// $inc — শর্তসহ স্টক কমানো: একটি document-এর ভেতরে এটি atomic
db.products.updateOne({ _id: 101, stock: { $gte: 1 } }, { $inc: { stock: -1 } })
// matchedCount: 0 এলে স্টক শেষ — অর্ডার নেবেন না

// $push আর $pull — array-তে যোগ ও বাদ; total-ও একসাথে বদলাতে হবে
db.orders.updateOne({ _id: 1006 }, {
  $push: { items: { product_id: 102, name: "Headphone", qty: 1, unit_price: NumberDecimal("1200") } },
  $inc:  { total: NumberDecimal("1200") }
})
db.orders.updateOne({ _id: 1006 }, {
  $pull: { items: { product_id: 102 } },
  $inc:  { total: NumberDecimal("-1200") }
})

// updateMany — শর্তে মেলা সব document
db.products.updateMany({ stock: 0 }, { $set: { available: false } })

Upsert (update + insert) — মিললে বদলানো, না মিললে নতুন বানানো। দিনভিত্তিক বিক্রির সারাংশের জন্য আদর্শ। আর মোছা — deleteOne আর deleteMany:

db.daily_sales.updateOne(
  { _id: "2025-09-01" },
  { $inc: { orders: 1, revenue: NumberDecimal("17400") } },
  { upsert: true }
)
// প্রথমবার: upsertedCount: 1 → { _id: "2025-09-01", orders: 1, revenue: 17400 }
// পরেরবার: matchedCount: 1  → orders আর revenue বাড়ে

db.orders.deleteOne({ _id: 1004 })                 // { acknowledged: true, deletedCount: 1 }
db.orders.deleteMany({ status: "cancelled", order_date: { $lt: ISODate("2025-01-01") } })
db.orders.deleteMany({})                           // সাবধান: সব document মুছে যায়!

SQLite-এও JSON document এভাবে বদলানো যায় — json_set ≈ $set, path-এ [#] দিয়ে json_insert ≈ $push. তবে পার্থক্য আছে: SQLite প্রতিবার পুরো লেখাটি নতুন করে লেখে, আর টাইপ রক্ষার দায়িত্ব পুরোপুরি আপনার:

-- $set
UPDATE order_docs SET doc = json_set(doc, '$.status', 'shipped') WHERE id = 1006;
-- $inc (প্রথম item-এর qty)
UPDATE order_docs
SET doc = json_set(doc, '$.items[0].qty', (doc ->> '$.items[0].qty') + 1)
WHERE id = 1006;
-- $push
UPDATE order_docs
SET doc = json_insert(doc, '$.items[#]',
          json_object('product_id', 102, 'qty', 1, 'unit_price', 1200))
WHERE id = 1006;
SELECT json_pretty(doc) AS doc FROM order_docs WHERE id = 1006;

✓ UPDATE — ১টি সারি বদলেছে  (তিনবার)
{
    "_id": 1006,
    "customer": { "_id": 6, "name": "Farhana Akter", "city": "Sylhet" },
    "order_date": "2025-09-20",
    "status": "shipped",
    "items": [
        { "product_id": 110, "qty": 2, "unit_price": 3500.0 },
        { "product_id": 102, "qty": 1, "unit_price": 1200 }
    ]
}

৫ · db-shop-কে document-এ সাজানো — embed নাকি reference

Relational ডিজাইনে প্রশ্ন ছিল “ডেটা কী?” — তারপর normalization (পর্ব ৩৬)। Document ডিজাইনে প্রথম প্রশ্ন “অ্যাপ কোন প্রশ্নগুলো সবচেয়ে বেশি করে?” দুটি মূল হাতিয়ার: embed — সম্পর্কিত তথ্য একই document-এর ভেতরে (embedded document বা array); আর reference — শুধু অন্য document-এর _id রাখা (document reference), দরকারে আলাদা পড়া বা $lookup. db-shop-এর অর্ডার দিয়ে ছয়টি প্রশ্নে দুই পথ মিলিয়ে দেখুন:

// Embed: item-এর নাম আর দাম অর্ডারেই কপি
{ _id: 1001, customer: { _id: 1, name: 'Rahim Uddin' },
  items: [ { product_id: 101, name: 'Mobile Phone',
             qty: 1, unit_price: Decimal128('15000') }, … ] }

// Reference: শুধু আইডি
{ _id: 1001, customer_id: 1,
  items: [ { product_id: 101, qty: 1 }, … ] }
// দাম? নাম? → products collection থেকে আনতে হবে

কপি রাখার দুই দিক নিজে চালিয়ে দেখুন। প্রথম কোয়েরি দেখায়, কোন অর্ডারে দেওয়া দাম আজকের দামের থেকে আলাদা — কপি না থাকলে এই ইতিহাস হারিয়ে যেত। তারপর গ্রাহকের নাম বদলানো হলো — কপিগুলো পুরোনোই থেকে গেল:

-- কপি করা দাম বনাম আজকের দাম
SELECT d.id, j.value ->> 'product_id' AS product_id,
       j.value ->> 'unit_price' AS paid, p.price AS price_now
FROM order_docs d, json_each(d.doc, '$.items') j
JOIN products p ON p.product_id = j.value ->> 'product_id'
WHERE j.value ->> 'unit_price' <> p.price;

-- আসল সারিতে নাম বদলাল; document-এর কপি?
UPDATE customers SET name = 'Rahim Uddin Khan' WHERE customer_id = 1;
SELECT id, doc ->> '$.customer.name' AS name_in_order FROM order_docs
WHERE doc ->> '$.customer._id' = 1;

id   │ product_id │ paid  │ price_now
1007 │ 102        │ 1150  │ 1200
1009 │ 101        │ 14500 │ 15000

✓ UPDATE — ১টি সারি বদলেছে
id   │ name_in_order
1001 │ Rahim Uddin
1003 │ Rahim Uddin
1009 │ Rahim Uddin

পাঁচটি প্রচলিত schema pattern

Bucket pattern এতটাই প্রচলিত যে MongoDB ৫.০ থেকে time series collection নামে এটি নিজেই দেয় — আপনি একটি একটি করে মাপ ঢোকান, ভেতরে সার্ভার সেগুলো গুচ্ছ করে আর সংকুচিত রাখে। Computed pattern-এর দাম হলো দায়িত্ব: অংশ ৪-এ $push-এর সাথে $inc: { total } ভুলে গেলে total আর item-এর যোগফল আর মিলবে না।

৬ · Aggregation pipeline — SQL-এর পাশে পাশে

find document বাছে আর সাজায়, কিন্তু যোগফল, গড় বা গ্রুপ করা হিসাব পারে না। তার জন্য aggregation pipeline: stage-এর একটি তালিকা, যেখানে প্রতিটি stage আগেরটির বের করা document-গুলো নেয়, কিছু করে, পরেরটিকে দেয় — কারখানার কনভেয়ার বেল্টের মতো। প্রধান stage: $match (বাছাই), $project (field বাছা বা নতুন field), $unwind (array-র প্রতিটি উপাদানকে আলাদা document), $lookup (অন্য collection থেকে মেলানো — left join-এর মতো), $group, $sort, $limit.

প্রশ্ন ১: delivered আর shipped অর্ডারে ক্যাটাগরিভিত্তিক বিক্রি কত? প্রথম ট্যাবে MongoDB, দ্বিতীয়টিতে SQL:

db.orders.aggregate([
  { $match:  { status: { $in: ["delivered", "shipped"] } } },
  { $unwind: "$items" },
  { $lookup: { from: "products", localField: "items.product_id",
               foreignField: "_id", as: "product" } },
  { $unwind: "$product" },
  { $group:  { _id: "$product.category",
               revenue: { $sum: { $multiply: ["$items.qty", "$items.unit_price"] } } } },
  { $sort:   { revenue: -1 } },
  { $project: { _id: 0, category: "$_id", revenue: 1 } }
])

SELECT c.name AS category, SUM(i.quantity * i.unit_price) AS revenue
FROM orders o                                          -- db.orders
JOIN order_items i ON i.order_id = o.order_id          -- $unwind "$items"
JOIN products p    ON p.product_id = i.product_id      -- $lookup + $unwind
JOIN categories c  ON c.category_id = p.category_id
WHERE o.status IN ('delivered', 'shipped')             -- $match
GROUP BY c.name                                        -- $group
ORDER BY revenue DESC;                                 -- $sort

দশটি অর্ডার এই pipeline দিয়ে কীভাবে বয়ে যায়, ধাপে ধাপে দেখুন:

এবার SQL-এ চালিয়ে দেখুন — প্রথমে সাধারণ টেবিলে, তারপর document-এর ওপর। দ্বিতীয়টিতে json_each ঠিক $unwind-এর কাজ করছে:

SELECT c.name AS category,
       SUM(i.quantity * i.unit_price) AS revenue
FROM orders o
JOIN order_items i ON i.order_id = o.order_id
JOIN products p    ON p.product_id = i.product_id
JOIN categories c  ON c.category_id = p.category_id
WHERE o.status IN ('delivered', 'shipped')
GROUP BY c.name
ORDER BY revenue DESC;

category    │ revenue
Electronics │ 18550
Grocery     │ 4920
Clothing    │ 4400
Books       │ 2950

-- document-এর ওপর: json_each = $unwind, JOIN products = $lookup
SELECT c.name AS category,
       SUM((j.value ->> 'qty') * (j.value ->> 'unit_price')) AS revenue,
       COUNT(*) AS line_items
FROM order_docs d, json_each(d.doc, '$.items') j
JOIN products p   ON p.product_id = j.value ->> 'product_id'
JOIN categories c ON c.category_id = p.category_id
WHERE d.doc ->> '$.status' IN ('delivered', 'shipped')
GROUP BY c.name
ORDER BY revenue DESC;

category    │ revenue │ line_items
Electronics │ 18550   │ 3
Grocery     │ 4920    │ 4
Clothing    │ 4400    │ 1
Books       │ 2950    │ 4

pipeline-এর ভেতরের যুক্তিটা আরও স্পষ্ট হয়, যখন প্রতিটি stage-কে একটি সাধারণ ফাংশন হিসেবে লেখা হয় — document-এর তালিকা ঢোকে, document-এর তালিকা বেরোয়। নিচের Python প্রোগ্রামটি (শুধু standard library) db-shop-এর দশটি অর্ডারের ওপর একই pipeline চালায়:

from collections import defaultdict
category = {**dict.fromkeys([101, 102, 103, 110], "Electronics"), **dict.fromkeys([104, 105], "Books"),
            **dict.fromkeys([106, 107], "Clothing"), **dict.fromkeys([108, 109], "Grocery")}
raw = [(1001, "delivered", [(101, 1, 15000), (102, 2, 1200)]), (1002, "delivered", [(104, 1, 650), (105, 2, 550)]),
       (1003, "shipped", [(108, 3, 420), (109, 2, 260)]), (1004, "cancelled", [(107, 1, 4500)]),
       (1005, "delivered", [(104, 1, 650), (106, 2, 2200)]), (1006, "pending", [(110, 1, 3500)]),
       (1007, "delivered", [(102, 1, 1150), (108, 5, 420)]), (1008, "shipped", [(105, 1, 550)]),
       (1009, "pending", [(101, 1, 14500), (110, 1, 3500)]), (1010, "delivered", [(109, 4, 260)])]
docs = [{"_id": o, "status": s, "items": [{"product_id": p, "qty": q, "unit_price": u} for p, q, u in it]} for o, s, it in raw]
def group_sum(docs):                     # {$group: {_id: "$category", revenue: {$sum: {$multiply: [qty, price]}}}}
    acc = defaultdict(int)
    for d in docs: acc[d["category"]] += d["items"]["qty"] * d["items"]["unit_price"]
    return [{"_id": k, "revenue": v} for k, v in acc.items()]
pipeline = [("$match",  lambda ds: [d for d in ds if d["status"] in ("delivered", "shipped")]),
            ("$unwind", lambda ds: [{**d, "items": x} for d in ds for x in d["items"]]),
            ("$lookup", lambda ds: [{**d, "category": category[d["items"]["product_id"]]} for d in ds]),
            ("$group",  group_sum),
            ("$sort",   lambda ds: sorted(ds, key=lambda d: -d["revenue"]))]
print(f"input    -> {len(docs):2} docs")
for name, stage in pipeline:
    docs = stage(docs); print(f"{name:8} -> {len(docs):2} docs")
for d in docs: print(d)

input    -> 10 docs
$match   ->  7 docs
$unwind  -> 12 docs
$lookup  -> 12 docs
$group   ->  4 docs
$sort    ->  4 docs
{'_id': 'Electronics', 'revenue': 18550}
{'_id': 'Grocery', 'revenue': 4920}
{'_id': 'Clothing', 'revenue': 4400}
{'_id': 'Books', 'revenue': 2950}

প্রশ্ন ২: সবচেয়ে বেশি কেনাকাটা করা তিন গ্রাহক। অর্ডারে total (computed) আর customer-এর কপি (extended reference) থাকায় MongoDB-তে $lookup-ই লাগে না:

db.orders.aggregate([
  { $match: { status: { $in: ["delivered", "shipped"] } } },
  { $group: { _id: "$customer._id", name: { $first: "$customer.name" },
              spent: { $sum: "$total" }, orders: { $sum: 1 } } },
  { $sort:  { spent: -1, _id: 1 } },
  { $limit: 3 }
])

SELECT c.customer_id, c.name,
       SUM(i.quantity * i.unit_price) AS spent,
       COUNT(DISTINCT o.order_id) AS orders
FROM customers c
JOIN orders o      ON o.customer_id = c.customer_id
JOIN order_items i ON i.order_id = o.order_id
WHERE o.status IN ('delivered', 'shipped')
GROUP BY c.customer_id, c.name
ORDER BY spent DESC, c.customer_id
LIMIT 3;

customer_id │ name         │ spent │ orders
1           │ Rahim Uddin  │ 19180 │ 2
4           │ Nusrat Jahan │ 5050  │ 1
2           │ Karima Begum │ 5000  │ 2

৭ · Index, ESR নিয়ম আর explain()

Index ছাড়া প্রতিটি find পুরো collection পড়ে — explain-এ এর নাম COLLSCAN, SQL-এর full table scan. MongoDB-র সাধারণ index একটি B-tree (পর্ব ৪০), আর _id-এ একটি অনন্য index সবসময় নিজে থেকে থাকে। প্রধান ধরনগুলো:

db.orders.createIndex({ status: 1 })                              // single field
db.orders.createIndex({ status: 1, order_date: -1, total: 1 })    // compound (ESR, নিচে)
db.orders.createIndex({ "items.product_id": 1 })                  // multikey: array-র প্রতিটি মান
db.products.createIndex({ name: "text", description: "text" })    // text: প্রতি collection-এ একটি
db.sessions.createIndex({ last_seen: 1 }, { expireAfterSeconds: 1800 })  // TTL: ৩০ মিনিট পর মুছবে
db.customers.createIndex({ phone: 1 },
  { unique: true, partialFilterExpression: { phone: { $type: "string" } } })

• Compound (composite index) — একাধিক field, ক্রম গুরুত্বপূর্ণ; পর্ব ৪১-এর leftmost prefix নিয়ম এখানেও খাটে।
• Multikey — array field-এ index দিলে MongoDB নিজেই প্রতিটি উপাদানের জন্য একটি key রাখে; “Headphone আছে এমন সব অর্ডার” দ্রুত হয়। একটি compound index-এ প্রতি document-এ সর্বোচ্চ একটি field array হতে পারে।
• Text — শব্দভিত্তিক খোঁজ ($text), পর্ব ৩০-এর inverted index-এর ধারণা। Atlas-এ আরও শক্তিশালী Atlas Search আলাদা সেবা।
• TTL — Date field-এ, নির্দিষ্ট সময় পর document নিজে থেকে মোছে; লগইন session বা OTP-র জন্য উপযোগী। একটি পটভূমির কাজ প্রায় প্রতি ৬০ সেকেন্ডে চলে, তাই মোছা ঠিক সেই মুহূর্তে নয়।
• Unique + partial — MongoDB-র unique index-এ null বা না-থাকা field-ও একটি মান ধরা হয়, তাই ফোনহীন দুজন গ্রাহক (Tanvir-এর মতো) রাখা যেত না। SQLite, PostgreSQL বা MySQL-এর UNIQUE একাধিক NULL মেনে নেয় (পর্ব ১৩; SQL Server ব্যতিক্রম) — এখানে নয়। partialFilterExpression শুধু string ফোনগুলোকে index-এ রাখে।

ESR নিয়ম — compound index-এ field-এর ক্রম

প্রশ্ন: “delivered অর্ডার, total অন্তত ২,০০০, নতুন তারিখ আগে।” MongoDB-র নিজস্ব নির্দেশিকা ESR rule: compound index-এ আগে Equality-র field (=), তারপর Sort-এর field, শেষে Range-এর field ($gt, $lt, $in-এর অনেক ক্ষেত্র)। দশটি অর্ডারে চারটি বিকল্প মিলিয়ে দেখুন:

db.orders.find({ status: "delivered", total: { $gte: 2000 } }).sort({ order_date: -1 })
// উত্তর: 1007 (2025-10-01), 1005 (2025-09-15), 1001 (2025-09-01)

db.orders.find({ status: "delivered", total: { $gte: 2000 } })
         .sort({ order_date: -1 })
         .explain("executionStats")
// সংক্ষেপিত; গঠন সংস্করণভেদে আলাদা, আর সংখ্যাগুলো এই ছোট উদাহরণের আনুমানিক মান
// winningPlan:    { stage: "FETCH", inputStage: { stage: "IXSCAN",
//                   indexName: "status_1_order_date_-1_total_1", ... } }
// executionStats: { nReturned: 3, totalKeysExamined: 5, totalDocsExamined: 3, ... }

explain()-এ তিনটি জিনিস দেখুন: plan-এ COLLSCAN নাকি IXSCAN; আলাদা SORT stage আছে কি না; আর nReturned, totalKeysExamined, totalDocsExamined-এর অনুপাত — আদর্শ ক্ষেত্রে তিনটি কাছাকাছি। ফেরত ৩টি কিন্তু পড়া ১০,০০০টি হলে index ঠিক নেই। আর প্রতিটি index লেখাকে ধীর করে আর জায়গা নেয়, তাই পর্ব ৪১-এর মতো এখানেও অপ্রয়োজনীয় index বাদ দিন।

৮ · Schema validation আর transaction

$jsonSchema — “schema-less” মানে নিয়মহীন নয়

MongoDB-কে প্রায়ই “schema-less” বলা হয়, কিন্তু আসলে schema থাকে অ্যাপের কোডে — পর্ব ৪-এর schema-on-read. অংশ ৪-এ দেখেছেন, এতে টাইপ সহজেই মিশে যায়। তাই collection-এ schema validation দেওয়া যায় — JSON Schema-এর একটি রূপ দিয়ে, সাথে BSON টাইপের জন্য bsonType:

db.createCollection("orders", {
  validator: { $jsonSchema: {
    bsonType: "object",
    required: ["customer", "order_date", "status", "items", "total"],
    properties: {
      order_date: { bsonType: "date" },
      status: { enum: ["pending", "shipped", "delivered", "cancelled"] },
      total:  { bsonType: "decimal", minimum: 0 },
      items: { bsonType: "array", minItems: 1, items: {
        bsonType: "object", required: ["product_id", "qty", "unit_price"],
        properties: {
          qty:        { bsonType: "int", minimum: 1 },
          unit_price: { bsonType: "decimal" }          // সাধারণ 1200 (int বা double) চলবে না
        } } }
    } } },
  validationLevel: "strict",      // প্রতিটি insert আর update যাচাই
  validationAction: "error"       // ভুল হলে লেখা প্রত্যাখ্যান ("warn" = শুধু লগ)
})
// নিয়ম ভাঙলে: MongoServerError: Document failed validation

এটি SQL-এর CHECK আর NOT NULL-এর কাছাকাছি, কিন্তু foreign key নয় — product_id-এর পণ্যটি আদৌ আছে কি না, validator জানে না। একটি সূক্ষ্মতা: সাধারণ সংখ্যা (যেমন qty: 2) int হিসেবে যাবে নাকি double হিসেবে, তা শেল আর ড্রাইভারভেদে আলাদা (পুরোনো mongo শেল সব সংখ্যা double পাঠাত)। নিশ্চিত হতে NumberInt(2) লিখুন, অথবা নিয়ম শিথিল করে bsonType: ["int", "long", "double"] দিন। Validation এই অমিলগুলো শুরুতেই ধরে।

Transaction — কখন লাগে

MongoDB-তে একটি document-এর ভেতরে যেকোনো update atomic — $push আর $inc: { total } একসাথে হয়, নয়তো কোনোটিই না। Embed নকশার এটি বড় সুবিধা: অর্ডার আর তার item আলাদা টেবিলে না থাকায় অনেক ক্ষেত্রে transaction-ই লাগে না। কিন্তু একাধিক document বা collection একসাথে বদলাতে হলে — যেমন পণ্যের স্টক কমানো আর অর্ডার তৈরি — লাগবে multi-document transaction: replica set-এ ৪.০ (২০১৮) থেকে, sharded cluster-এ ৪.২ থেকে। Transaction চলে একটি session-এর ভেতরে:

const session = db.getMongo().startSession();
const shop = session.getDatabase("shop");
session.startTransaction({ readConcern: { level: "snapshot" },
                           writeConcern: { w: "majority" } });
try {
  const r = shop.products.updateOne({ _id: 110, stock: { $gte: 1 } },
                                    { $inc: { stock: -1 } });
  if (r.matchedCount === 0) throw new Error("out of stock");
  shop.orders.insertOne({ _id: 1011, customer: { _id: 5, name: "Tanvir Ahmed", city: "Khulna" },
    order_date: new Date(), status: "pending",
    items: [ { product_id: 110, name: "Smart Watch", qty: NumberInt(1), unit_price: NumberDecimal("3500") } ],
    total: NumberDecimal("3500") });
  session.commitTransaction();          // দুটি লেখা একসাথে দৃশ্যমান
} catch (e) {
  session.abortTransaction();           // কোনোটিই থাকবে না
  throw e;
} finally {
  session.endSession();
}

এখানে পর্ব ৪৪-এর ACID-এর সব কটি গুণ পাওয়া যায় — snapshot read concern আর majority write concern মিলে isolation আর durability. বাস্তবে Node.js বা Python-এর ড্রাইভারে withTransaction() ব্যবহার করা ভালো: এটি সাময়িক error-এ (যেমন আরেক transaction-এর সাথে write conflict) নিজে থেকে আবার চেষ্টা করে। সীমা মনে রাখুন: ডিফল্টে একটি transaction ৬০ সেকেন্ডের বেশি চলতে পারে না, আর বহু document ছোঁয়া দীর্ঘ transaction সার্ভারের ওপর চাপ বাড়ায়। নিয়মটা উল্টো দিক থেকে ভাবুন — প্রায় প্রতিটি কাজে transaction লাগলে নকশাটি হয়তো আসলে relational.

৯ · Replica set, sharding, concern, নিরাপত্তা — আর কখন MongoDB

Replica set: একই ডেটার কয়েকটি কপি রাখা সার্ভারের দল — একটি primary (সব লেখা এখানে), বাকিরা secondary, যারা primary-র oplog (সব পরিবর্তনের একটি বিশেষ collection) পড়ে নিজেদের কপি হালনাগাদ রাখে। Primary বন্ধ হলে বাকিরা ভোট দিয়ে নতুন primary বেছে নেয় — সাধারণত কয়েক সেকেন্ড থেকে দশ-বারো সেকেন্ডের মধ্যে, আর ড্রাইভার নিজে নতুন primary খুঁজে নেয়। ভোটে সংখ্যাগরিষ্ঠতা লাগে বলে সদস্য সাধারণত বিজোড়, অন্তত তিন। এটি পর্ব ৫২-এর replication আর failover-এর MongoDB রূপ।

Sharding: ডেটা একটি সার্ভারের সামর্থ্য ছাড়ালে collection-কে shard key ধরে কয়েকটি shard-এ (প্রতিটি নিজেই একটি replica set) ভাগ করা হয়। অ্যাপ কথা বলে mongos router-এর সাথে, যে config server থেকে জানে কোন key-র পরিসর কোন shard-এ। Shard key-ই সব ঠিক করে: customer._id-এর মতো key হলে এক গ্রাহকের প্রশ্ন একটি shard-এই যায়; key-টি filter-এ না থাকলে প্রশ্ন সব shard-এ ছড়ায় (scatter-gather). একটানা বাড়তে থাকা key (যেমন শুধু order_date) হলে সব নতুন লেখা এক shard-এ জমে — পর্ব ৫৪-এর hot spot. ৫.০ থেকে shard key বদলানো (resharding) সম্ভব, কিন্তু ভারী কাজ — শুরুতেই ভেবে নিন।

Write concern আর read concern: লেখা কতটা নিরাপদ হলে “হয়েছে” বলা হবে — w: 1 (শুধু primary পেয়েছে) বনাম w: "majority" (সংখ্যাগরিষ্ঠ সদস্য পেয়েছে, তাই failover-এও হারাবে না; ৫.০ থেকে বেশিরভাগ ক্ষেত্রে এটিই ডিফল্ট)। Read concern বলে কোন ডেটা পড়া যাবে — "local" (ডিফল্ট, হয়তো পরে rollback হতে পারে এমনও), "majority" (শুধু সংখ্যাগরিষ্ঠে নিশ্চিত), "snapshot" (transaction-এ)। আর read preference দিয়ে secondary থেকে পড়লে ডেটা একটু পুরোনো হতে পারে — eventual consistency, পর্ব ৫৪-এর CAP আলোচনার বাস্তব রূপ।

নিরাপত্তা — খোলা দরজা বন্ধ রাখুন

বহু বছর ধরে ইন্টারনেটে খোলা, password ছাড়া চলা MongoDB সার্ভার থেকে বিপুল ব্যক্তিগত তথ্য ফাঁস হয়েছে, আর কিছু ক্ষেত্রে আক্রমণকারী ডেটা মুছে “মুক্তিপণ” দাবি করেছে বলে ব্যাপকভাবে জানা যায়। সমস্যাটা প্রায়ই সফটওয়্যারের দুর্বলতা নয় — কনফিগারেশন। ৩.৬ সংস্করণ থেকে সার্ভার ডিফল্টে শুধু localhost-এ শোনে, কিন্তু Docker-এ ভুল port, ক্লাউডে 0.0.0.0/0 বা authentication বন্ধ রাখা — এই একই ভুল এখনো ঘটে। ন্যূনতম তালিকা:

• Authentication চালু (security.authorization: enabled; Atlas-এ এটি সবসময় চালু), প্রতিটি অ্যাপের আলাদা user
• Least privilege: অ্যাপের user-কে শুধু নিজের database-এ readWrite, admin role নয়
• নেটওয়ার্ক: bindIp শুধু দরকারি ঠিকানায়, firewall বা Atlas IP access list; ২৭০১৭ port কখনো পুরো ইন্টারনেটে নয়
• TLS দিয়ে সংযোগ; connection string-এর password কোডে নয়, environment variable বা secrets manager-এ
• ব্যবহারকারীর ইনপুট সরাসরি filter-এ নয় — { password: { $ne: null } }-এর মতো operator ঢুকে যেতে পারে (NoSQL injection); টাইপ যাচাই করুন (string চাই তো string), আর $where বা server-side JavaScript এড়িয়ে চলুন

কখন MongoDB, কখন PostgreSQL + JSONB

db-shop-এর মতো দোকানের জন্য — টাকা, স্টক আর বহু সম্পর্ক — PostgreSQL + JSONB প্রায়ই সহজ ও নিরাপদ বাছাই। কিন্তু একই দোকানের পণ্য-ক্যাটালগ আর রিভিউ, বা একটি কনটেন্ট-অ্যাপের পুরো ডেটা MongoDB-তে স্বাভাবিকভাবে বসে। প্রশ্নটা “কোন পণ্য সেরা” নয়, “আমার ডেটার আকার আর নিশ্চয়তার চাহিদা কী” (পর্ব ৫৬)।

১০ · AI-এর যুগে MongoDB

MongoDB-র কোড AI খুব সাবলীলভাবে লেখে — JSON-এর মতো সিনট্যাক্স ভাষা-মডেলের কাছে স্বাভাবিক। কিন্তু চলার মতো কোড আর সঠিক কোড এক নয়। SQL-এর মতোই এখানেও AI চলে কিন্তু ভুল ফল দেয় এমন কোয়েরি লেখে, field-এর নাম বানায়, আর index ও transaction-এর কথা ভুলে যায়:

AI-এর লেখা MongoDB কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি field-এর নাম আসল document-এর সাথে মিলিয়েছি (findOne() দিয়ে একটি নমুনা দেখে)
• array-তে একাধিক শর্ত থাকলে $elemMatch লাগবে কি না ভেবেছি; একটি “ফাঁদের” document দিয়ে পরীক্ষা করেছি
• ছোট পরীক্ষার ডেটায় চালিয়ে ফলের সংখ্যা হাতে গুনে মিলিয়েছি — null বা না-থাকা field, ফাঁকা array আর $unwind-এ বাদ পড়া document-সহ
• explain("executionStats")-এ COLLSCAN বা আলাদা SORT নেই, আর key ও document পড়ার সংখ্যা ফলের কাছাকাছি
• টাকা Decimal128-এ, তারিখ Date-এ; একাধিক document একসাথে বদলালে transaction বা নকশা বদলের কথা ভেবেছি; সংযোগে auth ও TLS আছে