Object, block আর file storage — কোনটি কোন কাজে

১ · তিন রকম storage, তিনটি আলমারি

পর্ব ১৯ পর্যন্ত আমরা বারবার বলেছি, state বাইরে রাখুন। Autoscaling একটি VM মুছে দিতে পারে, container যেকোনো সময় নতুন করে উঠতে পারে। তাহলে ডেটা থাকবে কোথায়? Cloud এখানে একটি নয়, তিন রকম উত্তর দেয়। একটি অফিসের কথা ভাবলে তিনটিই সহজ হয়ে যায়।

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

২ · Block storage — VM-এর নিজের disk

Block storage VM-কে একটি সাধারণ disk দেখায়। VM জানে শুধু “block ৪-এ এই ৮ KB লেখা হবে”। ফাইল, ফোল্ডার, নাম, এগুলো disk জানে না। সেগুলো VM-এর ভেতরের filesystem (ext4, xfs, NTFS) বানায়। এজন্য block storage-এর ওপর আপনি যা খুশি চালাতে পারেন: filesystem, database, এমনকি পুরো OS. Boot volume-ও এমনই একটি disk.

Cloud-এ একটি block disk-কে বলে volume. বাস্তবে সেটি সাধারণত VM-এর host-এ লাগানো নয়। ডেটা থাকে আলাদা storage server-এ, network পেরিয়ে। এই বিচ্ছিন্নতা থেকেই তিনটি বড় সুবিধা:

• VM মরলেও ডেটা থাকে: Volume খুলে আরেকটি VM-এ লাগানো যায়।
• আকার বদলানো যায়: VM না থামিয়েই অনেক সময় volume বড় করা যায়, তারপর ভেতরের filesystem-ও বড় করতে হয়। ছোট করা সাধারণত যায় না।
• Snapshot: Volume-এর একটি মুহূর্তের ছবি রাখা যায়। AWS-এর ডকুমেন্টেশন অনুযায়ী EBS snapshot জমা থাকে S3-তে, আর incremental হয়, অর্থাৎ পরের snapshot-এ শুধু বদলানো block যায়।

দুটি সীমাও মনে রাখুন। প্রথমত, সাধারণ volume একটি zone-এ বাঁধা, অর্থাৎ ঠিক যে availability zone-এ VM, সেখানেই থাকতে হয়। অন্য zone-এ নিতে হলে snapshot থেকে নতুন volume বানানোই সাধারণ পথ। Azure-এর zone-redundant disk আর Google-এর regional Persistent Disk-এর মতো ব্যতিক্রম আছে, যাদের দাম আর আচরণ আলাদা।

দ্বিতীয়ত, সাধারণত এক সময়ে এক VM. Provider-রা multi-attach সুবিধা দেন, কিন্তু দুই VM একই ext4 একসাথে mount করলে দুজনেই নিজের মতো metadata বদলাবে, আর filesystem নষ্ট হবে। এটি নিরাপদ শুধু ক্লাস্টার-সচেতন সফটওয়্যারের সাথে। ভাগ করাই লক্ষ্য হলে file storage নিন।

একটি volume বানানো আর লাগানো

নিচে AWS CLI-র উদাহরণ, মূল ধাপগুলো দেখানোর জন্য। Azure আর Google Cloud-এ ধাপ একই, কমান্ড আলাদা। এটি চালানোর দরকার নেই। চালালে volume-এর বিল শুরু হবে, এমনকি VM বন্ধ থাকলেও।

# Fake ids. Costs money if run on a real account.
aws ec2 create-volume --availability-zone ap-south-1a \
  --size 100 --volume-type gp3 --iops 3000 --throughput 125
aws ec2 attach-volume --volume-id vol-0123456789abcdef0 \
  --instance-id i-0123456789abcdef0 --device /dev/sdf

# Inside the VM. mkfs ERASES the disk: check the name first.
lsblk
sudo mkfs.ext4 /dev/nvme1n1
sudo mkdir -p /data
sudo mount /dev/nvme1n1 /data

# Clean up
sudo umount /data
aws ec2 detach-volume --volume-id vol-0123456789abcdef0
aws ec2 delete-volume --volume-id vol-0123456789abcdef0

একটি বাস্তব ফাঁদ: --device /dev/sdf লিখলেও ভেতরে নাম হতে পারে /dev/nvme1n1. তাই mkfs-এর আগে lsblk দেখে নিশ্চিত হোন। আর স্থায়ী mount-এর জন্য /etc/fstab-এ device-এর নাম নয়, UUID লিখুন, কারণ reboot-এ নাম বদলাতে পারে। /etc/fstab নিয়ে বিস্তারিত আছে পর্ব ৮-এ।

Volume-এর ধরন: সাধারণ বনাম provisioned

প্রতিটি provider কয়েক ধরনের volume দেন। মূল ভাগ দুটি। General-purpose volume বেশিরভাগ কাজের জন্য। Provisioned IOPS volume-এ আপনি ঠিক করে দেন কত IOPS চান, আর তার জন্য আলাদা দাম দেন। HDD-ভিত্তিক সস্তা ধরনও আছে, লম্বা sequential পড়ার জন্য।

পুরোনো প্রজন্মে IOPS volume-এর আকারের সাথে বাঁধা থাকত, আর burst credit ফুরোলে গতি হঠাৎ পড়ে যেত। নতুন অনেক ধরনে আকার আর গতি আলাদা করে কেনা যায়। আপনার ধরনে কোনটি প্রযোজ্য, সেটি ডকুমেন্টেশনে দেখে নেবেন।

Database-এর একটি লেখার যাত্রা

একটি অ্যাপ COMMIT বলল। “সফল” উত্তর আসার আগে ঠিক কী ঘটে? নিচের ঘড়ির মানগুলো অনুমিত, শুধু আকার বোঝানোর জন্য। বাস্তবে যন্ত্র আর ধরনভেদে আলাদা। শেষ সারিটি খেয়াল করুন: এই মুহূর্তে VM মরলে কী হতো।

৩ · IOPS, throughput আর latency — তিনটি আলাদা সীমা

একটি ঘাটের কথা ভাবুন। IOPS হলো প্রতি সেকেন্ডে কতবার নৌকা ছাড়ে। Block size হলো প্রতি নৌকায় কত মাল। Throughput হলো সেকেন্ডে মোট কত মাল পার হলো। আর latency হলো একটি নৌকার পার হতে কত সময় লাগে। ছোট নৌকা ঘনঘন চললেও মাল কম পার হয়। আবার ঘাট চওড়া হলেও পন্টুন সরু হলে আটকে যায়।

একটি volume-এ সাধারণত দুটি সীমাই থাকে, আর যেটিতে আগে ঠেকে সেটিই আপনার আসল সীমা। ধরি ৩,০০০ IOPS আর ১২৫ MB/s. ৪ KB-তে ৩,০০০ × ৪ KB = ১২ MB/s, অর্থাৎ IOPS আগে ফুরায়। ২৫৬ KB-তে IOPS-এর হিসাবে ৭৬৮ MB/s হওয়ার কথা, কিন্তু throughput ১২৫ MB/s-এ থামে, তাই আসল IOPS ১২৫,০০০ ÷ ২৫৬ ≈ ৪৮৮. দুই সীমা মেলে ১২৫,০০০ ÷ ৩,০০০ ≈ ৪১.৭ KB-তে।

আরও দুটি সীমা, যা বিলে লেখা থাকে না

VM-এর নিজের সীমা: প্রতিটি instance type-এর storage bandwidth-এর একটি সীমা আছে। ৫০০ MB/s-এর volume ছোট VM-এ লাগালে VM-ই থামিয়ে দেবে।

Queue depth: Little's law বলে, IOPS = একসাথে চলা I/O ÷ latency. Database যদি একটির পর একটি fsync করে, queue depth ১, latency ১ ms, তবে সর্বোচ্চ ১,০০০ IOPS. Volume ১৬,০০০ IOPS দিলেও লাভ নেই। নিচের সিমুলেটরে চারটি সীমাই আছে। সবচেয়ে ছোটটিই জেতে।

