Sender: katsu@FLAGSHIP.katsu.watanabe.name Newsgroups: fj.chat Subject: =?iso-2022-jp?b?YW5jaWVudCBmaiAbJEIlVyVtJTglJxsoQg==?= =?iso-2022-jp?b?GyRCJS8lSEM7Py4bKEIgTm8uMTA=?= From: WATANABE Katsuhiro Date: 10 May 2005 14:08:43 +0900 Message-ID: Organization: An individual person. User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Lines: 42 Xref: FLAGSHIP mine:482 --- 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