大量データを扱う場合は、普通に扱っては駄目だね

手元に大量のデータがある。

このデータはテキスト形式で、数にして約 60 万ファイル。
ファイルサイズは 200 byte 〜 4 Kbyte ぐらい。
サイズの総量は 2Gbyte ぐらい。

このデータは重複はしてるわ、内容の修正が必要だわで、修正内容をバージョン管理で残しておきたいという要求がある。

以前、Subversion で管理しようとしたが、ファイル数が大量すぎて Subversion プロセスが死んでしまうという問題があった。Subversion は、コミットする前になにやら準備をしていて、そこで死んじゃう感じだった。

Git ではこの問題は発生せず、60 万ファイルはコミットできた。ここまでは順調だった。

次に、重複ファイルを削除してユニークにするという作業。
Windows で重複ファイルを探すなら UnDup というシェアウェアが抜群に速くて安定している。他にもいくつか試してみたけど、ファイルが多すぎて終わる気配がない、または死んでしまう。

UnDup で 136 分かけて、28 万の重複を発見。UnDup 上から不要なファイルを削除しても良いんだけど、git rm で削除したかったので、結果を保存しシェルスクリプトに仕立て上げた。ここまでも順調。

git rm で重複ファイルを削除するプロセスは、シェルスクリプトから 28 万回呼び出されるんだけど、これがすごく時間がかかる。大体一回 2〜3 秒なので（やっぱり大量にあるからですかねぇ）、全部終わるのに大体 194 時間かかる。一人月以上ですか？

とはいえ、コンピュータは人間と違って 24 時間文句も言わずに働き続けられるので、連続稼動で約 8 日で終わると言えば終わる。現在半日が経過したところだ。

この 8 日、待つ価値があるかどうか。
全体に対する横断的な修正というのは、今後も多く行われる予定で、その都度修正をコミットしたいんだけど、その度に 8 日待たされるとなると、これは作業にならない。

以前、このデータの処理を Windows XP で行っていたが、10 万ファイルをひとつのフォルダに置くだけで、エクスプローラは応答しなくなるため、絶対に保存フォルダをあけたりファイル選択ダイアログを開いたりしてはならなかった。これは Vista 以降で改善され、かなり扱いやすくなった。

ファイルは 5 つのカテゴリに分類できるので、現在は 5 つのフォルダに分けて保存している。これを 5 つのファイルにして管理しようとしたこともある。すると今度はひとつのファイルが数百 MByte という具合になって、エディタで扱えなく（扱いづらく）なってしまう。

ということで、大量データを扱うときは、通常とは別のアプローチを取らなければならないと思った。
データベースを構築して、ひとつのファイルをレコードとして登録し、変更履歴を残すというよりは、変更した際の SQL を履歴として取っておく、というのが正解に近い気がする。

ただし、ファイルの実体がないので、気軽に内容を確認できないため、そういったことを考えると悩ましい問題である。