最終更新日: 2026年8月20日

GZIP vs BZIP2 vs XZ: Which Linux Compression Format Is Best?

GZIP vs BZIP2 vs XZ: どの Linux 圧縮形式がベストか？

日々のデータベースダンプをパックしたり、数ギガバイト規模のウェブサーバーログをローテーションしたり、数千台のノードにコンパイル済みバイナリを配布したりする場合でも、圧縮は Linux 管理における日常的な現実です。

tar を呼び出すときや標準入力を通じてストリーミングデータを処理するとき、通常は次の 3 つの標準ユーティリティに出会います: GZIP (.gz)、BZIP2 (.bz2)、および XZ (.xz)。

3 つすべてのツールは生のバイトをコンパクトなアーカイブに圧縮することを目的としていますが、圧縮率、CPU 実行時間、メモリ使用量の間で根本的に異なるエンジニアリング上のトレードオフを行います。間違った形式を選択すると、自動デプロイを静かにボトルネックさせ、予定されたバックアップウィンドウを遅延させ、時間とともに貴重なストレージを浪費する可能性があります。

本ガイドでは、各形式が内部でどのように機能するか、実際のワークロードでのパフォーマンス、そしてインフラストラクチャに最適な形式を選ぶ方法を詳しく解説します。

1. 簡潔な技術概要：3 つの競合者

GZIP (GNU Zip)

  • 基礎アルゴリズム: DEFLATE (LZ77 とハフマン符号化の組み合わせ)
  • デフォルト拡張子: .tar.gz, .tgz, .gz
  • リリース時期: 1992 (Jean-loup Gailly と Mark Adler によって、compress の特許フリー代替として作成された)
  • 主要な利点: 圧倒的な実行速度とほぼすべてのエコシステムでのサポート。
  • 主要な欠点: 最新の統計的および辞書ベースのエンコーダーと比較して、圧縮率が低い。

GZIP は、30 年以上にわたり Unix 環境のデフォルトの主力ツールとして使用されてきました。その DEFLATE アルゴリズムは小さなスライディングウィンドウ (32 KB) で動作するため、圧縮時も解凍時も GZIP のメモリオーバーヘッドはほぼ無視できるほどです。

BZIP2

  • 基礎アルゴリズム: Burrows-Wheeler 変換 (BWT) と Move-to-Front (MTF) 変換、ハフマン符号化の組み合わせ
  • デフォルト拡張子: .tar.bz2, .tbz2, .bz2
  • リリース時代: 1996 (Julian Seward によって作成)
  • コアの利点: GZIP よりも繰り返しの ASCII および構造化ログファイルで圧縮率が高いです。
  • コアの欠点: 全体的に遅く、特に解凍時に遅延があり、最新のアルゴリズムによりほぼ時代遅れです。

BZIP2 は、離散ブロック（通常 900 KB）でデータを処理し、エンコード前に類似した文字をまとめる可逆的な置換を使用します。1990 年代後半から 2000 年代にかけて GZIP のファイルサイズを上回ることで広く称賛されましたが、計算コストは比較的高いです。

XZ (LZMA2)

  • 基礎アルゴリズム: LZMA2（Lempel-Ziv-Markov chain Algorithm、改良版）
  • デフォルト拡張子: .tar.xz, .txz, .xz
  • リリース時代: 2009（古い lzma フォーマットに代わるものとして導入）
  • コアの利点: 非常に高い圧縮率と高速で軽量な解凍です。
  • 主要な欠点: 初回圧縮時の大量のRAM使用と長時間のCPU実行時間。

XZは可変辞書サイズ（デフォルトで通常32 MBまたは64 MBまで）を活用し、GZIPよりはるかに広いデータウィンドウで重複するバイトパターンを検出します。これにより、OSインストールメディア、カーネルソースツリー、ファームウェアイメージなどの大きく冗長なファイルを縮小するのに非常に効果的です。

2. パフォーマンス比較マトリックス

以下の表は、標準的なサーバーハードウェア上でデフォルト設定で実行した際の各ユーティリティの実際的なパフォーマンス動向をまとめたものです。

指標 / 次元GZIP (-6)BZIP2 (-9)XZ (-6)
圧縮率中程度（約65〜75％の削減）良好（約75-80％削減）優秀（約80-88％削減）
圧縮速度非常に高速遅い非常に遅い
解凍速度非常に速い遅いから中程度高速
圧縮時のRAM使用量ごくわずか (~1–2 MB)低い (~8–10 MB)高い (~100–700 MB+)
解凍時のRAM使用量ごくわずか (< 1 MB)低い (~4 MB)中程度 (~10–65 MB)
主要な最適ポイントログ、CI/CD パイプライン、リアルタイムストリームレガシーアーカイブ互換性パッケージリポジトリ、OS ISO、コールドストレージ

3. 実世界ベンチマークの洞察

実際の負荷下でこれらのツールがどのように動作するかを理解するために、代表的な 1 GB の生サーバーアクセスログと、圧縮されていない 500 MB のソフトウェアソースコードディレクトリを考えてみましょう。

シナリオ A: 大容量ログファイルの圧縮（1 GB テキスト）

  • GZIP: 12 秒未満で完了し、約 180 MB のアーカイブを生成します。
  • BZIP2: 約 45〜50 秒で完了し、ファイルを約 130 MB に圧縮します。
  • XZ: デフォルト設定で 80〜90 秒かかり、約 95 MB のアーカイブが得られます。

シナリオ B: 解凍ワークロード

