Cassandra Query Language (CQL) v0.99.1

Table of Contents

  1. Cassandra Query Language (CQL) v0.99.1
    1. Table of Contents
    2. USE
    3. SELECT
      1. Specifying Columns
      2. Column Family
      3. Consistency Level
      4. Filtering rows
      5. Limits
    4. UPDATE
      1. Column Family
      2. Consistency Level
      3. Specifying Columns and Row
    5. DELETE
      1. Specifying Columns
      2. Column Family
      3. Consistency Level
      4. Specifying Rows
    6. TRUNCATE
    7. CREATE KEYSPACE
    8. CREATE COLUMNFAMILY
      1. Specifying Column Type (optional)
      2. Column Family Options (optional)
    9. Common Idioms
      1. Specifying Consistency
      2. Term specification
        1. String Literals
        2. Unicode
        3. Integers / longs
        4. UUIDs

USE

Synopsis:

USE <KEYSPACE>;

A USE statement consists of the USE keyword, followed by a valid keyspace name. Its purpose is to assign the per-connection, current working keyspace. All subsequent keyspace-specific actions will be performed in the context of the supplied value.

SELECT

Synopsis:

SELECT [FIRST N] [REVERSED] <SELECT EXPR> FROM <COLUMN FAMILY> [USING <CONSISTENCY>]
        [WHERE <CLAUSE>] [LIMIT N];

A SELECT is used to read one or more records from a Cassandra column family. It returns a result-set of rows, where each row consists of a key and a collection of columns corresponding to the query.

Specifying Columns

SELECT [FIRST N] [REVERSED] name1, name2, name3 FROM ...
SELECT [FIRST N] [REVERSED] name1..nameN FROM ...

The SELECT expression determines which columns will appear in the results and takes the form of either a comma separated list of names, or a range. The range notation consists of a start and end column name separated by two periods (..). The set of columns returned for a range is start and end inclusive.

The FIRST option accepts an integer argument and can be used to apply a limit to the number of columns returned per row. When this limit is left unset it defaults to 10,000 columns.

The REVERSED option causes the sort order of the results to be reversed.

It is worth noting that unlike the projection in a SQL SELECT, there is no guarantee that the results will contain all of the columns specified. This is because Cassandra is schema-less and there are no guarantees that a given column exists.

Column Family

SELECT ... FROM <COLUMN FAMILY> ...

The FROM clause is used to specify the Cassandra column family applicable to a SELECT query.

Consistency Level

SELECT ... [USING <CONSISTENCY>] ...

Following the column family clause is an optional consistency level specification.

Filtering rows

SELECT ... WHERE KEY = keyname AND name1 = value1
SELECT ... WHERE KEY >= startkey and KEY =< endkey AND name1 = value1

The WHERE clause provides for filtering the rows that appear in results. The clause can filter on a key name, or range of keys, and in the case of indexed columns, on column values. Key filters are specified using the KEY keyword, a relational operator, (one of =, >, >=, <, and <=), and a term value. When terms appear on both sides of a relational operator it is assumed the filter applies to an indexed column. With column index filters, the term on the left of the operator is the name, the term on the right is the value to filter on.

Note: The greater-than and less-than operators (> and <) result in key ranges that are inclusive of the terms. There is no supported notion of “strictly” greater-than or less-than; these operators are merely supported as aliases to >= and <=.

Limits

SELECT ... WHERE <CLAUSE> [LIMIT N] ...

Limiting the number of rows returned can be achieved by adding the LIMIT option to a SELECT expression. LIMIT defaults to 10,000 when left unset.

UPDATE

Synopsis:

UPDATE <COLUMN FAMILY> [USING CONSISTENCY.<CL>]
        SET name1 = value1, name2 = value2 WHERE KEY = keyname;

An UPDATE is used to write one or more columns to a record in a Cassandra column family. No results are returned.

Column Family

UPDATE <COLUMN FAMILY> ...

