Object storage আর distributed file system — chunk, metadata, replication আর erasure coding

১ · Block, file আর object — তিন রকম storage, তিন রকম প্রতিশ্রুতি

ধরুন একটি ছবি-শেয়ারের অ্যাপ (কাল্পনিক) প্রতিদিন লাখো ছবি পায়। App server-এর disk-এ রাখা সহজ, কিন্তু দ্বিতীয় server যোগ হলেই এক server-এর ছবি অন্যটি দেখে না (পর্ব ১৩); disk ভরলে বা যন্ত্র নষ্ট হলে আরও বিপদ। আসল প্রশ্ন: কোন ধরনের storage, কোন interface দিয়ে?

ছবি, ভিডিও, backup আর log কেন object storage-এ? (১) একবার লেখা, বহুবার পড়া, প্রায় কখনো বদলানো নয়। (২) আকার বড়, সংখ্যা বিপুল — সমতল নাম আর ছড়ানো chunk দিয়ে সহজে বাড়ে। (৩) HTTP-তে সরাসরি পড়া যায়, তাই এটি CDN-এর স্বাভাবিক origin (পর্ব ১৭)। (৪) প্রতি GB খরচ কম, ঠান্ডা স্তরে আরও কম। (৫) App server stateless থাকে। কী রাখবেন না: ঘনঘন অল্প অংশ বদলানো ডেটা (database-এর page), ছোট ছোট transaction, lock লাগে এমন ভাগ করা ফাইল — সেগুলো block storage-এর ওপর database-এ (পর্ব ১৯, পর্ব ২০)।

২ · Object-এর মডেল — bucket, key, metadata, version আর lifecycle

Bucket হলো object-এর পাত্র; অনুমতি, region, versioning আর lifecycle-এর নিয়ম সাধারণত bucket-এ বসে। অনেক সেবায় bucket-এর নাম পুরো সেবায় অনন্য হতে হয়। Bucket-এর ভেতরে প্রতিটি object-এর পুরো নাম তার key, যেমন photos/u91/2026/a7f3.jpg.

এখানে একটি বড় সত্য: / চিহ্নের কোনো বিশেষ অর্থ নেই। Namespace সমতল (flat) — শুধু key থেকে object-এর একটি বিশাল সাজানো তালিকা। Console-এ যে “folder” দেখেন, তা key-এর শুরুর অংশ (prefix) ধরে সাজানো একটি দৃশ্য। LIST-এ prefix আর delimiter দিলে store “common prefix” ফেরত দেয়, তাই folder-এর মতো দেখায়:

GET /?list-type=2&prefix=photos/u91/&delimiter=/&max-keys=1000 HTTP/1.1
Host: my-bucket.store.example.com

HTTP/1.1 200 OK
<ListBucketResult>
  <Contents><Key>photos/u91/profile.jpg</Key><Size>48211</Size></Contents>
  <CommonPrefixes><Prefix>photos/u91/2025/</Prefix></CommonPrefixes>
  <CommonPrefixes><Prefix>photos/u91/2026/</Prefix></CommonPrefixes>
  <IsTruncated>false</IsTruncated>
</ListBucketResult>

ফল তিনটি। “Folder” rename মানে প্রতিটি object কপি করে পুরোনোটি মোছা — লাখো অনুরোধ, আর মাঝপথে থামলে অর্ধেক পুরোনো নামে। খালি folder বলে কিছু নেই; console শূন্য-byte-এর object দিয়ে নকল করে। আর LIST ধীর — অঙ্ক অনুশীলন ৩-এ।

Object = বাইট + metadata, আর বাইট বদলায় না

প্রতিটি object-এর সাথে থাকে metadata: system-এর (আকার, Content-Type, শেষ বদলের সময়, ETag, storage class) আর আপনার নিজের ছোট key-value (সাধারণত কয়েক KB-র সীমা)। বাইটগুলো অপরিবর্তনীয় (immutable): PUT পুরো object একবারে বদলে দেয় — পাঠক পুরোনোটি বা নতুনটি দেখেন, অর্ধেক-লেখা কখনো নয়। সাধারণ object-এ মাঝখানে লেখা বা শেষে জোড়া (append) নেই; কিছু নতুন storage class-এ সীমিত append যোগ হয়েছে (লেখার সময়ে)।

নকশার কৌশল: key-এ একটি অনন্য id বা বিষয়বস্তুর hash রাখুন (thumb/a7f3-400w.webp), তাহলে একই key-এ কখনো দ্বিতীয়বার লেখা হয় না। Key কখনো না বদলালে CDN সেটি নিশ্চিন্তে দীর্ঘদিন রাখে — পর্ব ১৭-এর asset fingerprinting-এর একই চিন্তা।

Versioning আর lifecycle

Versioning চালু থাকলে প্রতিটি PUT একটি নতুন version id বানায়, পুরোনো version থেকে যায়। Version না বলে DELETE করলে object মোছে না, ওপরে একটি delete marker বসে — ভুল মোছা ফেরানো যায়; নির্দিষ্ট version মুছলে তবেই চিরতরে যায়। দাম: প্রতিটি পুরোনো version জায়গা নেয়। তাই lifecycle rule দিয়ে পুরোনো version কয়েক সপ্তাহ পরে মোছা হয়, আর পুরোনো ডেটা সস্তা storage class-এ সরানো হয়:

