Unknown macro: {next_previous_links}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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.


    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 FactorNumber 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.
    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.

  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 

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
  • No labels