データベース

MariaDBのページ圧縮：パフォーマンスへの影響を最小限に抑えながらストレージ容量を節約

MariaDB ページ 圧縮機能は、InnoDBのページをストレージに書き込む前に圧縮することで物理的なストレージ使用量を削減し、I/O量を大幅に低減します。本記事では、ストレージを節約し、レイテンシを低く抑える方法、必要な前提条件、そして実運用において最も効果的な設定について解説します。.

中心点

これらの簡潔な要点は、最も重要な側面を紹介するものです。.

ページごとに 圧縮により、必要な容量とI/Oが削減されます。.
非圧縮の バッファプールは、RAMにおけるCPU負荷を抑制する。.
フレキシブル PAGE_COMPRESSED を使用したテーブルごとの有効化。.
ファイルシステム-スパース/ホールパンチングのサポートは必須です。.
アルゴリズムの選択 レート、レイテンシ、およびCPUコストを制御します。.

InnoDBのページ圧縮の技術的な仕組み

各InnoDBページをディスクに書き込む直前に圧縮を行うため、テーブルスペースが実際に占有するのは圧縮後のバイト数のみとなり、ファイルシステムは空き領域をスパースとしてマークします。 バッファプール ページは引き続き非圧縮のままにしておくことで、メモリ上のCPU負荷を低く抑え、頻繁な読み取りアクセスも高速なまま維持されます。デフォルトではInnoDBのページサイズは16Kですが、圧縮後の保存ブロックサイズは可変で小さくなるため、特にテキストやJSONフィールドにおいて大幅な容量節約につながります。読み込み時には、ページをRAMにロードした直後に解凍します。つまり、転送時の節約効果が最も大きなI/O境界で処理を行うのです。これにより、負荷を 入出力 CPUに関しては、ただしそれが妥当な範囲に限定して。.

ページ圧縮と従来のInnoDBテーブル圧縮の比較

従来の圧縮方式は、ROW_FORMAT=COMPRESSED と KEY_BLOCK_SIZE を組み合わせるもので、これにより固定長の圧縮ページ形式が生成されますが、書き込みや更新の際に追加の判断負荷が生じます。私は ページ 圧縮は柔軟性を維持できるため有効です。圧縮に失敗した場合でも、InnoDBはファイル形式全体を変更することなく、そのページを非圧縮のまま格納できます。バッファプールは引き続き非圧縮の16Kページで動作するため、キャッシュヒットが高速化され、CPUパスもシンプルに保たれます。挿入が多く、更新が中程度の典型的なOLTPワークロードでは、ページ圧縮はストレージ容量の節約とレイテンシのバランスに優れています。その結果、各操作で大きなオーバーヘッドを発生させることなく、多くの場合、顕著なI/O上のメリットを得ることができます。 更新情報 リスクに対して。.

前提条件と基本設定

ページ圧縮を行うには、InnoDB が必須であるため、これを有効にします。 innodb_file_per_table, 、各テーブルが独自のテーブルスペースを使用するようにします。ここで重要なのはファイルシステムです。スパースファイルとホールパンチングに対応している必要があり、これはext4やXFSではサポートされており、最新のクラウドボリュームにも通常備わっています。アルゴリズムの選択については、innodb_compression_algorithm を設定します。通常は、希望する圧縮率や CPU プロファイルに応じて、zlib、lz4、または lzo を選択します。ストレージ層を慎重に検討すれば、コンパクトなファイルシステムの比較その際、ドライバーやボリュームのオプションも考慮されます。こうして、構成, 、省スペースで、I/O負荷を低減し、信頼性の高い動作を実現する。.

テーブルレベルでの有効化

グローバル変数が適切に設定された後、テーブルごとにページ圧縮を有効にし、最大の効果をもたらすレコードを的確に指定できるようにしています。新しいテーブルの場合は、DDL内で直接オプションを設定します。既存のテーブルについては、ALTER TABLE ステートメントによって再書き込みを行い、変更を適用します。圧縮レベルは PAGE_COMPRESSION_LEVEL で定義しますが、その動作は使用される アルゴリズム 。移行には時間がかかるため、メンテナンスの時間を確保し、実際のデータサンプルを用いて、圧縮ありとなしの両方のケースで必要な容量を確認しています。このようにして、私は支出そして、予想通りの結果となった。.