{ "Rules": [ {
    "ID": "photos-age-out",
    "Filter": { "Prefix": "orig/" },
    "Transitions": [ { "Days": 30,  "StorageClass": "COOL" },
                     { "Days": 365, "StorageClass": "ARCHIVE" } ],
    "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
    "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
} ] }

স্তরের নাম, দাম, ন্যূনতম মেয়াদ আর ফেরত আনার সময় vendor আর সময়ভেদে বদলায় — হিসাবের আগে নথি দেখুন। নকশার প্রশ্নটি স্থির: এই ডেটা কত ঘনঘন পড়া হবে, আর দেরিতে পেলে ক্ষতি কত? কতদিন রাখবেন আর কখন মুছবেন, সেটি retention policy-র প্রশ্ন।

৩ · S3-ধাঁচের API — PUT, GET, LIST, multipart upload আর presigned URL

২০০৬ সালে Amazon S3 চালুর পর তার API কার্যত মানদণ্ড হয়ে গেছে; MinIO, Ceph-এর মতো open-source store-ও একই ধাঁচের API দেয়। মূল কাজ অল্প কয়েকটি:

Multipart upload — বড় ফাইল টুকরো করে

একটি ৩ GiB ভিডিও এক অনুরোধে পাঠালে মাঝপথে network কাটলে আবার শূন্য থেকে, আর একটি TCP সংযোগ পুরো link ভরাতে পারে না। Multipart upload-এ তিন ধাপ: Create (একটি uploadId), UploadPart (part নম্বর ধরে আলাদা অনুরোধে, সমান্তরালে; প্রতিটি দেয় একটি ETag) আর Complete (part নম্বর আর ETag-এর তালিকা) — তখনই object একবারে দৃশ্যমান। লেখার সময়ে S3-এর নথিতে: শেষটি ছাড়া প্রতিটি part অন্তত ৫ MiB, সর্বোচ্চ ৫ GiB, আর সর্বোচ্চ ১০,০০০টি part; অন্য store-এ আলাদা হতে পারে। ফাঁদ: অসমাপ্ত upload-এর part চোখে পড়ে না, কিন্তু জায়গা নেয় — তাই Abort, আর lifecycle দিয়ে কয়েক দিন পরে নিজে থেকে মোছা।

Presigned URL — চাবি না দিয়ে একটি কাজের অনুমতি

ফাইল app server দিয়ে পাঠালে তার bandwidth, memory আর সময় খরচ হয়। বিকল্প presigned URL: server নিজের গোপন চাবি দিয়ে একটি URL সই করে (HMAC-ভিত্তিক), যার ভেতরে method, bucket, key আর মেয়াদ। যার হাতে URL, তিনি চাবি না জেনেই ঠিক সেই কাজটি করতে পারেন; একটি অক্ষর বদলালে সই আর মেলে না।

এবার দুটি মিলিয়ে একটি ২০০ MiB ভিডিও আপলোড, part ৬৪ MiB — তাই ৪টি part: ৬৪ + ৬৪ + ৬৪ + ৮ MiB.

Part কত বড় হবে, কয়টি একসাথে? নিচের planner-এ একটি ৩ GiB ভিডিও, ৪০ Mbit/s-এর uplink (ধরা যাক), আর একটি TCP সংযোগ একা যে গতি পায় তার সীমা:

// Multipart upload planner. ASSUMED inputs: change them and run again.
const MiB = 1024 * 1024, GiB = 1024 * MiB;
const FILE = 3 * GiB;               // a 3 GiB video from a phone
const LINK_MBIT = 40;               // uplink capacity, Mbit/s
const STREAM_MBIT = 12;             // one TCP connection alone reaches ~12 Mbit/s (RTT, window)
const PER_PART_S = 0.3;             // per-part overhead: request, signing, response (seconds)
const MAX_PARTS = 10000;            // S3-style limit at the time of writing; check your vendor
const MIN_PART = 5 * MiB;           // every part except the last must be at least this big

const fmt = (s) => (s >= 60 ? (s / 60).toFixed(1) + " min" : s.toFixed(1) + " s");
console.log(`file ${FILE / GiB} GiB, link ${LINK_MBIT} Mbit/s, one stream ${STREAM_MBIT} Mbit/s`);
console.log("part    parts  max file   streams  total time  resend if 1 part fails");
for (const partMiB of [5, 16, 64, 256]) {
  const part = partMiB * MiB, parts = Math.ceil(FILE / part);
  if (part < MIN_PART || parts > MAX_PARTS) { console.log(partMiB + " MiB: not allowed"); continue; }
  const maxFile = (MAX_PARTS * part / GiB).toFixed(0) + " GiB";
  for (const streams of [1, 4, 8]) {
    const mbit = Math.min(LINK_MBIT, streams * STREAM_MBIT);       // parallel streams share the link
    const total = FILE * 8 / (mbit * 1e6) + Math.ceil(parts / streams) * PER_PART_S;
    const resend = part * 8 / (STREAM_MBIT * 1e6);                 // the failed part goes again
    console.log((partMiB + " MiB").padEnd(8) + String(parts).padEnd(7) + maxFile.padEnd(11) +
      String(streams).padEnd(9) + fmt(total).padEnd(12) + fmt(resend));
  }
}

