Re: [Kai-devel-ja] ストレージ担当

[masahito i. <coo...@gm...>]

gist 最高ですよね！！
fork して頂き、修正後のファイルを見せて頂けると助かります。
push request を頂ければ、master に反映します。

> dets/btree の検証は、容量制限の回避が目的でしょうか?

単純に、どちらの方が、key/value ペアを保存するストレージとして
優れているんだろうなー？という疑問を持ったのが発端です。

私が考えている "優れている" の定義は下記の通りです。
（優先順位が高いものから順に並べています）
１．保存と取得の速度が早い
２．壊れ難い
３．ファイルサイズが小さい

まー、1  の箇所でいきなり迷走してますが（w；

> 64bit erlang だったら、ets でも容量制限は事実上無い、みたいな話が

あれ？
ets って昔から容量制限が無いと思い込んでいたのですが
容量制限ってあるんでしたっけ？
dets と Mnesia は、1テーブルの最大サイズが 2GByte ですよね？
（Mnesia は、内部で dets を利用）

2008/7/25 Shunichi Shinohara <shi...@gm...>:
> On 07/25/2008 "masahito ikuta" <coo...@gm...> wrote:
>> shino さんから、sync のご指摘を頂いているので
>> その辺りも考慮してみないといけませんね。
>
> gist がすてきなので、手元でやってみました
> # が、ここから push できない f(--)
>
> 34> couchdb_btree_vs_dets:test(1000).
> --<dets>--
> set:10(27)ms
> get:40(42)ms
> --<dets with sync>--
> set:520(1868)ms
> get:40(41)ms
> --<CouchDB B-Tree(case1)>--
> set:0(5)ms
> get:0(6)ms
> --<CouchDB B-Tree(case2)>--
> set:450(648)ms
> get:150(171)ms
> --<CouchDB B-Tree(case3)>--
> set:440(648)ms
> get:10(5)ms
> --<CouchDB B-Tree(case4)>--
> set:0(5)ms
> get:210(228)ms
>
>> うーん、dets のテーブルを束ねて容量制限を回避して
>> 場合によっては ets をキャッシュとして使う
>> 等の方が初めは楽かもしれませんね。
>
> dets/btree の検証は、容量制限の回避が目的でしょうか?
> 64bit erlang だったら、ets でも容量制限は事実上無い、みたいな話が
> erlang-questions で教えてもらったような。。。 うろ覚え。
>
> shino
>



-- 
cooldaemon