CREATE TABLE log_entries (
    id BIGINT UNSIGNED PRIMARY KEY,
    created_at DATETIME NOT NULL,
    level VARCHAR(20),
    message TEXT
) ENGINE=InnoDB
  PAGE_COMPRESSED=1
  PAGE_COMPRESSION_LEVEL=6;

ALTER TABLE log_entries
  ENGINE=InnoDB,
  PAGE_COMPRESSED=1;

実運用におけるストレージの節約

データが均一で、テキストの割合が高ければ高いほど、その効果はより顕著になる圧縮; ログやレポート用のテーブルでは、たいてい顕著な効果が得られます。一般的なワークロードでは、zlibを使用すると使用メモリ量が40～60 %減少することがよくありますが、lz4では多くのケースで30～50 %の削減にとどまり、その分、スループットに余裕が残ります。高度に分散されたバイナリデータではその効果は小さくなりますが、それでもI/O量やコストが顕著に削減されるケースは少なくありません。私は常に、生産環境のスナップショットをステージング環境でテストし、有意義な比率を導き出し、レイテンシのピークを特定するようにしています。その結果、ストレージ上のデータ量が減少し、転送時間が短縮され、パフォーマンスが向上します。 スケーリング.

パフォーマンス：I/OとCPUの正しい評価

まず、ボトルネックがデータキャリアにあるのか、それとも CPU という点にあり、これによって圧縮方式の選択が決まります。I/Oがボトルネックとなる環境では、読み取りおよび書き込み量が大幅に減少するため、実効パフォーマンスが向上します。高速なアルゴリズムを使用した場合、非圧縮テーブルと比較して、追加負荷はわずか5～10 %にとどまることがよくあります。 CPUがボトルネックとなるシステムでは、処理速度が非常に速く、圧縮率もわずかに低いlz4やlzoが有効です。さらに、以下の点にも留意しています。ダブルライト・バッファ, 、それは書き込み動作に影響を与え、ページ圧縮と相まってI/O特性を形作るためである。バッファプールは非圧縮のままとなるため、頻繁なキャッシュヒットは レイテンシー より。

アルゴリズムの選択と圧縮レベル

を決める。 アルゴリズム-圧縮率だけに頼るのではなく、データパターン、読み書き速度、CPUの余裕度に基づいて判断します。Zlibは、適度な計算負荷で最大の容量削減効果をもたらすことが多く、一方lz4/lzoは低レイテンシが特徴です。 LZMAやbzip2はCPU負荷が高いため、主にアーカイブや変更頻度の低いテーブルに使用しています。圧縮レベル（PAGE_COMPRESSION_LEVEL）は、圧縮率と処理負荷のバランスを調整しますが、中程度のレベルを超えると限界効用は低下します。実際のデータセットを用いて簡単な測定を行うことで、最適な設定を素早く見つけることができます。 レベル.

アルゴリズム	一般的な金利	CPUコスト	適合性	備考
zlib	40–60 %	ミディアム	多数のOLTP／レポート用テーブル	宜しいバランスレート／レイテンシから
lz4	30–50 %	低い	高いスループット要件	非常に速い減圧
lzo	30–50 %	低い	書き込みが頻繁に行われるワークロード	インサート時の低レイテンシー
lzma	50–70 %	高い	アーカイブ／古いデータ	希少なものについては変更点
bzip2	50–70 %	高い	選択的な歴史	ゆっくり、視聴率も上々

モニタリングと指標を常に把握しておく

