CREATE KEYSPACE

Creates a keyspace with keyspace options.

Keyspaces are the first schema objects you create in Cassandra-based databases.

Keyspaces are containers for all lower schema objects, including tables, user-defined types, materialized views, and indexes.

Synopsis

CREATE KEYSPACE [ IF NOT EXISTS ] <keyspace_name>
  WITH REPLICATION = { <replication_map> }
  [ AND DURABLE_WRITES = ( true | false ) ]
  [ AND graph_engine = 'Core' ] ;

Legend
Syntax conventions	Description
UPPERCASE	Literal keyword.
Lowercase	Not literal.
`< >`	Variable value. Replace with a user-defined value.
`[]`	Optional. Square brackets (`[]`) surround optional command arguments. Do not type the square brackets.
`( )`	Group. Parentheses ( `( )` ) identify a group to choose from. Do not type the parentheses.
`\|`	Or. A vertical bar (`\|`) separates alternative elements. Type any one of the elements. Do not type the vertical bar.
`...`	Repeatable. An ellipsis ( `...` ) indicates that you can repeat the syntax element as often as required.
`'<Literal string>'`	Single quotation (`'`) marks must surround literal strings in CQL statements. Use single quotation marks to preserve upper case.
`{ <key> : <value> }`	Map collection. Braces (`{ }`) enclose map collections or key value pairs. A colon separates the key and the value.
`<<datatype1>,<datatype2>>`	Set, list, map, or tuple. Angle brackets ( `< >` ) enclose data types in a set, list, map, or tuple. Separate the data types with a comma.
`<cql_statement>;`	End CQL statement. A semicolon (`;`) terminates all CQL statements.
`[--]`	Separate the command line options from the command arguments with two hyphens ( `--` ). This syntax is useful when arguments might be mistaken for command line options.
`' <<schema\> ... </schema\>> '`	Search CQL only: Single quotation marks (`'`) surround an entire XML schema declaration.
`@<xml_entity>='<xml_entity_type>'`	Search CQL only: Identify the entity and literal value to overwrite the XML element in the schema and solrConfig files.

Options

Option Description Default

keyspace_name

Name of the keyspace to create.

The following rules apply to keyspace names:

Cannot exceed 222 characters.
Can contain only letters, numbers, and underscores.
Must start with a letter or number.
Converted to lowercase unless enclosed in double quotes, such as "Cassandra".
Cannot be changed after creating the keyspace.

IF NOT EXISTS

Allows silent skip by checking for existing keyspaces with the same name. If a match is found, the operation silently does nothing (no error is thrown). If no match is found, the operation creates the keyspace.

Not set. If a keyspace with the same name already exists, an error occurs and the operation fails.

WITH REPLICATION

A map of replication strategy and factor settings. Determines how many copies of the data are stored in a given datacenter. This setting impacts consistency, availability, and latency. For more information, see Data replication.

The class key is required.

The SimpleStrategy class requires the replication_factor key. It must be a whole integer between 1 and the number of nodes in the cluster. Typically it is set to an odd number. Assign the same replication factor to the entire cluster. Not recommended for production use.

The NetworkTopologyStrategy class requires a comma-separated list of datacenter names and replication factors. Datacenter names are case sensitive and must match the snitch DC name.

For examples, see Examples.

[IMPORTANT] ==== Use only replication strategy implementations included with your database. ====

DURABLE_WRITES

Non-default configuration not recommended.

If false, requests bypass the commit log when writing to the keyspace.

Never disable durable writes when using SimpleStrategy replication.

true

graph_engine

Optional. Use to treat a Cassandra keyspace as a graph. Only the Core engine is supported. Don’t use the Classic engine.

Examples

Use the SimpleStrategy class

Create a keyspace on a single-node cluster with the SimpleStrategy class:

CREATE KEYSPACE IF NOT EXISTS cycling
WITH REPLICATION = {
  'class' : 'SimpleStrategy',
  'replication_factor' : 1
};

Use the NetworkTopologyStrategy class

With the NetworkTopologyStrategy, you provide a list of datacenters with individual replication factors, instead of a single replication factor for the entire cluster.

You cannot insert data into a table in a keyspace that uses NetworkTopologyStrategy unless you define the datacenter names in the snitch properties file.

Verify the spelling of the datacenter name before using this command because datacenter names are case-sensitive and must match the names configured in the snitch properties file.

Use nodetool status to get the names of the datacenters:

nodetool status

The datacenter name is on the line before the node status table:

Datacenter: datacenter1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens       Owns    Host ID                               Rack
UN  10.200.181.134  4.97 MiB   1            ?       c9027497-011c-4390-ae59-e4ed1ac794cc  rack1
UN  10.200.181.135  5.16 MiB   1            ?       af2af8ec-5fa2-4a04-ac9c-c75669d8d3a0  rack1

Create a keyspace, specifying the keyspace name, replication class, and a comma-separated list of datacenters and replication factors:

CREATE KEYSPACE IF NOT EXISTS cycling
  WITH REPLICATION = {
    'class' : 'NetworkTopologyStrategy',
    'datacenter1': '3',
    'datacenter2': '3'
  };

Create a keyspace for a graph

Create a keyspace to use for graph data:

CREATE KEYSPACE food_cql
  WITH REPLICATION = {
    'class' : 'SimpleStrategy',
    'replication_factor': 1
  }
  AND graph_engine = 'Core';

Use a keyspace

After you create a keyspace, set it as your active keyspace with the USE command. Once set, you can run CQL commands against it without specifying the keyspace name in every command.

CREATE KEYSPACE

Synopsis

Options

Examples

Use a keyspace

See also

Was this helpful?

Give Feedback