このトピックでは、最適化されたバッファープール管理メカニズムを提供する高速 DDL 機能について説明します。このメカニズムにより、データ定義言語 (DDL) 操作の影響を軽減し、同時実行可能な DDL 操作の数を増やすことができます。
前提条件
お使いの RDS インスタンスは、以下のいずれかの MySQL バージョンで実行されている必要があります。- MySQL 8.0 (20200630 以降のマイナーエンジンバージョン)
- MySQL 5.7 (20200630 以降のマイナーエンジンバージョン)
- MySQL 5.6 (20200630 以降のマイナーエンジンバージョン)
背景情報
DDL 操作は RDS インスタンスでは一般的です。RDS インスタンスを使用していると、DDL 操作に関連する問題が発生することがあります。たとえば、次のような問題が発生する可能性があります。
- インデックスを追加する際に、なぜパフォーマンスジッターが発生し、RDS インスタンスでの読み取りおよび書き込み操作が中断されるのですか。
- サイズが 1 GB 未満のテーブルで DDL 操作を実行するのに、なぜ 10 分以上もかかるのですか。
- 一時テーブルを生成する接続が閉じられたときに、なぜパフォーマンスジッターが発生するのですか。
ApsaraDB for RDS のデータベースエンジンチームは、これらの問題を特定するために詳細な分析と集中的なテストを実施しました。分析とテストの結果に基づき、チームは DDL 操作の管理に使用されるキャッシュのメンテナンスロジックの欠陥を特定しました。これらの問題を修正するために、チームは高速 DDL 機能を開発しました。この機能が提供する最適化されたバッファープール管理メカニズムは、DDL 操作によって引き起こされるロックの競合を削減します。これにより、RDS インスタンスが通常のワークロードを処理している場合でも、DDL 操作中の RDS インスタンスのパフォーマンスを確保できます。
高速 DDL の有効化
ApsaraDB for RDS コンソールで[loose_innodb_rds_faster_ddl] パラメーターを[ON] に設定することで、高速 DDL 機能を有効にできます。詳細については、「インスタンスパラメーターの変更」をご参照ください。
DDL 操作のテスト
- テストシナリオ
インプレースアルゴリズムを使用し、MySQL 8.0 でサポートされているステートメント (CREATE INDEX および OPTIMIZE TABLE) を実行することで、オンライン DDL 操作を実行します。CREATE INDEX ステートメントは、テーブルを再構築せずにテーブルにインデックスを作成します。OPTIMIZE TABLE ステートメントは、テーブルを再構築して未使用領域を解放し、データの断片化を解消します。このプロセスでは、テーブル上のインデックスも再構築されます。
操作 インスタント インプレース テーブルの再構築 同時 DML 操作の許可 メタデータのみの変更 CREATE INDEX いいえ はい いいえ はい いいえ OPTIMIZE TABLE いいえ はい はい はい いいえ - テストインスタンス
テストに使用する RDS インスタンスは MySQL 8.0 を実行しており、8 CPU コア、64 GB のメモリを備えています。DDL 操作の対象となるテーブルのサイズは 600 MB です。
- テスト手順
SysBench を使用してストレステストを実行します。このテストでは、オンライン DDL 操作を実行し、その操作結果を比較します。
- テスト結果
操作 平均実行時間 (高速 DDL 無効) 平均実行時間 (高速 DDL 有効) パフォーマンス向上倍率 CREATE INDEX 56 秒 4.9 秒 11.4倍 OPTIMIZE TABLE 220 秒 17 秒 12.9倍 - テストのまとめ
高速 DDL 機能により、AliSQL を搭載した ApsaraDB for RDS for MySQL は、MySQL Community Edition と比較して DDL 操作の実行時間を 90% 以上短縮できます。
一時テーブルのテスト
一時テーブルは MySQL では一般的です。たとえば、information_schema データベースからテーブルをクエリしたり、複雑な SQL ステートメントの実行を高速化するために使用される一時テーブルがシステムによって作成されます。スレッドが終了すると、関連するすべての一時テーブルが削除されます。これは、RDS インスタンスでパフォーマンスジッターを引き起こす、特殊なタイプの DDL 操作です。詳細については、「Temp ibt tablespace truncation at disconnection stuck InnoDB under large BP」をご参照ください。
- テストインスタンス
テストに使用する RDS インスタンスは MySQL 8.0 を実行しており、8 CPU コアと 64 GB のメモリを備えています。
- テスト手順
tpcc-mysql を使用してストレステストを実行します。このテストでは、クエリを実行してバッファープールがほぼ満杯になるようにします。次に、短命な接続を介してシングルスレッドのリクエストを開始し、一時テーブルを生成します。
- テスト結果
比較項目 DDL 操作なし 高速 DDL 有効 高速 DDL 無効 秒間トランザクション数 (TPS) 42,000 40,000 < 10,000 以下の図は、ストレステストから取得した秒単位のパフォーマンスデータを示しています。赤色でハイライトされた部分は、高速 DDL 機能が無効な場合の RDS インスタンスの TPS を示しています。
- テストのまとめ
一時テーブルを生成するスレッドが終了するたびに、ネイティブの MySQL は深刻なパフォーマンスジッターを引き起こします。このジッターにより、TPS は 70% 以上低下します。高速 DDL 機能を有効にすると、TPS の低下は 5% に抑えられます。
最適化の効果
高速 DDL 機能は MySQL 5.6、5.7、および 8.0 をサポートしています。ただし、サポートされる DDL 操作は、選択した MySQL バージョンによって異なる場合があります。
| カテゴリ | DDL 操作 | MySQL 5.6 | MySQL 5.7 | MySQL 8.0 |
| インプレース DDL | インプレースアルゴリズムを使用するオンライン DDL 操作。詳細については、「MySQL 8.0 のオンライン DDL 操作」および「MySQL 5.7 のオンライン DDL 操作」をご参照ください。 | いいえ | はい | はい |
| 表領域管理 | 表領域の暗号化を有効または無効にする。 | いいえ | はい | はい |
| 表領域を解放または削除する。 | いいえ | はい | はい | |
| 表領域を破棄する。 | はい | はい | はい | |
| テーブルの削除 | テーブルを解放または削除する。 | はい | はい | はい |
| UNDO 操作 | UNDO 表領域を解放または削除する。 | いいえ | いいえ | はい |
| テーブルの更新 | テーブルとそのダーティーページを更新する。 | はい | はい | はい |
高速 DDL で修正された不具合
高速 DDL 機能は、以下の不具合を修正します：