Skip to content

Commit b2950df

Browse files
committed
AUTO: Sync ScalarDB docs in English to docs site repo
1 parent 772a39f commit b2950df

File tree

3 files changed

+141
-195
lines changed

3 files changed

+141
-195
lines changed

versioned_docs/version-3.13/configurations.mdx

Lines changed: 13 additions & 78 deletions
Original file line numberDiff line numberDiff line change
@@ -6,44 +6,32 @@ tags:
66
displayed_sidebar: docsEnglish
77
---
88

9-
# ScalarDB Configurations
9+
# ScalarDB Core Configurations
1010

1111
import Tabs from '@theme/Tabs';
1212
import TabItem from '@theme/TabItem';
1313

14-
This page describes the available configurations for ScalarDB.
14+
This page describes the available configurations for ScalarDB Core.
1515

16-
## ScalarDB client configurations
16+
:::tip
1717

18-
This section describes the configurations for the ScalarDB client. ScalarDB provides ways to run transactions by using Consensus Commit, run non-transactional storage operations, and run transactions through ScalarDB Cluster.
19-
20-
### Run transactions by using Consensus Commit
21-
22-
ScalarDB provides its own transaction protocol called Consensus Commit, which is the default transaction manager type in ScalarDB. To use the Consensus Commit transaction manager, add the following to the ScalarDB properties file:
23-
24-
```properties
25-
scalar.db.transaction_manager=consensus-commit
26-
```
27-
28-
:::note
29-
30-
If you don't specify the `scalar.db.transaction_manager` property, `consensus-commit` will be the default value.
18+
If you are using ScalarDB Cluster, please refer to [ScalarDB Cluster Configurations](./scalardb-cluster/scalardb-cluster-configurations.mdx) instead.
3119

3220
:::
3321

34-
#### Basic configurations
22+
## General configurations
3523

36-
The following basic configurations are available for the Consensus Commit transaction manager:
24+
The following configurations are available for the Consensus Commit transaction manager:
3725

