Managed NoSQL, cache আর data warehouse — কখন কোনটি

১ · এক database দিয়ে সব কাজ কেন চলে না

পর্ব ২২-এ আমরা managed relational database দেখেছি। সেটি দারুণ সাধারণ একটি হাতিয়ার, আর বেশিরভাগ app-এর শুরু সেখান থেকেই হওয়া উচিত। কিন্তু একটি কাল্পনিক অনলাইন বাজার অ্যাপ বড় হলে একই database-এ চারটি খুব আলাদা অনুরোধ আসে। কেউ নিজের cart খুলছেন। কেউ “লাল শাড়ি” লিখে খুঁজছেন। Home page-এর একই তালিকা প্রতি সেকেন্ডে হাজারবার পড়া হচ্ছে। আর হিসাব বিভাগ জানতে চাইছে, গত দুই বছরে কোন জেলায় কত বিক্রি হলো।

তাই প্রশ্নটি “কোন database সেরা” নয়। প্রশ্নটি হলো আপনার query দেখতে কেমন। Query কয়টি row ছোঁয়, কোন পথে খোঁজে, উত্তর কত দ্রুত চাই, আর data কত পুরোনো হলে চলবে। এই হিসাবকে আমরা বলব query shape. SQL আর NoSQL-এর তাত্ত্বিক তুলনা আছে System Design-এর SQL বনাম NoSQL পর্বে আর DBMS কোর্সের NoSQL পর্বে। এখানে আমরা দেখব, cloud-এ এগুলো কিনে চালাতে গেলে কী হিসাব করতে হয়।

তিন provider-এ একই ধারণা আলাদা নামে পাওয়া যায়। নিচের তালিকাটি লেখার সময়ের উদাহরণ। Service-এর নাম, ধরন আর সুবিধা বদলায়, তাই সিদ্ধান্তের আগে provider-এর docs দেখুন।

২ · Key-value আর document service — আগে প্রশ্ন, পরে নকশা

Key-value store-এ একটি key দিলে তার value ফেরত আসে। Document database-এ value হলো JSON-এর মতো গঠনের একটি document, আর তার ভেতরের field ধরেও খোঁজা যায়। DynamoDB, Cosmos DB আর Firestore এই ঘরানার managed উদাহরণ। আপনি server, patch বা disk দেখেন না। আপনি দেখেন table বা collection, আর প্রতিটি অনুরোধের বিল।

এর বিনিময়ে একটি শর্ত আছে। Relational নকশায় আগে data সাজানো হয়, প্রশ্ন আসে পরে। এখানে উল্টো। আগে access pattern-এর তালিকা, অর্থাৎ app ঠিক কোন কোন প্রশ্ন করবে তার তালিকা। তারপর key সাজানো, যাতে প্রতিটি প্রশ্ন একবারেই সঠিক জায়গায় পৌঁছায়। রান্নাঘরের রেসিপি খাতার সূচিপত্র রান্না শুরুর আগেই লেখা হয়; পরে নতুন ধরনের সূচি চাইলে পুরো খাতা নতুন করে সাজাতে হয়।

আমাদের কাল্পনিক অনলাইন বাজার অ্যাপের অর্ডার ধরা যাক। একটি item-এ দুই অংশের key থাকে। Partition key ঠিক করে item কোন ভাগে যাবে, আর sort key সেই ভাগের ভেতরে ক্রম ঠিক করে।

{
  "pk": "CUST#123",
  "sk": "ORDER#2026-10-30#9012",
  "shop_id": "SHOP#45",
  "status": "PAID",
  "total": 1850,
  "items": [{ "sku": "RICE-5KG", "qty": 2 }]
}

শেষ সারিটি সবচেয়ে গুরুত্বপূর্ণ। Query মানে একটি partition-এর ভেতরে পড়া। Scan মানে পুরো table পড়া, আর প্রতিটি পড়া item-এর দাম দেওয়া, filter করে ফেলে দিলেও। ধরুন ১০ GB-র table, প্রতি ৪ KB-তে ০.৫ capacity unit. তাহলে একটি Scan-এ লাগে 10,000,000 KB ÷ 4 × 0.5 = 1,250,000 ইউনিট। সেকেন্ডে ১,০০০ ইউনিট বরাদ্দ থাকলে ১,২৫০ সেকেন্ড, অর্থাৎ প্রায় ২১ মিনিট। ততক্ষণ বাকি app-এর ভাগে টান পড়ে।

