2019-12-08-01-fistで添付ファイルのメモリ内圧縮 - project-enigma

2019-12-08-01-fistで添付ファイルのメモリ内圧縮

>> Site top >> weblog >> 月別アーカイブ >> 2019年12月のlog >> 2019-12-08-01-fistで添付ファイルのメモリ内圧縮

最終更新日付:2019/12/08 01:00:00


fistで添付ファイルのメモリ内圧縮

2019 年 12 月 08 日

以前書いたとおり、fist でデータファイルとアーカイブファイルの zlib 圧縮を実現したものの、実行中のメモリ内データイメージは非圧縮のままだった。今回は、ひとまず添付ファイルについてはメモリ上でも圧縮形式で保持するように修整した話。

単に圧縮するだけなら話は簡単(というかそれほど難しくはないの)だけど、今回厄介だったのはファイル形式の問題だった。fist には2種類の保存ファイル形式があって、慣習的にそれぞれデータファイル、アーカイブファイルと呼んでいる。データファイルはいわゆるバイナリ形式で、起動時に読み込んで終了時に保存する、プライマリな保存形式だ。以前書いた、全体圧縮をするようにしたやつで、基本的には速度優先の形式になる。一方でアーカイブファイルは fist の backup コマンドで作成するファイルで、データ全体(または一部)をバックアップしたり他所へ移動するためのものだ。こちらは可搬性を目的としているためテキスト形式になっている。

ファイル形式に影響が出る変更というのは、たいてい上記のどちらかだけに変更が発生する。そういう場合、既存データの移行というのは「ちょっとした手順」くらいで済む。具体的には、データファイル形式変更なら「アーカイブから restore コマンドでよろしく」となるし、アーカイブファイル形式変更なら「古いアーカイブファイルは使えませんのでご注意」で済む。

問題は両方が同時に変わる場合で、これはどんなに注意しても一発移行はできない。新しいビルドを配備してしまったら、古いデータファイルは開けないし、古いアーカイブから restore することもできない。別途コンバータを用意するか、あるいは段階移行をするしかないのだ。

このファイル形式が両方同時に変わるケース、これまでに何回か対応してみて、まぁ毎回「もうたくさんだ」と思っていた。そしてバージョナブルスキーマみたいなものの導入を考えたりもするのだが、それだって本気でやるとなるとなかなかに大変な作業だ。だから結局今まで取り組まずじまい。そして今回の「添付ファイルのメモリ内圧縮」はまさにこれに該当してしまった。つまり、データファイルとアーカイブファイルの両方に変更が入ったのだ。

結局今回も段階移行をしたのだけど、まぁなんていうか、ユーザーが自分しかいないからこそできる DIY 対応だなとは思う。データファイルの形式だけを変更した移行専用のビルドを作成し、データファイルのみ新形式に(アーカイブからの restore で)移行、その後アーカイブ形式も更新された正式バージョンを配備‥‥‥こんなの不特定多数のユーザーがいたら絶対無理だろう。

そして悲しいことに、そんな苦労をして実現した添付ファイルのメモリ内圧縮は、それほど効果が上がらなかった。というのも、自分の使い方では、添付ファイルのほとんどが元々圧縮形式だったからだ。多くの画像ファイル形式がそうだし、ファイル数が多いため zip 形式に固めて添付することも多い。こういったファイルはさらに zlib 圧縮をかけてもサイズはほとんど変わらないため、無駄な処理コストをかけないために圧縮をしない措置をとったのだ。まぁ処理コストをかけても数%しか圧縮できなかったりするなら、やらない方がマシだよな。条件が悪いと逆にサイズが増えたりもするし。しかし今後は「ファイルでもメモリ上でもちゃんと圧縮されて保持する」とわかっているのだから、使い方も変わっていくかもしれない。その意味で次にやるかどうか迷っているのは、トラッキングデータのメモリ内圧縮だ。

 

コメント

このページにコメントする

 

このページのタグ

Page tag : fist

 

 


Copyright(C) 2005-2020 project-enigma.
Generated by CL-PREFAB.