file 3 GiB, link 40 Mbit/s, one stream 12 Mbit/s
part    parts  max file   streams  total time  resend if 1 part fails
5 MiB   615    49 GiB     1        38.9 min    3.5 s
5 MiB   615    49 GiB     4        11.5 min    3.5 s
5 MiB   615    49 GiB     8        11.1 min    3.5 s
16 MiB  192    156 GiB    1        36.8 min    11.2 s
16 MiB  192    156 GiB    4        11.0 min    11.2 s
16 MiB  192    156 GiB    8        10.9 min    11.2 s
64 MiB  48     625 GiB    1        36.0 min    44.7 s
64 MiB  48     625 GiB    4        10.8 min    44.7 s
64 MiB  48     625 GiB    8        10.8 min    44.7 s
256 MiB 12     2500 GiB   1        35.9 min    3.0 min
256 MiB 12     2500 GiB   4        10.8 min    3.0 min
256 MiB 12     2500 GiB   8        10.7 min    3.0 min

৪ · Consistency, ETag আর conditional request

PUT সফল হওয়ার পরমুহূর্তে অন্য কেউ GET করলে নতুনটি পাবেন তো? এই প্রতিশ্রুতির নাম read-after-write consistency. S3-এর ইতিহাস শিক্ষণীয়। চালু থেকে বহু বছর নতুন key-এর PUT-এর পরে পড়া সাধারণত নতুনটিই দিত, কিন্তু একই key-এ overwrite, DELETE আর LIST ছিল eventually consistent — কিছুক্ষণ পুরোনো উত্তর আসতে পারত। AWS-এর ঘোষণা অনুযায়ী ডিসেম্বর ২০২০ থেকে S3-এ সব PUT, DELETE আর LIST-এর পরে strong read-after-write consistency, বাড়তি খরচ ছাড়া। অন্য S3-সমর্থক store বা অন্য cloud-এর আচরণ আলাদা হতে পারে, আর region-এর মধ্যে কপি (cross-region replication) প্রায় সবখানেই asynchronous — নথি দেখে নিশ্চিত হোন।

ETag — সংস্করণের ছাপ, সবসময় MD5 নয়

প্রতিটি object-এর ETag তার বিষয়বস্তুর একটি ছাপ; বিষয়বস্তু বদলালে ETag বদলায়। এক অনুরোধে লেখা object-এ এটি প্রায়ই বিষয়বস্তুর MD5 — কিন্তু multipart-এ নয় (সাধারণত "…-4", অর্থাৎ ৪টি part), কিছু encryption-এও নয়। তাই অখণ্ডতা প্রমাণে upload-এর সময় আলাদা checksum পাঠান (নতুন API-গুলোতে CRC32C বা SHA-256-এর মতো বিকল্প আছে, লেখার সময়ে)।

Conditional request — শর্ত দিয়ে পড়া আর লেখা

Conditional request পর্ব ৮-এ দেখেছেন (ETag, If-Match আর 304). Object storage-এ চার ব্যবহার। GET + If-None-Match: না বদলালে 304, CDN-এর যাচাই এভাবেই। GET + If-Match: কয়েকটি Range-এ নামানোর মাঝে কেউ বদলালে 412, অর্ধেক পুরোনো-অর্ধেক নতুন জোড়া লাগে না। PUT + If-None-Match: *: key না থাকলে তবেই লেখা — দুই worker একই ফল লিখতে গেলে একজনই সফল। PUT + If-Match: compare-and-swap, অর্থাৎ optimistic concurrency. AWS ২০২৪ সালে S3-এ এমন conditional write যোগ করার ঘোষণা দেয়; অন্য store-এ সমর্থন যাচাই করুন।

PUT /sync/u91/manifest.json HTTP/1.1
If-Match: "9f2c41"                 # যে version পড়ে বদল করেছি

HTTP/1.1 412 Precondition Failed   # এর মধ্যে অন্য device নতুন version লিখেছে
                                   # → নতুন করে পড়া, মেলানো, আবার চেষ্টা

৫ · একটি distributed object store-এর ভেতরে — metadata, chunk আর placement

ডাকঘরের কাউন্টারে একটি রেজিস্টার খাতা — কোন পার্সেল কোন গুদামের কোন তাকে; পেছনে বিশাল গুদাম। খাতা ছোট কিন্তু প্রতিটি কাজে লাগে; গুদাম বিশাল কিন্তু শুধু মাল বয়। বড় storage সিস্টেমও এভাবে দুই ভাগে গড়া:

• API front-end: stateless সামনের স্তর — সই যাচাই, rate limit, ফাইলকে chunk-এ ভাগ। Load balancer-এর পেছনে অনেকগুলো।
• Metadata service: key থেকে {version, আকার, ETag, chunk-তালিকা ও তাদের স্থান}. প্রতিটি GET আর PUT এখানে আসে, তাই একে দ্রুত, একটি key-এর জন্য strongly consistent আর LIST-এর জন্য key-সাজানো হতে হয় — সাধারণত নিজেই একটি sharded, replicated key-value store: key-এর range ধরে ভাগ (পর্ব ২৩), প্রতিটি ভাগ consensus দিয়ে কপি করা (পর্ব ৪২)। আকারের হিসাব: ধরা যাক ১,০০০ কোটি object × প্রায় ১ KB metadata = ১০ TB — এক যন্ত্রে নয়।
• Data node: disk-ভরা অসংখ্য server; chunk থাকে local file system-এ সাধারণ ফাইল হিসেবে। নিয়মিত heartbeat-এ জানায় “আমি আছি, এত জায়গা খালি”।

