BLOB パフォーマンスの最適化 - PolarDB - Alibaba Cloud ドキュメントセンター

高い同時実行性を持つ環境で MySQL にバイナリラージオブジェクト (BLOB) を書き込むと、ロック競合や過剰な REDO ログの生成など、パフォーマンスのボトルネックが頻繁に発生します。PolarDB は、カーネルレベルの最適化によってこれらの課題に対処し、BLOB 操作中のロック競合、I/O プレッシャー、および領域管理の問題を解決します。これにより、DML と DDL のパフォーマンスが大幅に向上し、高い同時実行性を持つワークロード下でもサービスの安定的かつ効率的な運用が保証されます。

概要

バイナリラージオブジェクト (BLOB) は、画像、ドキュメント、長文テキストなどの大規模なデータオブジェクトを格納するために使用されるデータベースのフィールドタイプです。ネイティブの MySQL InnoDB ストレージエンジンでは、データ行の BLOB フィールドが特定のサイズを超えると、InnoDB はそれを別のオフページデータページに格納します。このメカニズムは大規模なデータを扱うことができますが、同時に 3 つの主要なパフォーマンス上の課題も引き起こします。

同時書き込みのボトルネック：オフページの BLOB を更新すると、悲観的ロックが取得されます。これにより、一度に 1 つのスレッドしかテーブルに BLOB を書き込むことができなくなり、同時実行性が著しく制限されます。
I/O プレッシャーの増大：大きなフィールドは、大量の REDO ログエントリを生成します。ディスク I/O が不十分な場合、ログのフラッシュがボトルネックとなり、フォアグラウンドの書き込み操作がブロックされます。
領域解放の遅延：古い BLOB データをクリーンアップするプロセス (パージプロセス) は非効率的です。これにより、ストレージ領域の肥大化やパフォーマンスの低下につながる可能性があります。

PolarDB の BLOB 最適化機能は、これらの問題を解決します。アプリケーションの変更を必要とせず、カーネルレベルで BLOB の書き込み、更新、解放を含むライフサイクル全体を最適化します。

課金

BLOB パフォーマンス最適化機能は PolarDB カーネルに組み込まれており、追加費用なしで利用できます。

BLOB 書き込みパフォーマンスの最適化

業務のピーク時に BLOB テーブルへの書き込みでスループットのボトルネックや高いレイテンシが発生する場合、その原因は多くの場合、書き込みロックの競合です。PolarDB は、ページ事前割り当てとインデックスラッチ最適化によってこの問題を解決します。

ページ事前割り当て

この最適化は、BLOB の書き込みプロセスを以下のステップに分解します。

必要なデータページ数を計算し、単一のバッチ操作で割り当てます。
ロックフリーの状態でデータをコピーし、新しく割り当てられたページを BLOB コンテンツで埋めます。
単一の楽観的ロック操作で、結果として得られたデータページのチェーンをインデックスレコードにアタッチします。

このプロセス全体を通じて、排他的になるのは最初の領域割り当てフェーズのみです。データコピーのような時間のかかる操作は、他の BLOB 書き込みと同時に実行できます。さらに、データコピーはクリティカルセクション外で行われるため、単一の書き込みが大量の REDO ログデータを生成し、ログバッファーを埋めて書き込みをブロックするリスクを回避します。最終的に、このメカニズムはグローバルロックの保持時間を最小限に抑え、同時書き込みパフォーマンスを大幅に向上させます。

インデックスラッチ最適化

小さい (8 KB 未満) または混合サイズの BLOB フィールドを含むテーブルでは、ネイティブ MySQL はインデックスページの構造変更操作 (SMO) 中に楽観的ロックを早期に放棄することがよくあります。その後、非効率的な悲観的ロックモデルにフォールバックし、同時実行パフォーマンスに深刻な影響を与えます。インデックスラッチ最適化は、操作をより長く楽観的パスに留めることで、このボトルネックを解決します。この最適化は、以下のステップで機能します。

楽観的パスの維持：潜在的な BLOB フィールドの更新が検出されると、最適化ロジックはすぐに悲観的ロックに切り替えません。代わりに、競合の可能性が低い共有ラッチ (S-latch) を保持し続け、楽観的更新パスに留まります。
事前構築と更新の試行：楽観的パス上で、更新に必要な BLOB データ構造を事前に構築し、インデックスページを直接変更しようと試みます。
決定とコミットまたはフォールバック：
- 成功：更新されたレコードが現在のインデックスページの領域要件内に収まる場合、操作は楽観的パス上で迅速に完了します。
- 失敗：例えば、ページに十分な領域がない場合、最適化は自動的に試行を放棄し、ネイティブ MySQL の悲観的ロックパスにシームレスにフォールバックします。その後、ネイティブパスが更新操作全体を完了させ、データ整合性を保証します。

