Creating Keyspaces

Conceptually similar to a database in relational database management systems, a keyspace in Cassandra is a logical namespace for a group of Cassandra Column Families. Just as a relational database contains multiple tables, a Cassandra Keyspace contains multiple Column Families. A keyspace typically has a name and a set of attributes to define its behavior as described below when creating a keyspace.

A single Cassandra cluster can contain multiple keyspace. The recommended best practice is to use one keyspace per application so that the applications in a single cluster are logically isolated through their respective keyspaces. However, this practice may have practical limitations when it comes to managing a bulk of applications.

Note that as a user, you need to be assigned to a role with the relevant authority in order to create or edit keyspaces. The Admin user is by default granted authority to perform this task. See more information about managing users and roles.

Follow the instructions below to add/delete keyspaces using the Management Console.

Log in to the WSO2 Storage Server management console and select Add under Cassandra Keyspaces in the Main menu.

Fill in the details and save.

For Simple Strategy:

For Network Topology Strategy:

The fields in the new keyspace window are described below:

Field	Description
Name	Name of the keyspace. This field is mandatory. The name "system" is reserved for Cassandra internals.
Replication Placement Strategy	Replica placement strategy determines how the keyspace data copies are placed in the Cassandra cluster, which nodes carry copies of which keys etc. We have the 'Simple' Strategy, 'Old Network Topology' Strategy and 'Network Topology' Strategy.
Replication Factor	For Simple Strategy: Number of replicas (additional copies) of keyspace data stored in a Cassandra cluster. For example, if replication factor is set to 2, then 2 nodes in the cluster will have copies of keyspace data and this replication is transparent to the clients. The replication factor should not exceed the number of nodes in the cluster. For Network Topology Strategy: Number of replicas (additional copies) of keyspace data stored in each Data Center in a Cassandra cluster. For example, in a particular Data Center, if replication factor is set to 2, then 2 nodes in that Data Center will have copies of keyspace data and this replication is transparent to the clients. The replication factor should not exceed the number of nodes in that particular Data Center.

The added keyspace is listed under Keyspaces.
Storage Server has the system keyspace by default. It is the metadata table used by Cassandra server, and users are not allowed to modify it.
You can perform the following operations on the newly-added custom keyspace.
- Set Permissions
- Edit: Takes you back to step 2 above to change keyspace information
- Delete: Allows to delete the keyspace. Once executed, this operation cannot be undone

Note that when a cassandra keyspace is created, followed by column families in that keyspace, you can use the tenant user credentials (user@tenant.com) to log in to that cassandra server.

View keyspace information

You can view information about the keyspace by clicking on its name. This displays general information of the keyspace such as name of the cluster, name of the keyspace, replication factor, placement strategy and endpoints.

Set permissions

Permissions can be provided for the roles available in the keyspace by selecting the relevant checkboxes under Permission.

For more information on creating user roles, refer to Creating a User Role. The following roles are available by default:

Admin: Tenant administrator role
everyone: Default tenant user role