このページは機械翻訳したものです。

15.9.1.6 OLTP ワークロードの圧縮

従来、InnoDB の圧縮機能は、データウェアハウス構成などで、主に読み取り専用または読み取りが大半のワークロードに対して使用することが推奨されていました。 高速だが比較的小規模でコストがかかる SSD ストレージデバイスの増加により、OLTP ワークロードにも圧縮が魅力的になります: トラフィック量の多い対話型 web サイトでは、INSERT、UPDATE および DELETE の操作を頻繁に行うアプリケーションで圧縮テーブルを使用することで、ストレージ要件および秒当たりの I/O 操作 (IOPS) を減らすことができます。

これらの構成オプションを使用すると、書込み集中型操作のパフォーマンスとスケーラビリティに重点を置いて、特定の MySQL インスタンスの圧縮方法を調整できます:

• innodb_compression_level を使用すると、圧縮の程度を上げたり、下げたりできます。 値を大きくすると、ストレージデバイス上に収容できるデータ量が多くなりますが、圧縮時の CPU オーバーヘッドも多くなるという犠牲が伴います。 値を小さくすると、ストレージ領域がクリティカルでない場合に、CPU のオーバーヘッドを削減できます。それ以外の場合は、データが特に圧縮可能でないと予測されます。

• innodb_compression_failure_threshold_pct には、圧縮テーブルへの更新時に圧縮が失敗したときのカットオフポイントが指定されます。 このしきい値を超えると、MySQL は、最大で innodb_compression_pad_pct_max で指定されたページサイズの割合まで空き領域の量を動的に調整することで、新しい各圧縮済みページ内に追加の空き領域を残し始めます。

• innodb_compression_pad_pct_max を使用すると、ページ全体を再度圧縮する必要なしで、変更を圧縮済み行に記録するための各ページ内に予約されている領域の最大量を調整できます。 値を大きくすると、ページを再度圧縮せずに記録できる変更の量が多くなります。 MySQL では、実行時に指定した割合の圧縮操作に「失敗した」ときにのみ、各圧縮テーブル内にあるページ用に可変量の空き領域が使用されますが、圧縮済みページを分割するために負荷の高い操作が必要となります。

• innodb_log_compressed_pages では、redo log への re-compressed pages のイメージの書込みを無効にできます。 圧縮されたデータが変更されると、再圧縮が発生する場合があります。 このオプションは、リカバリ時に異なるバージョンの zlib 圧縮アルゴリズムが使用された場合に発生する可能性がある破損を防ぐために、デフォルトで有効になっています。 zlib のバージョンが変更されないことが確実な場合は、innodb_log_compressed_pages を無効にして、圧縮データを変更するワークロードの redo ログ生成を減らします。

圧縮済みデータを操作すると、圧縮済みと非圧縮の両方のバージョンのページが同時にメモリー内に保持されるため、OLTP スタイルのワークロードで圧縮を使用するときは、innodb_buffer_pool_size 構成オプションの値を大きくする準備をしてください。