バラクーダと圧縮の利点
私はMySQLのファイル形式であるアンテロープとバラクーダについて少し前から読んでおり、バラクーダと圧縮を使用することで利益を得られるかどうか疑問に思っています。
私のサーバーは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つの点は改善されないだろうと思ったので、CPU使用率が意味をなさない増加する？
読み取り/書き込みの多いアプリケーションでメリットがありますか？バラクーダと圧縮に変更することを勧めますか？
バラクーダの問題を知っていますか？
次の質問の答えはいくつかの問題を指摘しているようですが、2011年からなので、今では修正されていると思います： https://serverfault.com/questions/258022/ mysql-innodb-how-to-switch-to-barracuda-format
"Dynamic"については、非圧縮のバラクーダのみの形式で、主にでコンパクトからほとんど変更されていません。ブロブ（および非常に動的なフィールド）の格納方法。コンパクトとダイナミックの問題は一度もないので、バラクーダのダイナミックを安全に推奨できます。 Barracudaは古い冗長でコンパクトな行フォーマットもサポートしていることに注意してください。
あなたが言及している記事はおそらく古すぎる（5.1）であり、PerconaのCEOであるPeter Z.はコメントについて少し誤解を招く可能性があると述べています。これは、ワークロードによっては圧縮が大きな利益になり得ないという意味ではありません。ただし、FacebookとOracleの両方で多くの改善が行われているため、5.6以上のバージョンで試してみることをお勧めします。
最近の参考資料として、次のことをお勧めします。
特に、私はFacebookの資料が好きです。彼らはサードパーティであり（議題は必要ありません）、MySQLが世界で最大規模で展開されているためです。ご覧のとおり、SSDテクノロジーと圧縮を組み合わせた非常に成功したセットアップが行われています。
メリットはありますか？ ワークロード、ワーキングセット、セットアップ（IOPS、メモリ）によって異なります。 IOバウンド、CPUバウンド、メモリバウンドのいずれであるかに応じて、追加のCPU、メモリ要件を追加することにより、圧縮がマイナスの影響を与える場合があります（圧縮ページと非圧縮ページの両方がInnoDBバッファープールに保存されます） ）または、非常に多くの圧縮エラーが発生し、レイテンシが増加します。これは、データのタイプにも依存します。圧縮は、大きなテキストBLOBの場合に役立ちますが、既に圧縮されたデータでは役に立たない場合があります。
私の経験では、実際には、圧縮がパフォーマンスの聖杯であり、非常に満足している人がいますが、それ以外の場合、利益が得られなかったため、非圧縮データに戻さなければなりませんでした。非常に重い書き込みワークロードは圧縮に適さない環境のように思えるかもしれませんが、特定のケースでCPUバウンドでもメモリバウンドでもない場合は、IOPSバウンドであると役に立ちます。
一般に、結果を予測することは非常に困難です。通常、ベンチマーク用のテスト環境をセットアップしてから、結果の良し悪しを確認する必要があります（そのようにして、さまざまなブロックサイズで遊ぶことができます）。バラクーダは完全に安全です。圧縮が適している場合とそうでない場合があります。そして、ブロブのクライアント側の圧縮などのその他の圧縮方法をいつでも試すことができます（たとえば、CPUにバインドされている場合）またはその他RocksDBやTokuDBなどのサードパーティエンジン。InnoDBが処理できるよりも大きなデータセットのパフォーマンスに重点が置かれているため、圧縮が優先されます。
一言で言えば、バラクーダを使用する主な理由は、BLOB処理、innodb_large_prefix互換性（大きなインデックス）と圧縮。動的、MySQL 8.0ではデフォルトのファイル形式になりました。