この楽観的アプローチの主な利点は、楽観的更新の成功率を大幅に高めることです。これにより、本来なら悲観的ロックにフォールバックしていた多くの操作が、より効率的に完了できるようになります。これは、高い同時実行性下での混合サイズ BLOB データの更新スループットを大幅に向上させます。

書き込み最適化の有効化

PolarDB コンソールの設定と管理 > パラメーター ページで、次のパラメーターを表示および変更し、これらの最適化を有効にします：

パラメーター	説明	サポートされるバージョン
`innodb_blob_prepare_pages`	BLOB のページの事前割り当てを有効または無効にします。有効な値： ON：有効 OFF：無効	MySQL 5.6：サポートされていません MySQL 5.7：マイナーバージョン 5.7.1.0.35 以降。 MySQL 8.0.1：マイナーバージョン 8.0.1.1.47 以降。 MySQL 8.0.2：サポートされていません
`innodb_blob_prepare_max_extern_size`	ページの事前割り当てが使用される単一の BLOB カラムの最大長を設定します。
`innodb_blob_latch_optimize`	BLOB のインデックスラッチの最適化を有効または無効にします。

BLOB 書き込みにおける redo ログの削減

ご利用のワークロードに大量の BLOB データの書き込みが含まれ、redo ログの生成レートが I/O ボトルネックになっている場合は、redo 圧縮を有効にすることで負荷を軽減できます。

redo 圧縮は、BLOB 関連の redo ログエントリをログバッファーに書き込む前に並行して圧縮することで機能します。このプロセスにより、ディスクに書き込まれる redo ログデータの量を大幅に削減でき、テストでは平均 40% から 60% の削減が示されています。これにより、ストレージの I/O 負荷が低減し、redo モジュールがボトルネックとなって全体の書き込みパフォーマンスに影響を与えるのを防ぎます。クラッシュリカバリー中、システムはこれらのログを自動的に解凍して適用します。

redo 圧縮の有効化

この最適化を有効にするには、PolarDB コンソールに移動し、[設定と管理] > [パラメーター設定] ページで、次のパラメーターを表示および変更します：

パラメーター

説明

サポートされるバージョン

innodb_blob_redo_compress_algorithm

BLOB の redo ログの圧縮アルゴリズムを設定します。有効な値：

none (デフォルト)
lz4
zstd
zlib

MySQL 5.6：サポートされていません
MySQL 5.7：マイナーバージョン 5.7.1.0.39 以降。
MySQL 8.0.1：サポートされていません
MySQL 8.0.2：サポートされていません

innodb_blob_redo_compress_level

選択したアルゴリズムの圧縮レベルを設定します。

有効な値：0～9。デフォルト：6。

BLOB 領域再利用の高速化

BLOB データを頻繁に削除または更新した後に、表領域の再利用が遅く、ファイルが増え続ける場合、その根本原因は、非効率なネイティブ MySQL のバックグラウンドのパージプロセスにあります。このプロセスは、データをクリーンアップする際に、BLOB ページを読み取る前に、まず Index SX のようなコアロックを取得します。ページがメモリ内にない場合、ロックを保持したまま時間のかかるディスク I/O 操作がトリガーされ、テーブルに対する他の同時実行操作が長期間ブロックされる可能性があります。PolarDB のパージ事前読み取り最適化は、I/O 操作をロックプロセスから分離することで、このボトルネックを解決します。この最適化は、次の手順で機能します。

ターゲットページの特定：ロックを取得してクリーンアップを開始する前に、パージプロセスはまず、再利用が必要なオフページ BLOB の完全なチェーンを特定します。
非同期での事前読み取り：非同期 I/O リクエストを開始して、まだメモリにないターゲットページをディスクからバッファープールにロードします。
迅速なクリーンアップ：すべてのページがメモリにロードされた後、パージプロセスは Index SX などの必要なコアロックを取得し、メモリ内のページ解放とメタデータ変更操作を迅速に実行します。

パージ事前読み取りメカニズムは、ロックが保持されているクリティカルセクション内でディスク I/O 操作を実行することを回避します。最も時間のかかる I/O 操作をより早い段階に移動させることで、ロック保持時間は高速なメモリ内操作の持続時間に短縮されます。これにより、BLOB データの再利用効率が向上し、領域の肥大化が防がれるだけでなく、さらに重要なことに、バックグラウンドのクリーンアッププロセスによる、高い同時実行書き込みなどのフォアグラウンドのワークロードのブロックを削減します。結果として、データベース全体の同時実行性能と安定性が向上します。

パージ事前読み取りの有効化

PolarDB コンソールで、[設定と管理] > [パラメータ設定] ページに移動し、次のパラメーターを表示および変更して、この最適化を有効にします。

パラメーター

説明

サポートバージョン

innodb_purge_blob_read_ahead

BLOB のパージ事前読み取りを有効または無効にします。

有効な値：

