Database Reference
In-Depth Information
PRIMARY KEY (page_id)
) WITH caching = 'keys_only';
As you can see here, in Cassandra 2.0.x, we cannot set the number of rows per partition to
be cached. By default, Cassandra has key caching enabled.
You can add comments to describe the specifics of a table to clarify the purpose of the
table. Here's an example:
CREATE TABLE pigeon_hole (
pigeon_id uuid,
pigeon_offense text,
pigeon_age int,
is_it_a_fun_pigeon boolean,
PRIMARY KEY(pigeon_id)
) WITH comment = 'Pigeon hole is a table for criminal
pigeons. They cannot see or talk to each other but if they
are fun, we may want to feed them once in a while';
As we know from Chapter 2 , Cassandra Architecture , Memtables eventually get flushed
to disk as immutable SSTables. But with time, we get lots of SSTables that may make data
retrieval slow, and data mutation operations such as update and delete render rows
living in an old SSTable useless. Cassandra performs compaction where it merges SST-
ables to solve these issues. We will see compaction in a little more detail in Chapter 5 ,
Performance Tuning . For now, you should know that there are two types of compaction
strategies:
SizeTieredCompactionStrategy : This favors a write-intensive load
where updates are less frequent.
LeveledCompactionStrategy : Inspired by Google's LevelDB, this
strategy is good for the cases where data is mutated more frequently. This strategy
is a bit disk I/O intensive.
An example of setting a compaction strategy is as follows:
CREATE TABLE compaction_demo (id uuid PRIMARY KEY, name
varchar)
WITH
COMPACTION = {
'class': 'SizeTieredCompactionStrategy',
Search WWH ::




Custom Search