AUTO: Sync ScalarDB docs in Japanese to docs site repo

Author: josh-wong

i18n/versioned_docs/ja-jp/docusaurus-plugin-content-docs/current/add-scalardb-to-your-build.mdx

@@ -3,6 +3,7 @@ tags:
   - Community
   - Enterprise Standard
   - Enterprise Premium
+displayed_sidebar: docsJapanese
 ---
 
 # ビルドに ScalarDB を追加する

i18n/versioned_docs/ja-jp/docusaurus-plugin-content-docs/current/api-guide.mdx

@@ -3,6 +3,7 @@ tags:
   - Community
   - Enterprise Standard
   - Enterprise Premium
+displayed_sidebar: docsJapanese
 ---
 
 # ScalarDB Java API ガイド
@@ -46,7 +47,7 @@ admin.close();
 
 ### 名前空間を作成する
 
-テーブルは 1 つの名前空間に属するため、テーブルを作成する前に名前空間を作成する必要があります。
+テーブルは1つの名前空間に属するため、テーブルを作成する前に名前空間を作成する必要があります。
 
 名前空間は次のように作成できます。
 
@@ -404,7 +405,7 @@ DistributedTransaction transaction = transactionManager.start("<TRANSACTION_ID>"
 
 トランザクション ID を指定すると、外部システムを ScalarDB にリンクする場合に便利です。それ以外の場合は、`begin()` メソッドまたは `start()` メソッドを使用する必要があります。
 
-トランザクション ID を指定する場合は、ScalarDB の正確性はトランザクション ID の一意性に依存するため、システム全体で一意の ID (UUID v4 など) を指定してください。
+トランザクション ID を指定する場合は、ScalarDB の正確性はトランザクション ID の一意性に依存するため、システム全体で一意の ID (UUID v4など) を指定してください。
 
 :::
 
@@ -480,7 +481,7 @@ Key key3 = Key.ofDouble("col1", 1.3d);
 Key key4 = Key.ofText("col1", "value");
 ```
 
-2～5 列で設定されるキーの場合は、`Key.of()` メソッドを使用して次のようにキーを構築できます。Guava の `ImmutableMap.of()` と同様に、列名と値を順番に指定する必要があります。
+2～5列で設定されるキーの場合は、`Key.of()` メソッドを使用して次のようにキーを構築できます。Guava の `ImmutableMap.of()` と同様に、列名と値を順番に指定する必要があります。
 
 ```java
 // For a key that consists of two to five columns.
@@ -490,7 +491,7 @@ Key key3 = Key.of("col1", 1, "col2", 100L, "col3", 1.3d, "col4", "value");
 Key key4 = Key.of("col1", 1, "col2", 100L, "col3", 1.3d, "col4", "value", "col5", false);
 ```
 
-5 列を超えるキーの場合は、ビルダーを使用して次のようにキーを構築できます。
+5列を超えるキーの場合は、ビルダーを使用して次のようにキーを構築できます。
 
 ```java
 // For a key that consists of more than five columns.
@@ -506,7 +507,7 @@ Key key = Key.newBuilder()
 
 ##### `Get` 操作
 
-`Get` は、プライマリーキーで指定された単一のレコードを取得する操作です。
+`Get` は、主キーで指定された単一のレコードを取得する操作です。
 
 まず `Get` オブジェクトを作成し、次に次のように `transaction.get()` メソッドを使用してオブジェクトを実行する必要があります。
 
@@ -808,11 +809,11 @@ List<Result> results = transaction.scan(scan);
 
 :::note
 
-`Put` 操作は ScalarDB 3.13 以降では非推奨となり、将来のリリースでは削除される予定です。`Put` 操作の代わりに、`Insert` 操作、`Upsert` 操作、または `Update` 操作を使用してください。
+`Put` 操作は ScalarDB 3.13以降では非推奨となり、将来のリリースでは削除される予定です。`Put` 操作の代わりに、`Insert` 操作、`Upsert` 操作、または `Update` 操作を使用してください。
 
 :::
 
-`Put` は、プライマリーキーで指定されたレコードを配置する操作です。この操作はレコードの upsert 操作として動作し、レコードが存在する場合はレコードを更新し、レコードが存在しない場合はレコードを挿入します。
+`Put` は、主キーで指定されたレコードを配置する操作です。この操作はレコードの upsert 操作として動作し、レコードが存在する場合はレコードを更新し、レコードが存在しない場合はレコードを挿入します。
 
 :::note
 
@@ -957,7 +958,7 @@ transaction.update(update);
 
 ##### `Delete` 操作
 
-`Delete` は、プライマリーキーで指定されたレコードを削除する操作です。
+`Delete` は、主キーで指定されたレコードを削除する操作です。
 
 :::note
 
@@ -986,7 +987,7 @@ transaction.delete(delete);
 
 ##### 条件付きの `Put`、`Delete`、`Update`
 
-トランザクション内で条件をチェックするロジックを実装することで、コミット前にトランザクションが満たす必要のある任意の条件 (たとえば、銀行口座の残高が 0 以上である必要がある) を記述できます。または、`Put`、`Delete`、`Update` などのミューテーション操作で単純な条件を記述することもできます。
+トランザクション内で条件をチェックするロジックを実装することで、コミット前にトランザクションが満たす必要のある任意の条件 (たとえば、銀行口座の残高が0以上である必要がある) を記述できます。または、`Put`、`Delete`、`Update` などのミューテーション操作で単純な条件を記述することもできます。
 
 `Put`、`Delete`、`Update` 操作に条件が含まれている場合、指定された条件が満たされた場合にのみ操作が実行されます。操作の実行時に条件が満たされていない場合は、`UnsatisfiedConditionException` という例外がスローされます。
 
@@ -1195,7 +1196,7 @@ ScalarDB で例外を処理する方法の詳細については、[例外の処
 
 #### `Get` 操作を実行する
 
-`Get` は、プライマリーキーで指定された単一のレコードを取得する操作です。
+`Get` は、主キーで指定された単一のレコードを取得する操作です。
 
 最初に `Get` オブジェクトを作成し、次に次のように `transactionManager.get()` メソッドを使用してオブジェクトを実行する必要があります。
 
@@ -1253,7 +1254,7 @@ List<Result> results = transactionManager.scan(scan);
 
 :::note
 
-`Put` 操作は ScalarDB 3.13 以降では非推奨となり、将来のリリースでは削除される予定です。`Put` 操作の代わりに、`Insert` 操作、`Upsert` 操作、または `Update` 操作を使用してください。
+`Put` 操作は ScalarDB 3.13以降では非推奨となり、将来のリリースでは削除される予定です。`Put` 操作の代わりに、`Insert` 操作、`Upsert` 操作、または `Update` 操作を使用してください。
 
 :::
 
@@ -1363,7 +1364,7 @@ transactionManager.update(update);
 
 #### `Delete` 操作を実行する
 
-`Delete` は、プライマリーキーで指定されたレコードを削除する操作です。
+`Delete` は、主キーで指定されたレコードを削除する操作です。
 
 まず `Delete` オブジェクトを作成し、次に次のように `transaction.delete()` メソッドを使用してオブジェクトを実行する必要があります。
 
@@ -1556,15 +1557,15 @@ CRUD 操作の API (`get()`、`scan()`、`put()`、`delete()`、および `mutat
 
 :::note
 
-サンプルコードでは、トランザクションは最大 3 回再試行され、再試行される前に 100 ミリ秒間スリープします。ただし、アプリケーションの要件に応じて、指数バックオフなどの再試行ポリシーを選択できます。
+サンプルコードでは、トランザクションは最大3回再試行され、再試行される前に100ミリ秒間スリープします。ただし、アプリケーションの要件に応じて、指数バックオフなどの再試行ポリシーを選択できます。
 
 :::
 
 ## Coordinator テーブルのグループコミット
 
 Consensus Commit トランザクションに使用される Coordinator テーブルは重要なデータストアであり、堅牢なストレージを使用することをお勧めします。ただし、内部でマルチ AZ またはマルチリージョンレプリケーションを活用するなど、より堅牢なストレージオプションを使用すると、ストレージにレコードを書き込むときにレイテンシが増加し、スループットパフォーマンスが低下する可能性があります。
 
-ScalarDB は、Coordinator テーブルにグループコミット機能を提供します。この機能は、複数のレコードの書き込みを 1 つの書き込み操作にグループ化し、書き込みスループットを向上させます。この場合、基盤となるデータベースとワークロードに応じて、レイテンシが増加または減少する可能性があります。
+ScalarDB は、Coordinator テーブルにグループコミット機能を提供します。この機能は、複数のレコードの書き込みを1つの書き込み操作にグループ化し、書き込みスループットを向上させます。この場合、基盤となるデータベースとワークロードに応じて、レイテンシが増加または減少する可能性があります。
 
 グループコミット機能を有効にするには、次の設定を追加します。
 
@@ -1603,11 +1604,11 @@ scalar.db.consensus_commit.coordinator.group_commit.enabled=true
    logger.info("The transaction state: {}", manager.getState(transaction.getId()));
 ```
 
-#### 2 フェーズコミットインターフェースでの使用の禁止
+#### 2フェーズコミットインターフェースでの使用の禁止
 
-グループコミット機能は、進行中のすべてのトランザクションをメモリ内で管理します。この機能が 2 フェーズコミットインターフェースで有効になっている場合、Coordinator テーブルへの参加者サービスの一貫性のない書き込みによって生じる競合 (グループ間で異なるトランザクション分散が含まれる場合があります) を防ぐために、情報は Coordinator サービスによってのみ維持される必要があります。
+グループコミット機能は、進行中のすべてのトランザクションをメモリ内で管理します。この機能が2フェーズコミットインターフェースで有効になっている場合、Coordinator テーブルへの参加者サービスの一貫性のない書き込みによって生じる競合 (グループ間で異なるトランザクション分散が含まれる場合があります) を防ぐために、情報は Coordinator サービスによってのみ維持される必要があります。
 
-この制限により、アプリケーション開発に関連する複雑さと柔軟性が損なわれます。したがって、グループコミット機能と 2 フェーズコミットインターフェースを組み合わせて使用​​することは現在禁止されています。
+この制限により、アプリケーション開発に関連する複雑さと柔軟性が損なわれます。したがって、グループコミット機能と2フェーズコミットインターフェースを組み合わせて使用​​することは現在禁止されています。
 
 ## Consensus Commit トランザクションマネージャーエラーの調査
 

i18n/versioned_docs/ja-jp/docusaurus-plugin-content-docs/current/backup-restore.mdx

@@ -3,6 +3,7 @@ tags:
   - Community
   - Enterprise Standard
   - Enterprise Premium
+displayed_sidebar: docsJapanese
 ---
 
 # ScalarDB で使用されるデータベースのバックアップと復元方法
@@ -40,7 +41,7 @@ flowchart TD
 
 :::
 
-ScalarDB でバックアップを作成するための要件の 1 つは、ScalarDB が管理するすべてのテーブル (Coordinator テーブルを含む) のバックアップがトランザクション的に一貫しているか、トランザクション的に一貫した状態に自動的に回復可能である必要があることです。つまり、すべてのテーブルを 1 回のトランザクションでダンプして、一貫性のあるバックアップを作成する必要があります。
+ScalarDB でバックアップを作成するための要件の1つは、ScalarDB が管理するすべてのテーブル (Coordinator テーブルを含む) のバックアップがトランザクション的に一貫しているか、トランザクション的に一貫した状態に自動的に回復可能である必要があることです。つまり、すべてのテーブルを1回のトランザクションでダンプして、一貫性のあるバックアップを作成する必要があります。
 
 トランザクション的に一貫性のあるバックアップを作成する方法は、使用しているデータベースの種類によって異なります。データベースを選択して、ScalarDB のトランザクション的に一貫性のあるバックアップを作成する方法を確認してください。
 
@@ -81,7 +82,7 @@ ScalarDB でバックアップを作成するための要件の 1 つは、Scala
 
 PITR 機能を使用する場合は、NTP などのクロック同期を使用して、クライアントとサーバー間のクロックのずれを最小限に抑える必要があります。そうしないと、一時停止期間として取得される時間が、一時停止が実際に行われた時間と大きく異なる可能性があり、バックアップが進行中のトランザクションが存在する時点に復元される可能性があります。
 
-また、クロック同期ではノード間のクロックを完全に同期できないため、十分な時間 (たとえば、5 秒) 一時停止し、一時停止期間の中間時間を復元ポイントとして使用する必要があります。
+また、クロック同期ではノード間のクロックを完全に同期できないため、十分な時間 (たとえば、5秒) 一時停止し、一時停止期間の中間時間を復元ポイントとして使用する必要があります。
 
 :::
 
@@ -109,7 +110,7 @@ ScalarDB が未処理のリクエストを排出し、新しいリクエスト
     トランザクション的に一貫性のある復元ポイントを指定するには、[明示的に一時停止してバックアップする](#明示的に一時停止してバックアップする)の説明に従って、ScalarDB を Cosmos DB for NoSQL とともに使用しているアプリケーションを一時停止します。
   </TabItem>
   <TabItem value="Cassandra" label="Cassandra" default>
-    Cassandra にはレプリケーション機能が組み込まれているため、必ずしもトランザクション的に一貫性のあるバックアップを作成する必要はありません。たとえば、レプリケーション係数が `3` に設定されていて、Cassandra クラスター内のノードの 1 つのデータのみが失われた場合、通常のトランザクション的に一貫性のないバックアップ (スナップショット) と修復機能を使用してノードを回復できるため、トランザクション的に一貫性のあるバックアップ (スナップショット) は必要ありません。
+    Cassandra にはレプリケーション機能が組み込まれているため、必ずしもトランザクション的に一貫性のあるバックアップを作成する必要はありません。たとえば、レプリケーション係数が `3` に設定されていて、Cassandra クラスター内のノードの1つのデータのみが失われた場合、通常のトランザクション的に一貫性のないバックアップ (スナップショット) と修復機能を使用してノードを回復できるため、トランザクション的に一貫性のあるバックアップ (スナップショット) は必要ありません。
 
     ただし、クラスターノードのクォーラムでデータが失われた場合は、クラスターを特定のトランザクション的に一貫性のあるポイントに復元するために、トランザクション的に一貫性のあるバックアップ (スナップショット) が必要になります。
 
@@ -160,7 +161,7 @@ ScalarDB が未処理のリクエストを排出し、新しいリクエスト
 
 :::note
 
-* テーブルは一度に 1 つしか復元できないため、上記の手順はテーブルごとに実行する必要があります。
+* テーブルは一度に1つしか復元できないため、上記の手順はテーブルごとに実行する必要があります。
 * 復元されたテーブルでは、PITR や自動スケーリングポリシーなどの設定がデフォルト値にリセットされるため、必要な設定を手動で行う必要があります。詳細については、公式 AWS ドキュメントの [DynamoDB を使用した DynamoDB テーブルのバックアップと復元の仕組み](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/CreateBackup.html#CreateBackup_HowItWorks-restore)を参照してください。
 
 :::