Database Reference
In-Depth Information
With the occasional burst of the I/O load during compaction,
SizeTieredCompac-
tionStrategy
is a good fit where rows are inserted and never mutated. This will en-
sure that all the bits of rows are in one SSTable. This is a write and I/O friendly strategy.
Leveled compaction
LeveledCompactionStrategy
is a relatively new introduction to Cassandra, and
the concepts are taken from Google's LevelDB project. Unlike size-tiered compaction, this
has many small and fixed size SSTables, grouped into levels. Within a level, the SSTables
do not have any overlap. Leveled compaction works in such a way that, for most of the
cases, a row will need to access just one SSTable. This is a big advantage over the size-
tiered version. It makes
LeveledCompactionStrategy
a better choice for reading
heavy tables. Updates are favored in level compaction, since it tries to spread rows as low
as possible.
The downside of leveled compaction is high I/O. There is no apparent benefit if the data is
write-once type. In this case, even with the size-tiered strategy, the data is going to stay in
one SSTable.
Anyone, coming from the traditional database world who has worked on scaling up read
requests and speeding up data retrievals, knows that caching is the most effective way to
speed up the reads. It prevents database hits for the data that has been fetched (in the re-
cent past) for the price of extra RAM that caching mechanism uses to store the data tem-
porarily. So, you have a third-party memory caching mechanism, such as Memcached,
which manages it for you. The nasty side of a third-party caching mechanism is the man-
aging the distributed cache. The cache management logic may intrude into application
code.
Cassandra provides an inbuilt caching mechanism that can be really helpful if your applic-
ation requires heavy read capability. There are two types of caches in Cassandra, row
cache and key cache. The following figure shows how caching works:
