Database Reference
In-Depth Information
data=writeback, nobh.
When you set
data=writeback
,
metadata for files is lazily written after the file is written. While this won't
cause file system corruption, it may cause the most recent changes to be
lost in the event of a crash. Since most files in Cassandra are written on
and not edited in place, this is a low-risk change.
nobh
(no buffer heads)
refers to the operating system's attempt to avoid associating buffer heads
to data pages. In other words, don't create a map of the disk block inform-
ation. This is a useful setting for Cassandra because it doesn't update in
place.
Note that if you make changes on a disk that is already mounted, you will have
to unmount and remount the disk in order for the changes to take effect.
Caching
The use of caching is an important part of getting performance out of any system.
Caching is the ability to store something in a temporary location that makes it
faster or easier to access than getting it the way it would otherwise be retrieved. In
other words, you don't go to the store to buy a glass of milk. You buy a gallon of
milk, store it in your fridge, and then go to your fridge when you want a glass of
milk.
Cache works the same way. Assuming that you have row caching on, if you are
constantly going back to get the same row from a ColumnFamily and that row isn't
located on the coordinator node, the coordinator node and the queried node will
cache it. The next time the coordinator is asked for that row, it will go to the tem-
porary store (cache) and check that location first. If it finds the data in the cache,
this will negate the need to check the node actually responsible for the data. This
means there will be less disk I/O, less network traffic, and less system overhead
that doesn't need to be dedicated to listening for query results externally.
How Cassandra Caching Works
Before we talk specifically about tuning the cache, we should discuss how caching
in Cassandra works. When both the row cache and key cache are configured and
enabled, the standard order for searching for the data is row cache, key cache,
SSTables, and then MemTables. Let's break this down a little bit further.
When your application requests a row of data, the first thing that Cassandra
does is to go to the row cache. If Cassandra finds the row in the row cache,
it returns it to the application and that is a win for caching. If the row is not