// Which limit binds? Every number is an ASSUMED example
const vol = { iops: 3000, mbps: 125 };      // general-purpose volume
const vmMbps = 250;                         // the VM's own storage limit
const cases = [                             // queue depth, latency in ms
  { name: "db 8 KB, 1 thread",   kb: 8,   qd: 1,  ms: 1.0 },
  { name: "db 8 KB, 32 queued",  kb: 8,   qd: 32, ms: 1.0 },
  { name: "mixed 16 KB",         kb: 16,  qd: 32, ms: 1.0 },
  { name: "scan 64 KB",          kb: 64,  qd: 32, ms: 1.0 },
  { name: "backup 256 KB",       kb: 256, qd: 16, ms: 1.0 },
];
function solve(v, vm, c) {
  const limits = [                          // each limit, as I/O per second
    ["queue", c.qd * 1000 / c.ms],          // Little: depth / latency
    ["volume IOPS", v.iops],
    ["volume MB/s", v.mbps * 1000 / c.kb],
    ["VM MB/s", vm * 1000 / c.kb],
  ].sort((a, b) => a[1] - b[1]);
  const iops = limits[0][1];
  return { iops, mbps: iops * c.kb / 1000, binds: limits[0][0] };
}
function report(title, v) {
  console.log(title + ": " + v.iops + " IOPS, " + v.mbps + " MB/s, VM " + vmMbps + " MB/s");
  for (const c of cases) {
    const r = solve(v, vmMbps, c);
    console.log(c.name.padEnd(20) + String(Math.round(r.iops)).padStart(6) + " IOPS"
      + r.mbps.toFixed(1).padStart(7) + " MB/s  binds: " + r.binds);
  }
}
report("general", vol);
report("provisioned", { iops: 16000, mbps: 500 });
console.log("knee block size = " + (vol.mbps * 1000 / vol.iops).toFixed(1) + " KB");

general: 3000 IOPS, 125 MB/s, VM 250 MB/s
db 8 KB, 1 thread     1000 IOPS    8.0 MB/s  binds: queue
db 8 KB, 32 queued    3000 IOPS   24.0 MB/s  binds: volume IOPS
mixed 16 KB           3000 IOPS   48.0 MB/s  binds: volume IOPS
scan 64 KB            1953 IOPS  125.0 MB/s  binds: volume MB/s
backup 256 KB          488 IOPS  125.0 MB/s  binds: volume MB/s
provisioned: 16000 IOPS, 500 MB/s, VM 250 MB/s
db 8 KB, 1 thread     1000 IOPS    8.0 MB/s  binds: queue
db 8 KB, 32 queued   16000 IOPS  128.0 MB/s  binds: volume IOPS
mixed 16 KB          15625 IOPS  250.0 MB/s  binds: VM MB/s
scan 64 KB            3906 IOPS  250.0 MB/s  binds: VM MB/s
backup 256 KB          977 IOPS  250.0 MB/s  binds: VM MB/s
knee block size = 41.7 KB

লোকাল NVMe বনাম network storage

VM-এর সাথে লাগানো NVMe SSD-তে network-এর পথটুকু নেই। নিচের সংখ্যাগুলো শুধু মাত্রা বোঝানোর জন্য, যন্ত্র আর ধরনভেদে অনেক আলাদা হতে পারে।

তাহলে সব database লোকাল NVMe-তে নয় কেন? কারণ সেই disk host-এর ভাগ্যের সাথে বাঁধা। Host নষ্ট হলে ডেটাও যায়। তাই যেসব সিস্টেম নিজেরাই একাধিক node-এ ডেটা replicate করে, তারাই লোকাল NVMe-তে স্বচ্ছন্দ। আর cache, scratch ডেটা, সাময়িক ফাইল, এগুলোও ভালো প্রার্থী।

