ZIP vs 7Z vs ZSTD: 実世界データによる徹底比較

ZIP、7Z、ZSTDのどれを選ぶかは、アプリケーションのデプロイ、日々のバックアップの送信、ストレージや帯域幅のコスト削減（ファイルの圧縮と解凍の方法を参照）が必要になるまでは些細な問題のように思えるかもしれません。実際には、この選択は配信時間、CPU/RAMの使用率、さらにはサードパーティ製のツールやシステムとの互換性にも影響します。

実際のデータと非常に異なるコンテキスト（デプロイメント用の5,4 GB の .NET データセット、 1 GB のWikipediaテキスト コーパス、コンテナ イメージ、28,7 GB のバイナリなど）を使用した複数のベンチマークをレビューした結果、比率を優先すべきタイミング、解凍速度が重要な場合、互換性がどのような影響を与えるか（従来の ZIP、ZSTD を使用した ZIP、LZMA2 または代替コーデックを使用した 7Z など）が明らかになりました。

何を比較するのか、そしてなぜそれが重要なのか

最も一般的に使用されているアーカイブ形式であるZIP（Deflate）、7Z（LZMA/LZMA2）、およびZSTDを分析しました。Brotli 、XZ、bzip2、zpaq、およびLZ4も議論に含めています。なぜなら、実際のシナリオでは、単純な直接比較はめったにできないからです。たとえば、.NET環境では、互換性、スループット、および速度のバランスは、一括バックアップや配布パッケージのパッケージングとは異なる重み付けになります。

状況によって最適なソリューションは異なります。導入時間の短縮と包括的なサポートを求める場合と、 15個のバックアップファイルの保存容量を最小限に抑え（さらに圧縮ファイルを分割し）、データ転送コストを最適化する場合では、選択肢が全く異なります。幸いなことに、現在では比較可能な数値と明確なパターンが存在するため、情報に基づいた意思決定を行うことができます。

各フォーマットの仕組み（そして実際の意味）

• ZIP（圧縮） LZ77とハフマンを組み合わせた、老舗で広く普及し、完全な互換性を持つ圧縮方式です。圧縮率や速度では最新の圧縮方式に勝ることはありません。 どこでも開く （方法を見る ブラウザ拡張機能を管理する）であり、その実装は安定しており、よく知られています。従来のZIP（方法8）には歴史的な制限がありましたが、現代の圧縮技術はこれらの制約の多くを克服しています。
• 7Z それは主に LZMA/LZMA2非常に優れた比率と成熟したツールを備えています。さらに、7-Zipは並列化に優れており、「賢明なデフォルト» 機敏な気分になれる。 事実上の標準 デスクトップおよび開発環境で幅広くサポートされています Windows, Linux および macOS (場合によっては外部ユーティリティを使用)。
• Z標準（ZSTD）によって作成された Facebook （2015年）は、 極めて急速な減圧 非常に幅広いレベルパレット（1～22）を備えています。Deflateと同等かそれ以上の性能を実現し、LZMAに比肩する比率で、一般的に高速な実行速度を実現することを目指しています。BSD/Linuxカーネルに統合されています。 パケット圧縮 (例: Arch Linux は zstd レベル 20 を使用しており、XZ よりも 14 倍高速に解凍され、サイズはわずか +0,8% です)。また、CI/CD パイプラインでもますます普及しています。

知っておくべき他の俳優

• ブロトリウェブ用に設計されたこの圧縮方式は、テキストコンテンツをgzipよりも圧縮率が高く、 コンテンツエンコーディング ブラウザの圧縮ベンチマークはシングルスレッドであるため、時間の比較が歪んでしまいます。 本物の壁掛け時計 マルチスレッドコーデックを扱う場合、並列実装も存在します。サーバー環境では、消費電力は 合計CPU（ユーザー+システム） 壁掛け時計よりも関連性が高いです。
• XZ LZMAを改善し、犠牲にして優れた比率を提供します 圧縮時間が長い大きなバイナリの場合、競争力はありますが、解凍速度はZSTDや7Zに劣ることが多いです。マルチスレッドの同時実行性とパラメータ -e（極端） 奇跡を起こすわけではありませんが、写真の品質はいくらか向上します。
• bzip2/pbzip2 比率とCPUのバランスはボードの中央付近でとられています。 pbzip2 並列性は得られる。しかし、多くの現代のケースでは、ZSTDと7Zの方が優れている。 トレードオフ グローバル
• ズパック 彼は「最大比率の全地形対応車» ジャーナリング型の増分圧縮で、バイト数を圧縮することに重点を置いており、 減圧速度コールド バックアップの場合、これは良いアイデアかもしれませんが、一般的な用途ではそうではありません。

