Skip to main content
Version: 3.7

ScalarDB Configurations

This page describes the available configurations for ScalarDB.

ScalarDB client configurations

ScalarDB provides its own transaction protocol called Consensus Commit. You can use the Consensus Commit protocol directly through the ScalarDB client library or through the gRPC-based ScalarDB Server, which is a daemon process that manages ScalarDB transactions.

Use Consensus Commit directly

Consensus Commit is the default transaction manager type in ScalarDB. To use the Consensus Commit transaction manager, add the following to the ScalarDB properties file:

scalar.db.transaction_manager=consensus-commit
note

If you don't specify the scalar.db.transaction_manager property, consensus-commit will be the default value.

Basic configurations

The following basic configurations are available for the Consensus Commit transaction manager:

NameDescriptionDefault
scalar.db.transaction_managerconsensus-commit should be specified.-
scalar.db.consensus_commit.isolation_levelIsolation level used for Consensus Commit. Either SNAPSHOT or SERIALIZABLE can be specified.SNAPSHOT
scalar.db.consensus_commit.serializable_strategySerializable strategy used for Consensus Commit. Either EXTRA_READ or EXTRA_WRITE can be specified. If SNAPSHOT is specified in the property scalar.db.consensus_commit.isolation_level, this configuration will be ignored.EXTRA_READ
scalar.db.consensus_commit.coordinator.namespaceNamespace name of Coordinator tables.coordinator

The following performance-related configurations are available for the Consensus Commit transaction manager:

NameDescriptionDefault
scalar.db.consensus_commit.parallel_executor_countNumber of executors (threads) for parallel execution.128
scalar.db.consensus_commit.parallel_preparation.enabledWhether or not the preparation phase is executed in parallel.true
scalar.db.consensus_commit.parallel_validation.enabledWhether or not the validation phase (in EXTRA_READ) is executed in parallel.The value of scalar.db.consensus_commit.parallel_commit.enabled
scalar.db.consensus_commit.parallel_commit.enabledWhether or not the commit phase is executed in parallel.true
scalar.db.consensus_commit.parallel_rollback.enabledWhether or not the rollback phase is executed in parallel.The value of scalar.db.consensus_commit.parallel_commit.enabled
scalar.db.consensus_commit.async_commit.enabledWhether or not the commit phase is executed asynchronously.false
scalar.db.consensus_commit.async_rollback.enabledWhether or not the rollback phase is executed asynchronously.The value of scalar.db.consensus_commit.async_commit.enabled

Underlying storage or database configurations

Consensus Commit has a storage abstraction layer and supports multiple underlying storages. You can specify the storage implementation by using the scalar.db.storage property.

Select a database to see the configurations available for each storage.

The following configurations are available for Cassandra:

NameDescriptionDefault
scalar.db.storagecassandra must be specified.-
scalar.db.contact_pointsComma-separated contact points.
scalar.db.contact_portPort number for all the contact points.
scalar.db.usernameUsername to access the database.
scalar.db.passwordPassword to access the database.
Multi-storage support

ScalarDB supports using multiple storage implementations simultaneously. You can use multiple storages by specifying multi-storage as the value for the scalar.db.storage property.

For details about using multiple storages, see Multi-Storage Transactions.

Use Consensus Commit through ScalarDB Server

ScalarDB Server is a standalone server that provides a gRPC interface to ScalarDB. To interact with ScalarDB Server, you must add the following to the ScalarDB properties file:

scalar.db.transaction_manager=grpc

The following configurations are available for the gRPC transaction manager for ScalarDB Server:

NameDescriptionDefault
scalar.db.transaction_managergrpc should be specified.-
scalar.db.contact_pointsScalarDB Server host.
scalar.db.contact_portPort number for ScalarDB Server.60051
scalar.db.grpc.deadline_duration_millisThe deadline duration for gRPC connections in milliseconds.60000 (60 seconds)
scalar.db.grpc.max_inbound_message_sizeThe maximum message size allowed for a single gRPC frame.The gRPC default value.
scalar.db.grpc.max_inbound_metadata_sizeThe maximum size of metadata allowed to be received.The gRPC default value.

For details about ScalarDB Server, see ScalarDB Server.

ScalarDB Server configurations

ScalarDB Server is a standalone server that provides a gRPC interface to ScalarDB. This section explains ScalarDB Server configurations.

In addition to the configurations when using Consensus Commit directly and other ScalarDB configurations, the following configurations are available for ScalarDB Server:

NameDescriptionDefault
scalar.db.server.portPort number for ScalarDB Server.60051
scalar.db.server.prometheus_exporter_portPrometheus exporter port. Prometheus exporter will not be started if a negative number is given.8080
scalar.db.server.grpc.max_inbound_message_sizeThe maximum message size allowed to be received.The gRPC default value.
scalar.db.server.grpc.max_inbound_metadata_sizeThe maximum size of metadata allowed to be received.The gRPC default value.

For details about ScalarDB Server, see ScalarDB Server.

Other ScalarDB configurations

The following are additional configurations available for ScalarDB:

NameDescriptionDefault
scalar.db.metadata.cache_expiration_time_secsScalarDB has a metadata cache to reduce the number of requests to the database. This setting specifies the expiration time of the cache in seconds.-1 (no expiration)

Configuration examples

This section provides some configuration examples.

Configuration example #1 - App and database

In this example configuration, the app (ScalarDB library with Consensus Commit) connects to an underlying storage or database (in this case, Cassandra) directly.

warning

This configuration exists only for development purposes and isn’t suitable for a production environment. This is because the app needs to implement the Scalar Admin interface to take transactionally consistent backups for ScalarDB, which requires additional configurations.

The following is an example of the configuration for connecting the app to the underlying database through ScalarDB:

# Transaction manager implementation.
scalar.db.transaction_manager=consensus-commit

# Storage implementation.
scalar.db.storage=cassandra

# Comma-separated contact points.
scalar.db.contact_points=<CASSANDRA_HOST>

# Credential information to access the database.
scalar.db.username=<USERNAME>
scalar.db.password=<PASSWORD>

Configuration example #2 - App, ScalarDB Server, and database

In this example configuration, the app (ScalarDB library with gRPC) connects to an underlying storage or database (in this case, Cassandra) through ScalarDB Server.

note

This configuration is acceptable for production use because ScalarDB Server implements the Scalar Admin interface, which enables you to take transactionally consistent backups for ScalarDB by pausing ScalarDB Server.

The following is an example of the configuration for connecting the app to the underlying database through ScalarDB Server:

# Transaction manager implementation.
scalar.db.transaction_manager=grpc

# ScalarDB Server host.
scalar.db.contact_points=<SCALARDB_SERVER_HOST>

# ScalarDB Server port.
scalar.db.contact_port=<SCALARDB_SERVER_PORT>