Logical Unit Storage Overview
A Logical Unit (LU) is a blueprint that holds a set of definitions / instructions used for creating and maintaining the data of a business entity such as a customer.
Fabric uses the System DB as a default Logical Unit's storage layer, where each business entity's instance is saved as a MicroDB in an entity table (and in an entity_chunks table for big LUs).
The below descriptions relate to additional storage types supported by Fabric.
Storage Types
The location of a Logical Unit's permanent storage depends on the settings of the LU Schema's Storage property. The following storage types exist:
- Default, inherits storage settings in the [fabricdb] section of the config.ini file.
- None, does not store the instance in Cassandra after a GET retrieves instance data from the source DB.
- Cassandra, stores LU instances in the Cassandra DB after the execution of the GET command.
- S3, stores LU instances in the AWS S3 Storage after the execution of the GET command. The storage connection details are defined in the [s3_storage] section of the config.ini.
- Azure Blob Store, stores LU instances in the Azure Blob Store Storage after the execution of the GET command. The storage connection details are defined in the [azure_blob_storage] section of the config.ini.
- Google Cloud Storage, stores LU instances in the Google Cloud Storage after the execution of the GET command. The storage connection details are defined in the [gcs_storage] section of the config.ini.
To display an LU's storage type, use the Fabric LIST command.
Click for more information about the LIST command.
Note that Fabric uses the Cassandra DB as a default system management database. Therefore, changing the LU Storage from Cassandra DB to one of the above storage types doesn't replace the Fabric need for other persistent storage.
Click for more information about Fabric System Database.
Starting with Fabric 8.0, it is possible to store the business entities on PostgreSQL when the use case is mostly around querying cross-entities data. For further reading, click here.
Logical Unit Storage Overview
A Logical Unit (LU) is a blueprint that holds a set of definitions / instructions used for creating and maintaining the data of a business entity such as a customer.
Fabric uses the System DB as a default Logical Unit's storage layer, where each business entity's instance is saved as a MicroDB in an entity table (and in an entity_chunks table for big LUs).
The below descriptions relate to additional storage types supported by Fabric.
Storage Types
The location of a Logical Unit's permanent storage depends on the settings of the LU Schema's Storage property. The following storage types exist:
- Default, inherits storage settings in the [fabricdb] section of the config.ini file.
- None, does not store the instance in Cassandra after a GET retrieves instance data from the source DB.
- Cassandra, stores LU instances in the Cassandra DB after the execution of the GET command.
- S3, stores LU instances in the AWS S3 Storage after the execution of the GET command. The storage connection details are defined in the [s3_storage] section of the config.ini.
- Azure Blob Store, stores LU instances in the Azure Blob Store Storage after the execution of the GET command. The storage connection details are defined in the [azure_blob_storage] section of the config.ini.
- Google Cloud Storage, stores LU instances in the Google Cloud Storage after the execution of the GET command. The storage connection details are defined in the [gcs_storage] section of the config.ini.
To display an LU's storage type, use the Fabric LIST command.
Click for more information about the LIST command.
Note that Fabric uses the Cassandra DB as a default system management database. Therefore, changing the LU Storage from Cassandra DB to one of the above storage types doesn't replace the Fabric need for other persistent storage.
Click for more information about Fabric System Database.
Starting with Fabric 8.0, it is possible to store the business entities on PostgreSQL when the use case is mostly around querying cross-entities data. For further reading, click here.