ON：有効
OFF：無効

すべてのバージョンでサポートされています。

DDL 実行効率の向上

大量の BLOB データを含むテーブルに対して ALTER TABLE などの DDL 操作を実行する必要があり、その操作に時間がかかりすぎる場合は、DDL 関連の BLOB 最適化を有効にすることで、操作時間を大幅に短縮できます。

ページの事前割り当て：BLOB フィールドのオーバーフロー列はプライマリキー上に存在するため、プライマリテーブルを再構築する DDL 操作には BLOB フィールドの書き込みも含まれます。ページの事前割り当ての最適化では、より直接的で簡素化されたロック方式を使用して BLOB データを書き込みます。これにより、複雑な同時実行の競合を処理するオーバーヘッドが回避され、再構築の効率が大幅に向上します。
ラッチの最適化：パラレル DDL はプライマリキーツリーをパーティション分割するため、複数のワーカースレッドが同じデータページを操作することはありません。この最適化により、新しいページの割り当てが独立して保護されるため、他の操作を同時に実行でき、効率が向上します。
Redo の最適化：
1. ページの集約：バルクロード中、システムはレコードごとに Redo ログエントリを生成する代わりに、ページがいっぱいになった後、データページ全体の変更を単一の大きな Redo ログエントリとして書き込みます。これにより、Redo 操作の効率が向上します。
2. 集約圧縮：集約された大きな Redo ログエントリは、さらに圧縮され、DDL プロセス中に生成される Redo ログデータの量が削減されます。

DDL 最適化の有効化

PolarDB コンソールで、[設定と管理] > [パラメーター設定] ページに移動し、表示および変更して、これらの最適化を有効にします。

説明

次の表の一部のパラメーターは手動で変更できません。変更が必要な場合は、して、サポートにお問い合わせください。

パラメーター	説明	サポートされているバージョン
`innodb_blob_prepare_pages_in_ddl`	DDL 操作中に BLOB 最適化を有効にするかどうかを指定します。有効な値： OFF (デフォルト) ON	MySQL 5.6：サポートされていません MySQL 5.7：マイナーバージョン 5.7.1.0.39 以降。 MySQL 8.0.1：マイナーバージョン 8.0.1.1.50 以降。 MySQL 8.0.2：サポートされていません
`innodb_bulk_load_without_index_lock_enable`	DDL 操作中にインデックスロックの最適化を有効にするかどうかを指定します。有効な値： OFF (デフォルト) ON	MySQL 5.6：サポートされていません MySQL 5.7：マイナーバージョン 5.7.1.0.39 以降。 MySQL 8.0.1：マイナーバージョン 8.0.1.1.47 以降。 MySQL 8.0.2：マイナーバージョン 8.0.2.2.30 以降。
`innodb_bulk_load_page_grained_redo_enable`	DDL のバルクロード中に Redo ページの集約を有効にするかどうかを指定します。有効な値： OFF ON (デフォルト)	MySQL 5.6：サポートされていません MySQL 5.7：サポートされています。マイナーバージョンの要件はありません。 MySQL 8.0.1：サポートされています。マイナーバージョンの要件はありません。 MySQL 8.0.2：サポートされています。マイナーバージョンの要件はありません。
`innodb_bulk_load_redo_compress_algorithm`	DDL のバルクロードに使用する Redo 圧縮アルゴリズムを設定します。有効な値： `none` (デフォルト) `lz4` `zstd`	MySQL 5.6：サポートされていません MySQL 5.7：マイナーバージョン 5.7.1.0.39 以降。 MySQL 8.0.1：マイナーバージョン 8.0.1.1.52 以降。 MySQL 8.0.2：マイナーバージョン 8.0.2.2.30 以降。
`innodb_bulk_load_redo_compress_enable`	DDL 操作中の Redo 圧縮のターゲットを設定します。有効な値： 0: none (デフォルト) 1: セカンダリインデックス 2: all	MySQL 5.6：サポートされていません MySQL 5.7：マイナーバージョン 5.7.1.0.39 以降。 MySQL 8.0.1：マイナーバージョン 8.0.1.1.52 以降。 MySQL 8.0.2：マイナーバージョン 8.0.2.2.30 以降。

パフォーマンスベンチマーク

次のデータは、BLOB 最適化を有効にした後の DML および DDL シナリオにおけるパフォーマンスの向上を示しています。

DML パフォーマンス：行の長さが 100 KB および 200 KB の高い同時実行数のシナリオでは、PolarDB の最適化により、挿入および更新のパフォーマンスが約 3 倍向上します。 redo 圧縮と組み合わせると、パフォーマンスは 4〜5 倍向上します。
DDL パフォーマンス：BLOB フィールドを含む 40 GB のテーブルの場合、これらの最適化を有効にすると、DDL の書き込みレートが 5〜6 倍に向上し、総実行時間が 84% 短縮されます。