Chunk কত বড়? নকশাভেদে কয়েক MB থেকে ৬৪ MB বা বেশি। বড় chunk মানে কম metadata আর টানা দ্রুত পড়া; ছোট chunk মানে বেশি সমান্তরাল পড়া। লাখো ছোট ছবির প্রতিটি আলাদা ফাইল হলে disk-এর file system-এ চাপ পড়ে, তাই অনেক নকশা ছোট object বড় একটি ফাইলে পরপর জোড়ে — Facebook-এর ছবি-store Haystack-এর ২০১০ সালের গবেষণাপত্রে এই চিন্তা আছে।

কোন chunk কোথায় (placement)? Metadata-তে প্রতিটি chunk-এর স্থান লিখে রাখা — নমনীয়, কিন্তু map বড়; অথবা chunk id-এর hash থেকে হিসাব করা — consistent hashing-এর মতো (পর্ব ১৬), lookup-table লাগে না। যে পথেই হোক, placement-কে failure domain মানতে হয়: একই chunk-এর কপি আলাদা যন্ত্রে, আলাদা rack-এ, আর region-স্তরের নিরাপত্তায় আলাদা availability zone-এ।

লেখার পথ, আর তার ক্রম: front-end chunk-গুলোর সব কপি (বা fragment) সমান্তরালে লেখে, checksum মিলিয়ে নিশ্চিতি পায় — তারপর metadata-য় key-কে নতুন version-এর দিকে ফেরায়, তারপরই client পায় 200. এই শেষ metadata-লেখাই commit point: আগে কেউ নতুন version দেখে না, পরে সবাই দেখে — এজন্যই PUT “সব বা কিছুই না”। ব্যর্থ upload-এর chunk কোনো key-এর নাগালে থাকে না; পরে একটি পরিষ্কারের কাজ সেগুলো মোছে। এবার ছবি ২৬.১ ধরে একটি GET অনুসরণ করি — chunk ৮ MiB, ছবি ২০ MiB, তাই c1 (০–৮), c2 (৮–১৬), c3 (১৬–২০ MiB):

৬ · Replication বনাম erasure coding — জায়গা, সহনশীলতা আর মেরামতের দাম

প্রতিটি chunk-কে বাঁচানোর দুই পথ। Replication: r টি পূর্ণ কপি — r গুণ জায়গা, r − ১টি হারানো সয়, যেকোনো একটি কপি থেকে সরাসরি পড়া। Erasure coding (k, m): ডেটাকে k টুকরো (fragment) করে আরও m টি parity fragment হিসাব করা, মোট n = k + m টি আলাদা disk-এ; যেকোনো k টি থাকলেই পুরো ডেটা ফেরে। Storage overhead = (k + m) ÷ k, সহনশীলতা m.

XOR parity-র খেলনা-রূপ নিচে: ৪টি data chunk, একটি parity. সাথে প্রতিটি chunk-এর checksum — কেন লাগে, দেখবেন:

// Toy erasure code: k = 4 data chunks + ONE XOR parity chunk (like RAID 5),
// plus a per-chunk FNV-1a checksum so a scrubber can tell WHICH chunk went bad.
const fnv = (a) => { let h = 0x811c9dc5;
  for (const b of a) { h ^= b; h = Math.imul(h, 0x01000193) >>> 0; }
  return h.toString(16).padStart(8, "0"); };
const hex = (a) => Array.from(a, (b) => b.toString(16).padStart(2, "0")).join(" ");
const str = (a) => String.fromCharCode(...a);
const xorAll = (list) => list.reduce((acc, c) => acc.map((v, i) => v ^ c[i]));

const file = Array.from("PHOTO_DHAKA_2026", (c) => c.charCodeAt(0));   // 16 bytes
const K = 4, S = file.length / K;
const D = [];
for (let i = 0; i < K; i++) D.push(file.slice(i * S, (i + 1) * S));
const P = xorAll(D);                                   // parity = D0 ^ D1 ^ D2 ^ D3
const saved = [...D, P].map(fnv);                      // checksums stored at write time
D.forEach((d, i) => console.log(`D${i} "${str(d)}"  ${hex(d)}  sum ${saved[i]}`));
console.log(`P  (parity) ${hex(P)}  sum ${saved[K]}`);

D[2][1] ^= 0x04;                                       // bit rot: one bit flips on disk
console.log(`\nafter bit rot D2 = "${str(D[2])}"`);
const bad = [...D, P].map((c, i) => (fnv(c) === saved[i] ? -1 : i)).filter((i) => i >= 0);
console.log("scrubber: checksum mismatch in chunk", bad.map((i) => (i < K ? "D" + i : "P")).join(","));

const others = D.filter((_, i) => i !== bad[0]);
const fixed = xorAll([...others, P]);                  // D2 = D0 ^ D1 ^ D3 ^ P
console.log(`rebuilt D2 = "${str(fixed)}"  sum ${fnv(fixed)}  ok=${fnv(fixed) === saved[2]}`);
D[2] = fixed;
console.log(`file = "${D.map(str).join("")}"`);

// Two chunks lost (D1 and D3): XOR of the survivors only gives D1 ^ D3.
const mix = xorAll([D[0], D[2], P]);
console.log(`\nlose D1+D3: survivors give ${hex(mix)} = D1^D3 -> cannot split, need m >= 2`);

