CREATE TABLE

column_name

Use a unique name for each column in table. To preserve case or use special characters, enclose the name in double-quotes.

cql_type_definition

Defines the type of data allowed in the column, see CQL data type or a user-defined type.

STATIC

Optional, the column has a single value.

PRIMARY KEY

When the PRIMARY KEY is one column, append PRIMARY KEY to the end of the column definition. This is only schema information required to create a table. When there is one primary key, it is the partition key; the data is divided and stored by the unique values in this column.column_name cql_type_definition PRIMARY KEY.

Alternatively, you can declare the primary key consisting of only one column in the same way as you declare a compound primary key.

column_list

Defines a partition and clustering columns, which affects how the data in stored.

• Compound primary key: the first column is the partition key, and the additional columns are clustering keys. Syntax: PRIMARY KEY (partition_column_name, clustering_column_name [, ...])
• Composite partition key: Multiple columns in the partition key. Enclose the partition key columns in parenthesis. Syntax: PRIMARY KEY ((partition_column_name[, ...]),clustering_column_name [, ...])

Tunes data handling, including I/O operations, compression, and compaction. Table property options use the following syntax:

• Single values: option_name = 'value'
• Multiple values: option_name = { 'subproperty' : 'value' [, ...] } [AND ...]

  Simple JSON format, key-value pairs in a comma-separated list enclosed by curly brackets.

ALTER TABLE [keyspace_name.]table_name
WITH option_name = 'value' 
AND option_name = {option_map};

bloom_filter_fp_chance = N

False-positive probability for SSTable bloom filter. When a client requests data, the bloom filter checks if the row exists before executing disk I/O. Values range from 0 to 1.0, where: 0 is the minimum value use to enable the largest possible bloom filter (uses the most memory) and 1.0is the maximum value disabling the bloom filter.

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

Default: bloom_filter_fp_chance = '0.01'

caching = { 'keys' : 'value', 'rows_per_partition' : 'value'}

Optimizes the use of cache memory without manual tuning. Weighs the cached data by size and access frequency. Coordinate this setting with the global caching properties in the cassandra.yaml file. Valid values:

• ALL– all primary keys or rows
• NONE– no primary keys or rows
• N: (rows per partition only) – specify a whole number

Default: { 'keys': 'ALL', 'rows_per_partition': 'NONE' }

cdc = TRUE | FALSE

Creates a Change Data Capture (CDC) log on the table.

Valid values:

• TRUE- create CDC log
• FALSE- do not create CDC log

comments = 'some text that describes the table etc'

Provide documentation on the table.

Tip: Enter a description of the types of queries the table was designed to satisfy.

dclocal_read_repair_chance

Probability that a successful read operation triggers a read repair, between 0 and 1. Unlike the repair controlled by read_repair_chance, this repair is limited to replicas in the same DC as the coordinator.

Default value: 0.01

Note: In DataStax Distribution of Apache Cassandra™ (DDAC), dclocal_read_repair_chance is deprecated and should be set to 0.0.

default_time_to_live

TTL (Time To Live) in seconds, where zero is disabled. The maximum configurable value is 630720000 (20 years). Beginning in 2018, the expiration timestamp can exceed the maximum value supported by the storage engine, see the warning below. If the value is greater than zero, TTL is enabled for the entire table and an expiration timestamp is added to each column. A new TTL timestamp is calculated each time the data is updated and the row is removed after all the data expires.

Default value: 0 (disabled).

Warning: The database storage engine can only encode TTL timestamps through January 19 2038 03:14:07 UTC due to the Year 2038 problem. The TTL date overflow policy determines whether requests with expiration timestamps later than the maximum date are rejected or inserted. See -Dcassandra.expiration_date_overflow_policy=POLICY.

gc_grace_seconds

Seconds after data is marked with a tombstone (deletion marker) before it is eligible for garbage-collection. Default value: 864000. The default value allows time for the database to maximize consistency prior to deletion.

Note: Tombstoned records within the grace period are excluded from hints or batched mutations.

In a single-node cluster, this property can safely be set to zero. You can also reduce this value for tables whose data is not 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. The database 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, the database does not replay a batched mutation older than gc_grace_seconds after creation. 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 give some control of the batch replay process. The most important factors, however, are the size and scope of the batches you use.

memtable_flush_period_in_ms

Milliseconds before memtables associated with the table are flushed.

When memtable_flush_period_in_ms=0, the memtable will flush when:

• the flush threshold is met
• on shutdown
• on nodetool flush
• when commitlogs get full

Default: 0

min_index_interval

Minimum gap between index entries in the index summary. A lower min_index_interval means the index summary contains more entries from the index, which allows the database to search fewer index entries to execute a read. A larger index summary may also use more memory. The value for min_index_interval is the densest possible sampling of the index.

max_index_interval

If the total memory usage of all index summaries reaches this value, Cassandra decreases the index summaries for the coldest SSTables to the maximum set by max_index_interval. The max_index_interval is the sparsest possible sampling in relation to memory pressure.

read_repair_chance

The probability that a successful read operation triggers a read repair. Unlike the repair controlled by dclocal_read_repair_chance, this repair is not limited to replicas in the same DC as the coordinator. The value must be between 0 and 1.

Default value: 0.0

Note: In Cassandra, read_repair_chance is deprecated and should be set to 0.0.

speculative_retry

Overrides normal read timeout when read_repair_chance is not 1.0, sending another request to read. Specify the value as a number followed by a type, ms (milliseconds) or percentile. For example, speculative_retry = '3ms'.

Configures rapid read protection. Normal read requests are sent to just enough replica nodes to satisfy the consistency level. In rapid read protection, extra read requests are sent to other replicas, even after the consistency level has been met. The speculative retry property specifies the trigger for these extra read requests.

• ALWAYS: The coordinator node sends extra read requests to all other replicas after every read of that table.
• Xpercentile: Track each table's typical read latency (in milliseconds). Coordinator node retrieves the typical latency time of the table being read and calculates X percent of that figure. The coordinator sends redundant read requests if the number of milliseconds it waits without responses exceeds that calculated figure.

  For example, if the speculative_retry property for Table_A is set to 80percentile, and that table's typical latency is 60 milliseconds, the coordinator node handling a read of Table_A would send a normal read request first, and send out redundant read requests if it received no responses within 48ms, which is 80 % of 60ms.

• Nms: The coordinator node sends extra read requests to all other replicas if the coordinator node has not received any responses within N milliseconds.
• NONE: The coordinator node does not send extra read requests after any read of that table.