৪ · File storage — অনেক VM, একটি ফোল্ডার

File storage একটি পুরো filesystem network-এ দেয়। VM-এ একটি share mount করলে সেটি সাধারণ ফোল্ডারের মতো দেখায়। open, read, rename, ls সবই চলে, তাই পুরোনো সফটওয়্যার না বদলেই কাজ করে। Filesystem-এর দায়িত্ব এখানে VM-এ নয়, সার্ভারে। এই কারণেই অনেক VM একসাথে নিরাপদে ব্যবহার করতে পারে।

প্রোটোকল দুটি প্রধান। NFS এসেছে Unix জগৎ থেকে, Linux-এ সাধারণ। SMB মূলত Windows জগতের, ফাইল-শেয়ারিংয়ের পরিচিত পথ। AWS EFS মূলত NFS দেয়, Azure Files SMB আর NFS দুটোই দেয়, আর Google Filestore NFS দেয়। অনেক সেবা zone-জুড়ে mount করা যায়, তবে ধরনভেদে আলাদা।

# Fake hostname. Needs a real NFS share and firewall access.
sudo mkdir -p /mnt/shared
sudo mount -t nfs4 fs.example.internal:/ /mnt/shared
df -h /mnt/shared          # now looks like a normal folder
ls -l /mnt/shared
sudo umount /mnt/shared

এটি জাদু নয়। প্রতিটি metadata-র কাজ, যেমন “এই ফাইল আছে কি না”, একটি network যাত্রা। তাই হাজার হাজার ছোট ফাইলের ls -R বা npm install এখানে হতাশাজনকভাবে ধীর। আর সেবাভেদে throughput আকারের সাথে বাঁধা থাকতে পারে: কম ডেটা রাখলে কম গতি।

দুই VM একই ফাইল খুললে কী হয়

ধরি web-1 একটি ৩ MB ইনভয়েস লিখছে, আর web-2 সেটি খুলতে চায়। NFS-এর সাধারণ আচরণের নাম close-to-open consistency: একজনের লেখা অন্যজন নিশ্চিতভাবে দেখবেন প্রথমজন বন্ধ করার পর দ্বিতীয়জন আবার খুললে। ক্লায়েন্টের cache এর কারণ। Provider আর mount option ভেদে সময় আলাদা হতে পারে।

৫ · Object storage — key, HTTP আর পুরো জিনিস

Object storage-এ আপনি একটি bucket-এর ভেতরে key দিয়ে পুরো জিনিস রাখেন। চারটি বৈশিষ্ট্য একে আলাদা করে:

• সমতল নামের জগৎ (flat namespace): ফোল্ডার নেই। img/2026/a.png একটিই লম্বা key. Console যে ফোল্ডার দেখায়, সেটি / দিয়ে বানানো একটি সুবিধা মাত্র।
• HTTP API: Mount নয়, PUT, GET, DELETE, LIST. তাই যেকোনো ভাষা, যেকোনো জায়গা থেকে চলে, অনুমতি থাকলে।
• অপরিবর্তনীয় (immutable) object: এক বাইট বদলাতেও পুরো object আবার লিখতে হয়। মাঝখানে লেখা বা append সাধারণত নেই। পড়ার বেলায় অংশবিশেষ (range request) আনা যায়।
• বিশাল মাপ: মোট জায়গার ব্যবহারিক সীমা প্রায় নেই। আপনাকে আগে থেকে আকার বলতে হয় না, যা রাখেন তারই বিল। তবে একটি object-এর সর্বোচ্চ আকার, প্রতি সেকেন্ডের অনুরোধ, এগুলোর সীমা আছে, যা provider-ভেদে আলাদা।

এই সীমাবদ্ধতাগুলো দুর্বলতা নয়, বরং দাম। Object বদলায় না বলে কপি মেলানো সহজ, আর hierarchy নেই বলে একটি metadata সার্ভারে ভিড় হয় না। ভেতরের নকশা, chunk, placement আর erasure coding দেখুন System Design কোর্সের Object storage পর্বে। এখানে আমরা API-র দিক থেকে দেখি।