D0 "PHOT"  50 48 4f 54  sum 6f2f695e
D1 "O_DH"  4f 5f 44 48  sum 4b961b27
D2 "AKA_"  41 4b 41 5f  sum 9dc82e29
D3 "2026"  32 30 32 36  sum 40293d93
P  (parity) 6c 6c 78 75  sum 1d31bf56

after bit rot D2 = "AOA_"
scrubber: checksum mismatch in chunk D2
rebuilt D2 = "AKA_"  sum 9dc82e29  ok=true
file = "PHOTO_DHAKA_2026"

lose D1+D3: survivors give 7d 6f 76 7e = D1^D3 -> cannot split, need m >= 2

এবার বড় ছবি: জায়গা, সহনশীলতা, মেরামতে কত পড়া, আর একটি সরল durability অনুমান। মডেলটি পর্ব ৫-এর replication-মডেলের সাধারণ রূপ: n টি fragment-এর m + ১টি মেরামতের আগেই মরলে ডেটা হারায়; হার ≈ n!/(n − m − ১)! · λ^m+1 · R^m, যেখানে λ প্রতি disk-ঘণ্টায় নষ্টের হার আর R মেরামতের ঘণ্টা। r কপির জন্য k = ১, m = r − ১ বসালে পর্ব ৫-এর সূত্রই ফেরে।

// Replication vs erasure coding. ASSUMED inputs: a TEACHING MODEL, not a real system.
const AFR = 0.02;                          // assumed: a disk fails 2% per year, independently
const lambda = -Math.log(1 - AFR) / 8760;  // failures per disk-hour
const NODE_TB = 10;                        // assumed: data on the one node that died
const fact = (n) => (n <= 1 ? 1 : n * fact(n - 1));

// A stripe = k data + m parity fragments on n = k + m different disks. It is lost
// only if m + 1 fragments die before repair finishes (R hours). Markov estimate:
// rate = n!/(n-m-1)! * lambda^(m+1) * R^m   (r full copies: k = 1, m = r - 1)
function nines(k, m, R) {
  const n = k + m;
  const rate = fact(n) / fact(n - m - 1) * Math.pow(lambda, m + 1) * Math.pow(R, m);
  const p = -Math.expm1(-rate * 8760);     // P(this stripe is lost within a year)
  return { p, nines: -Math.log10(p) };
}
const pad = (s, w) => String(s).padEnd(w);
console.log(pad("scheme", 10) + pad("disks", 7) + pad("space", 7) + pad("lose ok", 9) +
  pad("repair read", 13) + pad("P(loss)/yr R=24h", 18) + "nines 24h / 72h");
for (const [name, k, m] of [["2 copies", 1, 1], ["3 copies", 1, 2], ["RS(4,2)", 4, 2],
                            ["RS(6,3)", 6, 3], ["RS(10,4)", 10, 4]]) {
  const a = nines(k, m, 24), b = nines(k, m, 72);
  console.log(pad(name, 10) + pad(k + m, 7) + pad(((k + m) / k).toFixed(2) + "x", 7) +
    pad(m, 9) + pad(k * NODE_TB + " TB", 13) + pad(a.p.toExponential(2), 18) +
    a.nines.toFixed(1) + " / " + b.nines.toFixed(1));
}

scheme    disks  space  lose ok  repair read  P(loss)/yr R=24h  nines 24h / 72h
2 copies  2      2.00x  1        10 TB        2.24e-6           5.7 / 5.2
3 copies  3      3.00x  2        10 TB        3.71e-10          9.4 / 8.5
RS(4,2)   6      1.50x  2        40 TB        7.43e-9           8.1 / 7.2
RS(6,3)   9      1.50x  3        60 TB        1.04e-11          11.0 / 9.6
RS(10,4)  14     1.40x  4        100 TB       4.56e-14          13.3 / 11.4

কখন কোনটি? ছোট, গরম, ঘনঘন পড়া object-এ replication — latency কম, decode নেই। বড় আর উষ্ণ-ঠান্ডা ডেটায় EC — PB মাপে সাশ্রয় বিশাল। অনেক নকশা আগে কপি করে লেখে, পরে পেছনে EC-তে রূপান্তর করে; HDFS-এ Hadoop ৩ থেকে EC, প্রচলিত policy RS-6-3. এবার RS(6,3)-এর একটি stripe — ৯টি fragment, প্রতি zone-এ ৩টি — একটি node হারালে কী হয়:

৭ · Bit rot, scrubbing, মেরামত আর “এগারো nine”

Bit rot বা নিঃশব্দ ডেটা-বিকৃতি: disk, controller, memory বা firmware-এর ত্রুটিতে বিট বদলায়, অথচ পড়া “সফল” হয়। লাখো disk-এর ওপর ২০০৮ সালের একটি বড় মাঠ-গবেষণায় (FAST সম্মেলন) কয়েক লাখ নিঃশব্দ checksum-অমিল ধরা পড়ে। প্রতিরক্ষা তিন স্তরে:

