アクション
テーブル内のデータを論理的にサイズが指定されたサイズに近いいくつかの断片に分割し、分割点の間に分割点を返し、断片がある機械に関するプロンプトを返します。このAPIは、一般に、コンピューティングエンジン上の計画の並行性などの実行計画に使用されます。
リクエストの構造
message ComputeSplitPointsBySizeRequest {
required string table_name = 1;
required int64 split_size = 2; // in 100MB
}
table_name:
- タイプ:String
- 必須パラメータ:はい
- 分割するデータを保持するテーブルの名前。
split_size:
- タイプ:int64
- 必須パラメータ:はい
- 各シャードのおおよそのサイズ。単位は100 MBです。
レスポンスメッセージの構造
message ComputeSplitPointsBySizeResponse {
required ConsumedCapacity consumed = 1;
repeated PrimaryKeySchema schema = 2;
/**
*スプリット間のスプリットポイントは、昇順で
*
*分割は、連続する主キーの範囲です。
*そのデータサイズはリクエストで指定されたsplit_size程度です。
*そのためサイズは正確ではありません。
*
*スプリットポイントは、プライマリキー列wrtの配列です。テーブルスキーマは、
*表スキーマの長さより長くなることはありません。
*Tailing -infは送信ペイロードを減らすために省略されます。
*/
repeated bytes split_points = 3;
/**
*分割される場所。
*TableStoreが管理している性質上、これらの場所は手掛かり以上のものはありません。
*場所がわからない場合は、空の文字列が配置されます。
*/
message SplitLocation {
required string location = 1;
required sint64 repeat = 2;
}
repeated SplitLocation locations = 4;
}
consumed:
- タイプ:ConsumedCapacity
- この要求によって消費されたサービス容量単位。
schema:
- タイプ:PrimaryKeySchema
- 表のスキーマ。表の作成時に指定されたスキーマと同じです。
split_points:
- Type: タイプ:繰り返しバイト
- T分割点はシャード間にあります。スプリットポイントは、シャード間で単調に増加する必要があります。各スプリットポイントはPlainbufferエンコードされた行で、主キーのみを含んでいます。より小さい量のデータを送信するために、各分割点の最後の「-inf」は送信されない。
locations:
- タイプ:split SplitLocation
- スプリットポイントが配置されているマシンに関するプロンプト。nullでもかまいません。
たとえば、テーブルには主キーの3つの列があり、最初の列は文字列型です。このAPIが呼び出されると、(-inf,-inf,-inf)
から ("a",-inf,-inf)
, ("a",-inf,-inf)
から ("b",-inf,-inf)
, ("b",-inf,-inf)
から ("c",-inf,-inf)
, ("c",-inf,-inf)
から ("d",-inf,-inf)
, ("d",-inf,-inf)
から (+inf,+inf,+inf)
となります。最初の3つのシャードは “machine-A”にあり、最後の2つは “machine-B”にあります。この例では、split_pointsは [("a"),("b"),("c"),("d")]
となり、locationsは"machine-A"*3, "machine-B"*2
となります。
容量単位の使用
使用される読み出しサービス容量単位の数は、断片の数と同じです。書き込みサービス容量単位は消費されません。