L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Design et création · SKILL.md

storage-engines

storage-engines

Storage-engine and database-internals architecture: B-tree vs LSM-tree, write- ahead logging, buffer/page cache, MVCC and concurrency control, durability/fsync, and compaction. Architect-level engine selection and data-path design. USE WHEN: designing or choosing a storage engine, "B-tree vs LSM", "WAL", "buffer pool", "MVCC", "compaction", "write amplific…

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: storage-engines description: | Storage-engine and database-internals architecture: B-tree vs LSM-tree, write- ahead logging, buffer/page cache, MVCC and concurrency control, durability/fsync, and compaction. Architect-level engine selection and data-path design.

USE WHEN: designing or choosing a storage engine, "B-tree vs LSM", "WAL", "buffer pool", "MVCC", "compaction", "write amplification", "fsync/durability", embedded KV store, database internals, read/write-optimized store choice.

DO NOT USE FOR: SQL query writing/ORM (use database/orm skills); data pipelines (use data-intensive); vector indexes (use vector-stores skills). allowed-tools: Read, Grep, Glob

Storage-Engine Internals

B-tree vs LSM-tree — the defining choice

B-tree (InnoDB, Postgres)LSM-tree (RocksDB, Cassandra)
WritesIn-place; random I/O; write-amp from page writesSequential (memtable→SST); high throughput
Reads1 path, predictableMay touch many levels → read-amp (mitigate w/ bloom filters)
SpaceFragmentationSpace-amp until compaction
Best forRead-heavy, range scans, point lookupsWrite-heavy ingest, SSD-friendly

The three amplifications (write / read / space) trade off against each other — state which one the workload can least afford.

Durability & the write path

  • WAL: append before applying; fsync/fdatasync policy = the durability ↔ throughput knob (group commit amortizes fsync). O_DIRECT vs page cache; fsync correctness (don't trust it lying — the "fsync-gate").
  • Buffer/page cache: hit ratio drives everything; eviction (LRU/CLOCK), dirty-page writeback, checkpointing to bound recovery time.
  • Crash recovery: redo/undo, ARIES, checkpoints; recovery time vs steady-state.

Concurrency control

  • MVCC (snapshot reads, no read locks) vs 2PL (locking) vs OCC (validate at commit). MVCC needs version GC/vacuum (Postgres bloat).
  • Isolation levels and their anomalies; SSI for serializable without heavy locks.

When to recommend what

  • Write-heavy ingest / time-series / SSD → LSM (RocksDB/Cassandra/ScyllaDB).
  • Read-heavy, rich queries, range scans → B-tree (Postgres/InnoDB).
  • Embedded/edge KV → LMDB (B-tree, mmap) or RocksDB (LSM) by read/write mix.
Skills enregistrées