PUT /reports/2026-10.csv HTTP/1.1
Host: example-bucket.objects.example.com
Authorization: (signed request)
Content-Length: 5000000
(৫ MB বাইট)

signature মিলল     OK
policy: PutObject  OK
bucket আছে         OK

device-a  zone-1  লেখা হলো
device-b  zone-2  লেখা হলো
device-c  zone-3  লেখা হলো
metadata এখনো পুরোনো, GET নতুনটি পাবে না

reports/2026-10.csv -> version 1

HTTP/1.1 200 OK
ETag: "a1b2c3d4e5f6"

GET /reports/2026-10.csv HTTP/1.1

HTTP/1.1 200 OK
Content-Length: 5000000
ETag: "a1b2c3d4e5f6"

GET    পুরো ৫ MB আনা
লোকালে এক লাইন বদলানো
PUT    পুরো ৫ MB আবার পাঠানো
ETag: "f6e5d4c3b2a1"   (নতুন)

Consistency — সংক্ষেপে

তিন মডেলের প্রতিশ্রুতি আলাদা। Block-এ একজনই লেখেন, তাই প্রশ্ন সহজ: fsync ফিরলে ডেটা নিরাপদ। File-এ সাধারণত close-to-open. Object-এ এক key-এর জন্য read-after-write. AWS-এর ঘোষণা অনুযায়ী S3-এ এটি পুরোপুরি এসেছে ডিসেম্বর ২০২০ থেকে, আর লেখার সময়ে Azure Blob আর Google Cloud Storage-ও একই ধরনের প্রতিশ্রুতি দেয়। তবু দুটি ফাঁক থাকে: দুটি object একসাথে atomically বদলানোর ব্যবস্থা নেই, আর সামনে CDN থাকলে পুরোনো কপি কিছুক্ষণ আসতে পারে। তত্ত্বের জন্য System Design-এর CAP ও consistency দেখুন।

৬ · Durability বনাম availability — “এগারো nine” আসলে কী

দুটি প্রশ্ন আলাদা। Durability জিজ্ঞেস করে: ডেটা আছে তো? Availability জিজ্ঞেস করে: ডেটা এখন পাওয়া যাচ্ছে তো? ব্যাংকের লকারে গয়না নিরাপদ, কিন্তু ব্যাংক বন্ধের দিনে পাবেন না। সেদিন durability পুরো, availability শূন্য।

AWS তার প্রকাশিত FAQ-এ বলে, S3-এর সাধারণ storage এক বছরে ৯৯.৯৯৯৯৯৯৯৯৯% durability-র জন্য নকশা করা, অর্থাৎ এগারোটি nine. অন্য বড় provider-রাও একই ধরনের লক্ষ্য বলেন। সূত্রটি সরল: প্রতি object-এর বছরে হারানোর সম্ভাবনা p = ১০^−১১, আর N সংখ্যক object-এ প্রত্যাশিত ক্ষতি N × p.

// Expected yearly loss from a durability figure (a design target)
function loss(objects, nines) {
  const p = Math.pow(10, -nines);            // chance one object is lost in a year
  const expected = objects * p;
  const atLeastOne = -Math.expm1(objects * Math.log1p(-p));
  return { expected, atLeastOne, years: 1 / expected };
}
const fmt = (x) => x.toExponential(1);
console.log("objects     nines  lost/year  P(any)   one per years");
for (const [n, label] of [[1e7, "10 million"], [1e9, "1 billion"], [1e12, "1 trillion"]]) {
  for (const nines of [9, 11]) {
    const r = loss(n, nines);
    console.log(label.padEnd(12) + String(nines).padStart(4) + fmt(r.expected).padStart(11)
      + fmt(r.atLeastOne).padStart(9) + fmt(r.years).padStart(14));
  }
}
// A block volume fails as one unit, so the unit of loss is much larger
const afr = 0.002, volumes = 100, sizeGB = 500;   // assumed yearly failure rate
const pAny = 1 - Math.pow(1 - afr, volumes);
console.log("100 volumes at AFR 0.2%: expected " + (afr * volumes).toFixed(1)
  + " per year, P(any) " + (pAny * 100).toFixed(1) + "%");