3826
| Name | Description | Default |
3927
|-------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------|
40-
| `scalar.db.transaction_manager` | `consensus-commit` should be specified. | - |
28+
| `scalar.db.transaction_manager` | Transaction manager of ScalarDB. Specify `consensus-commit` to use [Consensus Commit](./consensus-commit.mdx) or `single-crud-operation` to [run non-transactional storage operations](./run-non-transactional-storage-operations-through-library.mdx). Note that the configurations under the `scalar.db.consensus_commit` prefix are ignored if you use `single-crud-operation`. | `consensus-commit` |
4129
| `scalar.db.consensus_commit.isolation_level` | Isolation level used for Consensus Commit. Either `SNAPSHOT` or `SERIALIZABLE` can be specified. | `SNAPSHOT` |
4230
| `scalar.db.consensus_commit.serializable_strategy` | Serializable 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` |
4331
| `scalar.db.consensus_commit.coordinator.namespace` | Namespace name of Coordinator tables. | `coordinator` |
4432
| `scalar.db.consensus_commit.include_metadata.enabled` | If set to `true`, `Get` and `Scan` operations results will contain transaction metadata. To see the transaction metadata columns details for a given table, you can use the `DistributedTransactionAdmin.getTableMetadata()` method, which will return the table metadata augmented with the transaction metadata columns. Using this configuration can be useful to investigate transaction-related issues. | `false` |
4533

46-
#### Performance-related configurations
34+
## Performance-related configurations
4735

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

@@ -65,9 +53,9 @@ The following performance-related configurations are available for the Consensus
6553
| `scalar.db.consensus_commit.coordinator.group_commit.timeout_check_interval_millis` | Interval for checking the group commit–related timeouts. | `20` |
6654
| `scalar.db.consensus_commit.coordinator.group_commit.metrics_monitor_log_enabled` | Whether or not the metrics of the group commit are logged periodically. | `false` |
6755

68-
#### Underlying storage or database configurations
56+
## Storage-related configurations
6957

70-
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.
58+
ScalarDB has a storage (database) abstraction layer that supports multiple storage implementations. You can specify the storage implementation by using the `scalar.db.storage` property.
7159

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

@@ -97,7 +85,7 @@ Select a database to see the configurations available for each storage.
9785

9886
:::note
9987

100-
#### SQLite3
88+
**SQLite3**
10189

10290
If you're using SQLite3 as a JDBC database, you must set `scalar.db.contact_points` as follows:
10391

@@ -107,7 +95,7 @@ scalar.db.contact_points=jdbc:sqlite:<SQLITE_DB_FILE_PATH>?busy_timeout=10000
10795

10896
Unlike other JDBC databases, [SQLite3 doesn't fully support concurrent access](https://www.sqlite.org/lang_transaction.html). To avoid frequent errors caused internally by [`SQLITE_BUSY`](https://www.sqlite.org/rescode.html#busy), setting a [`busy_timeout`](https://www.sqlite.org/c3ref/busy_timeout.html) parameter is recommended.
10997

110-
#### YugabyteDB
98+
**YugabyteDB**
11199

112100
If you're using YugabyteDB as a JDBC database, you can specify multiple endpoints in `scalar.db.contact_points` as follows:
113101

@@ -183,22 +171,6 @@ For non-JDBC databases, transactions could be executed at read-committed snapsho
183171
| `scalar.db.cross_partition_scan.filtering.enabled` | Enable filtering in cross-partition scan. | `false` |
184172
| `scalar.db.cross_partition_scan.ordering.enabled` | Enable ordering in cross-partition scan. | `false` |
185173

186-
### Run non-transactional storage operations
187-
188-
To run non-transactional storage operations, you need to configure the `scalar.db.transaction_manager` property to `single-crud-operation`:
189-
190-
```properties
191-
scalar.db.transaction_manager=single-crud-operation
192-
```
193-
194-
Also, you need to configure the underlying storage or database as described in [Underlying storage or database configurations](#underlying-storage-or-database-configurations).
195-
196-
### Run transactions through ScalarDB Cluster
197-
198-
[ScalarDB Cluster](scalardb-cluster/index.mdx) is a component that provides a gRPC interface to ScalarDB.
199-
200-
For details about client configurations, see the [ScalarDB Cluster client configurations](scalardb-cluster/developer-guide-for-scalardb-cluster-with-java-api.mdx#client-configurations).
201-
202174
## Other ScalarDB configurations
203175

204176
The following are additional configurations available for ScalarDB:
@@ -222,11 +194,7 @@ scalar.db.password=${env:SCALAR_DB_PASSWORD}
222194

223195
In this example configuration, ScalarDB reads the username and password from environment variables. If the environment variable `SCALAR_DB_USERNAME` does not exist, ScalarDB uses the default value `admin`.
224196

225-
## Configuration examples
226-
227-
This section provides some configuration examples.
228-
229-
### Configuration example #1 - App and database
197+
## Configuration example - App and database
230198

231199
```mermaid
232200
flowchart LR
@@ -259,36 +227,3 @@ scalar.db.contact_points=<CASSANDRA_HOST>
259227
scalar.db.username=<USERNAME>
260228
scalar.db.password=<PASSWORD>
261229
```
262-
263-
### Configuration example #2 - App, ScalarDB Cluster, and database
264-
265-
```mermaid
266-
flowchart LR
267-
app["App -<br />ScalarDB library with gRPC"]
268-
cluster["ScalarDB Cluster -<br />(ScalarDB library with<br />Consensus Commit)"]
269-
db[(Underlying storage or database)]
270-
app --> cluster --> db
271-
```
272-
273-
In this example configuration, the app (ScalarDB library with gRPC) connects to an underlying storage or database (in this case, Cassandra) through ScalarDB Cluster, which is a component that is available only in the ScalarDB Enterprise edition.
274-
275-
:::note
276-
277-
This configuration is acceptable for production use because ScalarDB Cluster implements the [Scalar Admin](https://github.com/scalar-labs/scalar-admin) interface, which enables you to take transactionally consistent backups for ScalarDB by pausing ScalarDB Cluster.
278-
279-
280-
:::
281-
282-
The following is an example of the configuration for connecting the app to the underlying database through ScalarDB Cluster:
283-
284-
```properties
285-
# Transaction manager implementation.
286-
scalar.db.transaction_manager=cluster
287-
288-
# Contact point of the cluster.
289-
scalar.db.contact_points=indirect:<SCALARDB_CLUSTER_CONTACT_POINT>
290-
```
291-
292-
For details about client configurations, see the [ScalarDB Cluster client configurations](scalardb-cluster/developer-guide-for-scalardb-cluster-with-java-api.mdx#client-configurations).
293-
294-
[^1]: It's worth benchmarking the performance with a few variations (for example, 75% and 125% of the default value) on the same underlying storage that your application uses, considering your application's access pattern, to determine the optimal configuration as it really depends on those factors. Also, it's important to benchmark combinations of these parameters (for example, first, `slot_capacity:20` and `group_size_fix_timeout_millis:40`; second, `slot_capacity:30` and `group_size_fix_timeout_millis:40`; and third, `slot_capacity:20` and `group_size_fix_timeout_millis:80`) to determine the optimal combination.

0 commit comments

Comments
 (0)