This documentation is for WSO2 Storage Server 1.0.3. View documentation for the latest release.
Page Comparison - Creating Keyspaces (v.6 vs v.7) - Storage Server 1.0.3 - WSO2 Documentation

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.

    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.

    • 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
    • Share
    • View Information
Share keyspace
Anchor
share
share

A user role can be selected from the Available Roles drop-down list that appears after clicking Share link.

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
  • wso2.anonymous.role: Anonymous role
View Keyspace Information 
Anchor
ViewInfor
ViewInfor

Displays general information of the keyspace such as name of the cluster, replication factor, placement strategy and endpoints.