スループット、レイテンシ、CPU使用率、および バッファプール-ヒット率。全体像を把握して初めて、実際の効果がわかるからだ。レイテンシが横ばいまたは改善された状態でI/O量が減少した場合は、設定が適切であることを示しています。CPU使用率が適正レベルを超えて上昇した場合は、アルゴリズムとレベルを確認し、必要に応じてlz4に切り替えます。さらに、リドゥログのサイズとチェックポイントの挙動にも注意を払っています。これらはいずれも書き込みプロファイルに影響を与えるためです。長期的に傾向を把握することで、変化した状況に対して先手を打って対応することが可能になります。 ワークロード 反応する。

バックアップとメンテナンスをしっかりと計画する

フルバックアップおよび増分バックアップでは、 データ量, 、これはコピーされるバイト数が少なくなるためですが、論理ダンプは通常、そのサイズを維持します。私は実際のデータを使って復元時間をテストし、節約できた容量と実際の復元にかかる時間を天秤にかけて判断しています。アルゴリズムやレベルへの変更は文書化し、使用しているMariaDBバージョンとのバックアップツールの互換性を確認しています。また、特に多数のテーブルがページ圧縮に切り替えられた場合、大規模なALTER TABLE操作後の整合性を検証しています。これにより、 リスタート時間 予測可能であり、バックアップ戦略も信頼性が高い。.

ファイルシステムとストレージ層の理解

スパースファイルが機能するためには、ファイルシステムには以下が必要です。 穴あけ, 。これはext4やXFSで利用可能であり、ホスティング環境では広く普及しています。マウントオプションやキュー深度には特に注意を払っています。これらはI/O特性に大きな影響を与えるからです。 ext4については、コミット間隔やジャーナルモードなどを確認し、SSD/NVMeにおけるガベージコレクションの影響も考慮に入れます。適切な ext4のオプションページ圧縮の効果をファイルシステムの特徴に合わせて調整するのに役立ちます。そこで、私は物理的な ストレージ 効率的であり、副作用を防ぐ。.

導入のための実践ガイド

まずはテスト環境を立ち上げ、代表的な本番データをコピーして、クォータ、レイテンシ、および スループット を取得します。その後、まず、更新頻度が低く、主に読み取りが行われる大規模なテーブルやアーカイブに対して、ページ圧縮を有効にします。結果は明確な指標に基づいて評価し、初期状態と比較した上で、他のテーブルへの適用を進めます。アプリケーションチームとの早期の連携により、メンテナンスウィンドウでの予期せぬ事態を防ぎ、明確な期待値を設定できます。適用範囲を拡大するたびに、レベルと アルゴリズム 保存容量の削減とレイテンシが目標範囲内に入るまで。.

その他の最適化との組み合わせ

優れたインデックスは閲覧ページ数を減らすため、私は確認している インデックスのカバー範囲 およびカーディナリティを定期的に確認する。適切に記述されたクエリ、適切な結合、そしてEXPLAINの的確な活用により、I/Oを削減し、キャッシュヒット率を高く維持できます。十分な大きさのバッファプールを確保することで、ディスクからの不要な読み込みを防止し、ホットセットにおける圧縮オーバーヘッドを実質的に目立たなくすることができます。ハードウェア面では、SSDやNVMeの高いIOPSと低いレイテンシが効果を発揮し、ページ圧縮の利点をさらに高めます。総じて、圧縮はクエリ設計、インデックスの活用、および ストレージの拡張 を組み合わせることで、スリムなデータパスを形成します。.

互換性、バージョン、および制限事項

ページ圧縮がどの環境でサポートされており、どこに制限があるのかを常に把握しています。ext4 や XFS といった一般的な Linux ファイルシステムでは、ホールパンチングは安定して動作します。ZFS の場合は状況が異なります。ZFS では同等のパンチング機能が利用できないため、ZFS ではむしろ ネイティブ ZFSの圧縮を有効にし、ページ圧縮は使用しません。OverlayFSを使用したコンテナ環境では、パンチングやスパースファイルが確実に機能するように、データディレクトリをホストからバインドマウントとしてマウントすることを推奨します。また、ページ圧縮とファイルレベルのInnoDBテーブル暗号化を併用することは避けています。暗号化を行うと、データが圧縮アルゴリズムにとってほぼランダムな状態になり、場合によってはパンチングも阻害されるためです。両方が必要な場合は、InnoDBの下位層でボリューム／ファイルシステム暗号化を採用してください。.

InnoDBのページサイズ（innodb_page_size）については、私は通常16Kに設定しています。ページサイズを小さくしすぎると、圧縮が難しくなり、管理上のオーバーヘッドが増加する可能性があります。一時テーブルやMEMORY/作業用テーブルは、ページ圧縮の影響を受けません。圧縮によるメリットは、該当する.ibdテーブルスペース内でのみ得られます。.

予期せぬ事態のないアクティベーション、デアクティベーション、およびリビルド

ALTER TABLE による変更では、常にテーブルの再構築が行われます。そのため、私は次のように計画しています：

明確なSLAが定められ、一時コピー用の十分なストレージ容量が確保されたメンテナンスウィンドウ。.
ALTER に対する EXPLAIN による事前確認を行い、予想される処理方法（INPLACE/COPY、ロックレベル）を確認する。.
オプションのバッチ処理戦略：まず、変更頻度の低い大規模なテーブルを処理し、次に中規模のテーブルを処理し、最後に（もしあれば）頻繁に更新されるテーブルを処理する。.

この機能を無効にするには、対称的な手順を踏んで PAGE_COMPRESSED=0 を設定します。その後、OPTIMIZE TABLE または ALTER リビルドを再度実行し、テーブルスペースに空き領域が生じない状態で書き込みが行われ、物理的な使用容量が現実的に反映されるようにします。.

一括読み込み、ホットアップデート、およびデフラグ

大量データの取り込みについては、I/Oリソースが逼迫している場合は圧縮された状態で直接読み込むか、あるいは非圧縮状態で読み込んでから`ALTER TABLE`を使用して`PAGE_COMPRESSED`に切り替えることで、インポートを高速化しています。その後、リビルドを実行することで、ホールパンチング効果が最大化される最適なレイアウトが強制的に適用されます。インプレース更新が非常に多いテーブルについては、繰り返しの変更によって時間の経過とともに圧縮の効果が低下する可能性があるため、定期的なリライト（OPTIMIZE TABLE またはパーティションのロールオーバー）を計画しています。 BLOB/TEXT 列については、大容量のオフページデータを効率的に処理し、ページ間の隣接領域が不必要に拡大しないよう、最新の行形式（例：DYNAMIC）を採用しています。.

有効性を検証し、実証する

ページ圧縮が有効になっているかどうかは、簡単なシステムコマンドとMariaDBのビューを使って確認します：

# 見かけのサイズと使用済みブロックの比較
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd

# ファイルごとのパンチングの程度を確認する
filefrag -v your_table.ibd | tail -n +1

# MariaDB：テーブルステータスとDDLオプションの確認
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G

見かけのサイズ（ls）は論理データ容量のままですが、実際に使用されているブロック数が表示されます。顕著な差が見られる場合は、ホールパンチングが正常に機能していることを示しています。この測定値を、I/Oメトリクス（秒あたりの読み取り/書き込み回数、キューの深さ、レイテンシ）およびCPU使用率と照らし合わせて、全体的な効果を評価します。.

バックアップの詳細：Sparseデータを正しくバックアップおよび復元する

バックアップ時にスペースの節約が適切に行われるよう、使用するツールがスパース対応であるかを確認しています。物理ファイルをコピーする際は、空いた領域が「埋められない」ように、適切なオプションを使用しています：

# スパース領域を維持したままコピーする
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir

# コピー先のファイルが引き続きスパース状態であるか確認する
du -h dest.ibd
ls -ls dest.ibd

スナップショットバックアップ（例：ブロックデバイスレベル）の場合、その効果の大きさはプロバイダーによって異なります。論理ダンプ（mysqldump、mariadb-dump）の場合、エクスポートサイズにほとんど変化はありませんが、その後のリビルドでページ圧縮が再度有効化され、再構築時のI/O量が削減されるため、復元時間は短縮されます。.

