Difference between revisions of "Keystone-schema-in-cassandra"
(→Identity) |
|||
| Line 116: | Line 116: | ||
====assignment==== | ====assignment==== | ||
| − | + | Table in MySql | |
| + | {| class="wikitable" | ||
| + | |- | ||
| + | ! scope="col"| type | ||
| + | ! scope="col"| actor_id | ||
| + | ! scope="col"| target_id | ||
| + | ! scope="col"| role_id | ||
| + | |- | ||
| + | ! scope="row" colspan="4"| PK->(type, actor_id, target_id, role_id) | ||
| + | |} | ||
| + | |||
| + | The equivalent in Cassandra is | ||
| + | {| class="wikitable" | ||
| + | |+ assignment | ||
| + | |- | ||
| + | ! scope="col"| type | ||
| + | ! scope="col"| actor_id | ||
| + | ! scope="col"| target_id | ||
| + | ! scope="col"| role_id | ||
| + | |- | ||
| + | ! scope="row" colspan="4"| PK->(type, actor_id, target_id, role_id) | ||
| + | |} | ||
There are a lot of operations in this backend. All the operations are not written here for brevity. This table would be modelled with three tables in Cassandra. The first table looks similar to the MySQL table and the partition key would be (type, actor_id). There would be two additional table wherein the partition key would be target_id and role_id. These two tables are needed because when a project or role is deleted, all its role assignments should also be deleted. So index/search by role_id and project_id is needed. | There are a lot of operations in this backend. All the operations are not written here for brevity. This table would be modelled with three tables in Cassandra. The first table looks similar to the MySQL table and the partition key would be (type, actor_id). There would be two additional table wherein the partition key would be target_id and role_id. These two tables are needed because when a project or role is deleted, all its role assignments should also be deleted. So index/search by role_id and project_id is needed. | ||
Revision as of 09:13, 27 April 2015
The Cassandra tables for each of the backend in Keystone is described below.
Identity
The identity backend of Keystone holds data for users, groups and user-group membership. There are three tables in relational db for holding this data.
- user
- group
- user_group_membership
user
Table in MySql
| id | domain_id | name | enabled | password | extra | default_project_id |
|---|---|---|---|---|---|---|
| PK->(id), UK->(domain_id, name) | ||||||
The equivalent of this table in Cassandra is two tables.
| id | domain_id | name | enabled | password | extra | default_project_id |
|---|---|---|---|---|---|---|
| PK->(id) | ||||||
| domain_id | name | id |
|---|---|---|
| PK->(domain_id, name) | ||
- create_user(user_id, user)
- delete_user(user_id)
- update_user(domain_id, user_id, user)
- get_user(user_id)
- get_user_by_name(domain_id, name)
- list_users(domain_id)
From the operations it is evident that the data for user is queried on either (domain_id), or (domain_id, name) or (user_id). Based on this information, the equivalent of this table in Cassandra would consist of two tables. All the insert, update and delete for user table goes to these two table.
group
The group table is similar to user except few fields such as password and default_project_id. This table can be designed the same way as user.
user_group_membership
Table in MySql
| user_id | group_id |
|---|---|
| PK->(user_id, group_id), K->(group_id) | |
The equivalent in Cassandra is
| user_id | group_id |
|---|---|
| PK->(user_id, group_id) | |
| group_id | user_id |
|---|---|
| PK->(group_id, user_id) | |
- add_user_to_group(user_id, group_id)
- check_user_in_group(user_id, group_id)
- remove_user_from_group(user_id, group_id)
- list_users_in_group(group_id)
- list_groups_for_user(group_id)
There are two types of operations here. One is based on user_id and another is based on group_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.
Assignment
The assignment backend holds about the role assignments. It additionally has a role_backend which stores data for all the roles. There are two tables in relational db for this backend.
- assignment
- role
assignment
Table in MySql
| type | actor_id | target_id | role_id |
|---|---|---|---|
| PK->(type, actor_id, target_id, role_id) | |||
The equivalent in Cassandra is
| type | actor_id | target_id | role_id |
|---|---|---|---|
| PK->(type, actor_id, target_id, role_id) | |||
There are a lot of operations in this backend. All the operations are not written here for brevity. This table would be modelled with three tables in Cassandra. The first table looks similar to the MySQL table and the partition key would be (type, actor_id). There would be two additional table wherein the partition key would be target_id and role_id. These two tables are needed because when a project or role is deleted, all its role assignments should also be deleted. So index/search by role_id and project_id is needed.
