You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: versioned_docs/version-3.13/configurations.mdx
+13-78Lines changed: 13 additions & 78 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,44 +6,32 @@ tags:
6
6
displayed_sidebar: docsEnglish
7
7
---
8
8
9
-
# ScalarDB Configurations
9
+
# ScalarDB Core Configurations
10
10
11
11
importTabsfrom'@theme/Tabs';
12
12
importTabItemfrom'@theme/TabItem';
13
13
14
-
This page describes the available configurations for ScalarDB.
14
+
This page describes the available configurations for ScalarDB Core.
15
15
16
-
## ScalarDB client configurations
16
+
:::tip
17
17
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.
31
19
32
20
:::
33
21
34
-
#### Basic configurations
22
+
##General configurations
35
23
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:
|`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`|
41
29
|`scalar.db.consensus_commit.isolation_level`| Isolation level used for Consensus Commit. Either `SNAPSHOT` or `SERIALIZABLE` can be specified. |`SNAPSHOT`|
42
30
|`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`|
43
31
|`scalar.db.consensus_commit.coordinator.namespace`| Namespace name of Coordinator tables. |`coordinator`|
44
32
|`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`|
45
33
46
-
####Performance-related configurations
34
+
## Performance-related configurations
47
35
48
36
The following performance-related configurations are available for the Consensus Commit transaction manager:
49
37
@@ -65,9 +53,9 @@ The following performance-related configurations are available for the Consensus
65
53
|`scalar.db.consensus_commit.coordinator.group_commit.timeout_check_interval_millis`| Interval for checking the group commit–related timeouts. |`20`|
66
54
|`scalar.db.consensus_commit.coordinator.group_commit.metrics_monitor_log_enabled`| Whether or not the metrics of the group commit are logged periodically. |`false`|
67
55
68
-
#### Underlying storage or database configurations
56
+
##Storage-related configurations
69
57
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.
71
59
72
60
Select a database to see the configurations available for each storage.
73
61
@@ -97,7 +85,7 @@ Select a database to see the configurations available for each storage.
97
85
98
86
:::note
99
87
100
-
#### SQLite3
88
+
**SQLite3**
101
89
102
90
If you're using SQLite3 as a JDBC database, you must set `scalar.db.contact_points` as follows:
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.
109
97
110
-
#### YugabyteDB
98
+
**YugabyteDB**
111
99
112
100
If you're using YugabyteDB as a JDBC database, you can specify multiple endpoints in `scalar.db.contact_points` as follows:
113
101
@@ -183,22 +171,6 @@ For non-JDBC databases, transactions could be executed at read-committed snapsho
183
171
|`scalar.db.cross_partition_scan.filtering.enabled`| Enable filtering in cross-partition scan. |`false`|
184
172
|`scalar.db.cross_partition_scan.ordering.enabled`| Enable ordering in cross-partition scan. |`false`|
185
173
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`:
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
-
202
174
## Other ScalarDB configurations
203
175
204
176
The following are additional configurations available for ScalarDB:
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`.
224
196
225
-
## Configuration examples
226
-
227
-
This section provides some configuration examples.
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:
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