Consistency-ও service-ভেদে আলাদা। লেখার সময়ে DynamoDB-তে পড়া সাধারণত eventually consistent, আর অনুরোধে strongly consistent পড়া যায়, দ্বিগুণ দামে। Cosmos DB পাঁচটি স্তর দেয়, যার default সাধারণত Session. Firestore-এর পড়া strongly consistent বলে নথিভুক্ত। আসল কথা, “সদ্য লেখা জিনিস এখনই দেখা চাই কি না” একটি ব্যবসায়িক প্রশ্ন, এবং এর দাম আছে। তত্ত্ব আছে CAP আর consistency পর্বে।

৩ · Partition key আর hot partition

Table আসলে একটি জিনিস নয়। Provider data ভাগ করে অনেক partition-এ রাখে, আর partition key-র hash থেকে ঠিক হয় কোন item কোথায় যাবে। Sharding-এর তত্ত্ব আছে System Design-এর partitioning পর্বে। Cloud-এ এর সবচেয়ে বড় ব্যবহারিক ফল হলো, capacity পুরো table-এর হলেও সীমা বসে প্রতিটি partition-এ।

লেখার সময়ে DynamoDB-র একটি partition সাধারণত প্রতি সেকেন্ডে প্রায় ৩,০০০ RCU বা ১,০০০ WCU পর্যন্ত নিতে পারে বলে নথিভুক্ত। অন্য service-এ সংখ্যা আলাদা, ধারণা একই। নিচের simulator-এ table-এর ৪টি partition, মোট ৪,০০০ WCU, আর traffic মাত্র ৩,০০০ লেখা/সেকেন্ড। তিন রকম key-তে কী হয় দেখুন।

