Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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 each application so that the applications in a single cluster have logical isolation through their respective keyspace. However, this practice may have practical limitations when it comes to managing a bulk of applications.

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

  1. Log in to the WSO2 Storage Server management console and select Add under Cassandra Keyspaces in the Main menu.
     
  2. Fill in the details and save.

    For Simple Strategy:


    For Network Topology Strategy:


    The fields in the new keyspace window are described below:   

    FieldDescription
    NameName 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 FactorFor 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.
  3. 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.
  4. 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
View keyspace information 
Anchor
ViewInfor
ViewInfor

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.

Anchor
permissions
permissions
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