MySQL データ圧縮パフォーマンス比較の詳細

データ キューブに必要なデータは、書き込まれるとほとんど更新されないか、まったく更新されません。この種のデータは、ディスク使用量を削減するために圧縮するのに適しています。 MySQL 自体は、 archiveエンジンとMyISAMエンジン用のmyisampackメソッドの 2 つの圧縮方法を提供します。本日は、これら 2 つの方法を個別にテストし、ディスク使用量とクエリ パフォーマンスの観点からそれぞれの利点と欠点を比較しました。なぜこのようなことをするのかについては、後ほど紹介しますので、ご理解いただければと思います。そしてテキストを見てください:

1. テスト環境

1.1 ハードウェアとソフトウェア

64 ビット2.6.18-92カーネルLinux開発マシン、4G メモリ、4 つの2800Mhz Dual-Core AMD Opteron (tm) Processor 2220 CPU。

MySQL はraidではなく、7200 rpm SAT ハードディスクに配置されます。

MySQL に対して最適化は行われず、 query cacheテスト結果に干渉するのを防ぐためにquery cacheはオフにされました。

1.2 テーブル構造

2,424,753 件のレコード、実稼働環境のシャードの実際のデータ。

結合インデックス ( partition_by1,idx_rank ) と ( partition_by1,chg_idx ) がそれぞれ確立されます。ここで、partition_by1 は長さ 32 の varchar 型であり、取得に使用されます。他の 2 つのフィールドは浮動小数点数であり、主に並べ替えに使用されます。

サブ列として、 autokid PRIMARY KEYとして機能し、データのロード中にアトミック性を保証するためにのみ使用されます。実用的な意味はありません。

2. テストの目的

2.1 圧縮空間の比較

圧縮率が高いほど、占有するディスク容量が少なくなり、データ保存コストが直接的に削減されます。

2.2 クエリパフォーマンスの比較

圧縮後、クエリ パフォーマンスに顕著な低下は発生しないはずです。 Archiveインデックスをサポートしていないため、パフォーマンスの低下は避けられません。パフォーマンスがどの程度低下するのか、それが許容できるのかどうかについても把握しておく必要があります。

3. テストツール

3.1 mysqlslap

もちろん公式ツールが最良の選択です。 mysqlslapの概要については、公式ドキュメントを参照してください。

3.2 テストクエリ

実稼働環境でtopranks_v3テーブルにアクセスする実際の SQL ステートメントの合計 9973 件がインターセプトされ、その中からアクセス回数が最も多い 7 件が抽出され、同時実行数は 50 で 10 回繰り返されました。コマンドは次のとおりです。

./mysqlslap --defaults-file=../etc/my.cnf -u**** -p**** -c50 -i10 -q ../t.sql --debug-info

4. テストの結論

上記の表に示されているテスト データに基づいて、次のような結論を簡単に導き出すことができます。

• テストテーブルの場合、 Archiveテーブルが占めるスペースは以前のスペースの約18.7%で、 myisampack後の占有スペースは以前のスペースの約 24.6% です。両者の差はそれほど大きくありません。スペース使用率の観点からのみ見ると、 archiveテーブルを選択する必要があるようです。
• クエリのパフォーマンスを確認し、ベンチマーク テーブルと比較してみましょう。合計時間とシステム負荷の点では、50 同時実行でのpackテーブルのクエリ パフォーマンスはベンチマーク テーブルと同等ですが、 archiveテーブルでは 1 同時実行で 5 分以上かかります (これ以上待てないので、強制終了します)。

したがって、オンライン クエリを必要とするテーブルの場合、 ARCHIVEエンジンは基本的に無視できると結論付けることができるようです。

このテスト中にARCHIVEエンジンが遅いのはなぜですか?

mysqlディスク オーバーヘッドを削減するためにarchiveストレージ エンジンを提供していることはわかっていますが、前提条件もあります。つまり、アーカイブされたデータはオンラインでクエリする必要がないか、ほとんどクエリされないため、クエリが時々遅くなっても問題になりません。上記の理由により、 archiveテーブルでは自動インクリメント列以外のインデックスを作成することはできません。

このコンセンサスに基づいて、テスト SQL を使用して、インデックスを使用する前と使用後でクエリのパフォーマンスに大きな違いがある理由を分析してみましょう。

テスト SQL には次のような行があります。

mysqlslap.rpt_topranks_v3 から c1、c2、...、cn を選択します。
ここで... AND パーティション1 = '50008090'
追加数量3の降順で並べ替え
制限500

前に述べたように、テスト テーブルには、 partition_by1フィールドにインデックスがあります。したがって、このクエリでは、ベンチマーク テーブルとmyisampackテーブルのpartition_by1インデックスを使用する必要があると予備的に判断します。EXPLAIN :

mysql>説明
    -> mysqlslap.rpt_topranks_v3 から...を選択します
    -> WHERE ... AND パーティションバイ1 = '50008090'
    -> ORDER BY added_quantity3 DESC
    -> 制限 500\G
************************** 1. 行 ****************************
           id: 1
  選択タイプ: シンプル
        表: rpt_topranks_v3
         タイプ: ref
可能なキー: idx_toprank_pid、idx_toprank_chg
          キー: idx_toprank_pid
      キーの長さ: 99
          参照: 定数
         行数: 2477
        追加: USING WHERE; USING filesort
1 行 IN SET (0.00 秒)

予想どおり、このクエリは、 partition_by1フィールドのインデックスを使用し、ターゲット行数 2477 と一致し、次にadded_quantity3フィールドでソートが行われます。 added_quantity3にはインデックスがないため、 filesortが使用されます。

アーカイブ テーブルでのこの SQL の EXPLAIN 結果を見てみましょう。

mysql>説明
    -> mysqlslap.rpt_topranks_v3_<strong>アーカイブ</strong>から...を選択します
    -> WHERE ... AND パーティションバイ1 = '50008090'
    -> ORDER BY added_quantity3 DESC
    -> 制限 500\G
************************** 1. 行 ****************************
           id: 1
  選択タイプ: シンプル
        表: rpt_topranks_v3_archive
         タイプ: すべて
可能なキー: NULL
          キー: NULL
      キー長さ: NULL
          参照: NULL
         行数: 2424753
        追加: USING WHERE; USING filesort
1 行 IN SET (0.00 秒)

EXPLAIN は次のように言います: 「使用可能なインデックスがないので、テーブル全体をスキャンして 2424753 行を取得し、 filesort実行することしかできません。」 パフォーマンスを重視する場合、明らかにMySQL誤って使用しています。

これで、MySQL データ圧縮パフォーマンス比較の詳細に関するこの記事は終了です。MySQL データ圧縮パフォーマンス比較の詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。