BUILD ジョブは、データ書き込み後にパーティションを再構築し、インデックスを作成して冗長データをクリアすることで、読み取りパフォーマンスを向上させます。BUILD ジョブの実行中、システムはリアルタイムで書き込まれたデータを履歴パーティションとマージし、インデックスを作成して、保留中の DDL ステートメントを非同期で実行します。
仕組み
BUILD ジョブは、2 つのレベルで動作します。
-
テーブルレベル:異なるテーブルで BUILD ジョブが並行して実行されます。
-
シャードレベル:テーブルの BUILD ジョブが開始されると、シャード全体にタスクが分割されます。各シャードの 3 つのレプリカはすべて、独立してタスクを実行します。BUILD ジョブは、すべてのシャードタスクが完了したときに完了します。
BUILD ジョブは、データが変更されたパーティションのみを処理します。新しい INSERT、UPDATE、または DELETE 操作がないパーティションはスキップされます。
AnalyticDB for MySQL は、ログ構造化マージ (LSM) ストレージエンジンを使用します。DELETE または REPLACE を実行すると、影響を受ける行は物理層で削除対象としてマークされるだけで、バックグラウンドの BUILD ジョブによって非同期にクリアされます。大量の DELETE または REPLACE 操作の後、BUILD ジョブが完了していない場合、[Space Overview] に表示されるテーブルの行数は、SELECT COUNT(*) が返す値よりも大きくなります。[Space Overview] の行数は row_count 列の information_schema.kepler_partitions から取得され、削除対象としてマークされているがまだクリアされていない行を含む物理的な行を報告します。SELECT COUNT(*) は論理的に有効な行数を返し、削除対象としてマークされた行は除外します。2 つの値を収束させるには、BUILD TABLE を手動で実行して、削除対象としてマークされた行をクリアしてください。
注意事項
-
BUILD ジョブの実行中、
INSERT OVERWRITE SELECTはブロックされます。代わりにINSERT INTOを使用してください。 -
送信後の BUILD ジョブはキャンセルできません。
-
同時 BUILD ジョブの数は
ceil(コア数 / 3)に等しく、変更できません。32 コアのクラスターの場合、これは 11 の同時ジョブになります。 -
BUILD ジョブは CPU、メモリ、I/O リソースを消費します。ジョブの実行中に CPU 使用率とディスク I/O 使用量が急増し、完了後に正常に戻る場合があります。BUILD ジョブはオフピーク時に実行してください。
BUILD ジョブの自動トリガー
BUILD ジョブは、次のいずれかの条件が満たされると自動的にトリガーされます。
条件1:十分な新しいデータが蓄積された場合
最後の BUILD ジョブから最小間隔が経過し、かつ 少なくとも 50,000 行がシャードに追加された場合。
| エディション | 最小間隔 |
|---|---|
| Enterprise Edition | 1.5 時間 |
| Basic Edition | 1.5 時間 |
| Data Lakehouse Edition | 1.5 時間 |
| Data Warehouse Edition (elastic mode) | 1.5 時間 |
| Data Warehouse Edition (reserved mode) | 0.5 時間 |
条件2:時間ベースのフォールバック
最後の BUILD ジョブから 24 時間が経過し、少なくとも 1 行が変更された場合。
BUILD ジョブの手動トリガー
変更されたパーティションのみのビルド
デフォルトでは、データが変更されたパーティションのみが再構築されます。
-
XUANWU テーブル
BUILD TABLE <table_name>; -
XUANWU_V2 テーブル
説明テーブルエンジンを決定して指定する方法の詳細については、「XUANWU_V2 エンジン」の「テーブルエンジンを指定する」セクションをご参照ください。
BUILD TABLE <table_name> [BUILD_OPTION];BUILD_OPTIONにはttl(オプション) のみ指定できます。指定すると、BUILD ジョブの完了直後に期限切れのパーティションが削除されます。省略すると、変更されたパーティションのみが再構築されます。
特定のパーティションのビルド
V3.1.6.0 以降を実行している AnalyticDB for MySQL クラスターで利用可能です。
BUILD TABLE test force partitions='partition1,partition2';
このアプローチは、テーブルに大量のデータが含まれており、テーブル全体の BUILD を実行するとリソースを大量に消費する場合に使用します。特定のパーティションを対象とすることで、リソース使用量を削減し、ジョブを高速化します。
クラスターのマイナーバージョンを確認するには、「クラスターのマイナーバージョンを確認するにはどうすればよいですか?」をご参照ください。マイナーバージョンを更新するには、テクニカルサポートにご連絡ください。
テーブル全体のビルド
この操作は、既存のすべてのデータのインデックスを再作成するため、完了までに時間がかかる場合があります。続行する前に、影響とリスクを評価してください。この機能はデフォルトで無効になっています。有効にするには、チケットを起票してください。可能な場合は、上記の特定パーティションのアプローチを使用してください。
BUILD TABLE <table_name> force = true;
これにより、データが変更されていないパーティションを含め、テーブル内のすべてのパーティションのインデックスが再作成されます。
BUILD ジョブのスケジューリング
デフォルトでは、BUILD ジョブはデータが蓄積されると実行されます。ピーク時のビジネスアワーを避けるなど、特定のタイムウィンドウに制限するには、スケジュールを設定してください。
タイムウィンドウの設定
SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`<start>,<end>`;
| パラメーター | 説明 | 有効範囲 |
|---|---|---|
start |
スケジューリングウィンドウの開始 (時) | 0–24 |
end |
スケジューリングウィンドウの終了 (時) | 0–24 |
複数のタイムウィンドウはセミコロンで区切ってください。すべての値をバッククォートで囲ってください。
タイムウィンドウは、ジョブがスケジュールされる時刻を制御するものであり、ジョブが終了する時刻を制御するものではありません。ウィンドウが閉じる前にスケジュールされたジョブは、ウィンドウの終了後も実行され続ける場合があります。
例:BUILD ジョブを 00:00–06:59 と 18:00–22:59 の間にスケジュールします。
SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`0,6;18,22`;
スケジューリング優先度の設定
V3.1.5.0 以降を実行している AnalyticDB for MySQL クラスターで利用可能です。
デフォルトでは、BUILD ジョブは、最後の BUILD ジョブ以降に各シャードに追加されたデータの量によって優先順位が付けられます。新しく追加されたデータが多いシャードが最初にスケジュールされます。これを上書きするには、ヒントまたは SET ADB_CONFIG を使用してカスタム優先度を設定してください。
task_priority パラメーターは整数です (デフォルト: 0)。値が大きいほど優先度が高くなります。負の数に設定すると、そのテーブルの自動スケジューリングが無効になります。
クラスターのマイナーバージョンを確認または更新するには、AnalyticDB for MySQL コンソールにログインし、[Cluster Information] ページの [Configuration Information] セクションに移動してください。
ヒントの使用 (単一のテーブル、現在のジョブのみに適用)
/*build_task_priority = <task_priority> */ BUILD TABLE <db_name>.<table_name>;
例:adb_demo データベースの test テーブルの優先度を 30 に設定します。
/*build_task_priority = 30 */ Build TABLE adb_demo.test;
SET ADB_CONFIG の使用 (永続的、複数テーブルをサポート)
-
複数のデータベースにまたがる複数のテーブルの優先度を設定します。
SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.<table1_name>.<task_priority>;<db2_name>.<table2_name>.<task_priority>`;例:
adb_demo1.test1の優先度を 30、adb_demo2.test2の優先度を 10 に設定します。SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.test1.30;adb_demo2.test2.10`; -
データベース内のすべてのテーブルに同じ優先度を設定します。
SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.*.<task_priority>`;例:
adb_demo1内のすべてのテーブルの優先度を 30 に設定します。SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.*.30`; -
データベース内の 1 つのテーブルと残りのテーブルとの間で異なる優先度を設定します。
SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.*.<task_priority>;<db1_name>.<table_name>.<task_priority>`;例:
adb_demo1.test1の優先度を 30、adb_demo1内の他のすべてのテーブルの優先度を 10 に設定します。SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.*.10;adb_demo1.test1.30`;
同じテーブルに対してヒントと SET ADB_CONFIG の両方が設定されている場合、現在のジョブではヒントが優先されます。
現在の優先度設定を確認するには、SHOW ADB_CONFIG を実行してください。
BUILD ジョブのステータスの監視
過去 3 日間の BUILD ジョブのステータスを照会できます。
SELECT table_name, schema_name, status
FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK
ORDER BY create_time DESC
LIMIT 10;
| ステータス | 説明 |
|---|---|
INIT |
ジョブは初期化中です。 |
RUNNING |
ジョブは実行中です。 |
FINISH |
ジョブは完了しました。 |
よくある質問
自動スケジューリングが有効にならない
SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD の時間パラメーターは、バッククォートで囲む必要があります。バッククォートがない場合、値の解析に失敗し、スケジューリングは無視されます。
正しい構文:
SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`0,6`;
これにより、BUILD ジョブが 00:00 から 06:59 の間にスケジュールされます。