AWS Keyspaces is one of the supported database types to be used as Fabric Operational DB.
Below are various AWS Keyspaces limitations, that can lead to re-implementation in a Fabric project, along with some suitable troubleshooting tips:
The select count(*)
and truncate table
statements are not supported. The implementation that currently uses them (when working with Cassandra) would have to be modified.
When using the AWS Keyspaces, the user management is handled by AWS. Thus, Fabric's capability to create and drop users (as it exists in Cassandra) is not supported. These activities would have to be done via the adminInitialCredentials file (which creates an admin user for the initial access only). Subsequently, the user management will be handled via the authentication server.
TTL (time-to-live) mechanism is not automatically supported in AWS keyspaces. Thus, following the table creation, it should be altered in order to activate the TTL support.
To work with AWS Keyspaces as a Fabric interface, you should define it using the Cassandra interface type and set the connection settings to AWS server. Note that QUORUM
is not supported and as a result, when defining an interface, QUORUM should be replaced with LOCAL_QUORUM
via the server connection string.
When working with Cassandra, the upper limit on a field size is 2GB, while in AWS Keyspaces it is 1 MB. Hence, when using the AWS Keyspaces, you would need to set the INSTANCE_CHUNK_SIZE in the config.ini to 990000 (or less).
INSTANCE_CHUNK_SIZE=990000
In case of LU deployment failure check the following two parameters:
When a new table is created in AWS Keyspaces, it is created, by default, with an on-demand capacity mode. This means pay-per-request pricing for read and write requests, allowing you to pay only for what you've used. If, however, you would like to define how many reads and writes per second are required for your application, you can do so by setting the AWS_TABLE_PROVISIONED parameter in the [default_session] section of the config.ini. This parameter can include a semicolon separated list of initial read and write provision values per table, using the following format: AWS_TABLE_PROVISIONED = keyspace1.table1=40,35,onDemand;keyspace2.table2=10,12
.
AWS Keyspaces supports unlogged batch commands with up to 30 commands in the batch. Only unconditional INSERT, UPDATE, or DELETE commands are permitted in a batch. Logged batches are not supported. As a result, when using a DbLoad actor, keep batch=false.
AWS Keyspaces is one of the supported database types to be used as Fabric Operational DB.
Below are various AWS Keyspaces limitations, that can lead to re-implementation in a Fabric project, along with some suitable troubleshooting tips:
The select count(*)
and truncate table
statements are not supported. The implementation that currently uses them (when working with Cassandra) would have to be modified.
When using the AWS Keyspaces, the user management is handled by AWS. Thus, Fabric's capability to create and drop users (as it exists in Cassandra) is not supported. These activities would have to be done via the adminInitialCredentials file (which creates an admin user for the initial access only). Subsequently, the user management will be handled via the authentication server.
TTL (time-to-live) mechanism is not automatically supported in AWS keyspaces. Thus, following the table creation, it should be altered in order to activate the TTL support.
To work with AWS Keyspaces as a Fabric interface, you should define it using the Cassandra interface type and set the connection settings to AWS server. Note that QUORUM
is not supported and as a result, when defining an interface, QUORUM should be replaced with LOCAL_QUORUM
via the server connection string.
When working with Cassandra, the upper limit on a field size is 2GB, while in AWS Keyspaces it is 1 MB. Hence, when using the AWS Keyspaces, you would need to set the INSTANCE_CHUNK_SIZE in the config.ini to 990000 (or less).
INSTANCE_CHUNK_SIZE=990000
In case of LU deployment failure check the following two parameters:
When a new table is created in AWS Keyspaces, it is created, by default, with an on-demand capacity mode. This means pay-per-request pricing for read and write requests, allowing you to pay only for what you've used. If, however, you would like to define how many reads and writes per second are required for your application, you can do so by setting the AWS_TABLE_PROVISIONED parameter in the [default_session] section of the config.ini. This parameter can include a semicolon separated list of initial read and write provision values per table, using the following format: AWS_TABLE_PROVISIONED = keyspace1.table1=40,35,onDemand;keyspace2.table2=10,12
.
AWS Keyspaces supports unlogged batch commands with up to 30 commands in the batch. Only unconditional INSERT, UPDATE, or DELETE commands are permitted in a batch. Logged batches are not supported. As a result, when using a DbLoad actor, keep batch=false.