• শুরু থেকে শেষ পর্যন্ত checksum: client upload-এর সময় checksum পাঠায়, store প্রতিটি chunk-এর পাশে checksum রাখে (GFS-এর গবেষণাপত্রে প্রতি ৬৪ KB-তে একটি ৩২-বিট checksum), আর প্রতিটি পড়ায় মিলিয়ে নেয়। CRC-এর গণিত CN কোর্সের error detection পর্বে।
• Scrubbing: একটি পেছনের কাজ নিয়মিত (যেমন কয়েক সপ্তাহে একবার) সব chunk পড়ে checksum মেলায়, যাতে কম-পড়া ডেটার ক্ষতি জমে না থাকে; অমিল হলে অন্য কপি বা EC থেকে নতুন করে লেখা — উপরের XOR কোডের scrubber ঠিক এটাই করেছে।
• পেছনের মেরামত: heartbeat দিয়ে ব্যর্থতা চেনা (পর্ব ৪৪), grace period, তারপর সবচেয়ে ঝুঁকির stripe আগে। মেরামতের গতি সীমিত রাখলে ব্যবহারকারীর অনুরোধ ধীর হয় না, কিন্তু সূত্রের R বাড়ে — এটিই টানাপোড়েন।

সমান্তরাল মেরামতের হিসাব: ধরা যাক ১০ TB-এর একটি node মরল, ডেটা RS(6,3)-এ, আর তার fragment-গুলো ১,০০০টি node-এর stripe-এ ছড়ানো। মোট পড়া ৬০ TB, প্রতি node-এ ৬০ GB; প্রতিটি সেকেন্ডে ১০০ MB দিলে ৬০০ সেকেন্ড, প্রায় ১০ মিনিট — cluster জুড়ে তখন সেকেন্ডে ১০০ GB চলাচল। একটি RAID array-এর ভেতরে একই মেরামতে ঘণ্টার পর ঘণ্টা লাগত (RAID-এর rebuild). ছড়ানো placement মানে ছোট R, অর্থাৎ বেশি durability.

“এগারো nine” আসলে কী বলে

AWS তার প্রকাশিত FAQ-এ বলে S3-এর সাধারণ storage এক বছরে ৯৯.৯৯৯৯৯৯৯৯৯% durability-র জন্য নকশা করা — এগারোটি nine, আর ব্যাখ্যা দেয়: ১ কোটি object রাখলে গড়ে প্রতি ১০,০০০ বছরে একটি হারানোর আশা। অঙ্ক: ১০^৭ × ১০^−১১ = বছরে ১০^−৪টি object, অর্থাৎ ১০,০০০ বছরে একটি। আমাদের খেলনা-মডেলেও RS(6,3) দিয়েছিল ১১.০ nine — কিন্তু তিনটি সীমা মনে রাখুন:

• এটি নকশার লক্ষ্য, একটি মডেলের ফল — হার্ডওয়্যার ব্যর্থতার, স্বাধীনতা আর সময়মতো মেরামত ধরে। চুক্তির নিশ্চয়তা নয়; cloud-এর চুক্তি (SLA) সাধারণত availability নিয়ে।
• বাস্তবের ঝুঁকি একসাথে আসে: একই ব্যাচের disk, একই বিদ্যুৎ-লাইন, একটি ভুল release — correlated failure স্বাধীনতার অনুমান ভাঙে। মডেলে ২৪ থেকে ৭২ ঘণ্টায় যেতেই ১.৪ nine গেল।
• সবচেয়ে বড় ঝুঁকি আপনি নিজে: নিজের code-এর ভুল DELETE, ভুল lifecycle নিয়ম, চুরি যাওয়া চাবি — store নিখুঁতভাবে নির্দেশ মানবে। তাই versioning, মুছতে বাধা দেয় এমন lock (WORM) আর আলাদা অ্যাকাউন্টে backup — পর্ব ৫১, failover আর disaster recovery.

৮ · Distributed file system — GFS, HDFS আর তাদের পরে

Object storage-এর আগে আর পাশাপাশি এসেছে distributed file system — বহু যন্ত্র জুড়ে একটি file system. সবচেয়ে প্রভাবশালী নকশা ২০০৩ সালের SOSP সম্মেলনে Ghemawat, Gobioff আর Leung-এর Google File System. এর অনুমানগুলোই নকশা ঠিক করেছে: সস্তা হাজারো যন্ত্রে ব্যর্থতা রোজকার ঘটনা; ফাইল বিশাল (কয়েক GB); কাজ মূলত বড় টানা পড়া আর শেষে জোড়া (append), মাঝখানে লেখা বিরল।

• একটি master, অনেক chunkserver: master রাখে namespace, ফাইল থেকে chunk-এর map আর chunk-এর স্থান; স্থানগুলো disk-এ লেখে না, chunkserver-দের heartbeat থেকে জেনে নেয়। প্রতিটি chunk ৬৪ MB, ডিফল্টে ৩টি কপি।
• ডেটা master দিয়ে যায় না: client master-কে শুধু স্থান জিজ্ঞেস করে, উত্তর cache-এ রাখে, বাইট সরাসরি chunkserver থেকে — উপরের ছবির metadata আর data path-এর ভাগ এখানেই।
• লেখার ক্রম: master একটি কপিকে কিছু সময়ের জন্য primary বানায় (lease); primary লেখার ক্রম ঠিক করে, বাকিরা মানে। ডেটা chunkserver থেকে chunkserver-এ শিকলের মতো যায়।
• Record append: অনেক writer একই ফাইলে জোড়ে; GFS নিজে offset বেছে রেকর্ডটি অন্তত একবার atomically বসায় — retry-তে duplicate থাকতে পারে, পাঠক id আর checksum দিয়ে ছাঁকেন। শিথিল consistency, কিন্তু সহজে বড় হয়।