しばしば見落とされがちな重要な指標は 非対称性 です。

  • GZIP は 2–3 秒で解凍され、メモリ使用量は極めて少ないです。
  • XZ は 4–6 秒で解凍されます。初期の圧縮は遅かったものの、.xz の展開は .gz の展開とほぼ同等の速さです。
  • BZIP2 は展開だけでも約 25–30 秒かかります。これは Burrows-Wheeler 変換を逆にする計算コストがエンコードと対称的であるためです。

4. BZIP2 が支持を失いつつある理由

現代のインフラストラクチャでは、BZIP2 は微妙な中間地点に位置しています：

  1. GZIP に速度で勝る: 処理遅延や低 CPU 使用率が重要な場合、GZIP は大幅に速いです。
  2. XZ に圧縮率で勝る: 帯域幅の節約やストレージ効率が重要な場合、XZ ははるかに小さなアーカイブを生成します。
  3. 両方に解凍速度で劣る: ソフトウェア配信システムでは、.tar.bz2 ファイルの展開は .tar.gz や .tar.xz と比較して、顕著な CPU ペナルティが発生します。

その結果、主要な Linux ディストリビューション（Debian、Arch、Fedora など）は、公式パッケージ配布やカーネル tarball を BZIP2 から XZ に移行し、最近では実行時操作のために Zstandard も採用しています。

5. 実用的なコマンドライン使用法

Tar 統合（最も一般的なワークフロー）

GNU tar の最新実装は、ファイル拡張子に基づいて圧縮形式を自動的に認識しますが、明示的なフラグを使用することは依然として標準的な手法です:

# GZIP: Fast archive creation
tar -czvf project-backup.tar.gz /var/www/project/

# BZIP2: Legacy high-ratio archive
tar -cjvf project-backup.tar.bz2 /var/www/project/

# XZ: Maximum space savings
tar -cJvf project-backup.tar.xz /var/www/project/

# Generic extraction (tar auto-detects the format)
tar -xvf archive-name.tar.*

スタンドアロンファイル圧縮

個別のファイルをまとめずに圧縮するには:

# Compress keeping the original file intact (-k)
gzip -k access.log      # Output: access.log.gz
bzip2 -k access.log     # Output: access.log.bz2
xz -k access.log        # Output: access.log.xz

# Decompress individual files
gzip -d access.log.gz
bzip2 -d access.log.bz2
xz -d access.log.xz

マルチコアシステムの活用

デフォルトでは、これらのツールのシングルスレッド実装は1つのCPUコアしか使用しません。最新のマルチコアサーバーで数ギガバイト規模のアーカイブを圧縮する場合、シングルスレッド処理では数時間かかることがあります。

  • XZ マルチスレッド: -T または --threads によるネイティブサポート:
    xz -T0 -k database_dump.sql   # Uses all available CPU cores
  • 並列 GZIP (pigz): GZIP 操作にすべての CPU コアを使用するドロップイン置換:
    pigz -k database_dump.sql
  • 並列 BZIP2 (pbzip2): BZIP2 用のマルチスレッド実装:
    pbzip2 -k database_dump.sql

6. 選び方: 実践的な意思決定フレームワーク

ワークフローの主要な制約に基づいてツールを選択してください:

次の場合は GZIP を使用:

  • スループットが制限要因となるリアルタイムストリーム圧縮やネットワーク転送を設定しています。
  • 本番サーバーで自動ログローテーション（logrotate）を管理しており、CPUリソースはアプリケーションのワークロードのために確保しなければなりません。
  • レガシー組み込みシステムと標準ベースイメージ間での最大限のポータビリティが必要です。

次の場合は XZ を使用:

  • リリースアーティファクト、カーネルビルド、コンテナベースイメージ、またはサードパーティが頻繁にダウンロードする静的パッケージリポジトリを公開しています。
  • 長期のコールドアーカイブ（オフサイトの週次/月次バックアップ）を準備しており、ストレージコストが一度の圧縮時間を上回ります。
  • 小さなファイルサイズが必要ですが、利用者は高速なダウンロードと迅速な展開を求めています。

BZIP2 を保持するのは次の場合のみ:

  • レガシースクリプト、既存のバックアップ復元手順、またはXZデコーダを提供しないソフトウェアアプライアンスとの下位互換性を維持しています。

7. よくある質問（FAQ）

Q1. どの形式が最小のアーカイブサイズを提供しますか？ XZは、より大きなLZMA2辞書ウィンドウにより、3つのうち常に最小のアーカイブサイズを生成します。

Q2. ファイルを解凍する際、XZはGZIPより遅いですか？ XZは解凍時にGZIPよりわずかに遅いだけですが、BZIP2よりはるかに高速です。

Q3. GZIP と XZ は複数の CPU コアを活用できますか？ XZ は -T0 フラグを使用したネイティブなマルチスレッドをサポートし、GZIP は pigz のドロップインユーティリティを使用してコア間で並列化できます。

Q4. なぜ Linux ディストリビューションは BZIP2 を廃止しているのですか？ ディストリビューションは主に BZIP2 を段階的に廃止しています。なぜなら XZ は圧縮サイズが小さく、解凍が速く、GZIP は迅速な操作に対して依然として高速だからです。

Q5. -9 のような高い圧縮レベルは目に見える違いをもたらしますか？ レベル -9 を設定すると、平均でわずか 1%〜3% のサイズ削減にとどまり、CPU サイクル消費とメモリオーバーヘッドが大幅に増加します。

関連項目