IBM i の保管ファイルの圧縮オプション
クラウドの小規模な一時的IBM i パーティションでいくつかのテスト表に大量のデータを入力し終わり、ホッとしていました。ところが次の瞬間、それらの表とOSでディスク スペースの70%以上が占められていることに気付き、がっかりでした。安全に保管するためにすべてのデータを1つの保管ファイルに入れるにはどのようにしたらよいのでしょうか。
頭の中の警報ブザーは、はっきり聞こえていました。十分な空き容量がないので、うまくいきません。複数の保管ファイルを使用してテスト データを保管するというやり方は避けたいと思っており、そこで思い出したのが、ほとんどのファイル保管コマンドにはデータ圧縮（DTACPR）パラメーターがあるということでした。そのパラメーターは使用したことがなかったため、どれくらい使えそうなのか、ライブラリー保管（SAVLIB）で試してみることにしました。DTACPR(*HIGH)を指定してSAVLIBを実行したところ、テスト ライブラリー全体をシステムのストレージスペースの約7%で保管できるほどに十分に高い圧縮機能でした。
IBMは、3種類の圧縮のオプション（*LOW、*MEDIUM、*HIGH）を提供しており、以下は、それらのオプションについてのIBMのドキュメントでの説明です（強調の太字は筆者）。
- *NO -- データ圧縮は実行されません。
- *YES -- テープへの保管で、ターゲット装置が圧縮をサポートしている場合には、ハードウェアの圧縮が実行されます。圧縮がサポートされていないか、あるいは保管データが光ディスク媒体または保管ファイルに書き出される場合には、ソフトウェア圧縮が実行されます。低ソフトウェア圧縮は、中間ソフトウェア圧縮を使用する光ディスクDVD以外のすべての装置に使用されます。
- *LOW -- 保管操作が保管ファイルまたは光ディスクに対する操作の場合には、ソフトウェア・データ圧縮はSNAアルゴリズムで実行されます。通常、低圧縮はより高速であり、圧縮されるデータは中間および高圧縮が使用された場合より大きくなります。
- *MEDIUM -- 保管操作が保管ファイルまたは光ディスクに対する操作の場合には、ソフトウェア・データ圧縮はTERSEアルゴリズムで実行されます。通常、中間圧縮は低圧縮より低速になりますが、高圧縮よりは高速となります。圧縮されるデータは通常、低圧縮が使用された場合よりは小さくなり，高圧縮が使用された場合よりは大きくなります。
- *HIGH -- 保管操作が保管ファイルまたは光ディスクに対する操作の場合には、ソフトウェア・データ圧縮はLZ1アルゴリズムで実行されます。通常、高圧縮はより低速であり、圧縮されるデータは低および中間圧縮が使用された場合より小さくなります。
これらはすべて古い圧縮アルゴリズムであり、筆者も、聞いたことがあったのはLZ1だけでした。
そこで、最初に戻って、利用可能な圧縮オプションを比較してみることとしました。以下のように、オブジェクト保管（SAVOBJ）コマンドを使用して、保管ファイルに8GBのCUSTOMER表を保管します。
SAVOBJ OBJ(CUSTOMER)
LIB(MYDATA)
DEV(*SAVF)
OBJTYPE(*FILE)
SAVF(QGPL/MYSAVF)
CLEAR(*REPLACE)
DTACPR(*NO)同じ保管ファイル（SAVF）を、テストのたびに消去して再利用しました。次の表は、データ圧縮オプションごとの結果を示したものです。
| DTACPRのオプション | 平均CPU使用率（%） | SAVOBJの実行時間 | SAVFのサイズ（バイト） | 元のサイズに対する% |
|---|---|---|---|---|
| *NO | 4% | 5:41 | 8774656000 | |
| *HIGH | 40% | 13:11 | 5687762944 | 64.8% |
| *MEDIUM | 33% | 10:46 | 5701132288 | 65.0% |
| *LOW | 14% | 3:42 | 6383755264 | 72.8% |
テストは、2つのvCPU、4GBのRAM、200GBのディスクで、IBM i 7.3が稼働する、Power9クラウド パーティションで行いました。
上の表の平均CPU使用率（%）は、精度の高いものではありません。基本的に筆者が、システム活動の処理（WRKSYSACT）コマンドを使用し、平均CPU使用率を監視したものです。これらの保管テスト以外の処理をシステムがあまり行っていなかったとしても、すべてを実行するのにいくらかのCPUコストが掛かります。このマシンでは、「アイドル」状態で0.5%～1.5%でした。CPU使用率の大半は、間違いなく圧縮操作によるものでした。
この表から分かるのは、このマシンには確かにvCPUは2つだけでしたが、*HIGHまたは*MEDIUM圧縮レベルを求めることは、CPUの観点からするとかなり高くつく、ということでした。そのため、これらの圧縮オプションのいずれかを指定して保管コマンド（SAVnnn）を実行する場合は、システムに十分なCPU性能があることを確認してからにすることをお勧めします。
筆者のCUSTOMER表では、*HIGH圧縮と*MEDIUM圧縮とで、節減できるスペースに違いはほぼありませんでした（約0.2%のみ）。*LOWオプションは、スペース節減という点では効果的ではありませんでした（*HIGHに比べて約8%サイズが大きい）が、処理速度は最も高速でした。所要時間が重要な場合は注意が必要です。ご覧の通り、*HIGHおよび*MEDIUMオプションは、圧縮なしの保管に比べてかなり時間が掛かります。
もちろん、データ オブジェクトがどれくらい圧縮に向いているかによっても、結果は異なります。一般的に、繰り返し要素の多いデータの場合、圧縮率が高く（サイズが小さく）なります。テストの「CUSTOMER」表には、確かにランダムな文字が数多くありました。したがって、「普通の」データであれば、もっと高い圧縮率が期待できると思われます。
大きなプレーン テキスト ファイルなど、「圧縮しやすい」データの場合にどれくらいの圧縮率で圧縮されるか、2つ目のテストを行って調べてみることにしました。Geonames.orgというWebサイトから英国の郵便番号のフリー リストをダウンロードして、IBM i 上で/tmp/GB_full.txtに解凍し、オブジェクト保管（SAV）コマンドを使用してこのテキスト ファイルをIFSから保管ファイルへ保管します。
SAV DEV('/qsys.lib/qgpl.lib/mysavf.file')
OBJ(('/tmp/GB_full.txt'))
CLEAR(*REPLACE)
DTACPR(*HIGH)次の表に、選択したデータ圧縮（DTACPR）に応じた、それぞれの保管ファイルのサイズを示します。
| ファイルの説明 | ファイル サイズ（バイト） | 元のサイズに対する% |
|---|---|---|
| 圧縮されていないファイル | 173821160 | |
| Zipファイル（ダウンロードしたオリジナル ファイル） | 13946129 | 8.0% |
| 保管ファイル（圧縮なし） | 184705024 | 106.3% |
| 保管ファイル（高圧縮） | 18907136 | 10.9% |
| 保管ファイル（中圧縮） | 32538624 | 18.7% |
| 保管ファイル（低圧縮） | 173039616 | 99.6% |
このテストでは保管操作がどれくらい掛かるは重要でなかったため、実行時間とCPU%は含めませんでした。それぞれの圧縮レベルがどれくらいの圧縮率になるかという点に関して、このテストの結果は最初のテストと大きく異なったため、このテストは行ってみてよかったと思います。
Zip圧縮は、IBM i の旧式の圧縮アルゴリズムと比べて非常に高い圧縮率でした。IFSファイルのzip/unzipには、QSHELLを使用してjarコマンドを利用できることを覚えておいてください。主な目的が大幅なサイズ削減や保管ファイルなしでのデータ共有という場合には、インターネット検索を厭わなければ、数多くのユーティリティや他の圧縮形式（7zやtarなど）も、IFSファイルの圧縮にQSHELLから使用することができます。必要なら、常にzipファイルを保管ファイルに入れるようにすれば、両方のメリットを得ることもできます。
1つ目の圧縮のデモと異なり、圧縮のタイプによって、結果のファイル サイズにかなりの違いが生じました。*LOW圧縮は、前のテストでは非常に有用でしたが、プレーン テキスト ファイルでは、ほぼ何もしないようなものでした。
結論としては、保管ファイルにデータを保存するときに、特定のデータ圧縮オプションを使用した場合のコスト（CPU使用率および実行期間）とメリット（ディスク スペースの節約）を比較してみても損はないということです。最適な設定はデータ セット（たとえば、プログラム オブジェクト対表データおよびジャーナル レシーバー、プレーン テキスト データ対バイナリー データなど）によって異なるため、必ずそれぞれのケースごとにテストするのがお勧めです。IFSデータの圧縮に関心があるだけなら、他の圧縮オプションが利用可能です。
