Tenant Mapping to Cassandra

[Table of Contents](https://github.com/dell-oss/Doradus/wiki/Doradus Administration: Table-of-Contents) | [Previous](https://github.com/dell-oss/Doradus/wiki/Multi-Tenant Configuration) | [Next](https://github.com/dell-oss/Doradus/wiki/Single-Tenant Operation)
[Multi-Tenant Configuration](https://github.com/dell-oss/Doradus/wiki/Multi-Tenant Configuration): Tenant Mapping to Cassandra

---

Each tenant is mapped to a Cassandra keyspace, meaning a keyspace is created using the tenant name. All data and metadata are stored in ColumnFamilies within the keyspace. Three ColumnFamilies are shared by all applications owned by the tenant:

• Applications: This ColumnFamily holds metadata for all applications owned by the tenant including schemas and, for non-default tenants, tenant options.

• Tasks: This ColumnFamily holds status and synchronization records used by the Doradus Task Manager service to perform background tasks such as data aging.

• OLAP: This ColumnFamily holds data for all Doradus OLAP applications, if any, owned by the tenant.

If the tenant owns any Doradus Spider applications, data is stored in application-specific ColumnFamilies. Two kinds of ColumnFamilies are currently used for Spider applications:

• application_table: This ColumnFamily holds object data for a specific Spider application and table.

• application_table_terms: This ColumnFamily holds indexing data for a specific Spider application and table.

Each tenant possesses one or more user IDs that can be used to access applications. Each user ID is mapped to a Cassandra user, prefixed with the tenant name. For example, if the tenant named HelloKitty owns a user called Katniss, the corresponding Cassandra user ID is HelloKitty_Katniss. This allows different tenants to independently define the same user ID. In Doradus REST commands, the tenant user ID (not the Cassandra user ID) and password are provided using basic auth.

Each tenant can also define the replication factor (RF) to use for its applications. This value cannot exceed the number of underlying Cassandra nodes. RF values greater than 1 ensure that data is replicated to 2 or more nodes, thus providing high availability in case of node failure.