Statements begin with the UPDATE keyword followed by a Cassandra column family name.

Consistency Level

UPDATE ... [USING <CONSISTENCY>] ...

Following the column family identifier is an optional consistency level specification.

Specifying Columns and Row

UPDATE ... SET name1 = value1, name2 = value2 WHERE KEY = keyname;

Rows are created or updated by supplying column names and values in term assignment format. Multiple columns can be set by separating the name/value pairs using commas. Each update statement requires exactly one key to be specified using a WHERE clause and the KEY keyword.

Additionally, it is also possible to send multiple UPDATES to a node at once using a batch syntax:

BEGIN BATCH [USING <CONSISTENCY>]
UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
APPLY BATCH

When batching UPDATEs, a single consistency level is used for the entire batch, it appears after the BEGIN BATCH statement, and uses the standard consistency level specification. Batch UPDATEs default to CONSISTENCY.ONE when left unspecified.

NOTE: While there are no isolation guarantees, UPDATE queries are atomic within a give record.

DELETE

Synopsis:

DELETE [COLUMNS] FROM <COLUMN FAMILY> [USING <CONSISTENCY>] WHERE KEY = keyname1
DELETE [COLUMNS] FROM <COLUMN FAMILY> [USING <CONSISTENCY>] WHERE KEY IN (keyname1, keyname2);

A DELETE is used to perform the removal of one or more columns from one or more rows.

Specifying Columns

DELETE [COLUMNS] ...

Following the DELETE keyword is an optional comma-delimited list of column name terms. When no column names are specified, the remove applies to the entire row(s) matched by the WHERE clause

Column Family

DELETE ... FROM <COLUMN FAMILY> ...

The column family name follows the list of column names.

Consistency Level

UPDATE ... [USING <CONSISTENCY>] ...

Following the column family identifier is an optional consistency level specification.

Specifying Rows

UPDATE ... WHERE KEY = keyname1
UPDATE ... WHERE KEY IN (keyname1, keyname2)

The WHERE clause is used to determine which row(s) a DELETE applies to. The first form allows the specification of a single keyname using the KEY keyword and the = operator. The second form allows a list of keyname terms to be specified using the IN notation and a parenthesized list of comma-delimited keyname terms.

TRUNCATE

Synopsis:

TRUNCATE <COLUMN FAMILY>

Accepts a single argument for the column family name, and permanently removes all data from said column family.

CREATE KEYSPACE

Synopsis:

CREATE KEYSPACE <NAME> WITH replication_factor = <NUM> AND strategy_class = "<STRATEGY>"
    [AND strategy_options.<OPTION> = <VALUE> [AND strategy_options.<OPTION> = <VALUE>]];

The CREATE KEYSPACE statement creates a new top-level namespace (aka “keyspace”). Valid names are any string constructed of alphanumeric characters and underscores, but must begin with a letter. Properties such as replication strategy and count are specified during creation using the following accepted keyword arguments:

keywordrequireddescription
replication_factoryesNumeric argument that specifies the number of replicas for this keyspace.
strategy_classyesClass name to use for managing replica placement. Any of the shipped strategies can be used by specifying the class name relative to org.apache.cassandra.locator, others will need to be fully-qualified and located on the classpath.
strategy_optionsnoSome strategies require additional arguments which can be supplied by appending the option name to the strategy_options keyword, separated by a colon (:). For example, a strategy option of “DC1” with a value of “1” would be specified as strategy_options:DC1 = "1".

CREATE COLUMNFAMILY

Synopsis:

CREATE COLUMNFAMILY <COLUMN FAMILY> [(name1 type, name2 type, ...)] [WITH keyword1 = arg1
    [AND keyword2 = arg2 [AND ...]]];

CREATE COLUMNFAMILY statements create new column family namespaces under the current keyspace. Valid column family names are strings of alphanumeric characters and underscores, which begin with a letter.

Specifying Column Type (optional)

CREATE COLUMNFAMILY <COLUMN FAMILY> (name1 type, name2 type) ...;

