記事 <3991827news.pl@rananim.ie.u-ryukyu.ac.jp> で
kono@ie.u-ryukyu.ac.jp (Shinji KONO) さんいはく

> > はできても、restore ができません。restore が進むうち、
> > プロセスが肥大していって、仮想記憶空間関係の資源を食い
> > つぶすらして異常終了してしまいます。

>     Swap 多めに取ればいいんじゃない?

多分その通りでしょう。コンピュータ技術者としては賛成です。

でも一方で考えてみてくださいよ。せっかく(仮想)記憶システムの
外に取り分けて配置したモノ(ファイル)のために、(仮想)記憶
空間を広げるんですよ。記憶空間とは関連外にしたモノが増えれば
増えるほど、記憶空間の調整の必要性が増える・・・これは皮肉な
話ではないべか？


> > gdbm を使ったのデータベースも、事実上作成できません。数が
> > 数十万になるあたりからファイルのアクセスばかりになって、
> > insert 処理が進まなくなってしまいます。単純な key value
> > ペアだけのために、RDB を使うべきかどうなのか。
> 
> いや、まさにそういうものに使うべきなんですが....
> 
> hash だと、rehash されちゃうと破綻します。最初にhashの
> 大きさを指定できれば良いんですけどね。

今日 man して初めてわかったんですが、dbopen(3) インタフェース
のうちの hash(3) 型データベースは、hash の大きさを初期設定
できるみたいです。そして今の dbm は、もはや独立した実装では
なく、dbopen/hash の wrapper になっているとわかりました。


RDB 側から dbm(key value pairs) ファミリの仕様を見れば
・テーブルが単一。スキーマの管理が事実上不要。
・join(self join しかありえないけど)をサポートしなくていい。
・候補キーが常に１つで、そのキーはunique。主キーのみ。
・検索は、厳密な同値によるselectと、先頭からの順方向
　カーソルによる全枚挙の2種類のみ。
・ストアドプロシージャも制約もなにもない。
と、とても小さいサブセットですよね。性能で dbm が RDB に
負けるようなら悔しいです。(まだ勝ち負けは調べてません)

あるいは、さらに
・比較的小さいデータ数向けに tune してある。
という条件があると考えることにすべきかしら。

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