Jump to: navigation, search

Difference between revisions of "Keystone-schema-in-cassandra"

m (The user Table)
m (The group table)
Line 68: Line 68:
 
|}
 
|}
  
Keeping the equivalent data in Cassandra is done similarly to what was done with the user table, i.e., with two Cassandra tables as follows.  
+
The operations pertaining to this table rely on being able to efficiently access data given one of the following sets of columns: (domain_id), (domain_id, name), (id). Keeping the equivalent data in Cassandra is done similarly to what was done with the user table, i.e., with two Cassandra tables as follows.  
  
 
{| class="wikitable"
 
{| class="wikitable"

Revision as of 07:25, 30 April 2015

Introduction

The purpose of this wiki article is to describe the Cassandra tables for each of the backends of Keystone. A discussion of the general concepts related to schema design in Cassandra has been covered separately.

Identity

The identity backend of Keystone holds data for users, groups and user-group membership. There are three tables in the MySQL DB for this purpose.

  • user
  • group
  • user_group_membership

The user Table

The user table in MySQL is as follows.

user
id domain_id name enabled password extra default_project_id
Primary Key: (id), Unique Key: (domain_id, name)

The operations pertaining to this table rely on being able to efficiently access data given one of the following sets of columns: (domain_id), (domain_id, name), (id). The equivalent operations in Cassandra are supported by the following two tables.

user
id domain_id name enabled password extra default_project_id
Primary Key: (id)
user_name_index
domain_id name id
Primary Key: (domain_id, name)

The group table

The group table in MySQL is similar to the user table, and is as follows.

group
id domain_id name extra description
Primary Key: (id), Unique Key: (domain_id, name)

The operations pertaining to this table rely on being able to efficiently access data given one of the following sets of columns: (domain_id), (domain_id, name), (id). Keeping the equivalent data in Cassandra is done similarly to what was done with the user table, i.e., with two Cassandra tables as follows.

group
id domain_id name extra description
Primary Key: (id)
group_name_index
domain_id name id
Primary Key: (domain_id, name)

The user_group_membership Table

The user_group_membership table used in MySQL is as follows.

user_group_membership
user_id group_id
Primary Key: (user_id, group_id), Key: (group_id)

The operation pertaining to this table are based on columns [(user_id), (user_id, group_id), (group_id), (group_id, user_id)]. So there are two tables in Cassandra to store user_group_membership. All the insert, update and delete go to both the tables in Cassandra.

user_group
user_id group_id
Primary Key: (user_id, group_id); clustering column: group_id
group_user
group_id user_id
Primary Key: (group_id, user_id); clustering column: user_id

Assignment

The assignment backend holds data about the role assignments. It additionally has a "role backend" which stores data for all the roles. There are two tables in the MySQL DB.

  • assignment
  • role

The assignment Table

The assignment table in MySQL is as follows.

type actor_id target_id role_id inherited
Primary Key: (type, actor_id, target_id, role_id), Key: (actor_id), Key: (role_id)

The operation pertaining to this table are based on columns [(type, actor_id, target_id, role_id), (type, actor_id, target_id), (actor_id), (target_id), (role_id)]. This table looks the same in Cassandra. Additionaly there are two secondary index on columns target_id and role_id. These would come handy when a role_id or target_id is deleted from Keystone.

Note: Since HMT feature is not included in this schema design, the inherited column has been omitted from the Cassandra design.

assignment
type actor_id target_id role_id
Primary Key: (type, actor_id, target_id, role_id), Secondary Indices: (target_id) and (role_id)


The role Table

The role table in MySQL is as follows.

role
id name extra
Primary Key: (id), Unique Key: (name)

Most of the operations on this table are done based on role_id. There is an api in v2.0 which allows the client to get a role by its name. So we need the name to id mapping in second table. To preserve the uniqueness of the name, a row is first inserted to the role_name_index table. If that succeeds then the row is inserted to the role table. The equivalent in Cassandra is two tables.

role
id name extra
Primary Key: (id)
role_name_index
name id
Primary Key: (name)

Resource

The resource backend holds data about projects and domains. There are two tables in this backend.

  • project
  • domain

The project Table

The project table in MySQL is as follows.

project
id domain_id name enabled description extra parent_id
Primary Key:(id), Unique Key: (domain_id, name), Key: (parent_id)

The operations pertaining to this table are based on columns [(id), (domain_id), (domain_id, name)]. Currently, this design does not account for Hierarchical Multi Tenancy, which will be accounted for later. If we leave out the parent_id part in this table, then this table looks exactly similar to user table and also is modeled exactly the same.

project
id domain_id name enabled extra description
Primary Key: (id)
project_name_index
domain_id name id
Primary Key: (domain_id, name)

The domain Table

The domain table in MySQL is as follows.

domain
id name extra
Primary Key: (id), Unique Key: (name)

The operations on this table are based on columns [(id)]. These operations are supported by following tables in Cassandra.

domain
id name extra
Primary Key: (id)
domain_name_index
name id
Primary Key: (name)

Credential

The Credential backend holds data related to EC2 credentials. It has one table.

The credential Table

The credential table in MySQL is as follows.

credential
id user_id project_id blob type extra
Primary Key: (id)

The operations pertaining to this table are based on columns [(id), (user_id), (project_id)]. These operations are supported by the following Cassandra table. Additionally as an optimization later, secondary indices can be created on columns user_id and project_id.

credential
id user_id project_id blob type extra
Primary Key: (id)

Trust

The Trust backend stores data related to trust delegation functionality offered to users.

The trust Table

The trust table in MySQL is as follows.

trust
id trustor_user_id trustee_user_id project_id impersonation deleted_at expires_at remaining_uses extra roles
Primary Key: (id)

This table has the same schema in Cassandra as well.