--- ancient fj プロジェクト短信 No.10 ----

ニューススプールやアーカイブのように、大量のファイルを
扱おうとすると、まだ色々変なことが起こります。現在手元に
あって試験的に扱っている記事ファイル群は 400万ぐらいです。
大量といっても、現在のパーソナルコンピュータ構成バランス
から言えば、さほど大きな数には思えませんよね。ところが...

今動かしている BSD 系の某 OS では、filesystem の dump
はできても、restore ができません。restore が進むうち、
プロセスが肥大していって、仮想記憶空間関係の資源を食い
つぶすらして異常終了してしまいます。（ただし restore
ユーザプロセスの問題なので、ファイルシステムやカーネル
空間は無関係で無事）これには困惑します。

gdbm を使ったのデータベースも、事実上作成できません。数が
数十万になるあたりからファイルのアクセスばかりになって、
insert 処理が進まなくなってしまいます。単純な key value
ペアだけのために、RDB を使うべきかどうなのか。

    余談:
    データ群を deploy した状態でのファイルシステムの
    restore が使えないので、サーバの保守などの際には、
    元となるデータからの 'make install' をしなおす
    ことにしてました。ところが、make 中には gdbm-
    DB の作成作業もあり、それが滞留してしまいます。
    先日ディスクが壊れて入れ替える際には、手作業で
    手をかけてやる羽目になりました。

以前の短信でも紹介したとおり、WinXP 上の tar のクローンや
NTFS も大量のファイルで致命的な問題を起こしていました。

大量のデータを扱うために数に対して(線形に)scale する
プログラムを書くためには、何かを中間的に記憶していくような
戦略は向かないんだなと感じます。


でも7桁＝百万単位程度で色々問題が起きるのは、現在のバランス
からは、何か限界が低いかなあ。

-- 
渡邊克宏 http://katsu.watanabe.name