データを使用したベンチマーク: テキスト、大きなバイナリ、デプロイメント

1) テキストデータセット (Wikipedia 1 GB)

1 GB の Wikipedia テキストに対して、ZIP (7zip 経由)、7zip、XZ、Brotli、Zstandard、zpaqを比較し、各レベルで時間とサイズの関係をグラフ化しました。著者は、これらは非科学的なテストであり、Brotli のシングルスレッド参照は「実世界」の時間を過小評価していると述べています。ユーザー + システム コンピューティングでは、Brotli の状況は改善されます。ZSTD は非常に競争力があり、非常に高速に解凍し、高負荷時でも XZ/7zip に匹敵する比率を達成します。

主な調査結果： ZIPは圧縮率と処理時間において劣勢。7zipはより洗練されたツールとマルチスレッド処理で進化。XZは圧縮率を向上させるが、解凍速度はZSTDより遅い。ZSTDは処理量を増やすと非常に優れたバランスを実現。zpaqは特に解凍時にかなりの時間を要するものの、最高の圧縮率を達成。

2) PeaZip「最大圧縮」テスト（Windows、i7-8565U）

PeaZip/WinRARを使用し、入力ファイルサイズを303,0MB、テストごとに5回繰り返した場合、平均値は以下のとおりです（サイズはMB単位、時間は秒単位）。

フォーマット	サイズ	比	圧縮	抽出
RAR ベスト (WinRar)	78,1	25,78%	28,5	1,8
7Zウルトラ（LZMA2）	71,2	23,50%	137,0	3,4
7Zウルトラブロトリ	75,1	24,79%	208,0	0,8
7ZウルトラZstd	75,3	24,85%	300,0	1,2
7Z ウルトラ BZip2	80,6	26,60%	81,0	7,1
ZPAQウルトラ	57,6	19,01%	359,0	358,0

結論：ZPAQは圧縮率では優れていますが、解凍時でも非常に低速です。7Z （LZMA2）は圧縮率が高く、解凍も妥当です。7Z内でBrotli/ZSTDを使用すると、解凍が非常に高速になります（Brotliはさらに高速）。ただし、圧縮時間はLZMA2のウルトラ設定よりも長くなります。RARは圧縮速度を優先し、圧縮率を多少犠牲にしています。セキュリティが必要な場合は、圧縮ファイルにパスワードを設定する方法を学ぶことができます。

3) 巨大な28,7GBのバイナリ（Linux、Ryzen 5 5600G）

28,65～28,7 GBのファイルに対して、可能な限り圧縮し、xz、pbzip2、7z、zstdとの比率と時間を比較することが目標でした。

• xz -9e -T12: 12,6 GiB、約15分49秒（≈ 44,0%）
• pbzip2 -9: 13,07 GiB、約4分29秒（≈ 44,55%）
• 7z -mx=9: 12,9 GiB、約16分43秒（≈ 43,98%）
• zstd –ウルトラ -22 -T12: 12,48 GiB、約19分48秒（≈ 43,57%）

「最大圧縮」では、ZSTDがサイズでわずかに勝利しましたが、処理時間は長くなりました。pbzip2は速度で驚異的な結果を示し、同様の圧縮率を達成しました。この事例は、非常に大きなバイナリの場合、GB単位の絶対的な差は、分単位のCPU使用率と同じくらい重要であり、両方を定量化する価値があることを示しています。

4) ゲームZIP（EU4）とZSTDを使用したtar+brotliからZIPへの変換

実際の例：EU4のセーブデータは圧縮率の低いZIPファイルとして届きます。解凍と再圧縮をテストしたところ、再圧縮で約17%の容量削減ができました。ZIPファイル内のコーデックを変更した結果、レベルごとに以下の改善が見られました。

方法	削減	時間（ミリ秒）
zstd (3)	40%	463
zstd (5)	45%	755
zstd (7)	50%	1256
ブロトリ (4)	32%	1481
ブロトリ (9)	54%	4210

