Following the column family clause is an optional consistency level specification.
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 <=.
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.
Synopsis:
UPDATE <COLUMN FAMILY> [USING CONSISTENCY.<CL>]
+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.
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.
UPDATE <COLUMN FAMILY> ...
Statements begin with the UPDATE keyword followed by a Cassandra column family name.
UPDATE ... [USING <CONSISTENCY>] ...
@@ -34,4 +34,4 @@ UPDATE ... WHERE KEY IN (keyname1, keyname2)
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:
| type | description |
|---|---|
| bytes | Arbitrary bytes (no validation) |
| ascii | ASCII character string |
| utf8 | UTF8 encoded string |
| timeuuid | Type 1 UUID |
| uuid | Type 4 UUID |
| int | 4-byte integer |
| long | 8-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.
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.
| keyword | default | description |
|---|---|---|
| comparator | bytes | Determines sorting and validation of column names. Valid values are identical to the types listed in Specifying Column Type above. |
| comment | none | A free-form, human-readable comment. |
| row_cache_size | 0 | Number of rows whose entire contents to cache in memory. |
| key_cache_size | 200000 | Number of keys per SSTable whose locations are kept in memory in “mostly LRU” order. |
| read_repair_chance | 1.0 | The probability with which read repairs should be invoked on non-quorum reads. |
| gc_grace_seconds | 864000 | Time to wait before garbage collecting tombstones (deletion markers). |
| default_validation | bytes | Determines validation of column values. Valid values are identical to the types listed in Specifying Column Type above. |
| min_compaction_threshold | 4 | Minimum number of SSTables needed to start a minor compaction. |
| max_compaction_threshold | 32 | Maximum number of SSTables allowed before a minor compaction is forced. |
| row_cache_save_period_in_seconds | 0 | Number of seconds between saving row caches. |
| key_cache_save_period_in_seconds | 14400 | Number of seconds between saving key caches. |
| memtable_flush_after_mins | 60 | Maximum time to leave a dirty table unflushed. |
| memtable_throughput_in_mb | dynamic | Maximum size of the memtable before it is flushed. |
| memtable_operations_in_millions | dynamic | Number of operations in millions before the memtable is flushed. |
| replicate_on_write | false |
Synopsis:
CREATE INDEX [index_name] ON <column_family> (column_name);
A CREATE INDEX statement is used to create a new, automatic secondary index for the named column.
... USING <CONSISTENCY> ...
-Consistency level specifications are made up the keyword USING, followed by a consistency level identifier. Valid consistency levels are as follows:
CONSISTENCY.ZEROCONSISTENCY.ONE (default)CONSISTENCY.QUORUMCONSISTENCY.ALLCONSISTENCY.DCQUORUMCONSISTENCY.DCQUORUMSYNCWhere possible, the type of terms are inferred; the following term types are supported:
String literals are any value enclosed in double-quotes, (`"`). String literals are treated as raw bytes; no interpolation is performed.
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 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.
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:
| argument | example | behavior |
|---|---|---|
| none | timeuuid() | Results in the creation of a new UUID based on system time of the node parsing the query. |
| now | timeuuid(“now”) | Results in the creation of a new UUID based on system time of the node parsing the query. |
| milliseconds since epoch | timeuuid(1296755320376) | Creates a UUID with a time component that is based on the supplied time-stamp. |
| iso8601 timestamp | timeuuid(“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. |