LSM-tree: memtable, SSTable ও compaction
LSM-Trees, SSTables, and Compaction
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- WAL, memtable ও SSTable write path
- Compaction, Bloom filter ও read amplification
- B-tree বনাম LSM workload trade-off
সমস্যা দিয়ে শুরু
এক event store প্রচুর ছোট writes নিচ্ছে। Traditional random page update-এর বদলে append/batched disk work আকর্ষণীয়, কিন্তু read latency ও background compaction-এর প্রভাব আছে। LSM-tree storage engine write-heavy workload-এর জন্য একটি design family; এটি database query model বা consistency level নিজে নির্ধারণ করে না।
সহজ করে বুঝি
LSM write সাধারণত write-ahead log-এ record করে এবং sorted in-memory memtable-এ যায়। Memtable full হলে immutable sorted table বা SSTable disk-এ flush হয়। এক key-এর পুরোনো/newer versions একাধিক file-এ থাকতে পারে; read newest visible value খোঁজে। Compaction files merge করে obsolete versions/tombstones পরিষ্কার করতে পারে। Bloom filter definitely absent candidate file বাদ দিতে সাহায্য করে; false positive possible। WAL durability exact fsync/ack configuration অনুযায়ী বিচার করতে হয়।
পরিচিত একটি উপমা
দোকানদার প্রতিটি sale পুরোনো বড় ledger-এর সঠিক পাতায় না লিখে ছোট ordered notebook-এ রাখেন, পূর্ণ হলে sealed register বানান। পরে registers merge করে পুরোনো entry বাদ দেন। Write দ্রুত organized হতে পারে, কিন্তু query-তে কয়েকটি register খুঁজতে হয় এবং merge কাজের জন্য staff দরকার।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD W[Incoming write] --> L[Write ahead log] L --> M[Sorted memtable] M --> F[Flush immutable sorted table] F --> S[(SSTable files)] S --> C[Background compaction] C --> S R[Point read] --> B[Bloom filters and indexes] B --> S R --> M
Write log ও memtable path ধরে। Flush sorted immutable file তৈরি করে। Read current memtable এবং relevant disk files বিবেচনা করে newest version পায়। Compaction background-এ extra IO করে; diagram-এর loop free কাজ নয়। Delete tombstone হিসেবে লেখা হতে পারে এবং safety/retention rule পূরণ না হওয়া পর্যন্ত physical bytes থাকে।
PHP ও Laravel-এ প্রয়োগ
নিচের Laravel migration fragment write-heavy event shape দেখায়, LSM engine implement করে না। Laravel-এর PostgreSQL/MySQL table স্বয়ংক্রিয়ভাবে LSM হয়ে যায় না। RocksDB-ভিত্তিক service ব্যবহার করলে supported adapter/service boundary দরকার; SQL API দেখে internal engine assumption করবেন না। Event retention ও dedup policy আলাদা।
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
Schema::create('device_events', function (Blueprint $table) {
$table->id();
$table->uuid('event_id')->unique();
$table->unsignedBigInteger('device_id');
$table->timestampTz('occurred_at');
$table->json('payload');
$table->index(['device_id', 'occurred_at']);
});সুবিধা, সীমাবদ্ধতা ও trade-off
LSM sequential/batched write path ব্যবহার করতে পারে, তবে write amplification compaction-এ ফিরে আসে। Read amplification বহু sorted runs/files খোঁজার cost; space amplification obsolete copies রাখার cost। B-tree in-place/page-oriented organization read/update workload-এ অন্য trade-off দেয়। কোনও family সব workload-এ জেতে না। Cache, SSD, compression, key distribution ও compaction policy benchmark result বদলায়।
সাধারণ ভুল
- SSTable immutable বলে পুরোনো data কখনো delete হয় না বলা।
- WAL write মানেই fsync complete ধরে নেওয়া।
- Compaction IO ও disk headroom capacity estimate থেকে বাদ দেওয়া।
আরও একটু গভীরে
Leveled compaction read/space amplification কমানোর দিকে, universal/tiered style write behavior-এর দিকে trade-off করতে পারে; engine-specific policy পড়ুন। Large tombstone backlog range scan ধীর করতে পারে। Compaction pause, write stall এবং p99 latency দেখুন। Database isolation, replication ও transaction guarantee engine data structure থেকে আলাদা layers; LSM ব্যবহার করলেই eventual consistency বা NoSQL বাধ্যতামূলক নয়।
মনে রাখুন
LSM write, read ও compaction-এর মধ্যে কাজ স্থানান্তর করে। WAL, sorted files ও cleanup path একসঙ্গে বুঝুন। Real storage engine configuration ছাড়া latency/durability দাবি করবেন না।
নিজে চেষ্টা করুন
এক key তিনবার update, একবার delete এবং দুই flush-এর timeline আঁকুন। Read কোন version নেবে এবং compaction কী বাদ দিতে পারে বলুন। Same workload-এ write/read/space amplification measurement plan তৈরি করুন।
নিজের বোঝা যাচাই করুন
1. Memtable data durable?
Memory একা নয়। WAL sync/ack ও recovery configuration durability নির্ধারণ করে। Crash-এর আগে acknowledged boundary জানতে হবে।
2. SSTable immutable কেন?
Sorted file replace না করে নতুন runs ও merge-based compaction manage করা যায়। Update নতুন version হিসেবে আসে, পুরোনো file rewrite নয়।
3. Bloom filter exact?
Definitely absent signal দেয়, possible present-এ false positive থাকতে পারে। Positive হলে file/index lookup এখনও করতে হয়।
4. Compaction free?
না। CPU, disk bandwidth ও temporary space লাগে। Write stalls ও tail latency operational metrics-এ ধরুন।
5. LSM মানেই NoSQL?
না। Storage engine structure এবং database data model/transaction contract আলাদা। Product-specific semantics পড়তে হবে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।