Table properties

The Bloom filter sets the false-positive probability for SSTable Bloom filters. When a client requests data, Cassandra uses the Bloom filter to check if the row exists before doing disk I/O. Bloom filter property value ranges from 0 to 1.0. Lower Bloom filter property probabilities result in larger Bloom filters that use more memory. The effects of the minimum and maximum values:

• 0: Enables the unmodified, effectively the largest possible, Bloom filter.
• 1.0: Disables the Bloom filter.

Recommended setting: 0.1. A higher value yields diminishing returns.

Configure the cache by creating a property map of values for the caching property. Options:

• keys: ALL or NONE
• rows_per_partition: number of CQL rows (N), NONE, or ALL

According to the rows_per_partition value, Cassandra caches only the first N rows in a partition, as determined by the clustering order.

For example:

CREATE TABLE DogTypes (
  block_id uuid,
  species text,
  alias text,
  population varint,
  PRIMARY KEY (species, block_id)
) WITH caching = { 'keys' : 'NONE', 'rows_per_partition' : '120' };

The compaction property defines the compaction strategy class for this table. Choose the compaction strategy that best fits your data and environment.

• SizeTieredCompactionStrategy (STCS): The default compaction strategy. This strategy triggers a minor compaction when there are a number of similar sized SSTables on disk as configured by the table subproperty min_threshold. A minor compaction does not involve all the tables in a keyspace. See STCS compaction subproperties.
• DateTieredCompactionStrategy (DTCS): This strategy is particularly useful for time series data. DateTieredCompactionStrategy stores data written within a certain period of time in the same SSTable. For example, Cassandra stores your last hour of data in one SSTable time window, and the next 4 hours of data in another time window, and so on. Cassandra performs compaction when the number of SSTables in those windows reaches min_threshold (4 by default). The most common queries for time series workloads retrieve the last hour/day/month of data. Cassandra can limit SSTables returned to those having the relevant data. Also, Cassandra can store data set to expire using TTL in an SSTable with other data scheduled to expire at approximately the same time. Cassandra can then drop the SSTable without doing any compaction. Also see DTCS compaction subproperties.
• LeveledCompactionStrategy (LCS): Creates SSTables of a fixed, relatively small size (160 MB by default) that are grouped into levels. Within each level, SSTables are guaranteed to be non-overlapping. LCS uses STCS for the first level, called level 0 (L0). Each level beyond L0 (L1, L2 and so on) is 10 times as large as the previous level. Disk I/O is more uniform and predictable on higher than on lower levels as SSTables are continuously being compacted into progressively larger levels. At each level, row keys are merged into non-overlapping SSTables. This can improve performance for reads, because Cassandra can determine which SSTables in each level to check for the existence of row key data. This compaction strategy is modeled after Google's LevelDB implementation. See LCS compaction subproperties.

The default value or gc_grace_seconds is 864000 seconds (10 days). In a single-node cluster, this property can safely be set to zero. This value can also be reduced for tables whose data will not be explicitly deleted — for example, tables containing only data with TTL set, or tables with default_time_to_live set. However, if you lower the gc_grace_seconds value, consider its interaction with these operations:

• hint replays — When a node goes down and then comes back up, other nodes replay the write operations (called hints) that are queued for that node while it was unresponsive. Cassandra does not replay hints older than gc_grace_seconds after creation. The max_hint_window_in_ms setting in the cassandra.yaml file sets the time limit (3 hours by default) for collecting hints for the unresponsive node.
• batch replays — Like hint queues, batch operations store database mutations that are replayed in sequence. As with hints, Cassandra does not replay a batched mutation until gc_grace_seconds after it was created. If your application uses batch operations, consider the possibility that decreasing gc_grace_seconds increases the chance that a batched write operation may restore deleted data. The batchlog_replay_throttle_in_kb property in the cassandra.yaml file gives some control of the batch replay process. The most important factors, however, are the size and scope of the batches you use.

• ALWAYS: Send extra read requests to all other replicas after every read.
• Xpercentile: Cassandra constantly tracks each table's typical read latency (in milliseconds). If you set speculative retry to Xpercentile, Cassandra sends redundant read requests if the coordinator has not received a response after X percent of the table's typical latency time.
• Nms: Send extra read requests to all other replicas if the coordinator node has not received any responses within N milliseconds.
• NONE: Do not send extra read requests after any read.

For example:

ALTER TABLE users WITH speculative_retry = '10ms';

Or:

ALTER TABLE users WITH speculative_retry = '99percentile';