さらに、トランスコーディング用のWasm ペイロードは、ZSTD が約 215 kB (エンコーダのみの場合は 136 kB)、Brotli が約 683 kBです。解析では、キャッシュからのフェッチ時間 (ブラウザの Brotliコンテンツエンコーディングは無料ではありません) を考慮すると、ZSTD と Brotli のパフォーマンスは非常に似ていました。Brotliはユーザー空間に解凍しないため、解析がわずかに高速です。ZSTDはコンテンツエンコーディングに触れないため、ディスクからより効率的に読み取ることができます。

アップロード速度が 30 Mb/s の場合、一般的な 7,7 MB の ZIP ファイルでトランスコーディングと転送を統合すると、次のようになります。オリジナル2,05 秒、ZSTD-3 1,70 秒、ZSTD-5 1,88 秒、ZSTD-7 2,28 秒。ストレージ容量を節約するには、 ZSTD レベル 7が実用上推奨されます(バケット料金を支払う場合)。ただし、レイテンシを優先する場合は、レベル 3 も魅力的です。

5) .NET デプロイメント (5,4 GB 公開)

5,4 GB の出力を持つ .NET アプリケーション（自己完結型とフレームワーク依存型の混在）をデプロイする場合、実用的なガイドは明確です。目的に応じて選択してください。普遍的な互換性を目指すなら、従来の ZIP を使用します。ボトルネックが解凍と速度であれば、ZSTD が有力な候補となります。確立された CLI とツールで高いスループット比を求めるなら、LZMA2 を使用した 7Z が依然として最良の選択肢です。

減圧：体験の中で最も顕著な要素

複数の独立したテスト結果から、 ZSTDは解凍性能において群を抜いていることが示されています。テキストベンチマークでは、 user+sysを見ると、ZSTDがファイルシステム圧縮（自動圧縮を無効にする方法を参照）とパッケージラッピングに最適な理由が明らかになります。読み込みが速く、CPU負荷が低いためです。7 -Zipは非常に優れたユーザーエクスペリエンスを提供しており、XZとの違いはコーデックの魔法というよりも、ユーティリティとマルチスレッド処理によって説明できます。

ZIPはユーザー+システムファイルの解凍性能において予想をはるかに上回るパフォーマンスを発揮し、皆を驚かせました。対象とするユーザーのマシンがそれほど高性能でない場合や、高速な解凍が最優先されるワークフローの場合は、テストせずにZIPを候補から外すべきではありません。一方、 ZPAQは驚異的な効率性を誇るものの、解凍時間が非常に長いため、コールドバックアップに適しています。

ユースケース: データに基づいて決定する方法 (RAM、時間、比率、コスト)

コンテナプラットフォームのシナリオでは、 1日あたり30～100個のコンテナのバックアップが必要となるため、運用予算が最重要事項となります。そこで、実用的な評価システムが提案されました。

• RAM: 200 MB の圧縮と 100 MB の解凍を目標にすると 5 点になります。50 MB 以上ごとに 1 点減点されます。
• 時間: 毎日3時間、すべてのものを圧縮する時間枠。コンテナ1つあたり6～1,8分。スケールでは、120秒を超えるとスコア0、-20秒ごとにスコア1が加算されます。 10秒未満は5ポイント 減圧中。
• 比: 約 1,6 GB のオブジェクト (MariaDB + PHP + WordPress など) と、Backblaze/E2 タイプのバックエンドでの約 6 ドル/TB のストレージでは、4:1 以上を目指すと結果を抑えるのに役立ちます。 退出コスト (AWS では送信料金が 0,09 ドル/GB なので注意してください)。

テストレベルでは、ZSTD レベル 3 は207 MB の RAM で約 3 秒で約 3,5:1 を達成しました。Brotliレベル 6 は、適切な RAM プロファイルで約 30 秒で約 4,3:1 を達成しました。ZSTDのチューニング(strategy、searchLog、targetLength、minMatch) を調整しても、時間やメモリを犠牲にすることなくパフォーマンスを十分に向上させることはできませんでした。この特定の分析では、Brotli レベル 6 が最も優れていることがわかりました。興味深いことに、Brotli レベル 4 はレベル 3 および 5 よりも多くのメモリを使用しましたが、半分の時間でレベル 5 の比率に匹敵しました。追加の 13 MB のストレージが許容できる場合は、非常に魅力的なオプションです。

