liveBook · Manning

Row cache

As explained in ScyllaDB in Action

A row cache is an in-memory cache that stores database rows accessed by reads and can serve subsequent reads directly.

A row cache is an in-memory, read-through cache that keeps rows obtained from disk reads. When a later query needs a previously read row, it can often be served from the cache instead of requiring disk I/O. section 7.2.2 section 8.3.1

Disk I/O is one of the slowest low-level operations during a read. Rows can be spread across on-disk SSTables after writes and updates, so caching previously read rows helps reduce the cost of frequently repeated queries. section 7.2.2 section 8.3.1

Place the row cache among the main read and write components on a node:

  • Writes enter a memtable and commit log before being flushed into SSTables on disk. section 8.3.1
  • Reads check in-memory and on-disk structures for current row versions; the row cache helps speed these reads. section 7.4
  • Each CPU-core shard has its own row cache, memtable, commit log, and SSTables. section 8.3.2
Figure 8.11 Scylla’s row cache stores rows obtained by reading SSTables in response to a query.
figure

The figure traces the cache’s input: rows read from SSTables in response to a query are stored for later reads. section 8.3.1

How ScyllaDB in Action covers it

How deep it goes
Explains the read-through behavior and per-shard placement, while deferring deeper read-path details.
Examples
Illustrates cached rows with an SSTable read-path figure and a per-core sharding diagram.
What you can do after
Evaluate/understand why frequently repeated queries can avoid disk I/O through cached rows.
How it connects
Connects row caching to memtables, commit logs, SSTables, Bloom filters, and shard-per-core architecture.

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.