Cassandra Keyspaces for Fabric
Fabric uses the Cassandra DB as a storage layer and also as a Fabric application management database.
Fabric creates several keyspaces for its operation:
- Each Fabric keyspace starts with the k2 prefix.
- Each deployed LU creates an additional k2view_[LU Name] Cassandra keyspace. For example: k2view_customer.
Notes:
- When set in the node.id configuration file, the cluster_id is concatenated to each keyspace name. For example: if the cluster_id is set to crm1, the keyspace k2view_customer_crm1 is created.
- When a Fabric project is opened in the Fabric Studio, it creates the keyspaces of the project in the Cassandra debug server and concatenates the project name to the keyspace name.
- A k2view_k2_ws keyspace is created for deployed WS.
Login Cassandra DB
Use the following command to connect to the Cassandra DB from the Cassandra server:
cqlsh -u <username> -p <password>
Note that if the ip_address is not populated, the login command connects to the local host of the Fabric server.
List of Cassandra Fabric-Related Keyspaces
The following table lists the Cassandra keyspaces created by Fabric:
|
Keyspace Name |
Keyspace Description |
Keyspace Tables |
|
|
k2system |
Fabric main system keyspace. |
Table Name |
Table Description |
|
k2_lut_info
|
Holds the metadata of the LUs, Common (reference) tables and Web Services deployed to Fabric. |
||
|
k2_jobs
|
Holds information on the execution of all Fabric jobs. |
||
|
nodes
|
List of all Fabric nodes in the cluster. |
||
|
global_settings |
List of all Globals and Environments whose default value has been overidden using the SET_GLOBAL command. This table is used to identify the overridden value of Globals or Environments when restarting Fabric. |
||
|
k2auth |
Fabric security and credentials keyspace |
Table Name |
Table Description |
|
user_credentials |
List of Fabric users and their assigned roles. |
||
|
roles |
List of role definitions. |
||
|
credentials |
List of tokens with assigned roles. The tokens are encrypted. |
||
|
permissions |
List of permissions for a given role. |
||
|
stripe_key_storage |
Holds encrypted information about the master key. This table contains the key description, index, and value fields. The Master Key is broken into bytes, where each byte is stored in a separate record. Click for more information about Fabric Security Hardening. |
||
|
keys_descriptions |
Holds a description of the master key. |
||
|
k2batchprocess |
Fabric batch processes information |
Table Name |
Table Description |
|
batchprocess_list |
List of the entire history of the batch process commands. |
||
|
batchprocess_node_info
|
Summary of handled entities per batch process per node. |
||
|
batchprocess_entities_info |
Detailed information about an execution of a given entity per batch process command. |
||
|
batchprocess_entities_errors |
Detailed information about failed entities per batch process command. This table simplifies the analysis of failed entities. |
||
|
k2audit |
Fabric auditing |
Table Name |
Table Description |
|
k2_auditing |
Saves all activities performed on Fabric, when AUDIT is set to ON in the config.ini file. |
||
|
k2staging |
Staging tables for IIDFinder mechanism: A different set of caching, delta, solo and orphans’ tables is created for each LU that is synchronized by the IIDFinder (proactive sync) mechanism.
|
||
|
K2view_<LU Name> |
A new keyspace is created for each deployed LU. Note that when deploying the LU to Fabric debug server, Fabric also concatenates the Fabric version and the project name to the keyspace of each LU. For example: k2view_test_cust_6_2_kb_fabric_project. |
Table Name |
Table Description |
|
entity |
Stores the list of all LUIs and their MicroDB. |
||
|
entity_chunks |
Stores large LUIs. The MicroDB of a Large LUI is divided into chunks and stored in entity_chunks. |
||
Click for more information about Fabric Architecture overview.
Cassandra Keyspaces for Fabric
Fabric uses the Cassandra DB as a storage layer and also as a Fabric application management database.
Fabric creates several keyspaces for its operation:
- Each Fabric keyspace starts with the k2 prefix.
- Each deployed LU creates an additional k2view_[LU Name] Cassandra keyspace. For example: k2view_customer.
Notes:
- When set in the node.id configuration file, the cluster_id is concatenated to each keyspace name. For example: if the cluster_id is set to crm1, the keyspace k2view_customer_crm1 is created.
- When a Fabric project is opened in the Fabric Studio, it creates the keyspaces of the project in the Cassandra debug server and concatenates the project name to the keyspace name.
- A k2view_k2_ws keyspace is created for deployed WS.
Login Cassandra DB
Use the following command to connect to the Cassandra DB from the Cassandra server:
cqlsh -u <username> -p <password>
Note that if the ip_address is not populated, the login command connects to the local host of the Fabric server.
List of Cassandra Fabric-Related Keyspaces
The following table lists the Cassandra keyspaces created by Fabric:
|
Keyspace Name |
Keyspace Description |
Keyspace Tables |
|
|
k2system |
Fabric main system keyspace. |
Table Name |
Table Description |
|
k2_lut_info
|
Holds the metadata of the LUs, Common (reference) tables and Web Services deployed to Fabric. |
||
|
k2_jobs
|
Holds information on the execution of all Fabric jobs. |
||
|
nodes
|
List of all Fabric nodes in the cluster. |
||
|
global_settings |
List of all Globals and Environments whose default value has been overidden using the SET_GLOBAL command. This table is used to identify the overridden value of Globals or Environments when restarting Fabric. |
||
|
k2auth |
Fabric security and credentials keyspace |
Table Name |
Table Description |
|
user_credentials |
List of Fabric users and their assigned roles. |
||
|
roles |
List of role definitions. |
||
|
credentials |
List of tokens with assigned roles. The tokens are encrypted. |
||
|
permissions |
List of permissions for a given role. |
||
|
stripe_key_storage |
Holds encrypted information about the master key. This table contains the key description, index, and value fields. The Master Key is broken into bytes, where each byte is stored in a separate record. Click for more information about Fabric Security Hardening. |
||
|
keys_descriptions |
Holds a description of the master key. |
||
|
k2batchprocess |
Fabric batch processes information |
Table Name |
Table Description |
|
batchprocess_list |
List of the entire history of the batch process commands. |
||
|
batchprocess_node_info
|
Summary of handled entities per batch process per node. |
||
|
batchprocess_entities_info |
Detailed information about an execution of a given entity per batch process command. |
||
|
batchprocess_entities_errors |
Detailed information about failed entities per batch process command. This table simplifies the analysis of failed entities. |
||
|
k2audit |
Fabric auditing |
Table Name |
Table Description |
|
k2_auditing |
Saves all activities performed on Fabric, when AUDIT is set to ON in the config.ini file. |
||
|
k2staging |
Staging tables for IIDFinder mechanism: A different set of caching, delta, solo and orphans’ tables is created for each LU that is synchronized by the IIDFinder (proactive sync) mechanism.
|
||
|
K2view_<LU Name> |
A new keyspace is created for each deployed LU. Note that when deploying the LU to Fabric debug server, Fabric also concatenates the Fabric version and the project name to the keyspace of each LU. For example: k2view_test_cust_6_2_kb_fabric_project. |
Table Name |
Table Description |
|
entity |
Stores the list of all LUIs and their MicroDB. |
||
|
entity_chunks |
Stores large LUIs. The MicroDB of a Large LUI is divided into chunks and stored in entity_chunks. |
||
Click for more information about Fabric Architecture overview.