Hadoop-এর HDFS একই ছাঁচে গড়া: NameNode (master) আর DataNode; নতুন সংস্করণে ডিফল্ট block ১২৮ MB (আগে ৬৪), replication ৩. ডিফল্ট placement rack মানে: একটি কপি লেখকের node-এ, বাকি দুটি অন্য এক rack-এর দুটি node-এ — পুরো rack গেলেও কপি থাকে (সংস্করণভেদে আলাদা)।

একটি master-এর সীমা

বড় chunk কেন? GFS-এর গবেষণাপত্র বলে, master প্রতি ৬৪ MB chunk-এ ৬৪ byte-এর কম metadata রাখে। ১ PiB ডেটা = ২^৫০ ÷ ২^২৬ ≈ ১.৬৮ কোটি chunk, metadata প্রায় ১ GiB — এক যন্ত্রের memory-তে আঁটে। ১ MiB chunk হলে ১০৭ কোটির বেশি chunk আর প্রায় ৬৪ GiB. তবু সীমা এল: ফাইলের সংখ্যা master-এর memory-তে বাঁধা; লাখো ছোট ফাইল (small files problem) metadata ফোলায়; সব metadata-প্রশ্ন একটি যন্ত্রে; আর master বিকল হলে সব থামে — GFS-এ shadow master শুধু পড়তে দিত। ২০০৯ সালে ACM Queue-এর একটি সাক্ষাৎকারে GFS-এর একজন প্রকৌশলী এই চাপগুলোর কথা বলেন। HDFS পরে standby NameNode (high availability) আর namespace ভাগ (federation) যোগ করে।

পরের নকশাগুলোর মূল চাল: metadata-কেও distributed করা। Google-এর প্রকাশিত লেখা অনুযায়ী GFS-এর উত্তরসূরি Colossus metadata রাখে Bigtable-ধাঁচের একটি distributed database-এ; Ceph placement হিসাব করে নেয়; আধুনিক object store metadata রাখে sharded database-এ। Data lake-এর বড় অংশও HDFS থেকে object storage-এ সরেছে, compute আর storage আলাদা বাড়ানোর জন্য; rename দামি বলে সেখানে table format-গুলো manifest আর একটি pointer-এর atomic বদল ব্যবহার করে। Batch কাজ পর্ব ৩৬-এ।

OS-এর দিক থেকে NFS, AFS আর GFS-এর consistency semantics OS কোর্সের distributed OS পর্বে।

৯ · নকশা — ছবির অ্যাপের আপলোড, আর Dropbox-ধাঁচের file sync

ক · একটি ছবির অ্যাপের আপলোড, শুরু থেকে শেষ

একটি কাল্পনিক ছবি-শেয়ারের অ্যাপ। ধরা যাক দিনে ২০ লাখ ছবি, গড় ৩ MB: দিনে ৬ TB, বছরে প্রায় ২.১৯ PB মূল ডেটা — ৩ কপিতে ৬.৫৭ PB, RS(6,3)-এ প্রায় ৩.২৯ PB (হিসাবের কৌশল পর্ব ৩-এ)। পথটি:

1. অনুমতি: API লগইন আর quota দেখে, key বানায় (orig/u91/7f3a.jpg), status = pending লেখে, আর দেয় ৫ মিনিটের সই করা PUT URL, আকার-ধরন বাঁধা।
2. সরাসরি store-এ: বড় হলে multipart (অংশ ৩)।
3. Event: store “object তৈরি হয়েছে” event notification পাঠায় একটি queue-তে (পর্ব ৩১)।
4. Worker: আসল ধরন আর আকার যাচাই, malware scan, ছবির অবস্থান-তথ্য (EXIF GPS) মুছে গোপনীয়তা রক্ষা, তিন মাপের thumbnail (নামে hash, তাই immutable), তারপর status = ready. Event দুবার আসতে পারে (at-least-once, পর্ব ৩৪), তাই কাজটি idempotent: ছবির id-ই চাবি, একই output key.
5. পড়া: CDN thumbnail দেয় (পর্ব ১৭); ব্যক্তিগত ছবিতে স্বল্পমেয়াদি signed URL.
6. Event হারালে: একটি মিলিয়ে-দেখার কাজ পুরোনো pending সারি খুঁজে HEAD দিয়ে দেখে, আবার queue-তে দেয়। Database আর store — দুই জায়গায় লেখার সমস্যা আর outbox পর্ব ২৫-এ; দীর্ঘ কাজ পর্ব ৩৭-এ; ভিডিওর transcoding পর্ব ৫৯-এর case study-তে।

খ · Dropbox-ধাঁচের file sync — একটি খসড়া

কোনো প্রতিষ্ঠানের ভেতরের নকশা নয়, একটি সাধারণ খসড়া। মূল চিন্তা content-addressed storage: প্রতিটি chunk-এর নাম তার বিষয়বস্তুর SHA-256 hash; ফাইলের একটি version মানে chunk-hash-এর ক্রমিক তালিকা (manifest). একই বিষয়বস্তু দুবার রাখার প্রশ্নই নেই — স্বাভাবিক deduplication.

