Database Reference
In-Depth Information
•
row_cache_save_period
: Similar to
key_cache_save_period
, this
saves the cache to saved caches directory after the prescribed time. Unlike key
caches, row caches are bigger and saving it to the disk is an I/O expensive task to
do. Compared to the fuss for saving row cache, it does not give proportional be-
nefit. It is okay to leave it to zero, that is, disabled.
•
row_cache_keys_to_save
: This is the same as
key_cache_keys_to_save
.
•
memory_allocator
: Out of the box, Cassandra provides two mechanisms to
enable row cache:
◦
NativeAllocator
: This uses the native GCC allocator to store off
heap data. This is by default, and good for most of the use cases.
◦
JEMallocAllocator
: This is a slightly better alternative to
Nat-
iveAllocator
. The main feature of this allocator is that it is
fragmentation-resistant. To be able to use this, you will need to install
cassandra-env.sh
. Here is the part that you need to change; uncom-
ment the last two lines with
JEMALLOC_HOME
set as the location, where
jemalloc
is installed as follows:
# Configure the following for JEMallocAllocator
and if jemalloc is not available in the system
# library path (Example: /usr/local/lib/).
Usually "make install" will do the right thing.
# export LD_LIBRARY_PATH=<JEMALLOC_HOME>/lib/
# JVM_OPTS="$JVM_OPTS
-Djava.library.path=<JEMALLOC_HOME>/lib/"
Enabling compression
Table (or column family) compression is a very effective mechanism to improve read and
write throughput. As one can expect, compression (any) leads to compact representation
of data at the cost of some CPU cycles. Enabling compression on a table makes the disk
representation of the data (SSTables) terse. This means efficient disk utilization, lesser
I/O, and a little extra burden to the CPU. In the case of Cassandra, the trade-off between
I/O and the CPU, due to compression, almost always yields favorable results. The cost of
CPU performing compression and decompression is less than what it takes to read more
data from the disk.