console.log("one failure takes " + sizeGB + " GB; a snapshot is the way back");
// Human error is outside the durability figure
const bad = 1e7 * 0.001;                     // a bad script deletes 0.1%
console.log("bad delete of 0.1% of 10 million: " + bad + " objects, at once");

objects     nines  lost/year  P(any)   one per years
10 million     9     1.0e-2   1.0e-2        1.0e+2
10 million    11     1.0e-4   1.0e-4        1.0e+4
1 billion      9     1.0e+0   6.3e-1        1.0e+0
1 billion     11     1.0e-2   1.0e-2        1.0e+2
1 trillion     9     1.0e+3   1.0e+0        1.0e-3
1 trillion    11     1.0e+1   1.0e+0        1.0e-1
100 volumes at AFR 0.2%: expected 0.2 per year, P(any) 18.1%
one failure takes 500 GB; a snapshot is the way back
bad delete of 0.1% of 10 million: 10000 objects, at once

তিনটি সতর্কতা:

• এটি নকশার লক্ষ্য, চুক্তি নয়। সংখ্যাটি একটি মডেলের ফল, যা স্বাধীন ব্যর্থতা ধরে নেয়। SLA সাধারণত availability নিয়ে হয়, আর ক্ষতিপূরণ সাধারণত service credit.
• বাস্তবের ঝুঁকি একসাথে আসে। একই ব্যাচের disk, একটি ভুল release, এগুলো correlated failure, যা মডেলের অনুমান ভাঙে।
• Durability ভুল মোছা ঠেকায় না। আপনার DELETE-ও store নিখুঁতভাবে মানে। Versioning আর আলাদা account-এ backup দেখবেন পর্ব ২১ আর পর্ব ২৪-এ।

Availability-র সংখ্যা সাধারণত অনেক কম, যেমন তিন বা চার nine-এর ঘরে, আর storage class-ভেদে আলাদা। ফেব্রুয়ারি ২০১৭-র S3 ঘটনাটি এর ক্লাসিক উদাহরণ। AWS-এর প্রকাশিত বিবরণ অনুযায়ী, একটি কমান্ডে ভুল ইনপুটের কারণে একটি region-এ প্রয়োজনের চেয়ে বেশি server সরে যায়, আর কয়েক ঘণ্টা S3 ব্যাহত হয়। ডেটা হারানোর কথা সেখানে বলা হয়নি: availability গিয়েছিল, durability নয়।

৭ · খরচ — জায়গা, অনুরোধ আর বাইরে পাঠানো ডেটা

“প্রতি GB কত” দেখে storage বাছলে ভুল হবে। বিলের তিনটি অংশ:

• জায়গা: Block-এ আপনি যত GB কিনেছেন তার দাম, ভেতরে অর্ধেক ফাঁকা থাকলেও। File আর object-এ সাধারণত যত GB রেখেছেন তার দাম।
• অনুরোধ ও গতি: Object-এ প্রতি PUT আর GET-এর দাম। Provisioned volume-এ কেনা IOPS-এর দাম, ব্যবহার হোক বা না হোক।
• Data transfer: Internet-এ বাইরে যাওয়া ডেটা, অর্থাৎ egress. Zone-এর মধ্যে চলাচলেও অনেক সময় দাম লাগে।

নিচের সব দাম আমাদের ধরে নেওয়া গোল সংখ্যা, কোনো provider-এর বর্তমান দাম নয়। আসল হিসাবের আগে pricing পাতা দেখে নেবেন। ধরি ১ TB (১,০০০ GB) ডেটা এক মাস রাখব, আর ১,০০০ GB-র volume কিনেছি।