運用におけるレプリケーション、HA、およびロールアウト

ページ圧縮は、レプリケーションやバイナリログに対して透過的に機能します。これは、レプリケートされるのはSQLの変更であり、圧縮されたページそのものではないためです。私は、DDLの変更については、まずレプリカに展開し、レイテンシやI/Oを監視した上で、プライマリサーバーの切り替えを行うことを優先しています。マルチソースまたはカスケードトポロジーの場合は、同一のDDLが同じ挙動を示すよう、すべてのノードで適切なアルゴリズム（innodb_compression_algorithm）が設定されていることを確認します。ダウンタイムゼロのロールアウトを実現するため、切り替え作業をスイッチオーバー／フェイルオーバー計画と組み合わせて実施します。.

より詳細なチューニング：I/Oプロファイルとチェックポイント

圧縮によって書き込み対象のブロックの数とサイズが変わるため、InnoDBのI/Oパラメータを新しいプロファイルに合わせて調整します。現実的なinnodb_io_capacity（および*_max）を設定することで、フラッシュの急激なピークが発生することなく、クリーンなチェックポイントを作成できるようになります。ダブルライトバッファが新しい書き込み特性と調和しているかを確認し、ダーティページとfsyncレートの比率を監視します。並列処理能力の高いデバイス（NVMe）では、書き込みスレッド数とブロックデバイスのキュー深度を調整し、データ量の減少が実際のレイテンシ低減につながるようにします。.

トラブルシューティングとよくある問題点

有効化後のCPUピーク値： アルゴリズムをlz4/lzoに変更するか、PAGE_COMPRESSION_LEVELを適度に下げるか、バッファプール内のホットセットを拡大する。.
I/Oは減少するが、レイテンシは変動する： チェックポイントとダーティページ率を確認する。リドゥログが小さすぎると、フラッシュが頻繁に発生する。.
予想外にスペースの節約効果が低い： データ構造を確認する（バイナリ／ランダムなフィールドが多い場合）、リビルドを強制実行し、BLOB／TEXTのパターンを分析し、必要に応じてzlibに切り替える。.
ファイルサイズには影響しません： ファイルシステムのホールパンチング対応を確認し、コンテナレイヤーを避け、スパースコピーを「非スパース化」しないようにする。.
話題沸騰中の表： ページ圧縮を適宜適用する。代替案を検討する（アーカイブ／ログテーブルのみを圧縮する）。.

実務に即した設定例

スムーズなスタートを切るために、グローバル設定は簡潔で管理しやすいものにしています：

[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib   # またはプロファイルに応じて lz4/lzo
# プラットフォームに合わせてその他の I/O パラメータを調整
# innodb_io_capacity=...
# innodb_io_capacity_max=...

各テーブルごとに圧縮を明示的に定義し、意図しない副作用が生じないようにしています。大規模なインポートや多数の更新を行った後は、OPTIMIZE TABLE を適切に実行して、空き領域を再調整し、時間の経過とともに生じた断片化を軽減しています。.

簡単にまとめると

InnoDBのページ圧縮は、メモリ使用量を著しく削減し、負荷を 入出力 バッファプールを変更することなくCPUに直接アクセスします。lz4やzlibのような適切に選択されたアルゴリズムは、多くのワークロードにおいて30～60 %の削減効果をもたらし、レイテンシも許容範囲内に収まります。重要なのは、ホールパンチング機能を備えたファイルシステム、innodb_file_per_tableの設定、そしてテーブルレベルでの適切な有効化です。実際のデータを用いたテストを実施し、モニタリングを組み込み、レベルやアルゴリズムを微調整することで、信頼性を確保しつつ、長期的に低コストを実現できます。 パフォーマンス. これにより、スペースを節約し、システムの動作をスムーズに保ち、増え続けるデータセットに対応するための余裕を確保できます。.