Skip to content

Commit af3d6c5

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

File tree

3 files changed

+257
-143
lines changed

3 files changed

+257
-143
lines changed

versioned_docs/version-3.12/configurations.mdx

Lines changed: 16 additions & 70 deletions
Original file line numberDiff line numberDiff line change
@@ -5,44 +5,32 @@ tags:
55
- Enterprise Premium
66
---
77

8-
# ScalarDB Configurations
8+
# ScalarDB Core Configurations
99

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

13-
This page describes the available configurations for ScalarDB.
13+
This page describes the available configurations for ScalarDB Core.
1414

15-
## ScalarDB client configurations
15+
:::tip
1616

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.
3018

3119
:::
3220

33-
#### Basic configurations
21+
## General configurations
3422

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:
3624

3725
| Name | Description | Default |
3826
|-------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------|
39-
| `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` |
4028
| `scalar.db.consensus_commit.isolation_level` | Isolation level used for Consensus Commit. Either `SNAPSHOT` or `SERIALIZABLE` can be specified. | `SNAPSHOT` |
4129
| `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` |
4230
| `scalar.db.consensus_commit.coordinator.namespace` | Namespace name of Coordinator tables. | `coordinator` |
4331
| `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` |
4432

45-
#### Performance-related configurations
33+
## Performance-related configurations
4634

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

@@ -57,9 +45,9 @@ The following performance-related configurations are available for the Consensus
5745
| `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` |
5846
| `scalar.db.consensus_commit.parallel_implicit_pre_read.enabled` | Whether or not implicit pre-read is executed in parallel. | `true` |
5947

60-
#### Underlying storage or database configurations
48+
## Storage-related configurations
6149

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.
6351

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

@@ -89,14 +77,13 @@ Select a database to see the configurations available for each storage.
8977

9078
:::note
9179

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:
9381

9482
```properties
9583
scalar.db.contact_points=jdbc:sqlite:<SQLITE_DB_FILE_PATH>?busy_timeout=10000
9684
```
9785

98-
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.
10087

10188
:::
10289
</TabItem>
@@ -143,21 +130,15 @@ ScalarDB supports using multiple storage implementations simultaneously. You can
143130

144131
For details about using multiple storages, see [Multi-Storage Transactions](multi-storage-transactions.mdx).
145132

146-
### Use Consensus Commit through ScalarDB Cluster
133+
##### Cross-partition scan configurations
147134

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`.
155136

156137
For details on how to use cross-partition scan, see [Scan operation](./api-guide.mdx#scan-operation).
157138

158139
:::warning
159140

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.
161142

162143
:::
163144

@@ -190,11 +171,7 @@ scalar.db.password=${env:SCALAR_DB_PASSWORD}
190171

191172
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`.
192173

193-
## Configuration examples
194-
195-
This section provides some configuration examples.
196-
197-
### Configuration example #1 - App and database
174+
## Configuration example - App and database
198175

199176
```mermaid
200177
flowchart LR
@@ -227,34 +204,3 @@ scalar.db.contact_points=<CASSANDRA_HOST>
227204
scalar.db.username=<USERNAME>
228205
scalar.db.password=<PASSWORD>
229206
```
230-
231-
### Configuration example #2 - App, ScalarDB Cluster, and database
232-
233-
```mermaid
234-
flowchart LR
235-
app["App -<br />ScalarDB library with gRPC"]
236-
cluster["ScalarDB Cluster -<br />(ScalarDB library with<br />Consensus Commit)"]
237-
db[(Underlying storage or database)]
238-
app --> cluster --> db
239-
```
240-
241-
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:
251-
252-
```properties
253-
# Transaction manager implementation.
254-
scalar.db.transaction_manager=cluster
255-
256-
# Contact point of the cluster.
257-
scalar.db.contact_points=indirect:<SCALARDB_CLUSTER_CONTACT_POINT>
258-
```
259-
260-
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

Comments
 (0)