In Cassandra, the keyspace is the container for your application data, similar to a schema in a relational database. Keyspaces are used to group column families together. Typically, a cluster has one keyspace per application.
Replication is controlled on a per-keyspace basis, so data that has different replication requirements should reside in different keyspaces. Keyspaces are not designed to be used as a significant map layer within the data model, only as a way to control data replication for a set of column families. DataStax recommends NetworkTopologyStrategy for single and multiple data center clusters because it allows for expansion to multiple data centers in the future. By configuring a flexible replication strategy in the beginning, you can avoid having to reconfigure replication later after you have loaded data into your cluster.
Data Definition Language (DDL) commands for defining and altering keyspaces are provided in the various client interfaces, such as Cassandra CLI and CQL. For example, to define a keyspace in CQL:
These examples work with pre-release CQL 3 in Cassandra 1.1.x. The syntax differs in the release version of CQL 3 in Cassandra 1.2 and later.
CREATE KEYSPACE test WITH strategy_class = 'NetworkTopologyStrategy' AND strategy_options:us-east = 6;
Or for a multiple data center cluster:
CREATE KEYSPACE test2 WITH strategy_class = 'NetworkTopologyStrategy’ AND strategy_options:DC1 = 3 AND strategy_options:DC2 = 6;
When declaring the keyspace strategy_options, use the data center names defined for the snitch that you chose for the cluster. To place replicas in the correct location, Cassandra requires a keyspace definition that uses the snitch-aware data center names. For example, if the cluster uses the PropertyFileSnitch create the keyspace using the user-defined data center and rack names in the cassandra-topologies.properties file. If the cluster uses the EC2Snitch, create the keyspace using EC2 data center and rack names. All snitches are compatible with both replica placement strategies.
For more information on DDL commands, see Querying Cassandra.