ScalarDB Java API ガイド
このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。
ScalarDB Java API は、主に管理 API とトランザクション API で設定されています。このガイドでは、どのような種類の API が存在 するのか、それらの使用方法、例外の処理方法などの関連トピックについて簡単に説明します。
Administrative API
このセクションでは、ScalarDB の管理 API を使用してプログラムで管理操作を実行する方法について説明します。
管理操作を実行する別の方法は、Schema Loader を使用することです。
DistributedTransactionAdmin インスタンスを取得する
管理操作を実行するには、まず DistributedTransactionAdmin インスタンスを取得する必要があります。
DistributedTransactionAdmin インスタンスを取得するには、次のように TransactionFactory を使用します。
TransactionFactory transactionFactory = TransactionFactory.create("<CONFIGURATION_FILE_PATH>");
DistributedTransactionAdmin admin = transactionFactory.getTransactionAdmin();
設定の詳細については、ScalarDB 設定を参照してください。
すべての管理操作を実行したら、次のように DistributedTransactionAdmin インスタンスを閉じる必要があります。
admin.close();
名前空間を作成する
テーブルは1つの名前空間に属するため、テーブルを作成する前に名前空間を作成する必要があります。
名前空間は次のように作成できます。
// Create the namespace "ns". If the namespace already exists, an exception will be thrown.
admin.createNamespace("ns");
// Create the namespace only if it does not already exist.
boolean ifNotExists = true;
admin.createNamespace("ns", ifNotExists);
// Create the namespace with options.
Map<String, String> options = ...;
admin.createNamespace("ns", options);
作成オプション
名前空間の作成操作では、オプション名と値のマップであるオプション (Map<String, String>) を指定できます。オプションを使用すると、ストレージアダプタ固有の設定ができます。
データベースを選択して、使用可能なオプションを確認します。
- JDBC データベース
- DynamoDB
- Cosmos DB for NoSQL
- Cassandra
- Object Storage
使用可能なオプションはありません。
使用可能なオプションはありません。
| 名前 | 説明 | デフォルト |
|---|---|---|
| ru | 基本リソース単位。 | 400 |
| no-scaling | Cosmos DB for NoSQL の自動スケーリングを無効にします。 | false |
| 名前 | 説明 | デフォルト |
|---|---|---|
| replication-strategy | Cassandra レプリケーション戦略。SimpleStrategy または NetworkTopologyStrategy である必要があります。 | SimpleStrategy |
| replication-factor | Cassandra の複製係数。 | 1 |
使用可能なオプションはありません。
テーブルを作成する
テーブルを作成するときは、テーブルメタデータを定義してからテーブルを作成する必要があります。
テーブルメタデータを定義するには、TableMetadata を使用できます。次の図は、テーブルの列、パーティションキー、クラスタリングキー (クラスタリング順序を含む)、およびセカンダリインデックスを定義する方法を示しています。
// Define the table metadata.
TableMetadata tableMetadata =
TableMetadata.newBuilder()
.addColumn("c1", DataType.INT)
.addColumn("c2", DataType.TEXT)
.addColumn("c3", DataType.BIGINT)
.addColumn("c4", DataType.FLOAT)
.addColumn("c5", DataType.DOUBLE)
.addPartitionKey("c1")
.addClusteringKey("c2", Scan.Ordering.Order.DESC)
.addClusteringKey("c3", Scan.Ordering.Order.ASC)
.addSecondaryIndex("c4")
.build();
ScalarDB のデータモデルの詳細については、データモデルを参照してください。
次に、次のようにテーブルを作成します。
// Create the table "ns.tbl". If the table already exists, an exception will be thrown.
admin.createTable("ns", "tbl", tableMetadata);
// Create the table only if it does not already exist.
boolean ifNotExists = true;
admin.createTable("ns", "tbl", tableMetadata, ifNotExists);
// Create the table with options.
Map<String, String> options = ...;
admin.createTable("ns", "tbl", tableMetadata, options);
作成オプション
テーブルの作成操作では、オプション名と値のマップであるオプション (Map<String, String>) を指定できます。オプションを使用すると、ストレージアダプタ固有の設定ができます。
データベースを選択して、使用可能なオプションを確認します。
- JDBC データベース
- DynamoDB
- Cosmos DB for NoSQL
- Cassandra
- Object Storage
| 名前 | 説明 | デフォルト |
|---|---|---|
| transaction-metadata-decoupling | Consensus Commitを使用している場合に、トランザクションメタデータ分離を有効にします。これにより、トランザクションメタデータがアプリケーションデータとは別のテーブルで管理されます。 | false |
| 名前 | 説明 | デフォルト |
|---|---|---|
| no-scaling | DynamoDB の自動スケーリングを無効にします。 | false |
| no-backup | DynamoDB の継続的なバックアップを無効にします。 | false |
| ru | 基本リソース単位。 | 10 |
使用可能なオプションはありません。
| 名前 | 説明 | デフォルト |
|---|---|---|
| compaction-strategy | Cassandra の圧縮戦略。LCS、STCS、または TWCS である必要があります。 | STCS |
使用可能なオプションはありません。
セカンダリインデックスを作成する
セカンダリインデックスは次のように作成できます。
// Create a secondary index on column "c5" for table "ns.tbl". If a secondary index already exists, an exception will be thrown.
admin.createIndex("ns", "tbl", "c5");
// Create the secondary index only if it does not already exist.
boolean ifNotExists = true;
admin.createIndex("ns", "tbl", "c5", ifNotExists);
// Create the secondary index with options.
Map<String, String> options = ...;
admin.createIndex("ns", "tbl", "c5", options);
Consensus Commit を使用している場合、非プライマリキー列で createIndex() を使用すると、コンパニオン before-image セカンダリインデックスも作成されます。詳細については、インデックスベース読み取りの正確性を参照してください。
作成オ プション
セカンダリインデックスの作成操作では、オプション名と値のマップであるオプション (Map<String, String>) を指定できます。オプションを使用すると、ストレージアダプタ固有の設定ができます。
データベースを選択して、使用可能なオプションを確認します。
- JDBC データベース
- DynamoDB
- Cosmos DB for NoSQL
- Cassandra
- Object Storage
使用可能なオプションはありません。
| 名前 | 説明 | デフォルト |
|---|---|---|
| no-scaling | DynamoDB の自動スケーリングを無効にします。 | false |
| ru | 基本リソース単位。 | 10 |
使用可能なオプションはありません。
使用可能なオプションはありません。
使用可能なオプションはあり ません。
テーブルに新しい列を追加する
次のように、テーブルに新しい非パーティションキー列を追加できます。
// Add a new column "c6" with the INT data type to the table "ns.tbl".
admin.addNewColumnToTable("ns", "tbl", "c6", DataType.INT);
// Add the new column only if it does not already exist.
boolean ifNotExists = true;
admin.addNewColumnToTable("ns", "tbl", "c6", DataType.INT, false, ifNotExists);
テーブルに新しい列を追加する場合は、基盤となるストレージによって実行時間が大きく異なる可能性があるため、慎重に検討する必要があります。特にデータベースが本番環境で実行されている場合は、以下の点を考慮して適切に計画を立ててください。
- Cosmos DB for NoSQL および DynamoDB の場合: テーブルスキーマは変更されないため、列の追加はほぼ瞬時に行われます。別のテーブルに格納されているテーブルメタデータのみが更新されます。
- Cassandra の場合: 列を追加すると、スキーマメタデータのみが更新され、既存のスキーマレコードは変更されません。クラスタートポロジが実行時間の主な要因です。スキーマメタデータの変更は、ゴシッププロトコルを介して各クラスターノードに共有されます。このため、クラスターが大きいほど、すべてのノードが更新されるまでの時間が長くなります。
- リレーショナルデータベース (MySQL、Oracle など) の場合: 列の追加は、データベースエンジンによってはテーブルの再構築を引き起こす可能性があります。そのような場合、実行に長時間かかることがあります。
テーブルから列を削除する
次のようにテーブルから列を削除できます。
// Drop the column "c6" from the table "ns.tbl".
admin.dropColumnFromTable("ns", "tbl", "c6");
// Drop the column only if it exists.
boolean ifExists = true;
admin.dropColumnFromTable("ns", "tbl", "c6", ifExists);
次の場合、テーブルから列を削除することはできません。
- 列がパーティションキーまたはクラスタリングキーの一部である場合。
- テーブルが Cassandra を除く非 JDBC データベース上にある場合。
テーブルから列を削除する場合は、基盤となるストレージによって実行時間が大きく異なる可能性があるため、慎重に検討する必要があります。特にデータベースが本番環境で実行されている場合は、以下の点を考慮して適切に計画を立ててください。
- Cassandra の場合: 列を削除すると、スキーマメタデータのみが更新され、実際のデータは次のコンパクション時に削除されま す。クラスタートポロジが実行時間の主な要因です。スキーマメタデータの変更は、ゴシッププロトコルを介して各クラスターノードに共有されます。このため、クラスターが大きいほど、すべてのノードが更新されるまでの時間が長くなります。
- リレーショナルデータベース (MySQL、Oracle など) の場合: 列の削除は、基盤となるリレーショナルデータベースに
ALTER TABLE ... DROP COLUMNを発行し、データベースによってはテーブルの再構築を引き起こす可能性があります。そのような場合、実行に長時間かかることがあります。
テーブルの列の名前を変更する
次のようにテーブルの列の名前を変更できます。
// Rename the column "c6" to "c66" in the table "ns.tbl".
admin.renameColumnInTable("ns", "tbl", "c6", "c66");
次の場合、テーブルの列の名前を変更することはできません。
- テーブルが Cassandra を除く非 JDBC データベース上にある場合。
- Cassandra の場合、列がパーティションキーまたはクラスタリングキーの一部でない場合。
- Db2 の場合、列がパーティションキー、クラスタリングキー、またはセカンダリイ ンデックスキーの一部である場合。
テーブルの名前を変更する
次のようにテーブルの名前を変更できます。
// Rename the table "ns.tbl" to "ns.new_tbl".
admin.renameTable("ns", "tbl", "new_tbl");
非 JDBC データベースではテーブルの名前を変更することはできません。
テーブルの列のデータ型を変更する
次のようにテーブルの列のデータ型を変更できます。
// Alter the data type of the column "c6" to BIGINT in the table "ns.tbl".
admin.alterColumnDataType("ns", "tbl", "c6", DataType.BIGINT);
次の場合、テーブルの列のデータ型を変更することはできません。
- 列がパーティションキー、クラスタリングキー、またはセカンダリインデックスキーの一部である場合。
- テーブルが非 JDBC データベース上または SQLite 上にある場合。
- INT から BIGINT、FLOAT から DOUBLE、および任意のデータから TEXT への変換以外の変換が指定されている場合。
- Oracle の場合、INT から BIGINT 以外の変換が指定されている場合。
- Db2 および TiDB の場合、BLOB から TEXT への変換が指定されている場合。
列の型を変更する場合は、基盤となるストレージによって実行時間が大きく異なる可能性があるため、慎重に検討する必要があります。特にデータベースが本番環境で実行されている場合は、以下の点を考慮して適切に計画を立ててください。
- リレーショナルデータベース (MySQL、Oracle など) の場合: 列の変更は、基盤となるリレーショナルデータベースに
ALTER TABLE ... ALTER COLUMNまたはALTER TABLE ... MODIFYを発行し、データベースによってはテーブルの再構築を引き起こす可能性があります。そのような場合、実行に長時間かかることがあります。