いまここで議論している大規模な hash 表の扱いなんてものは、
DB 屋さんが 20 年ぐらい前にさんざんやったとの追体験なの
でしょうか。


記事 <3992098news.pl@rananim.ie.u-ryukyu.ac.jp> で
kono@ie.u-ryukyu.ac.jp (Shinji KONO) さんいはく
> > このとき、loadavg は下がり、ページングではない種類の
> > ディスクアクセスばかりをやる状況になっていました。
> > しかし、この性能悪化の本質を私は絞れていません。
> 
> DB は、normal file ですか? Unix FS 上に作っちゃうと、
> i-node 自体が B-Tree 的な構造になるので、hash と干渉
> するかも知れません。

FFS 上の普通のファイルです。

具体的なプログラム *.c や計測手順 Makefile は、すべて記事
<ufyut3jss.fsf@katsu.watanabe.name> の shar に入ってます。

関係する i-node は dbm ファイルの１つだけでキャッシュに
当然入ってるでしょう。i-node → block の対応表を厳しく
アクセスして重くなったとしても、それは結局メモリのアクセスの
範囲内で、デバイスのアクセスにつながることはないはずです。
もっと dbm のアルゴリズムに直接関係した事情と見ています。


> Berkeley DB って、レコードの大きさは32bit 表現なんですね。
> 64bit 対応のが欲しいんだけど... PostgreSQL は出来るとか
> 聞きましたが、どうなんだろう?

もう何でも 64bit の時代なんでしょうか。

PostgreSQL はまだできないと思います。field に入るのは 1GB
までです。
  http://www.postgresql.org/docs/faqs.FAQ.html#4.4

row あたりだと 1.6TB という話とどこかで混ざったのでは。
(Berkeley DB の hash に代表される)表だと「レコード」と
表現して会話をしても 1 field って決まってますが、
それを row と解釈されたとか。

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