• আপলোড: device নিজে chunk আর hash বানায়, server-কে জিজ্ঞেস করে কোনগুলো নেই, শুধু সেগুলো পাঠায়, তারপর নতুন manifest লেখে conditional write দিয়ে (অংশ ৪)। দুই device অফলাইনে একই ফাইল বদলালে একটির লেখা 412 পায় — তখন দুটিই রাখা হয়, “conflicted copy” নামে।
• অন্য device: long polling বা WebSocket-এ খবর পায় (পর্ব ১০), manifest মিলিয়ে শুধু নতুন chunk নামায়।
• Chunk কোথায় কাটবেন: নির্দিষ্ট আকারে কাটলে শুরুতে একটি byte ঢোকালেই পরের সব chunk সরে যায়। Content-defined chunking সীমা ঠিক করে বিষয়বস্তু দেখে, একটি rolling hash দিয়ে; chunk-এর ভেতরের ছোট বদলে rsync-ধাঁচের delta sync.
• প্রতিরক্ষা: hash জানা মানেই পড়ার অধিকার নয় — প্রতিটি fetch-এ মালিকানা যাচাই। বহুজনের মধ্যে dedup “ফাইলটি কি আগেই আছে?” ফাঁস করতে পারে, তাই পরিধি প্রায়ই এক ব্যবহারকারী বা এক দল।

Fixed-size আর content-defined chunking-এর পার্থক্য সংখ্যায় দেখুন — ২৫৬ KiB-এর একটি ফাইলে একটি byte ঢুকিয়ে:

// Dedup after inserting ONE byte: fixed-size chunks vs content-defined chunking (CDC).
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 rnd = mulberry32(26);                        // seeded: same "file" on every run
const N = 256 * 1024, INSERT_AT = 5000;            // 256 KiB file; edit position (try others)
const v1 = Uint8Array.from({ length: N }, () => Math.floor(rnd() * 256));
const v2 = new Uint8Array(N + 1);                  // v2 = v1 with one byte inserted
v2.set(v1.subarray(0, INSERT_AT)); v2[INSERT_AT] = 42; v2.set(v1.subarray(INSERT_AT), INSERT_AT + 1);
const GEAR = Array.from({ length: 256 }, () => Math.floor(rnd() * 4294967296));

const fnv = (b, s, e) => { let h = 0x811c9dc5;       // chunk id (real systems: SHA-256)
  for (let i = s; i < e; i++) { h ^= b[i]; h = Math.imul(h, 0x01000193) >>> 0; } return h; };
function fixedCuts(b, size) { const c = [];
  for (let s = 0; s < b.length; s += size) c.push([s, Math.min(s + size, b.length)]); return c; }
function cdcCuts(b, MIN, MASK, MAX) {             // gear rolling hash: depends on last 32 bytes
  const c = []; let s = 0, h = 0;
  for (let i = 0; i < b.length; i++) {
    h = ((h << 1) + GEAR[b[i]]) >>> 0;
    const len = i - s + 1;
    if ((len >= MIN && (h & MASK) === 0) || len >= MAX) { c.push([s, i + 1]); s = i + 1; h = 0; }
  }
  if (s < b.length) c.push([s, b.length]); return c;
}
function report(name, cut) {
  const c1 = cut(v1), c2 = cut(v2), have = new Set(c1.map(([s, e]) => fnv(v1, s, e)));
  let reused = 0, upload = 0;
  for (const [s, e] of c2) { if (have.has(fnv(v2, s, e))) reused++; else upload += e - s; }
  console.log(name.padEnd(14) + String(c1.length).padStart(5) + String(c2.length).padStart(5) +
    String(reused).padStart(8) + String(upload).padStart(11) + (100 * upload / v2.length).toFixed(1).padStart(8) + "%");
}
console.log(`insert 1 byte at ${INSERT_AT} of ${N} bytes`);
console.log("method".padEnd(14) + "   v1   v2  reused   upload B  of file");
report("fixed 4 KiB", (b) => fixedCuts(b, 4096));
report("CDC ~4 KiB", (b) => cdcCuts(b, 2048, 0x7ff, 16384));

insert 1 byte at 5000 of 262144 bytes
method           v1   v2  reused   upload B  of file
fixed 4 KiB      64   65       1     258049    98.4%
CDC ~4 KiB       73   73      72       3370     1.3%

Object store আর আলাদা metadata-র একটি পূর্ণ ইন্টারভিউ-ধাঁচের walkthrough — pastebin-এর requirement, API, schema আর scale — পর্ব ৬৬-এর mock interview-এ।

১০ · AI-এর যুগে — storage নকশার পরামর্শ যাচাই

“ছবি কোথায় রাখব?” — AI-এর খসড়ায় প্রায়ই “S3 + Kafka + Redis + microservices” একসাথে। Storage-এর ভুল ধরা পড়ে দেরিতে: হারানো ডেটা, ফাঁস হওয়া URL বা বিশাল বিল। চেনা ভুল:

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

• Storage, egress আর repair traffic নিজে হিসাব করেছি — overhead (k + m) ÷ k আর মেরামতে k গুণ পড়া
• Fragment বা কপি failure domain-এ কীভাবে ছড়ানো, একটি পুরো zone গেলে কী থাকে — লিখে দেখেছি
• Presigned URL: স্বল্প মেয়াদ, server-এর বানানো key, আকার-ধরনের সীমা, log-এ query string নেই
• Event দুবার এলে ও না এলে — idempotent worker আর মিলিয়ে-দেখার কাজ আছে
• Versioning, lifecycle, অসমাপ্ত multipart মোছা আর আলাদা backup-এর পরিকল্পনা আছে
• Consistency আর সীমা নথিতে মিলিয়েছি; ছোট load test আর failure-mode review করেছি — node, zone, metadata service আর নিজের ভুল