// 4 partitions, 1000 WCU/s each (4000 total). Traffic: 3000 writes/s for 60 s.
let seed = 23;
function rand() {                  // mulberry32: small seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0;
  let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
function hash(s) {                 // FNV-1a, stands in for the provider's hash
  let h = 0x811C9DC5;
  for (const c of s) h = Math.imul(h ^ c.charCodeAt(0), 16777619);
  return h >>> 0;
}
const PARTS = 4, LIMIT = 1000, RATE = 3000, SECONDS = 60;
function run(name, pickKey) {
  const done = Array(PARTS).fill(0), throttled = Array(PARTS).fill(0);
  for (let s = 0; s < SECONDS; s++) {
    const used = Array(PARTS).fill(0);          // the budget resets each second
    for (let i = 0; i < RATE; i++) {
      const p = hash(pickKey()) % PARTS;
      if (used[p] < LIMIT) { used[p]++; done[p]++; } else throttled[p]++;
    }
  }
  const lost = throttled.reduce((a, b) => a + b, 0);
  console.log(name);
  console.log("  writes/s per partition: " +
    done.map((d, p) => ((d + throttled[p]) / SECONDS).toFixed(0)).join("  "));
  console.log("  throttled: " + lost + " of " + RATE * SECONDS +
    " (" + (100 * lost / (RATE * SECONDS)).toFixed(1) + "%)");
}
const anyUser = () => "user#" + Math.floor(rand() * 100000);
run("A. many keys", anyUser);
run("B. 50% on one key", () => rand() < 0.5 ? "product#777" : anyUser());
run("C. hot key split into 20", () => rand() < 0.5 ?
  "product#777#" + Math.floor(rand() * 20) : anyUser());

C-র কৌশলকে বলে write sharding. দাম আছে: পণ্যটির সব লেখা পড়তে এখন ২০টি key-তে প্রশ্ন পাঠাতে হবে। তাই এটি উপযুক্ত গণনা বা log-এর জন্য, যেখানে পড়া কম। আধুনিক service-ও অনেকটা সাহায্য করে। Adaptive capacity ব্যস্ত partition-কে অন্যের অব্যবহৃত ভাগ ধার দেয়, আর partition ভেঙেও আলাদা করতে পারে। কিন্তু একটিমাত্র item-এ ঢালা ভার কোনো ভাগাভাগিতে ছড়ায় না। এটাকেই বলে hot key.

৪ · Capacity-র হিসাব — RCU, WCU আর দুই রকম বিল

Managed NoSQL-এ CPU বা RAM কেনা হয় না। কেনা হয় পড়া ও লেখার ইউনিট। নিচের সংখ্যাগুলো DynamoDB-র ধরনে, লেখার সময়ের। অন্য provider-এ মূল ধারণা এক, মাপ আলাদা। যেমন Cosmos DB-তে সব কাজ একটি একক Request Unit-এ মাপা হয়, যেখানে ১ KB item-এর point read প্রায় ১ RU, আর Firestore-এ বিল হয় পড়া ও লেখা document-এর সংখ্যায়।

পূর্ণ সমাধান: প্রতি সেকেন্ডে ২০০টি ৬ KB item পড়তে হবে, strongly consistent. ৬ ÷ ৪ = ১.৫, যা ওপরে গোল হয়ে ২ RCU. মোট ২০০ × ২ = ৪০০ RCU. Eventually consistent হলে ২০০ RCU. প্রতি সেকেন্ডে ৫০টি ২.৪ KB লেখা: ২.৪ ওপরে গোল হয়ে ৩ WCU, মোট ১৫০ WCU. একটি secondary index সব attribute রাখলে সেখানেও ১৫০, তাই মোট ৩০০ WCU.

নিচের stepper-এ একটি অর্ডার লেখার পুরো খরচ দেখুন। এখানে table-এ একটি secondary index আছে, যাতে item-এর সব attribute কপি হয়।

অনুমান না করে খরচ দেখার উপায়ও আছে। বেশিরভাগ SDK আর CLI একটি অনুরোধে কত ইউনিট গেল তা জানাতে পারে। নিচেরটি উদাহরণ, চালানোর জন্য নয়; আউটপুটটি নমুনা, version-ভেদে আলাদা হতে পারে।

aws dynamodb put-item --table-name orders \
  --item file://order_item.dynamodb.json \
  --return-consumed-capacity INDEXES

# নমুনা আউটপুট
# { "ConsumedCapacity": { "TableName": "orders", "CapacityUnits": 6.0,
#     "Table": { "CapacityUnits": 3.0 },
#     "GlobalSecondaryIndexes": { "shop-date": { "CapacityUnits": 3.0 } } } }

Provisioned নাকি on-demand

Provisioned capacity মানে আগেই বলে দেওয়া, “সেকেন্ডে এত ইউনিট রাখুন”, আর ব্যবহার হোক বা না হোক, ঘণ্টা ধরে দাম দেওয়া। On-demand capacity মানে প্রতিটি অনুরোধের দাম দেওয়া। প্রথমটি মাসিক CNG চুক্তি, দ্বিতীয়টি প্রতিবার আলাদা ভাড়া। রোজ একই পথে গেলে চুক্তি সস্তা, মাঝেমধ্যে গেলে আলাদা ভাড়া।

ধরে নিই ১ WCU-মাসের দাম $০.৫০, আর on-demand-এ প্রতি ১০ লাখ লেখায় $১। সংখ্যাগুলো হিসাব বোঝার জন্য; আসল দাম provider-এর pricing page-এ দেখুন। ৩০ দিনে ২৫,৯২,০০০ সেকেন্ড। Provisioned-এর লক্ষ্য ৭০% ব্যবহার ধরা হলো, যাতে headroom থাকে।

Break-even: ১ WCU সারা মাস পুরো চললে ২৫.৯২ লাখ লেখা হয়, যার on-demand দাম $২.৫৯২। Provisioned-এর দাম $০.৫০। তাই ০.৫০ ÷ ২.৫৯২ ≈ ১৯.৩%. গড় ব্যবহার এর বেশি হলে এই অনুমিত দামে provisioned সস্তা, কম হলে on-demand. দ্বিতীয় সারিতে autoscaling ঠিক সময়ে বাড়তে পারলে গড় প্রায় ১৩২ WCU, অর্থাৎ প্রায় $৬৬ হতো। কিন্তু ১০ থেকে ১,০০০-এ হঠাৎ লাফে autoscaling পিছিয়ে পড়ে, আর সেই ফাঁকে throttle হয়।

৫ · Managed cache — hit ratio-র হিসাব

Cache হলো দ্রুত মেমরিতে রাখা data-র সাময়িক কপি। সবচেয়ে চেনা নকশা cache-aside: app আগে cache-এ খোঁজে, না পেলে database থেকে এনে cache-এ রেখে দেয়। Write-through-সহ বিভিন্ন কৌশলের বিস্তারিত আছে Caching কৌশল পর্বে, আর Redis-এর গঠন DBMS কোর্সের Redis পর্বে।

ElastiCache, Azure Managed Redis আর Memorystore-এ node চালানো, patch, replica আর failover provider সামলায়। আপনার দায়িত্বে থাকে node-এর আকার, TTL, eviction নীতি, network নিয়ম, আর সবচেয়ে বড় কথা, cache না থাকলে কী হবে তার পরিকল্পনা। ধরে নিন cache আপনার VPC-র ভেতরে থাকবে, internet-এ খোলা নয়।

Cache-এর দক্ষতার মাপ cache hit ratio: যত অনুরোধ cache-এই উত্তর পেল তার ভাগ। ধরুন h হলো hit ratio, cache-এর সময় T_c, database-এর সময় T_db. Cache-aside-এ miss হলেও আগে cache-এ খোঁজা হয়, তাই:

পূর্ণ সমাধান: ১০,০০০ অনুরোধ/সেকেন্ড, T_c = ১ ms, T_db = ২০ ms. h = ০.৯ হলে গড় ১ + ০.১ × ২০ = ৩ ms আর database-এ ১,০০০ query/সেকেন্ড। h = ০.৯৫ হলে ২ ms আর ৫০০। h = ০.৯৯ হলে ১.২ ms আর ১০০। লক্ষ করুন, ৯৫% থেকে ৯৯%-এ যেতে latency তেমন কমে না, কিন্তু database-এর ভার পাঁচ ভাগের এক ভাগ হয়। তাই hit ratio-র আসল মূল্য প্রায়ই latency-তে নয়, database বাঁচানোয়।

Hit ratio আসে কোথা থেকে? বাস্তবে জনপ্রিয়তা বাঁকা: অল্প কিছু key-তেই বেশিরভাগ অনুরোধ। নিচের simulator-এ ১০,০০০ key, Zipf ধরনের বাঁকা জনপ্রিয়তা, আর LRU cache. Cache বড় করলে hit ratio, গড় latency আর database-এর ভার কীভাবে বদলায় দেখুন। Database-এর সীমা ২,০০০ query/সেকেন্ড ধরা হয়েছে।

// LRU cache in front of a database. 10,000 keys, skewed (Zipf) popularity.
let seed = 7;
function rand() {                  // mulberry32: small seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0;
  let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const KEYS = 10000, REQUESTS = 300000, WARMUP = 50000;
const CACHE_MS = 1, DB_MS = 20, TRAFFIC = 10000, DB_LIMIT = 2000;
const cdf = []; let sum = 0;
for (let k = 1; k <= KEYS; k++) { sum += 1 / k; cdf.push(sum); }
function pick() {                  // binary search on the Zipf CDF
  const x = rand() * sum; let lo = 0, hi = KEYS - 1;
  while (lo < hi) { const m = (lo + hi) >> 1; if (cdf[m] < x) lo = m + 1; else hi = m; }
  return lo;
}
function hitRatio(size) {
  const lru = new Map(); let hits = 0, total = 0;
  for (let i = 0; i < REQUESTS + WARMUP; i++) {
    const k = pick(), hit = lru.delete(k);  // re-inserting puts a key last
    if (!hit && lru.size >= size) lru.delete(lru.keys().next().value); // evict oldest
    lru.set(k, 1);
    if (i >= WARMUP) { total++; if (hit) hits++; }
  }
  return hits / total;
}
console.log("cache size  hit%    avg ms  DB q/s  DB load");
for (const size of [100, 500, 1000, 2000, 5000]) {
  const h = hitRatio(size);
  const ms = CACHE_MS + (1 - h) * DB_MS, db = (1 - h) * TRAFFIC;
  console.log(String(size).padStart(10) + (100 * h).toFixed(1).padStart(6) +
    ms.toFixed(1).padStart(10) + db.toFixed(0).padStart(8) +
    (100 * db / DB_LIMIT).toFixed(0).padStart(8) + "%");
}

চলমান system-এ hit ratio বের করা সহজ, কিন্তু একটি ফাঁদ আছে। Redis-ধরনের engine-এর INFO stats-এর counter শেষ restart থেকে জমতে থাকে। পুরোনো সংখ্যা এত বড় যে নতুন সমস্যা চোখে পড়ে না। তাই দুই সময়ের পার্থক্য নিতে হয়। নিচের block নমুনা লেখা থেকে হিসাব করে; কোনো আসল cache-এ যুক্ত হয় না।

set -euo pipefail
# Sample "INFO stats" text from one cache node, taken five minutes apart.
cat > before.txt <<'SAMPLE'
keyspace_hits:91000000
keyspace_misses:9000000
evicted_keys:120000
SAMPLE
cat > after.txt <<'SAMPLE'
keyspace_hits:91200000
keyspace_misses:9100000
evicted_keys:138000
SAMPLE

get() { awk -F: -v k="$2" '$1 == k { print $2 }' "$1"; }

for f in before.txt after.txt; do
  h=$(get "$f" keyspace_hits); m=$(get "$f" keyspace_misses)
  awk -v f="$f" -v h="$h" -v m="$m" \
    'BEGIN { printf "%-11s since restart: %.2f%%\n", f, 100 * h / (h + m) }'
done

dh=$(( $(get after.txt keyspace_hits) - $(get before.txt keyspace_hits) ))
dm=$(( $(get after.txt keyspace_misses) - $(get before.txt keyspace_misses) ))
de=$(( $(get after.txt evicted_keys) - $(get before.txt evicted_keys) ))
awk -v h="$dh" -v m="$dm" -v e="$de" 'BEGIN {
  printf "last 5 min : hits=%d misses=%d ratio=%.2f%%\n", h, m, 100 * h / (h + m)
  printf "evictions  : %d (%.0f per second)\n", e, e / 300
}'

Eviction — জায়গা ফুরালে কে বের হবে

মেমরি ভরলে কাউকে সরাতে হয়। এটাই eviction. Redis-এ maxmemory-policy নীতি ঠিক করে। Managed service-এ এটি সাধারণত CONFIG SET দিয়ে নয়, parameter group বা সমতুল্য settings দিয়ে বদলাতে হয়। Default-ও এক নয়: open source Redis-এ সাধারণত noeviction, আর কোনো কোনো managed service-এ অন্য কিছু। আগে দেখে নিন।

TTL আর invalidation-এর গভীরতর আলোচনা আছে Eviction আর invalidation পর্বে। evictions বাড়তে থাকা আর hit ratio পড়তে থাকা একসাথে দেখলে বুঝবেন cache ছোট পড়েছে।

৬ · Cache পড়ে গেলে কী হয় — আর Redis-এর লাইসেন্স

Cache বসানোর আগে সে ছিল “গতি বাড়ানোর জিনিস”। কিছুদিন পরে সে হয়ে যায় ভার বহনের দেয়াল। ওপরের হিসাবে database ২,০০০ query নিতে পারে, অথচ ১০,০০০ অনুরোধ আসছে। অর্থাৎ cache ছাড়া database আর টিকতে পারে না। নিচে ৪টি shard-এর একটি cache-এ একটি node মারা গেল। প্রতিটি shard ২৫% key ধরে রাখে, আর এটির কোনো replica নেই।

একসাথে অনেক key-র TTL ফুরালে বা একটি জনপ্রিয় key মুছে গেলেও প্রায় একই দৃশ্য ঘটে। হাজারো অনুরোধ একই জিনিস আনতে database-এ ছোটে। এটি thundering herd-এর একটি রূপ, যাকে cache-এর ক্ষেত্রে cache stampede বলে। সুরক্ষার তালিকা এমন:

• Replica আর একাধিক zone: Cache-কে single point of failure না রাখা। পর্ব ২২-এর failover-এর মতোই এখানে পরীক্ষা জরুরি।
• Database-এর সামনে সীমা: Miss-এর ঝড়ে connection pool আর concurrency সীমিত রাখা, যাতে কিছু অনুরোধ ধীর হয়, সব মারা না যায়।
• এক key, একটি আনা: Request coalescing, অর্থাৎ একই key-র অনেক miss-এর জন্য একটিই database query পাঠানো।
• TTL-এ jitter: সব key একই মুহূর্তে না ফুরানোর জন্য TTL-এ সামান্য এলোমেলো যোগ।
• Cache warming: নতুন node-কে traffic দেওয়ার আগে জনপ্রিয় key ভরে নেওয়া। Maintenance বা বড় deployment-এর আগে এটি বিশেষ কাজের।
• Backoff-সহ retry আর আংশিক সেবা: Resilience pattern মেনে পুরোনো data দেখানো বা ছোট feature বন্ধ রাখা। Capacity পরীক্ষার পদ্ধতি পর্ব ৬৮-এ।

Redis-এর লাইসেন্স বদল আর Valkey

Open source লাইসেন্স বদল এখন cloud কেনাকাটারও অংশ। Redis বহু বছর BSD লাইসেন্সে ছিল। ২০২৪-এর মার্চে Redis Ltd. জানায়, ৭.৪ থেকে নতুন version RSALv2 আর SSPL-এ আসবে। এর উত্তরে Linux Foundation-এর অধীনে শেষ BSD version থেকে Valkey নামে একটি fork শুরু হয়, যাতে AWS আর Google Cloud-সহ কয়েকটি প্রতিষ্ঠান যুক্ত। ২০২৫-এর Redis 8-এ AGPLv3-ও একটি বিকল্প হিসেবে যোগ হয়েছে বলে ঘোষণা করা হয়। লেখার সময়ে AWS আর Google-এর managed cache-এ Valkey বেছে নেওয়া যায়, আর Azure-এর পথ আলাদা। এই চিত্র বদলাতে পারে। Client কোড প্রায়ই একই থাকে, কিন্তু engine-এর version, বিল আর নতুন সুবিধায় পার্থক্য আসতে পারে। লাইসেন্স-সংক্রান্ত সিদ্ধান্তে আইনি পরামর্শ নিন।

৭ · Search আর time-series — দুটি বিশেষ আকৃতি

Search service

“লাল সুতি শাড়ি” খুঁজলে LIKE '%লাল%' পুরো table পড়ে, ভুল বানান ধরতে পারে না, আর ফলের ক্রমও ঠিক করে না। Search service একটি inverted index বানায়, যা বইয়ের শেষের নির্ঘণ্টের মতো: শব্দ থেকে document-এর তালিকা। তত্ত্ব আছে Search পর্বে। OpenSearch Service, Azure AI Search আর Elastic-এর managed সেবা এই ধরনের উদাহরণ। OpenSearch এসেছে ২০২১-এ Elasticsearch-এর লাইসেন্স বদলের পর একটি fork হিসেবে; Elastic ২০২৪-এ AGPLv3 বিকল্প যোগ করার ঘোষণা দেয়।

পরিচালনার দিক থেকে তিনটি কথা মনে রাখুন। এক, search index সাধারণত মূল data নয়, মূল database থেকে তৈরি একটি কপি। তাই সে কিছুটা পিছিয়ে থাকে, আর নষ্ট হলে আবার বানানো যায়। দুই, shard-এর সংখ্যা আর আকার পরে বদলানো কঠিন হতে পারে, আর shard খুব বেশি হলে cluster ভারী হয়। তিন, মেমরি আর disk-এই আসল খরচ, তাই পুরোনো log রাখার জন্য স্তরভিত্তিক storage আর মেয়াদের নিয়ম লাগে। Log-এর দিকটি পর্ব ৬৪-এ আসবে।

Time-series service

Server-এর CPU, সেন্সরের তাপমাত্রা, শেয়ারের দাম: প্রতিটি লেখায় একটি সময় থাকে, data প্রায় শুধু যোগ হয়, আর প্রশ্ন আসে “গত ১ ঘণ্টায় গড় কত”। Time-series database সময় ধরে data ভাগ করে, পাশাপাশি মান খুব ঘন করে চেপে রাখে, আর পুরোনো data-কে downsampling করে। Amazon Timestream, Azure Data Explorer, InfluxDB আর TimescaleDB এর উদাহরণ; ধরনগুলো হুবহু এক নয়। DBMS কোর্সে এর গঠন আছে, আর Prometheus পর্ব ৬৩-এ।

ছোট হিসাব: ১,০০০টি সেন্সর, প্রতিটি ১০ সেকেন্ডে একটি মান। অর্থাৎ ১০০ মান/সেকেন্ড, ৩০ দিনে ২৫.৯২ কোটি মান। চাপার পর প্রতিটি ১৬ byte ধরলে ৪.১৫ GB. ৫ মিনিটের গড়ে নামালে মানের সংখ্যা ৩০ ভাগের এক ভাগ, প্রায় ০.১৪ GB. তাই সাধারণ নিয়ম হলো: নতুন data সূক্ষ্ম, পুরোনো data মোটা দাগে। Cardinality, অর্থাৎ আলাদা sensor বা label-এর সংখ্যা, হঠাৎ বেড়ে গেলে কিন্তু খরচও লাফিয়ে বাড়ে।

৮ · Data warehouse আর data lake — পড়া byte-এর দাম

দোকানের ক্যাশ কাউন্টারে প্রতিটি বিক্রি একটি ছোট, দ্রুত কাজ: এটি OLTP. বছর শেষে হিসাবরক্ষক গুদামে বসে লাখো রসিদ যোগ করেন: এটি OLAP. দুটি কাজ এক ডেস্কে হলে কাউন্টারের লাইন আটকে যায়। Data warehouse হলো সেই আলাদা গুদাম। Star schema আর ETL-এর তত্ত্ব আছে DBMS কোর্সের Data warehouse পর্বে।

Columnar storage-এর ফল সরাসরি বিলে আসে। BigQuery-র on-demand ধরনে, Athena-তে আর Synapse serverless-এ বিল হয় মূলত কত byte পড়া হলো তাতে। একে বলব pay-per-scan. অন্যদিকে Redshift-এর node, Synapse-এর dedicated pool, Fabric-এর capacity বা BigQuery-র slot reservation-এ বিল হয় বরাদ্দ করা ক্ষমতায়। ধরে নিই ১ TB পড়তে $৫; আসল দাম আলাদা এবং বদলায়। Table: ১,২০০ GB, ২৪ মাসের partition, সাতটি column.

SELECT *
FROM shop.orders;

SELECT *
FROM shop.orders
LIMIT 10;

SELECT region, SUM(total)
FROM shop.orders
WHERE order_date >= '2026-09-01'
  AND order_date < '2026-10-01'
GROUP BY region;
-- table এখনো partition করা নয়

SELECT region, SUM(total)
FROM shop.orders
WHERE order_date >= '2026-09-01'
  AND order_date < '2026-10-01'
GROUP BY region;

SELECT SUM(total)
FROM shop.orders
WHERE order_date >= '2026-09-01'
  AND order_date < '2026-10-01'
  AND region = 'Rajshahi';

SELECT region, SUM(total)
FROM shop.orders
WHERE FORMAT_DATE('%Y-%m', order_date) = '2026-09'
GROUP BY region;

একই হিসাব এবার কোডে। Column-এর আকার ইচ্ছামতো বদলে দেখুন। মাসে ৬,০০০ query আর একটি অনুমিত স্থির capacity fee-র সাথে তুলনাও আছে।

// Columnar table: 24 monthly partitions, 1200 GB in total. Assumed $5 per TB.
const COLUMNS = { order_id: 60, order_date: 30, customer_id: 60, region: 30,
                  total: 120, items_json: 600, address: 300 };   // GB per column
const MONTHS = 24, PRICE_PER_TB = 5, QUERIES_PER_MONTH = 6000, FLAT_FEE = 2000;

function scanned(q) {
  const cols = q.cols === "*" ? Object.keys(COLUMNS) : q.cols;
  // Column pruning: read only named columns. Partition pruning: only these months.
  const gb = cols.reduce((a, c) => a + COLUMNS[c], 0);
  return gb * (q.months / MONTHS) * (q.blockShare ?? 1);
}
const three = ["order_date", "region", "total"];
const queries = [
  { name: "SELECT * (everything)",       cols: "*",   months: 24 },
  { name: "3 columns, all months",       cols: three, months: 24 },
  { name: "3 columns, 1 month",          cols: three, months: 1 },
  { name: "3 cols, 1 month, 1/5 blocks", cols: three, months: 1, blockShare: 0.2 },
];
console.log("query                         GB scanned   $/query   $/month");
for (const q of queries) {
  const gb = scanned(q), cost = gb / 1000 * PRICE_PER_TB;
  console.log(q.name.padEnd(28) + gb.toFixed(1).padStart(11) +
    cost.toFixed(4).padStart(10) + (cost * QUERIES_PER_MONTH).toFixed(0).padStart(10));
}
const perQuery = scanned(queries[1]) / 1000 * PRICE_PER_TB;
console.log("flat fee $" + FLAT_FEE + " beats 3-column full scans above " +
  Math.ceil(FLAT_FEE / perQuery) + " queries/month");

টাকা খরচের আগেই পড়া byte জানার উপায় আছে। নিচে BigQuery-র উদাহরণ, চালানোর জন্য নয়; আউটপুটটি নমুনা, version-ভেদে আলাদা হতে পারে। Dry run-এ query চলে না, তাই সাধারণত বিলও হয় না। প্রতি query-তে পড়ার সর্বোচ্চ সীমা (maximum bytes billed) আর project-এর quota বসিয়ে রাখা আরও নিরাপদ।

bq query --use_legacy_sql=false --dry_run \
  "SELECT region, SUM(total) FROM shop.orders
   WHERE order_date >= '2026-09-01' AND order_date < '2026-10-01'
   GROUP BY region"

# নমুনা আউটপুট
# Query successfully validated. Assuming the tables are not modified,
# running this query will process 7500000000 bytes of data.

Data lake — ধারণাটুকু

Data lake হলো সস্তা object storage-এ সব কাঁচা data ফেলে রাখা: log, JSON, ছবি, database-এর export. প্রশ্ন আগে ঠিক না হলেও চলে; গঠন ঠিক হয় পড়ার সময়। Object storage পর্ব ২০ আর ২১-এ বিস্তারিত আছে। সাধারণত Parquet-এর মতো columnar file-এ রাখলে Athena বা BigQuery-র external table সরাসরি query করতে পারে। ওপরের column আর partition-এর হিসাব এখানেও খাটে: folder-এর ভাগ যেন filter-এর সাথে মেলে।

নিয়ম না থাকলে lake হয়ে যায় “data swamp”, যেখানে কেউ জানে না কোন file ঠিক। Iceberg, Delta Lake আর Hudi-র মতো table format object storage-এর ওপর transaction আর schema-র ব্যবস্থা যোগ করে। Warehouse আর lake-এর এই মিলনকে অনেকে lakehouse বলেন, যদিও সীমারেখা নিয়ে মতভেদ আছে। Data ঢোকানোর batch আর stream পথ দেখতে পারেন Batch আর stream পর্বে।

৯ · কোনটি বাছবেন — আর বহু store-এর আসল দাম

ছবি ২৩.১ শুরুর পথ দেখায়। তারপর চারটি প্রশ্নে সিদ্ধান্ত পাকা করুন।

একই app-এ একাধিক store ব্যবহারের নাম polyglot persistence. শব্দটি ২০১১-র দিকে Martin Fowler-এর লেখায় ছড়িয়ে পড়ে। আমাদের কাল্পনিক অ্যাপ বড় হলে এমন হতে পারে: অর্ডার ও টাকা relational-এ, session আর cart key-value-তে, home page-এর তালিকা cache-এ, পণ্য খোঁজা search-এ, ব্যবসার প্রশ্ন warehouse-এ। প্রতিটি যুক্তিসঙ্গত। কিন্তু প্রতিটি নতুন store-এর সাথে আসে নিচের কাজের তালিকা, যাকে আমরা বলি operational burden:

• Backup আর restore-এর মহড়া (পর্ব ২৪)
• IAM, secret আর network নিয়ম (পর্ব ২৭, ৩১, ৩৩)
• আলাদা metric, alert, runbook আর on-call জ্ঞান (পর্ব ৬৩, ৬৬)
• Version আপগ্রেড আর API বদল সামলানো
• একটি আলাদা বিলের দাগ, যা কেউ না কেউ বুঝবেন (পর্ব ৭২, ৭৩)
• অন্য store-এর সাথে data মেলানোর পথ

শেষ কাজটিই সবচেয়ে কঠিন। App যদি database-এ লিখে তারপর search-এ লেখে, আর মাঝে crash করে, তবে দুটি store আলাদা কথা বলবে। এই ভুলকে বলে dual write সমস্যা। ভালো পথ হলো একটি store-কে সত্যের উৎস ধরা, আর তার পরিবর্তন change data capture বা queue (পর্ব ৭০) দিয়ে অন্যদের কাছে পাঠানো। ৫টি store-এ জোড়ার সম্ভাব্য সংখ্যা ৫ × ৪ ÷ ২ = ১০; সব জোড়া লাগে না, তবু জটিলতা store-এর সংখ্যার চেয়ে দ্রুত বাড়ে। তাই সব পথ একটি উৎস থেকে বের হওয়া ভালো।

১০ · AI-এর যুগে managed data service

AI আপনাকে দ্রুত table definition বা cache client লিখে দেবে। কিন্তু সে আপনার traffic-এর বণ্টন জানে না, আর বিল সে দেয় না। এই পর্বের ভুলগুলো প্রায়ই প্রথম দিনে নয়, ভিড়ের দিনে ধরা পড়ে।

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

• প্রতিটি access pattern-এর জন্য key বা index আছে; কোথাও চুপচাপ Scan নেই
• Peak traffic-এ সবচেয়ে ব্যস্ত partition-এর হিসাব নিজে করেছি
• Service limit, দাম আর flag provider-এর আজকের docs-এ মিলিয়েছি
• Cache ছাড়া database কত ভার পাবে জানি, আর সেই পরীক্ষা নিরাপদ পরিবেশে করেছি
• Warehouse query আগে dry run করেছি, আর byte-এর সীমা বসিয়েছি
• Network খোলা নয়, permission সীমিত, secret কোডে নেই, আর budget alert চালু
• Prompt-এ কোনো key, token বা গ্রাহকের data দিইনি