It is possible to assign columns a type during column family creation. Columns configured with a type are validated accordingly when a write occurs. Column types are specified as a parenthesized, comma-separated list of column term and type pairs. The list of recognized types are:

typedescription
bytesArbitrary bytes (no validation)
asciiASCII character string
utf8UTF8 encoded string
timeuuidType 1 UUID
uuidType 4 UUID
int4-byte integer
long8-byte long

Note: In addition to the recognized types listed above, it is also possible to supply a string containing the name of a class (a sub-class of AbstractType), either fully qualified, or relative to the org.apache.cassandra.db.marshal package.

Column Family Options (optional)

CREATE COLUMNFAMILY ... WITH keyword1 = arg1 AND keyword2 = arg2;

A number of optional keyword arguments can be supplied to control the configuration of a new column family.

keyworddefaultdescription
comparatorbytesDetermines sorting and validation of column names. Valid values are identical to the types listed in Specifying Column Type above.
commentnoneA free-form, human-readable comment.
row_cache_size0Number of rows whose entire contents to cache in memory.
key_cache_size200000Number of keys per SSTable whose locations are kept in memory in “mostly LRU” order.
read_repair_chance1.0The probability with which read repairs should be invoked on non-quorum reads.
gc_grace_seconds864000Time to wait before garbage collecting tombstones (deletion markers).
default_validationbytesDetermines validation of column values. Valid values are identical to the types listed in Specifying Column Type above.
min_compaction_threshold4Minimum number of SSTables needed to start a minor compaction.
max_compaction_threshold32Maximum number of SSTables allowed before a minor compaction is forced.
row_cache_save_period_in_seconds0Number of seconds between saving row caches.
key_cache_save_period_in_seconds14400Number of seconds between saving key caches.
memtable_flush_after_mins60Maximum time to leave a dirty table unflushed.
memtable_throughput_in_mbdynamicMaximum size of the memtable before it is flushed.
memtable_operations_in_millionsdynamicNumber of operations in millions before the memtable is flushed.
replicate_on_writefalse

Common Idioms

Specifying Consistency

... USING <CONSISTENCY> ...

Consistency level specifications are made up the keyword USING, followed by a consistency level identifier. Valid consistency levels are as follows:

Term specification

Where possible, the type of terms are inferred; the following term types are supported:

String Literals

String literals are any value enclosed in double-quotes, (`"`). String literals are treated as raw bytes; no interpolation is performed.

Unicode

Unicode terms are any double-quoted string prefixed with a lower-case u, for example u"© 2011 The Apache Software Foundation". Unicode terms are identical to standard string literals, with the exception that they are encoded to bytes using the UTF-8 charset.

Integers / longs

Integers are any term consisting soley of unquoted numericals, longs are any otherwise valid integer term followed by an upper case “L”, (e.g. 100L). It is an error to specify an integer term that will not fit in 4 bytes unsigned, or a long that will not fit in 8 bytes unsigned.

UUIDs

There are two types of UUIDs supported by the CQL specification, time-based (version 1) and randomly generated (version 4). These are specified in statements using the timeuuid(<UUID STRING>) and uuid(<UUID STRING>) notations respectively.

In addition to the hex-based string representation, timeuuid() terms also accept arguments to specify the data-time component. The full list of timeuuid() arguments are:

argumentexamplebehavior
nonetimeuuid()Results in the creation of a new UUID based on system time of the node parsing the query.
nowtimeuuid(“now”)Results in the creation of a new UUID based on system time of the node parsing the query.
milliseconds since epochtimeuuid(1296755320376)Creates a UUID with a time component that is based on the supplied time-stamp.
iso8601 timestamptimeuuid(“2011-02-01T14:00-0600”)Creates a UUID with a time component that is based on the supplied time-stamp.
string representation (hex)timeuuid(“e9229b24-2fbe-11e0-a4de-0026c650d722”)Reproduces the specified version 1 UUID node-side.