ScalarDB Core の設定
このページは英語版のページが機械翻訳されたものです。英語版 との間に矛盾または不一致がある場合は、英語版を正としてください。
このページでは、ScalarDB Core で使用可能な設定について説明します。
ScalarDB Cluster を使用している場合は、代わりに ScalarDB Cluster の設定を参照してください。
一般的な設定
ScalarDB トランザクションマネージャーでは、次の一般的な設定が利用可能です。
| 名前 | 説明 | デフォルト |
|---|---|---|
scalar.db.transaction_manager | ScalarDB のトランザクションマネージャー。Consensus Commit を使用するには consensus-commit を指定し、非トランザクションストレージ 操作を実行する には single-crud-operation を指定します。single-crud-operation を使用する場合、scalar.db.consensus_commit プレフィックスの下の設定は無視されることに注意してください。 | consensus-commit |
scalar.db.consensus_commit.isolation_level | Consensus Commit に使用される分離レベル。SNAPSHOT、SERIALIZABLE または READ_COMMITTED のいずれかを指定できます。 | SNAPSHOT |
scalar.db.consensus_commit.coordinator.namespace | Consensus Commit に使用される Coordinator テーブルの名前空間名。 | coordinator |
パフォーマンス関連の設定
Consensus Commit トランザクションマネージャーでは、次のパフォーマンス関連の設定が利用できます。
| 名前 | 説明 | デフォルト |
|---|---|---|
scalar.db.consensus_commit.parallel_executor_count | 並列実行のためのエグゼキュータ (スレッド) の数。この数値は、ScalarDB Cluster ノード内または ScalarDB プロセス内のトランザクション全体のスレッド数の合計を示します。 | 128 |
scalar.db.consensus_commit.parallel_preparation.enabled | 準備フェーズが並行して実行されるかどうか。 | true |
scalar.db.consensus_commit.parallel_validation.enabled | 検 証フェーズ (EXTRA_READ 内) が並列で実行されるかどうか。 | scalar.db.consensus_commit.parallel_commit.enabled の値 |
scalar.db.consensus_commit.parallel_commit.enabled | コミットフェーズが並列で実行されるかどうか。 | true |
scalar.db.consensus_commit.parallel_rollback.enabled | ロールバックフェーズが並列で実行されるかどうか。 | scalar.db.consensus_commit.parallel_commit.enabled の値 |
scalar.db.consensus_commit.async_commit.enabled | コミットフェーズが非同期で実行されるかどうか。 | false |
scalar.db.consensus_commit.async_rollback.enabled | ロールバックフェーズが非同期に実行されるかどうか。 | scalar.db.consensus_commit.async_commit.enabled の値 |
scalar.db.consensus_commit.parallel_implicit_pre_read.enabled | 暗黙的な事前読み取りが並列で実行されるかどうか。 | true |
scalar.db.consensus_commit.coordinator.group_commit.enabled | トランザクション状態のコミットがバッチモードで実行されるかどうか。この機能は、2フェーズコミットインターフェイスでは使用できません。 | false |
scalar.db.consensus_commit.coordinator.group_commit.slot_capacity | グループコミット機能のグループ内のスロットの最大数。値が大きいとグループコミットの効率は向上しますが、待ち時間が増加し、トランザクションの競合が発生する可能性も高くなります。[^1] | 20 |
scalar.db.consensus_commit.coordinator.group_commit.group_size_fix_timeout_millis | グループ内のスロットのサイズを固定するためのタイムアウト。値が大きいとグループコミットの効率が向上しますが、待ち時間が増加し、トランザクションの競合が発生する可能性も高くなります。[^1] | 40 |
scalar.db.consensus_commit.coordinator.group_commit.delayed_slot_move_timeout_millis | 遅延スロットをグループから別の分離グループに移動して、元のグループが遅延トランザクションの影響を受けないようにするためのタイムアウト。値が大きいとグループコミットの効率が向上しますが、待ち時間が増加し、トランザクションの競合が発生する可能性も高くなります。[^1] | 1200 |
scalar.db.consensus_commit.coordinator.group_commit.old_group_abort_timeout_millis | 進行中の古いグループをアボートするためのタイムアウト。値が小さいと、積極的なアボートによってリソースの消費量が減りますが、長時間実行されるトランザクションで不要なアボートが発生する可能性も高くなります。 | 60000 |
scalar.db.consensus_commit.coordinator.group_commit.timeout_check_interval_millis | グループコミット関連のタイムアウトをチェックする間隔。 | 20 |
scalar.db.consensus_commit.coordinator.group_commit.metrics_monitor_log_enabled | グループコミットのメトリックが定期的にログに記録されるかどうか。 | false |
ストレージ関連の設定
ScalarDB には、複数のストレージ実装をサポートするストレージ（データベース）抽象化レイヤーがあります。scalar.db.storage プロパティを使用してストレージ実装を指定できます。
データベースを選択して、各ストレージで使用可能な設定を確認します。
- JDBC データベース
- DynamoDB
- Cosmos DB for NoSQL
- Cassandra
JDBC データベースでは次の設定を使用できます。
| 名前 | 説明 | デフォルト |
|---|---|---|
scalar.db.storage | jdbc を指定する必要があります。 | - |
scalar.db.contact_points | JDBC 接続 URL。 | |
scalar.db.username | データベースにアクセスするためのユーザー名。 | |
scalar.db.password | データベースにアクセスするためのパスワード。 | |
scalar.db.jdbc.connection_pool.min_idle | 接続プール内のアイドル接続の最小数。 | 20 |
scalar.db.jdbc.connection_pool.max_idle | 接続プール内でアイドル状態のままにできる接続の最大数。 | 50 |
scalar.db.jdbc.connection_pool.max_total | 接続プールで同時にアクティブにできるアイドル接続と借用接続の最大合計数。制限がない場合は負の値を使用します。 | 200 |
scalar.db.jdbc.prepared_statements_pool.enabled | このプロパティを true に設定すると、準備済みステートメントプーリングが有効になります。 | false |
scalar.db.jdbc.prepared_statements_pool.max_open | ステートメントプールから同時に割り当てることができるオープンステートメントの最大数。制限がない場合は負の値を使用します。 | -1 |
scalar.db.jdbc.isolation_level | JDBC の分離レベル。READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ、または SERIALIZABLE を指定できます。 | 基盤データベース固有 |
scalar.db.jdbc.table_metadata.connection_pool.min_idle | テーブルメタデータの接続プール内のアイドル接続の最小数。 | 5 |
scalar.db.jdbc.table_metadata.connection_pool.max_idle | テーブルメタデータの接続プール内でアイドル状態のままにできる接続の最大数。 | 10 |
scalar.db.jdbc.table_metadata.connection_pool.max_total | テーブルメタデータの接続プールで同時にアクティブにできるアイドル接続と借用接続の最大合計数。制限がない場合は負の値を使用します。 | 25 |
scalar.db.jdbc.admin.connection_pool.min_idle | 管理者の接続プール内のアイドル接続の最小数。 | 5 |
scalar.db.jdbc.admin.connection_pool.max_idle | 管理者の接続プール内でアイドル状態のままにできる接続の最大数。 | 10 |
scalar.db.jdbc.admin.connection_pool.max_total | 管理者の接続プールで同時にアクティブにできるアイドル接続と借用接続の最大合計数。制限がない場合は負の値を使用します。 | 25 |
scalar.db.jdbc.mysql.variable_key_column_size | MySQL で主キーまたはセカンダリキーとして使用される場合の TEXT 列と BLOB 列の列サイズ。最小 64 バイト。 | 128 |
scalar.db.jdbc.oracle.variable_key_column_size | Oracle で主キーまたはセカンダリキーとして使用される場合の TEXT 列と BLOB 列の列サイズ。最小 64 バイト。 | 128 |
scalar.db.jdbc.oracle.time_column.default_date_component | Oracle で TIME データを格納するために使用される日付コンポーネントの値。Oracle には日付コンポーネントなしで時間のみを格納するデータ型がないため、ScalarDB は比較と並べ替えを容易にするために、同じ日付コンポーネント値を持つ TIME データを保存します。 | 1970-01-01 |
SQLite3
SQLite3 を JDBC データベースとして使用している場合は、scalar.db.contact_points を次のように設定する必要があります。
scalar.db.contact_points=jdbc:sqlite:<SQLITE_DB_FILE_PATH>?busy_timeout=10000
他の JDBC データベースとは異なり、SQLite3 doesn't fully support concurrent access。SQLITE_BUSY によって内部的に頻繁に発生するエラーを回避するには、busy_timeout パラメータを設定することをお勧めします。
YugabyteDB
YugabyteDB を JDBC データベースとして使用している場合は、次のように scalar.db.contact_points で複数のエンドポイントを指定できます。
scalar.db.contact_points=jdbc:yugabytedb://127.0.0.1:5433\\,127.0.0.2:5433\\,127.0.0.3:5433/?load-balance=true
複数のエンドポイントはエスケープされたコンマで区切る必要があります。
YugabyteDB のスマートドライバーと負荷分散の詳細については、YugabyteDB smart drivers for YSQL を参照してください。
DynamoDB では次の設定が利用可能です。
| 名前 | 説明 | デフォルト |
|---|---|---|
scalar.db.storage | dynamo を指定する必要があります。 | - |
scalar.db.contact_points | ScalarDB が通信する AWS リージョン (例: us-east-1)。 | |
scalar.db.username | AWS とやり取りするユーザーを識別するために使用される AWS アクセスキー。 | |
scalar.db.password | AWS と対話するユーザーを認証するために使用される AWS シークレットアクセスキー。 | |
scalar.db.dynamo.endpoint_override | ScalarDB が通信する Amazon DynamoDB エンドポイント。これは主に、AWS サービスではなくローカルインスタンスでのテストに使用されます。 | |
scalar.db.dynamo.namespace.prefix | ユーザー名前空間とメタデータ名前空間名のプレフィックス。AWS では単一の AWS リージョン内で一意のテーブル名を持つ必要があるため、単一の AWS リージョン内で複数の ScalarDB 環境 (開発、本番など) を使用する場合に便利です。 |
Cosmos DB for NoSQL では次の設定が利用可能です。
| 名前 | 説明 | デフォルト |
|---|---|---|
scalar.db.storage | cosmos を指定する必要があります。 | - |
scalar.db.contact_points | ScalarDB が通信する NoSQL エンドポイント用の Azure Cosmos DB。 | |
scalar.db.password | Azure Cosmos DB for NoSQL にアクセスするための認証を実行するために使用されるマスターキーまたは読み取り専用キーのいずれか。 | |
scalar.db.cosmos.consistency_level | Cosmos DB 操作に使用される一貫性レベル。STRONG または BOUNDED_STALENESS を指定できます。 | STRONG |
Cassandra では次の設定が利用可能です。
| 名前 | 説 明 | デフォルト |
|---|---|---|
scalar.db.storage | cassandra を指定する必要があります。 | - |
scalar.db.contact_points | カンマで区切られた連絡先。 | |
scalar.db.contact_port | すべての連絡先ポイントのポート番号。 | |
scalar.db.username | データベースにアクセスするためのユーザー名。 | |
scalar.db.password | データベースにアクセスするためのパスワード。 |
マルチストレージのサポート
ScalarDB は、複数のストレージ実装の同時使用をサポートしています。scalar.db.storage プロパティの値として multi-storage を指定することで、複数のストレージを使用できます。
複数のストレージの使用の詳細については、マルチストレージトランザクションを参照してください。
クロスパーティションスキャン設定
以下で説明するようにクロスパーティ ションスキャンオプションを有効にすると、Scan 操作でパーティション全体のすべてのレコードを取得できます。さらに、cross_partition_scan.filtering と cross_partition_scan.ordering をそれぞれ有効にすることで、クロスパーティション Scan 操作で任意の条件と順序を指定できます。現在、順序付けオプション付きのクロスパーティションスキャンは、JDBC データベースでのみ使用できます。フィルタリングと順序付けを有効にするには、scalar.db.cross_partition_scan.enabled を true に設定する必要があります。
クロスパーティションスキャンの使用方法の詳細については、Scan 操作を参照してください。
非 JDBC データベースの場合、SERIALIZABLE 分離レベルでクロスパーティションスキャンを有効にした場合でも、トランザクションは読み取りコミットスナップショット分離 (SNAPSHOT) で実行される可能性があります。これは、より低い分離レベルです。非 JDBC データベースを使用する場合は、トランザクションの一貫性が重要でない場合にのみ、クロスパーティションスキャンを使用してくださ い。
| 名前 | 説明 | デフォルト |
|---|---|---|
scalar.db.cross_partition_scan.enabled | パーティション間スキャンを有効にします。 | true |
scalar.db.cross_partition_scan.filtering.enabled | クロスパーティションスキャンでフィルタリングを有効にします。 | false |
scalar.db.cross_partition_scan.ordering.enabled | パーティション間スキャンでの順序付けを有効にします。 | false |
その他の ScalarDB 設定
ScalarDB で使用できる追加の設定は次のとおりです。
| 名前 | 説明 | デフォルト |
|---|---|---|
scalar.db.metadata.cache_expiration_time_secs | ScalarDB には、データベースへのリクエスト数を減らすためのメタデータキャッシュがあります。この設定では、キャッシュの有効期限を秒単位で指定します。-1を指定した場合は、キャッシュは期限切れになりません。 | 60 |
scalar.db.active_transaction_management.expiration_time_millis | ScalarDB は進行中のトランザクションを管理しており、トランザクション ID を使用して再開できます。この設定は、このトランザクション管理機能の有効期限をミリ秒単位で指定します。 | -1 (有効期限なし) |
scalar.db.consensus_commit.include_metadata.enabled | Consensus Commit を使用している場合に、true に設定すると、Get および Scan 操作の結果にトランザクションメタデータが含まれます。特定のテーブルのトランザクションメタデータ列の詳細を表示するには、DistributedTransactionAdmin.getTableMetadata() メソッドを使用します。このメソッドは、トランザクションメタデータ列が追加されたテーブルメタデータを返します。この設定を使用すると、トランザクション関連の問題を調査するのに役立ちます。 | false |
scalar.db.default_namespace_name | 指定された名前空間名は、名前空間を指定していない操作によって使用されます。 |
プレースホルダーの使用
値にプレースホルダーを使用できます。プレースホルダーは環境変数 (${env:<ENVIRONMENT_VARIABLE_NAME>}) またはシステムプロパティ (${sys:<SYSTEM_PROPERTY_NAME>}) に置き換えられます。また、${sys:<SYSTEM_PROPERTY_NAME>:-<DEFAULT_VALUE>} のようにプレースホルダーにデフォルト値を指定することもできます。
以下は、プレースホルダーを使用する設定の例です。
scalar.db.username=${env:SCALAR_DB_USERNAME:-admin}
scalar.db.password=${env:SCALAR_DB_PASSWORD}
この設定例では、ScalarDB は環境変数からユーザー名とパスワードを読み取ります。環境変数 SCALAR_DB_USERNAME が存在しない場合、ScalarDB はデフォルト値 admin を使用します。
設定例 - アプリとデータベース
この例の設定では、アプリ (Consensus Commit を備えた ScalarDB ライブラリ) が、基盤となるストレージまたはデータベース (この場合は Cassandra) に直接接続します。
この設定は開発目的のみに存在し、実稼働環境には適していません。これは、ScalarDB のトランザクション的に一貫性のあるバックアップを取得するために、アプリが Scalar Admin インターフェースを実装する必要があり、追加の設定が必要になるためです。
以下は、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>