バラクーダと圧縮の利点


12

私はMySQLのファイル形式AntelopeとBarracudaについて少し前に読んでいますが、BarracudaとCompressionを利用することで利益が得られるのではないかと考えています。

私のサーバーはMySQLのデフォルトであるため、現在Antelopeを使用しています。
私が持っている大規模なデータベースのために、メモリに関する問題が何度もありました。私のデータベースは毎日増加しています。

http://www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/のような圧縮は、少数の人々に利益をもたらしているようです

私はメモリとディスク容量が低くなることを理解していますが、これを理解しているかどうかはわかりません(記事から引用):
「トップに応じて〜5%のCPU負荷(80〜100%からほとんどI / Oを待っています)
0.01主キーによる平均検索時間(変換前の1〜20秒)

データが圧縮されている場合、サーバーは元のデータを再度取得するために圧縮を解除する必要があるため、これらの2つのことは改善されないと考えました。

これは、読み取り/書き込み集中型のアプリケーションで役立ちますか?Barracuda and Compressionに変更することをお勧めしますか?

バラクーダの問題を知っていますか?
次の質問の答えはいくつかの問題を指摘しているようですが、2011年からですので、今では修正されていると思います:https : //serverfault.com/questions/258022/mysql-innodb-how-to-switch -to-barracuda-format

回答:


14

圧縮されていないBarracudaのみの形式である「ダイナミック」については、主にブロブ(および非常に動的なフィールド)の格納方法がコンパクトからほとんど変わりません。コンパクトとダイナミックの問題は一度もなかったので、バラクーダのダイナミックを安全に推奨できます。バラクーダは、古い冗長でコンパクトな行フォーマットもサポートしていることに注意してください。

あなたが言及している記事はおそらく古すぎます(5.1)。そして、PerconaのCEOであるPeter Z.がコメントについて言及しているように、それは少し誤解を招くかもしれません。それは、ワークロードによっては、圧縮が大きな利益にならないという意味ではありません。ただし、FacebookとOracleの両方で多くの改善が行われているため、5.6以上のバージョンで試してみることをお勧めします。

最近の参考資料として、次のことをお勧めします。

特に、Facebookの資料はサードパーティであり(議題は不要)、世界最大のMySQL展開の1つを持っているので気に入っています。ご覧のとおり、SSDテクノロジーと圧縮を組み合わせたセットアップは非常に成功しています。

それはあなたに利益をもたらしますか?それは、ワークロード、ワーキングセット、およびセットアップ(IOPS、メモリ)に依存します。IOバウンド、CPUバウンド、またはメモリバウンドのいずれであるかに応じて、CPU、メモリー要件(圧縮および非圧縮の両方のページがInnoDBバッファープールに保存される)を追加するか、圧縮エラーが多すぎるため、圧縮がマイナスの影響を与える場合がありますレイテンシー。また、データの種類にも依存します。大きなテキストBLOBでは圧縮は非常に役立ちますが、すでに圧縮されたデータでは役に立たない場合があります。

私の経験では、実際には、圧縮がパフォーマンスの聖杯であり、非常に満足している人がいますが、他の場合には、ゲインが得られなかったため、非圧縮データに戻す必要がありました。非常に重い書き込みワークロードは圧縮の悪い環境のように思えるかもしれませんが、特定のケースでCPUバウンドとメモリバウンドではなく、iopsバウンドではない場合、それは役に立たないかもしれません。

一般に、結果を予測することは非常に困難です。通常、ベンチマーク用のテスト環境をセットアップし、結果が良くなるか悪くなる理由を発見する必要があります(また、異なるブロックサイズでプレイできる方法など)。バラクーダは完全に安全です。圧縮はあなたのためかもしれません。また、BLOBのクライアント側の圧縮(CPUにバインドされた場合など)や、RocksDBやTokuDBなど、圧縮が重視されるため、圧縮が大きな優先事項である他のサードパーティエンジンなど、他の圧縮方法をいつでも試すことができますInnoDBが処理できるよりも大きなデータセットのパフォーマンスが向上します。

簡単に言うと、Barracudaを使用する主な理由は、BLOB処理、innodb_large_prefix互換性(大きなインデックス)、圧縮です。動的、MySQL 8.0ではデフォルトのファイル形式になりました。


1
これは本当にすてきな答えです!それはすべて理にかなっており、まさに私が望んだ答えのタイプです。MySQL 5.6(最近アップグレードしたもの)に言及し、Facebookを例として紹介しています。これは、通常、他の誰よりも先に課題を克服する必要があるためです。残念ながら、テスト環境は実稼働と同じCPU / IO / RAM負荷を持たないため、これを最初にテストするのは簡単ではありませんが、実際に試してみる必要があります!ご清聴ありがとうございました。
ヌーノ14

行形式はテーブルレベルで選択できるため、実稼働環境でのテスト(別のマシンでの適切なテスト後)に柔軟性を持たせることができます。ただし、このアプローチでは、デバッグとベンチマークがさらに困難になる可能性があります。
jynus

うん、私はおそらく最初にいくつかのテーブルを変換しようとすることができます(おそらくそれほど大きくない/使用されていないテーブル)。ただし、大きなものについては、一度にすべてを変換する1つのダウンタイムではなく、数回のダウンタイムが必要になります。最善のアプローチは何かを見なければなりません。しかし、なぜデバッグが難しくなるのかわかりません。ここで正確に何を意味しますか?どうもありがとうございました。
ヌーノ14

1
オンラインでテーブルを再作成するには、pt-online-schema-changepercona.com/doc/percona - toolkit/2.2/…などのツールがあります。いくつかのテーブルだけを混在させると、エンジンの変更や通常の負荷の変更や、再作成時のキャッシュの変更により、CPU /メモリ/ IOPSの変更を測定するのが難しくなる可能性があると述べました。また、異なるハードウェアを搭載した別のマシンで見るのは難しいので、幸運を祈ります!
jynus

ZFSでは、ファイルシステムでLZ4を使用する場合に必ずしも良くないというわけではありません。
デニスデニソフ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.