liveBook · Manning

Log-structured merge-tree

As explained in ScyllaDB in Action

A log-structured merge-tree is a storage structure that buffers writes in memory and periodically persists them as immutable disk files merged by compaction.

A log-structured merge-tree (LSM tree) speeds writes by storing changes in memory, recording them in the commit log, and flushing batches to immutable SSTables. Compaction later merges files and removes obsolete data. section 8.3.3

The design trades cheaper writes for more complex reads:

  • Inserts, updates, and deletes can avoid disk access initially. section 8.3.3
  • Reads may inspect multiple SSTables to reconstruct the current value. section 8.3.3
  • Uncompacted obsolete data or ineligible tombstones can enlarge SSTables and slow queries. section 8.3.3

Inspecting persisted data

Flushing with nodetool and dumping an SSTable exposes stored partition keys, clustering rows, timestamps, and column values. SSTable indexes and Bloom filters help avoid unrelated files or partitions during reads. section 8.3.3

(scylla-1) $ nodetool flush

Use the flush command to force buffered data toward an SSTable before inspecting persisted storage. section 8.3.3

How ScyllaDB in Action covers it

How deep it goes
Traces memtables, commit logs, SSTables, compaction, tombstones, and read amplification without detailing compaction algorithms.
Examples
Uses nodetool flush, SSTable data inspection, partition keys, timestamps, and Bloom-filter lookup behavior.
What you can do after
Diagnose slow reads by relating large SSTables, obsolete data, tombstones, and multi-SSTable scans to compaction.
How it connects
Connects memtables, commit logs, SSTables, compaction, tombstones, Bloom filters, and sharding.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of ScyllaDB in Action. The section links point to the parts of the book it draws on.