目的が変わる場合（例えば、迅速な展開や集中的な読書など）、重みも変化しますが、ZSTDは超高速な解凍と中レベルでの適切な比率により、最もバランスの取れた選択肢となる傾向があります。

ZSTD における ZIP の互換性、サポート、役割

重要なポイントは、ZIP規格が仕様6.3.8（2020年）からZSTD（メソッド93）を組み込んだことです。これにより、最新のコーデックで「昔ながらのZIP 」が可能になります。エコシステムはどの程度これをサポートしているのでしょうか？現在、 WindowsエクスプローラーはZSTDを使用してZIPファイルを作成または展開しません。主流の7-Zipはこれを統合しており、既に動作するフォークも存在します。Linuxでは、p7zipのフォークがあります。状況は改善していますが、まだ多少の摩擦が残っています。

使用する場合 総司令官を置き換えることで、ZSTDで7zの読み込みを有効にすることができます。 TCLZMA64.DLL 互換性のあるバージョン（例えば、7-Zip ZSのTotalCmd.7zパッケージ）で動作します。TC内でZSTDを使用して7zファイルを作成する場合、古いプラグインは選択されたコーデックを常に考慮せず、LZMAにフォールバックします。 7-ジップ ZS 完了または コーデックプラグイン 既存の7-Zipインストールに7-Zip ZSをインストールすると、 ブロトリ、LZ4、リザード、ZSTD 7オンス容器の中身と取り扱い ZIP+ZSTD確認する 7z i アクティブなコーデック。

ウェブブラウザやパイプラインでは、 Brotliのコンテンツエンコーディングは「完全に無料」なソリューションのように思えますが、注意すべき点があります。ミドルウェア、プロキシ、フレームワーク（例えば、Next.jsのデバッグモードと本番モードの不一致）によって圧縮がやり直されたり、レイテンシが増加したりする可能性があります。また、事前に圧縮されたファイルを配信することも必ずしも簡単ではありません（Cloudflare Pagesは標準ではサポートしていません）。実際のいくつかのケースでは、ストリームをZIP形式のZSTDに置き換え、ユーザー空間で解凍することで、環境への依存度を減らし、同等以上の結果が得られました。

有用なパラメータと推奨レベル

ZSTDでは、レベル3、5、7が良好な動作点を提供します。30 Mb/sでのトランスコーディングと転送を比較した研究では、レベル3がエンドツーエンドで最速でしたが、レベル7はストレージを節約しました（EU4では、レベル5より12,5%、レベル3より25%少ない）。AWS Athenaは、レベル3がデフォルトで使用されない場合、レベル6～9を優先すると文書化しており、これはこの調査結果と一致しています。

長距離マッチングを有効にしたいという誘惑は確かにありますが、注意が必要です。そのためには、デコンプレッサとコンプレッサが同じ量のメモリを必要とします。デプロイメントやクライアントアプリケーションでは、この要件を満たすのは現実的ではありません。ウィンドウやテーブルのサイズは、適切な範囲内に抑えるのが賢明です。

Brotliでは、通常、重要な調整項目はレベルです。すでに高いレベルに設定している場合、lgwinを変更しても大きな効果は得られず、メモリ使用量が増える可能性があります。レベル4がレベル5と同等の性能を半分の時間で実現し、その分RAM使用量がわずかに増加するという観察結果は、メモリサイズを大幅に増やさずにレイテンシを低減したい場合に非常に役立ちます。

XZの場合、 -eフラグはプリセットの低速バージョンを適用し、わずかに高い圧縮率を目指します。マニュアルの表によると、圧縮機のメモリ使用量は増加しますが、解凍機のメモリ使用量は変わりません。それでも、ZSTDと比較すると、XZはパケットを高速で解凍しようとすると、しばしば性能が低下します。

従来のZIP形式に依存しつつもDeflateの高速性を求める場合、 libdeflateのようなライブラリはzlibに比べてスループットを大幅に向上させます。Rustのエコシステムでは、zip-rsはZIPファイル作成時にバックエンドを切り替える機能をまだ提供していないため、追加の作業なしにはこのアプローチは利用できない可能性があります。