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.12/configurations.mdx
+16-70Lines changed: 16 additions & 70 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,44 +5,32 @@ tags:
5
5
- Enterprise Premium
6
6
---
7
7
8
-
# ScalarDB Configurations
8
+
# ScalarDB Core Configurations
9
9
10
10
importTabsfrom'@theme/Tabs';
11
11
importTabItemfrom'@theme/TabItem';
12
12
13
-
This page describes the available configurations for ScalarDB.
13
+
This page describes the available configurations for ScalarDB Core.
14
14
15
-
## ScalarDB client configurations
15
+
:::tip
16
16
17
-
ScalarDB provides its own transaction protocol called Consensus Commit. You can use the Consensus Commit protocol directly through the ScalarDB client library or through [ScalarDB Cluster](scalardb-cluster/index.mdx), which is a component that is available only in the ScalarDB Enterprise edition.
18
-
19
-
### Use Consensus Commit directly
20
-
21
-
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:
22
-
23
-
```properties
24
-
scalar.db.transaction_manager=consensus-commit
25
-
```
26
-
27
-
:::note
28
-
29
-
If you don't specify the `scalar.db.transaction_manager` property, `consensus-commit` will be the default value.
17
+
If you are using ScalarDB Cluster, please refer to [ScalarDB Cluster Configurations](./scalardb-cluster/scalardb-cluster-configurations.mdx) instead.
30
18
31
19
:::
32
20
33
-
#### Basic configurations
21
+
##General configurations
34
22
35
-
The following basic configurations are available for the Consensus Commit transaction manager:
23
+
The following configurations are available for the Consensus Commit transaction manager:
|`scalar.db.transaction_manager`|`consensus-commit`should be specified. | -|
27
+
|`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`|
40
28
|`scalar.db.consensus_commit.isolation_level`| Isolation level used for Consensus Commit. Either `SNAPSHOT` or `SERIALIZABLE` can be specified. |`SNAPSHOT`|
41
29
|`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`|
42
30
|`scalar.db.consensus_commit.coordinator.namespace`| Namespace name of Coordinator tables. |`coordinator`|
43
31
|`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`|
44
32
45
-
####Performance-related configurations
33
+
## Performance-related configurations
46
34
47
35
The following performance-related configurations are available for the Consensus Commit transaction manager:
48
36
@@ -57,9 +45,9 @@ The following performance-related configurations are available for the Consensus
57
45
|`scalar.db.consensus_commit.async_rollback.enabled`| Whether or not the rollback phase is executed asynchronously. | The value of `scalar.db.consensus_commit.async_commit.enabled`|
58
46
|`scalar.db.consensus_commit.parallel_implicit_pre_read.enabled`| Whether or not implicit pre-read is executed in parallel. |`true`|
59
47
60
-
#### Underlying storage or database configurations
48
+
##Storage-related configurations
61
49
62
-
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.
50
+
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.
63
51
64
52
Select a database to see the configurations available for each storage.
65
53
@@ -89,14 +77,13 @@ Select a database to see the configurations available for each storage.
89
77
90
78
:::note
91
79
92
-
If you use SQLite3 as a JDBC database, you must set `scalar.db.contact_points` as follows.
80
+
If you're using SQLite3 as a JDBC database, you must set `scalar.db.contact_points` as follows:
Unlike other JDBC databases, [SQLite3 does not fully support concurrent access](https://www.sqlite.org/lang_transaction.html).
99
-
To avoid frequent errors caused internally by [`SQLITE_BUSY`](https://www.sqlite.org/rescode.html#busy), we recommend setting a [`busy_timeout`](https://www.sqlite.org/c3ref/busy_timeout.html) parameter.
86
+
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.
100
87
101
88
:::
102
89
</TabItem>
@@ -143,21 +130,15 @@ ScalarDB supports using multiple storage implementations simultaneously. You can
143
130
144
131
For details about using multiple storages, see [Multi-Storage Transactions](multi-storage-transactions.mdx).
145
132
146
-
###Use Consensus Commit through ScalarDB Cluster
133
+
##### Cross-partition scan configurations
147
134
148
-
[ScalarDB Cluster](scalardb-cluster/index.mdx) is a component that provides a gRPC interface to ScalarDB.
149
-
150
-
For details about client configurations, see the [ScalarDB Cluster client configurations](scalardb-cluster/developer-guide-for-scalardb-cluster-with-java-api.mdx#client-configurations).
151
-
152
-
## Cross-partition scan configurations
153
-
154
-
By enabling the cross-partition scan option below, the `Scan` operation can retrieve all records across partitions. In addition, you can specify arbitrary conditions and orderings in the cross-partition `Scan` operation by enabling `cross_partition_scan.filtering` and `cross_partition_scan.ordering`, respectively. Currently, the cross-partition scan with filtering and ordering is available only for JDBC databases. To enable filtering and ordering, `scalar.db.cross_partition_scan.enabled` must be set to `true`.
135
+
By enabling the cross-partition scan option as described below, the `Scan` operation can retrieve all records across partitions. In addition, you can specify arbitrary conditions and orderings in the cross-partition `Scan` operation by enabling `cross_partition_scan.filtering` and `cross_partition_scan.ordering`, respectively. Currently, the cross-partition scan with ordering option is available only for JDBC databases. To enable filtering and ordering, `scalar.db.cross_partition_scan.enabled` must be set to `true`.
155
136
156
137
For details on how to use cross-partition scan, see [Scan operation](./api-guide.mdx#scan-operation).
157
138
158
139
:::warning
159
140
160
-
For non-JDBC databases, we do not recommend enabling cross-partition scan with the `SERIALIAZABLE` isolation level because transactions could be executed at a lower isolation level (that is, `SNAPSHOT`). When using non-JDBC databases, use cross-partition scan at your own risk only if consistency does not matter for your transactions.
141
+
For non-JDBC databases, transactions could be executed at read-committed snapshot isolation (`SNAPSHOT`), which is a lower isolation level, even if you enable cross-partition scan with the `SERIALIZABLE` isolation level. When using non-JDBC databases, use cross-partition scan only if consistency does not matter for your transactions.
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`.
192
173
193
-
## Configuration examples
194
-
195
-
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.
242
-
243
-
:::note
244
-
245
-
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.
246
-
247
-
248
-
:::
249
-
250
-
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).
0 commit comments