Sender: katsu@FLAGSHIP.katsu.watanabe.name Newsgroups: fj.chat Subject: =?iso-2022-jp?b?UmU6IGFuY2llbnQgZmog?= =?iso-2022-jp?b?GyRCJVclbSU4JScbKEIgGyRCJS8lSEM7Py4bKEIgTm8uMTA=?= References: <3991827news.pl@rananim.ie.u-ryukyu.ac.jp> From: WATANABE Katsuhiro Date: 11 May 2005 17:24:46 +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: 50 Xref: FLAGSHIP mine:483 記事 <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 しかありえないけど)をサポートしなくていい。 ・候補キーが常に1つで、そのキーはunique。主キーのみ。 ・検索は、厳密な同値によるselectと、先頭からの順方向  カーソルによる全枚挙の2種類のみ。 ・ストアドプロシージャも制約もなにもない。 と、とても小さいサブセットですよね。性能で dbm が RDB に 負けるようなら悔しいです。(まだ勝ち負けは調べてません) あるいは、さらに ・比較的小さいデータ数向けに tune してある。 という条件があると考えることにすべきかしら。 -- 渡邊克宏 http://katsu.watanabe.name