The Scylla row cache, unlike the original Cassandra cache, is designed to reconcile data in cache with incoming writes. Cassandra’s row cache invalidates the whole partition for a given table on write, but Scylla’s does not. The result is that Scylla can run mixed read/write workloads efficiently. This reduces the need for data model complexity that is only present in order to work around the Cassandra read-before-write problem. Reducing data model complexity can have the indirect result of saving storage bandwidth as well.
Cassandra’s row cache caches only the head of a partition, where the number of rows cached is configurable. The Scylla cache is designed to enable caching of random rows from a partition. A near-future Scylla release will evict data from the row cache upon memory pressure gradually, starting from least recently used data.
Because the Cassandra row cache is ineffective for many workloads, some users introduce the additional complexity of running with the row cache disabled, and rely on the operating system page cache for serving reads. Scylla does not depend on the system page cache for caching on-disk data, but will rather dedicate all that memory to the application instead. Emphasizing the Scylla row cache over the OS page cache has several key advantages.
Cassandra compaction thrashes the page cache, because it reads and writes everything, and after compaction the most frequently used data is likely to no longer be in the cache. Cassandra has some workarounds for this problem, but the row cache is the most direct solution: compaction simply doesn’t touch the row cache, which remains populated with relevant data.
Getting started takes only a few minutes. Scylla has an installer for every major platform and is well documented. If you get stuck, we’re here to help.