// One month, 1 TB of data. All prices are ASSUMED round numbers.
const P = { gp: 0.08, piopsGB: 0.12, perIops: 0.05, file: 0.30, obj: 0.02,
  putM: 5, getM: 0.5, egress: 0.10 };          // $ per GB, per IOPS, per million
const GB = 1000, IOPS = 10000;
const patterns = [
  { name: "web files", put: 1, get: 20, out: 200 },   // millions, millions, GB
  { name: "tiny hot objects", put: 100, get: 1000, out: 200 },
];
function bill(p) {
  const out = p.out * P.egress;
  return {
    "block general": GB * P.gp + out,
    "block provisioned": GB * P.piopsGB + IOPS * P.perIops + out,
    "file share": GB * P.file + out,
    "object": GB * P.obj + p.put * P.putM + p.get * P.getM + out,
  };
}
const usd = (x) => "$" + x.toFixed(2).padStart(8);
for (const p of patterns) {
  console.log(p.name + ": PUT " + p.put + "M, GET " + p.get + "M, out " + p.out + " GB");
  for (const [k, v] of Object.entries(bill(p)))
    console.log("  " + k.padEnd(18) + usd(v) + "  " + usd(v / GB) + " per GB");
}
// Object storage's request budget before it costs more than a general volume
const gap = GB * (P.gp - P.obj);
console.log("storage gap $" + gap + " = " + (gap / P.getM) + "M GET or "
  + (gap / P.putM) + "M PUT");

web files: PUT 1M, GET 20M, out 200 GB
  block general     $  100.00  $    0.10 per GB
  block provisioned $  640.00  $    0.64 per GB
  file share        $  320.00  $    0.32 per GB
  object            $   55.00  $    0.06 per GB
tiny hot objects: PUT 100M, GET 1000M, out 200 GB
  block general     $  100.00  $    0.10 per GB
  block provisioned $  640.00  $    0.64 per GB
  file share        $  320.00  $    0.32 per GB
  object            $ 1040.00  $    1.04 per GB
storage gap $60 = 120M GET or 12M PUT

খরচের আরও গভীরে, যেমন storage class, ঠান্ডা ডেটা আর lifecycle, পর্ব ২১-এ। পুরো cloud বিলের ছবি পাবেন পর্ব ৭২-এ।

৮ · কোন কাজে কোনটি — access pattern দিয়ে বাছাই

ঠিক প্রশ্নটি “কোন storage ভালো” নয়। প্রশ্ন হলো ডেটা কীভাবে ব্যবহার হবে, অর্থাৎ access pattern. চারটি জিনিস জিজ্ঞেস করুন: কে কে পড়বে ও লিখবে? ডেটা বদলায় নাকি শুধু জমে? প্রতিটি I/O কত ছোট? আর latency কতটা জরুরি?

Kubernetes-এ এই তিনটিই ফিরে আসবে PV আর PVC হয়ে, পর্ব ৪৭-এ। আর database নিজে চালাবেন কি না, সেই প্রশ্ন পর্ব ২২-এর।

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

AI সহজেই বলে দেয় “S3 ব্যবহার করুন”, কিন্তু সে আপনার access pattern, বিল আর ডেটার গুরুত্ব দেখে না। এই বিষয়ে তার সাধারণ ভুলগুলো হলো:

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

• Access pattern লিখে মিলিয়েছি: কে লেখে, কে পড়ে, I/O কত বড়
• IOPS × block size নিজে হিসাব করেছি, আর VM-এর সীমাও দেখেছি
• বিলের তিন অংশই আছে, আর budget alert চালু
• Bucket private, 0.0.0.0/0 থেকে NFS খোলা নেই, অনুমতি নির্দিষ্ট
• Secret prompt-এ দিইনি, কোডেও নেই
• মুছে ফেলার সব কমান্ড আগে dry-run বা plan-এ দেখেছি, আর ফেলে-দেওয়া পরিবেশে চালিয়েছি
• Backup থেকে ফেরত এনে দেখেছি, শুধু backup নেওয়াই যথেষ্ট ধরিনি