kai-devel-ja — For Kai developers in Japanese

Re: [Kai-devel-ja] [Kai-users-ja] consistency check by vector clocks

[Takeru I. <tak...@gm...>]

# 開発の話になったので，kai-devel-ja のみで．

>> 初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。
>>
>> 7>
>> =ERROR REPORT==== 17-Nov-2008::13:08:21 ===
>> Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale
>> state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]}
>
> バグでした。branch で修正しましたので、確認してもらえるとありがたいです。
> - vector clocks の更新で、過去データを元にノードのカウンターをインクレメントするようにした
> - 古い状態(stale state)かどうかの判断は、cas unique が渡ってくる cas でしか出来無い(と思う)
>  ので、判断ロジックを削除

7月後半に，put でのバージョンチェックが議論になったけど，あれはクライアントが VectorClocks を送ってくるという前提になってました．
Kai の場合は，クライアントに VectorClocks が渡らないので，Dynamo とは状況が違ってますね．

put (set) の場合は，クライアントがバージョンに関する情報をまったく送ってこないので，チェックのしようがなかったです (shino
さんが書いているとおり)．
cas では，cas unique と，store されている checksum を比較することになりますね．

複数の checksum が混合されているときは，kai_coordinator で cas unique を分割してから
(実際の分割関数は kai_version に実装するんだろうけど)，store に送るのかな?
checksum の比較と VectorClocks の更新のタイミングも厳密に考慮すると，cas の導入は kai_coordinator
の実装を複雑にしかねないかも…
慎重に進めた方がいいかなぁ．

-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] consistency check by vector clocks

[Tomoya H. <tom...@gm...>]

橋本です。

早速Rev 99で同様に試してみました。こちらではエラーが発生しなくなりました。大体以下のような
数字が得られました。detsはetsの1/3ぐらい、という結果でした。

■ ets

[t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.207 -p 11211 -t 200 -n
100 -l 1024 -s -m 10000
condition =>
        memcached = 172.20.31.207:11211
        command = set
        200 thread run
        send 100 command a thread, total 20000 command
        data length = 1024
result =>
        interval =  12.847524 [sec]
        performance =  1556.720199 [command/sec]
        thread info:
          ave. = 10.303019[sec], min = 2.445050[sec], max = 12.843495[sec]

■ dets

[t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.205 -p 11211 -t 200 -n
100 -l 1024 -s -m 10000
condition =>
        memcached = 172.20.31.205:11211
        command = set
        200 thread run
        send 100 command a thread, total 20000 command
        data length = 1024
result =>
        interval =  38.860149 [sec]
        performance =  514.666064 [command/sec]
        thread info:
          ave. = 35.751326[sec], min = 19.174975[sec], max = 38.857620[sec]
[t-hashi@gtp301 ~]$

＃今度のErlang勉強会にお邪魔するのでご挨拶させてください

---
Tomoya Hashimoto

2008/11/17 17:34 shinohara <shi...@gm...>:
> しのはら(shino)です。
> # kai-users-ja にもクロスポストしてみます。
>
> On 11/17/08 1:28 PM Tomoya Hashimoto wrote:
>> 使い方がまずいのかもしれませんが、私の手元ではエラーが出ているので報告させていただきます。
>>
>> こちらのツールを使ってベンチマークを取っています。
>> http://www.interdb.jp/techinfo/mcb/
>
> エラー報告 & 便利なツールありがとうございます :-)
>
>> 初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。
>>
>> 7>
>> =ERROR REPORT==== 17-Nov-2008::13:08:21 ===
>> Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale
>> state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]}
>
> バグでした。branch で修正しましたので、確認してもらえるとありがたいです。
> - vector clocks の更新で、過去データを元にノードのカウンターをインクレメントするようにした
> - 古い状態(stale state)かどうかの判断は、cas unique が渡ってくる cas でしか出来無い(と思う)
>  ので、判断ロジックを削除
>
> URL: https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks
> Revision: 99
> Last Changed Author: shino_shun
> Last Changed Rev: 99
> Last Changed Date: 2008-11-17 16:52:10 +0900 (Mon, 17 Nov 2008)
>
> よろしくおねがいします m(_ _)m
>
> shino
>
>

Re: [Kai-devel-ja] consistency check by vector clocks

[shinohara <shi...@gm...>]

しのはら(shino)です。
# kai-users-ja にもクロスポストしてみます。

On 11/17/08 1:28 PM Tomoya Hashimoto wrote:
> 使い方がまずいのかもしれませんが、私の手元ではエラーが出ているので報告させていただきます。
> 
> こちらのツールを使ってベンチマークを取っています。
> http://www.interdb.jp/techinfo/mcb/

エラー報告 & 便利なツールありがとうございます :-)

> 初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。
> 
> 7>
> =ERROR REPORT==== 17-Nov-2008::13:08:21 ===
> Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale
> state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]}

バグでした。branch で修正しましたので、確認してもらえるとありがたいです。
- vector clocks の更新で、過去データを元にノードのカウンターをインクレメントするようにした
- 古い状態(stale state)かどうかの判断は、cas unique が渡ってくる cas でしか出来無い(と思う)
  ので、判断ロジックを削除

URL: https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks
Revision: 99
Last Changed Author: shino_shun
Last Changed Rev: 99
Last Changed Date: 2008-11-17 16:52:10 +0900 (Mon, 17 Nov 2008)

よろしくおねがいします m(_ _)m

shino

Re: [Kai-devel-ja] consistency check by vector clocks

[Tomoya H. <tom...@gm...>]

橋本と申します。

使い方がまずいのかもしれませんが、私の手元ではエラーが出ているので報告させていただきます。

こちらのツールを使ってベンチマークを取っています。

http://www.interdb.jp/techinfo/mcb/

ノードを３つ用意して、それぞれに以下のようなconfigを書いています。

[t-hashi@gtp205 shino_vector_clocks]$ cat kai.config
[{kai, [%{logfile, "kai.log"},
    %{hostname, "gtp205"},
    {rpc_port, 11011},
    {rpc_max_processes, 1024},
    {memcache_port, 11211},
    {memcache_max_processes, 1024},
    {max_connections, 1024},
    {n, 3},
    {r, 2},
    {w, 2},
    {number_of_buckets, 1024},
    {number_of_virtual_nodes, 128},
    {store, ets},
    %{dets_dir, "/data/kai"},
    {number_of_tables, 256}
]}].

リビジョンは98です。

以下のように起動して、クラスターをくみました。

[t-hashi@gtp205 shino_vector_clocks]$ erl -pa ebin -config kai
Erlang (BEAM) emulator version 5.6.4 [source] [64-bit] [smp:4]
[async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.6.4  (abort with ^G)
1> application:load(kai).
ok
2> application:start(kai).
2008-11-17 13:07:44.342412 [info] (<0.43.0>) ./kai_hash.erl:182: {update,
                                                                  [{{{172,20,
                                                                      31,205},
                                                                     11011},

[{number_of_virtual_nodes,
                                                                      128}]}],
                                                                  []}
ok
3> kai_rpc:check_node({{172,20,31,206}, 11011}, {{172,20,31,207}, 11011}).
ok
4> kai_rpc:check_node({{172,20,31,207}, 11011}, {{172,20,31,205}, 11011}).
ok
5> kai_rpc:check_node({{172,20,31,205}, 11011}, {{172,20,31,206}, 11011}).
ok
6> 2008-11-17 13:07:55.383257 [info] (<0.43.0>) ./kai_hash.erl:182: {update,
                                                                  [{{{172,20,
                                                                      31,207},
                                                                     11011},

[{number_of_virtual_nodes,
                                                                      128}]},
                                                                   {{{172,20,
                                                                      31,206},
                                                                     11011},

[{number_of_virtual_nodes,
                                                                      128}]}],
                                                                  []}

6> kai_hash:node_list().
{node_list,[{{172,20,31,206},11011},
            {{172,20,31,205},11011},
            {{172,20,31,207},11011}]}

ツールを使って以下のようにリクエストを投げます。

[t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.207 -p 11211 -t 1 -n 100
-l 1024 -s -m 10000
condition =>
        memcached = 172.20.31.207:11211
        command = set
        1 thread run
        send 100 command a thread, total 100 command
        data length = 1024
result =>
        interval =  0.115269 [sec]
        performance =  867.536346 [command/sec]
        thread info:
          ave. = 0.115235[sec], min = 0.115235[sec], max = 0.115235[sec]

初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。

7>
=ERROR REPORT==== 17-Nov-2008::13:08:21 ===
Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale
state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]}

2008-11-17 13:08:26.499833 [warning] (<0.1075.0>)
./kai_coordinator.erl:61: "route(\"1747\"): timeout"
2008-11-17 13:08:26.500094 [warning] (<0.1075.0>)
./kai_memcache.erl:113: "send_error_and_close/2: \"Failed to write.\""

何度か試したのですが、ほとんど毎回エラーになりました。パターンがあるかと試したのですが、そこまではわかりませんでした。

branches/takemaru_store_dets のコードでも同様に試しましたが、こちらではエラーは発生しませんでした。

使い方が間違えているかも、と思いましたが判断がつきかねるので報告させていただきました。

環境は3ノードともにCentOS5.2 x86_64です。

[t-hashi@gtp205 takemaru_store_dets]$ uname -a
Linux gtp205 2.6.18-92.1.13.el5.centos.plusxen #1 SMP Wed Oct 1
14:14:27 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

--
Tomoya Hashimoto

2008/11/12 11:55 shunichi shinohara <shi...@gm...>:
> しのはらです。
>
> vector clocks (以下、VC)による整合性チェックを一通り実装しました。
> https://sourceforge.net/tracker/index.php?func=detail&aid=1999912&group_id=228337&atid=1073615
> https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks
> rev 97  (trunk の変更分は merge 済)
>
> trunk にマージする前に、コード上であったり動作としてマズい部分などレビューして
> もらえるとありがたいなぁ、とおもっています。
>
> 現状の仕様(動作)
> - 複数バージョンがあったばあいの get(s)
>  - VC で順序解決できれば、一つだけ返す
>  - 解決できない組があれば、複数(並列なもの全て)返す
> - set の場合
>  - coordinator ノードの store にあるデータの VC を更新
>    cas が未実装なので、ここでのバージョンチェックは未だ
>  - この VC が、別ノードのデータの VC と衝突したら、そのノードではエラー
> - gets の場合の cas_unique
>  - 最初の 4 bit が VC の個数
>  - 残り 60 bit を VC の個数で割って checksum の頭から詰める
>  - ex1) 1 つのデータを返すとき:
>         0001[checksum の先頭 60 bits] (2 進表現、以下同様)
>    ex2) 2 つのデータを返すとき:
>         0010[データ1の checksum の先頭 30 bits][データ2の checksum の先頭 30 bits]
>    ex3) 7 つのデータを返すとき:
>         0111[データiのchecksum の先頭 8 bits]×7[0 埋め]
>
> ソースで(特に)気になるところ
> - kai_coordinator_SUITE で、複数ノードのテストのため、slave:start を使っているのですが、
>  やりかたとして、もっと簡単にできるとか、別の方法があるとかあればコメントいただきたいです
>
> 説明足りないところがあればツッコミおねがいします。
>
> # 勉強会までに、 cas まで実装するのを目標 f(--)
>
> --
> shino
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>

Re: [Kai-devel-ja] consistency check by vector clocks

[Takeru I. <tak...@gm...>]

>> get で複数バージョンが返されていたかも未チェックです．
>> このチェックは，kai_coordinator でログを出力させるしかないですよね?
>
> いちおう、memcached クライアントで、返ってきたデータの数をチェックすること
> は可能だとおもいます。クライアントの実装に依存してしまうので、コード読む
> 必要がありますが...
> # Ruby のある実装(memcache-client)は、key のリストを渡して、
> # get(s) が呼ばれて、戻りは、 key => value の Hash になっていたので、
> # kai には合わない

Perl で見たときには，コードを修正する必要がありました．
やはり，Kai にログを出力させた方が早いかな．．

>> - coordinator では vclock を呼ばないほうが，依存関係を少なくできる?
>
> ええと、今のところ、 coordinator で vector clocks のインクレメントを
> して、store で新旧の衝突チェック、という雰囲気で実装していました。
> coordinate_put(Data) ->
>    [...]
>    Data1 =
>        case kai_store:get(Data#data{bucket=Bucket}) of
>            PreviousData when is_record(PreviousData, data) ->
>                PreviousData;
>            undefined ->
>                #data{key=Key, vector_clocks=vclock:fresh()}
>        end,
>    {ok, Data2} = kai_version:update(Data1),
>    [...]
> このあたりを、kai_store:get_and_update_vector_clocks/1 みたいな
> 関数を作って、移動したほうがいいんじゃないか? ということでしょうか?

僕の中では，vclock.erl はモジュールの単位として細かすぎるかなと思っていて，提供してもらった経緯がなければ kai_version
にまとめて実装しただろうという考えがあるので，kai_version 以外から呼び出さない方がいいかなと感じてしまったまででした．
kai_version では，VectorClocks の初期化状態をチェックする必要がでてきますが．

大した話ではないので，今のままでもいいと思います．
依存関係を考慮した設計などは皆さんの方が詳しいと思うので，参考程度に捉えてください．

-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] consistency check by vector clocks

[shunichi s. <shi...@gm...>]

しのはらです。テスト & コメントありがとうございます :-)

2008/11/13 Takeru INOUE <tak...@gm...>:
> テストしてみました．
> 5ノードで 10,000 qps くらいまで負荷をかけてみましたが，OK でした．
> 大きな性能の低下もありません．

ほっとしました

> set でたまにエラーが起こってたけど，原因まで見ませんでした…．
> あとで見ておきます．

テストのキーの範囲に依りますが、短い時間に同じキーで set しにいくと、
kai_store でバージョンが衝突してエラーになることはあるとおもいます。

> get で複数バージョンが返されていたかも未チェックです．
> このチェックは，kai_coordinator でログを出力させるしかないですよね?

いちおう、memcached クライアントで、返ってきたデータの数をチェックすること
は可能だとおもいます。クライアントの実装に依存してしまうので、コード読む
必要がありますが...
# Ruby のある実装(memcache-client)は、key のリストを渡して、
# get(s) が呼ばれて、戻りは、 key => value の Hash になっていたので、
# kai には合わない

> - coordinator では vclock を呼ばないほうが，依存関係を少なくできる?

ええと、今のところ、 coordinator で vector clocks のインクレメントを
して、store で新旧の衝突チェック、という雰囲気で実装していました。
coordinate_put(Data) ->
    [...]
    Data1 =
        case kai_store:get(Data#data{bucket=Bucket}) of
            PreviousData when is_record(PreviousData, data) ->
                PreviousData;
            undefined ->
                #data{key=Key, vector_clocks=vclock:fresh()}
        end,
    {ok, Data2} = kai_version:update(Data1),
    [...]
このあたりを、kai_store:get_and_update_vector_clocks/1 みたいな
関数を作って、移動したほうがいいんじゃないか? ということでしょうか?

> - 設定名などの修正漏れがあるので，↓のパッチを当てておいてください．

レビューありがとうです。コミットしました m(_ _)m

>  Takeru INOUE <tak...@gm...>

-- 
shino

Re: [Kai-devel-ja] consistency check by vector clocks

[Takeru I. <tak...@gm...>]

テストしてみました．

5ノードで 10,000 qps くらいまで負荷をかけてみましたが，OK でした．
大きな性能の低下もありません．

set でたまにエラーが起こってたけど，原因まで見ませんでした…．
あとで見ておきます．

get で複数バージョンが返されていたかも未チェックです．
このチェックは，kai_coordinator でログを出力させるしかないですよね?

いくつか気になった点を．

- coordinator では vclock を呼ばないほうが，依存関係を少なくできる?
- 設定名などの修正漏れがあるので，↓のパッチを当てておいてください．
---
Index: branches/shino_vector_clocks/test/kai_version_SUITE.erl
===================================================================
--- branches/shino_vector_clocks/test/kai_version_SUITE.erl     (リビジョン 97)
+++ branches/shino_vector_clocks/test/kai_version_SUITE.erl     (作業コピー)
@@ -19,7 +19,7 @@
 init_per_testcase(_TestCase, Conf) ->
     kai_config:start_link([
                            {hostname, "localhost"},
-                           {port, 11011},
+                           {rpc_port, 11011},
                            {memcache_port, 11211},
                            {max_connections, 2},
                            {n, 1}, {r, 1}, {w, 1},
Index: branches/shino_vector_clocks/kai.config
===================================================================
--- branches/shino_vector_clocks/kai.config     (リビジョン 97)
+++ branches/shino_vector_clocks/kai.config     (作業コピー)
@@ -1,6 +1,6 @@
 [{kai, [
     % {logfile, "kai.log"},
-    {hostname, "127.0.0.1"},
+    %{hostname, "127.0.0.1"},
     {rpc_port, 11011},
     {rpc_max_processes, 30},
     {memcache_port, 11211},


2008/11/12 shunichi shinohara <shi...@gm...>:
> しのはらです。
>
> vector clocks (以下、VC)による整合性チェックを一通り実装しました。
> https://sourceforge.net/tracker/index.php?func=detail&aid=1999912&group_id=228337&atid=1073615
> https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks
> rev 97  (trunk の変更分は merge 済)
>
> trunk にマージする前に、コード上であったり動作としてマズい部分などレビューして
> もらえるとありがたいなぁ、とおもっています。
>
> 現状の仕様(動作)
> - 複数バージョンがあったばあいの get(s)
>  - VC で順序解決できれば、一つだけ返す
>  - 解決できない組があれば、複数(並列なもの全て)返す
> - set の場合
>  - coordinator ノードの store にあるデータの VC を更新
>    cas が未実装なので、ここでのバージョンチェックは未だ
>  - この VC が、別ノードのデータの VC と衝突したら、そのノードではエラー
> - gets の場合の cas_unique
>  - 最初の 4 bit が VC の個数
>  - 残り 60 bit を VC の個数で割って checksum の頭から詰める
>  - ex1) 1 つのデータを返すとき:
>         0001[checksum の先頭 60 bits] (2 進表現、以下同様)
>    ex2) 2 つのデータを返すとき:
>         0010[データ1の checksum の先頭 30 bits][データ2の checksum の先頭 30 bits]
>    ex3) 7 つのデータを返すとき:
>         0111[データiのchecksum の先頭 8 bits]×7[0 埋め]
>
> ソースで(特に)気になるところ
> - kai_coordinator_SUITE で、複数ノードのテストのため、slave:start を使っているのですが、
>  やりかたとして、もっと簡単にできるとか、別の方法があるとかあればコメントいただきたいです
>
> 説明足りないところがあればツッコミおねがいします。
>
> # 勉強会までに、 cas まで実装するのを目標 f(--)
>
> --
> shino
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>



-- 
  Takeru INOUE <tak...@gm...>

[Kai-devel-ja] consistency check by vector clocks

[shunichi s. <shi...@gm...>]

しのはらです。

vector clocks (以下、VC)による整合性チェックを一通り実装しました。
https://sourceforge.net/tracker/index.php?func=detail&aid=1999912&group_id=228337&atid=1073615
https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks
rev 97  (trunk の変更分は merge 済)

trunk にマージする前に、コード上であったり動作としてマズい部分などレビューして
もらえるとありがたいなぁ、とおもっています。

現状の仕様(動作)
- 複数バージョンがあったばあいの get(s)
  - VC で順序解決できれば、一つだけ返す
  - 解決できない組があれば、複数(並列なもの全て)返す
- set の場合
  - coordinator ノードの store にあるデータの VC を更新
    cas が未実装なので、ここでのバージョンチェックは未だ
  - この VC が、別ノードのデータの VC と衝突したら、そのノードではエラー
- gets の場合の cas_unique
  - 最初の 4 bit が VC の個数
  - 残り 60 bit を VC の個数で割って checksum の頭から詰める
  - ex1) 1 つのデータを返すとき:
         0001[checksum の先頭 60 bits] (2 進表現、以下同様)
    ex2) 2 つのデータを返すとき:
         0010[データ1の checksum の先頭 30 bits][データ2の checksum の先頭 30 bits]
    ex3) 7 つのデータを返すとき:
         0111[データiのchecksum の先頭 8 bits]×7[0 埋め]

ソースで(特に)気になるところ
- kai_coordinator_SUITE で、複数ノードのテストのため、slave:start を使っているのですが、
  やりかたとして、もっと簡単にできるとか、別の方法があるとかあればコメントいただきたいです

説明足りないところがあればツッコミおねがいします。

# 勉強会までに、 cas まで実装するのを目標 f(--)

-- 
shino

Re: [Kai-devel-ja] s/kai_api/kai_rpc/

[Takeru I. <tak...@gm...>]

branches/takemaru_store_dets を trunk/ にマージしました．

2008/11/1 shunichi shinohara <shi...@gm...>:
> shino です。
> ブランチ切ってからまったく trunk にマージしてなくてごめんなさい m(_ _)m
>
> 2008/10/31 Takeru INOUE <tak...@gm...>:
>> 前々から，kai_api というモジュール名は kai_rpc に変更すべきだと思ってるんですが，どうでしょうか．
>> api だと external api (memcache api) を想定してしまい，紛らわしいかなと．
>>
>> ためしに，branches/takemaru_store_dets で変更してみました．
>> 影響範囲がかなり大きいのですが，だいじょうぶですかね (特に branch で開発中の shino さん)．
>
> rpc のほうが好みなので、問題ないです。
> このへんの名前は、正しいものに変更していくほうが正解だとおもいます。

そうですね．
その方針で行きましょう．

> # まだ ver. 0.x だし
> # マージはどうなにかなるんじゃないかと思っています,ためしてないけど...

まぁ，いざとなれば branch を作り直すところからやればいいから ;-)

-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] s/kai_api/kai_rpc/

[shunichi s. <shi...@gm...>]

shino です。
ブランチ切ってからまったく trunk にマージしてなくてごめんなさい m(_ _)m

2008/10/31 Takeru INOUE <tak...@gm...>:
> 前々から，kai_api というモジュール名は kai_rpc に変更すべきだと思ってるんですが，どうでしょうか．
> api だと external api (memcache api) を想定してしまい，紛らわしいかなと．
>
> ためしに，branches/takemaru_store_dets で変更してみました．
> 影響範囲がかなり大きいのですが，だいじょうぶですかね (特に branch で開発中の shino さん)．

rpc のほうが好みなので、問題ないです。
このへんの名前は、正しいものに変更していくほうが正解だとおもいます。
# まだ ver. 0.x だし
# マージはどうなにかなるんじゃないかと思っています,ためしてないけど...

shino

[Kai-devel-ja] s/kai_api/kai_rpc/

[Takeru I. <tak...@gm...>]

前々から，kai_api というモジュール名は kai_rpc に変更すべきだと思ってるんですが，どうでしょうか．
api だと external api (memcache api) を想定してしまい，紛らわしいかなと．

ためしに，branches/takemaru_store_dets で変更してみました．
影響範囲がかなり大きいのですが，だいじょうぶですかね (特に branch で開発中の shino さん)．

-- 
  Takeru INOUE <tak...@gm...>

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

[Takeru I. <tak...@gm...>]

今回のアップデートで，タイムアウトが変更され，マクロが個別のソースコードから include/kai.hrl に移動されています．

dets に対応したことで，以前よりレスポンスが悪くなることが多くなりました．
このため，タイムアウトを長め (5秒) に設定しました．
5秒というのは，gen_server などのデフォルトタイムアウトと同じです．

マクロを include/kai.hrl に移動したことにたいした意味はないのですが，こういう数値は一カ所にまとめるべきなので，今さらながらそのようにしました．


2008/10/22 Takeru INOUE <tak...@gm...>:
> 別スレッドにもメールしましたが，dets に対応しました．
>
> dets には 2 GB の上限があるので，複数テーブルを使うようにしました．
> データを書き込むたびに sync (flush) するようにしています．
> dets を利用するときは，いくつかの項目を設定する必要があります．
>
>  store: ets or dets
>  dets_dir: dets テーブルを置くディレクトリ
>  number_of_tables: dets のテーブル数 (2 x number_of_tables [GB] が容量になる)
>
> 一方，ets の上限はアドレス空間で決定されるようなので (32 bit なら 3 GB, 64 bit ならほぼ無限)，ひとつのテーブルしか使っていません．
> テーブル数の指定は不要です．
>
> 少しだけ性能を計ってみました．
> 1 KB のデータでテストしたところ，dets の書き込み性能は ets より一桁以上劣るようです．
> ets が O(1000) なのに対して，dets は O(100) です．
> バラツキも大きいです．
> 今回はデータの更新を行いませんでしたが，更新が頻繁に行われる場合には fragment が発生してさらに性能が低下するかもしれません．
>
> もちろん，性能が低いのは書き込むたびに sync しているからです．
> この点を改善すれば，それなりに性能は向上すると思います．
> dets はいくつものパラメータを設定でき，slot とやらを適切な値にすることで，性能を向上させられるかもしれません．
>
> ちなみに，毎回の sync をやめると，適当なタイミングで (3分間あるいは数十 MB を書き込んだら?) sync してくれます．
> このモードで実験してみたところ，sync が始まると数百ミリ秒から数秒ほどシステムが停止してしまいました．
> 全体のスループットは向上しますが，これはこれでよくないなぁと思いました．
> もちろん，quorum によって，3つのうち 2つの書き込みが速く終わればいいわけで，気にしないでもよいのかもしれませんが．
>
> また，dets には ram_file というモードがあります．
> これは，close するまで flush しないため，とても速いです．
> このモードで物理メモリサイズを超えるデータを書き込んだらどうなるのだろうと思い，実験してみたのですが，一部のデータが失われるという結果になりました．．
>
>
> 2008/7/27 Takeru INOUE <tak...@gm...>:
>>>> ドキュメントには，sync を呼ばなかったときの同期について書いてない気がする．
>>>> 不親切だなぁ．
>>>
>>> そういうものだと思います。ファイルシステムでディスク(というか下回り)と
>>> sync するコストは高い(高すぎる)ので、よっぽどなんか書いてあるのを除き、
>>> sync はしないんじゃないかと。
>>
>> 数十MB 書き込まないと自動的な sync は行われなかった，という記事がありました．
>>
>>  detsの調査続き1 - Erlangとか，Hadoopとか，C++とか
>>
>>  http://d.hatena.ne.jp/huchiyama1976/20080422/1208876182
>>
>>> Dynamo は、レプリケーションで永続性を保証するんだと思ってました。
>>> なので、メモリベースでデータを持つんだろうなぁ、と。
>>> と、ここまで書いたところで、ノード毎に、物理的な RAM 以上のメモリを
>>> 持つことを想定しているのならば、ファイルにマップする意味があるのかなぁ、と
>>> おもいました。
>>
>> 基本は replication なんだろうけど，システムを止められるようにディスクに書き込むオプションも持たせてあるんだと思う．
>> Amazon では，MySQL や BDB を使ってるらしい．
>>
>> Kai としては，まず単純な disk storage (dets?) をサポートして，毎回 sync
>> するようにして，後でメモリキャッシュと組み合わせたり sync をサボったりという最適化を行うのが良いんじゃないかな．
>>
>>>> いまはディスクベースのストレージを比較しているので，ets は除くとします．
>>>> dets (w/ sync) と couch_btree をランダムアクセスで比較すると，
>>>>
>>>> - set の速度はほぼ同じ
>>>
>>> これは、データの永続性を保証する書き込みであれば、 sync(2) なので、
>>> ディスク(永続化デバイス)の性能に依存するし、安いデスクトップサーバで
>>> あれば、遅すぎる( =~ 1msec/sync) とおもています。
>>
>> Amazon では基本的には常に sync させているっぽくて，どうしても速度が必要なときのみ遅延書き込みをさせているらしい．
>>
>>>> - get は dets のが速い
>>>> - ファイルサイズは dets のが小さい
>>>> 壊れにくさはよく分からないですが，dets には修復機能が付いているようです．
>>>
>>> こっちは実装依存なので分からんです f(--)
>>> couchDB のほうが性能が悪いだけ、という可能性もあるですかね。
>>>
>>>> ひとつ気になるのが，CouchDB がわざわざ自前の tree を作った理由です．
>>>> ソースをみると範囲検索が必要だったのはわかるのですが，それにしても ordered_set dets ではいけなかったんだろうか?
>>>
>>> これは気になります。couchDB の人に聞いてみるのが、、、
>>> # といいつつ、このスレッドを英語でやれ、といわれると f(--)
>>
>> 単純に ordered_set dets を使ってない理由を聞いてみるという手はあるけど，Kai 的には直接役に立たない情報なんだよな
>> (ordered である必要がない)．
>>
>>>> Kai も Merkle tree を考えると set dets でいいのか? という疑問がないわけではないのですが，Merkle tree
>>>> は外付けで作る可能性もあるので，ひとまず無視していいかなぁ．
>>>>
>>>>>> 64bit erlang だったら、ets でも容量制限は事実上無い、みたいな話が
>>>>>
>>>>> あれ？
>>>>> ets って昔から容量制限が無いと思い込んでいたのですが
>>>>> 容量制限ってあるんでしたっけ？
>>>>
>>>> 工夫がなければ 32bit アーキテクチャなら 4GB で頭打ちになりそう，ということかな?
>>>
>>> 仮想アドレス空間のうち、アプリが使えるのが、32bit Win なら 2GB、32bit Linux だったら
>>> 3GB なので、メモリ上に単純に置くならその制限にひっかかるでしょうねぇ。
>>> 64bit Linux なら、制限はほぼない、と思っていいはず。
>>
>> 3GB なんだ．
>> 知らなかった．．
>>
>>>>> dets と Mnesia は、1テーブルの最大サイズが 2GByte ですよね？
>>>>> （Mnesia は、内部で dets を利用）
>>>>
>>>> ですね．
>>>> これが面倒の元凶．．
>>>
>>> dets の実装は知らないのですが、file で 2GB と聞くと、いわゆる large file の問題
>>> な気がするのですが、それと一緒?
>>
>> たぶん，そうじゃないのかな．
>> ドキュメントに 2GB まで，って書いてあったので，鵜呑みにしてる．
>>
>>> # 制限がどこでついてるのか、自分で分かってないので調べます
>>> # OS なのか、erlang なのか、dets なのか??
>>>
>>> --
>>> shino
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
  Takeru INOUE <tak...@gm...>

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

[Takeru I. <tak...@gm...>]

別スレッドにもメールしましたが，dets に対応しました．

dets には 2 GB の上限があるので，複数テーブルを使うようにしました．
データを書き込むたびに sync (flush) するようにしています．
dets を利用するときは，いくつかの項目を設定する必要があります．

 store: ets or dets
 dets_dir: dets テーブルを置くディレクトリ
 number_of_tables: dets のテーブル数 (2 x number_of_tables [GB] が容量になる)

一方，ets の上限はアドレス空間で決定されるようなので (32 bit なら 3 GB, 64 bit ならほぼ無限)，ひとつのテーブルしか使っていません．
テーブル数の指定は不要です．

少しだけ性能を計ってみました．
1 KB のデータでテストしたところ，dets の書き込み性能は ets より一桁以上劣るようです．
ets が O(1000) なのに対して，dets は O(100) です．
バラツキも大きいです．
今回はデータの更新を行いませんでしたが，更新が頻繁に行われる場合には fragment が発生してさらに性能が低下するかもしれません．

もちろん，性能が低いのは書き込むたびに sync しているからです．
この点を改善すれば，それなりに性能は向上すると思います．
dets はいくつものパラメータを設定でき，slot とやらを適切な値にすることで，性能を向上させられるかもしれません．

ちなみに，毎回の sync をやめると，適当なタイミングで (3分間あるいは数十 MB を書き込んだら?) sync してくれます．
このモードで実験してみたところ，sync が始まると数百ミリ秒から数秒ほどシステムが停止してしまいました．
全体のスループットは向上しますが，これはこれでよくないなぁと思いました．
もちろん，quorum によって，3つのうち 2つの書き込みが速く終わればいいわけで，気にしないでもよいのかもしれませんが．

また，dets には ram_file というモードがあります．
これは，close するまで flush しないため，とても速いです．
このモードで物理メモリサイズを超えるデータを書き込んだらどうなるのだろうと思い，実験してみたのですが，一部のデータが失われるという結果になりました．．


2008/7/27 Takeru INOUE <tak...@gm...>:
>>> ドキュメントには，sync を呼ばなかったときの同期について書いてない気がする．
>>> 不親切だなぁ．
>>
>> そういうものだと思います。ファイルシステムでディスク(というか下回り)と
>> sync するコストは高い(高すぎる)ので、よっぽどなんか書いてあるのを除き、
>> sync はしないんじゃないかと。
>
> 数十MB 書き込まないと自動的な sync は行われなかった，という記事がありました．
>
>  detsの調査続き1 - Erlangとか，Hadoopとか，C++とか
>
>  http://d.hatena.ne.jp/huchiyama1976/20080422/1208876182
>
>> Dynamo は、レプリケーションで永続性を保証するんだと思ってました。
>> なので、メモリベースでデータを持つんだろうなぁ、と。
>> と、ここまで書いたところで、ノード毎に、物理的な RAM 以上のメモリを
>> 持つことを想定しているのならば、ファイルにマップする意味があるのかなぁ、と
>> おもいました。
>
> 基本は replication なんだろうけど，システムを止められるようにディスクに書き込むオプションも持たせてあるんだと思う．
> Amazon では，MySQL や BDB を使ってるらしい．
>
> Kai としては，まず単純な disk storage (dets?) をサポートして，毎回 sync
> するようにして，後でメモリキャッシュと組み合わせたり sync をサボったりという最適化を行うのが良いんじゃないかな．
>
>>> いまはディスクベースのストレージを比較しているので，ets は除くとします．
>>> dets (w/ sync) と couch_btree をランダムアクセスで比較すると，
>>>
>>> - set の速度はほぼ同じ
>>
>> これは、データの永続性を保証する書き込みであれば、 sync(2) なので、
>> ディスク(永続化デバイス)の性能に依存するし、安いデスクトップサーバで
>> あれば、遅すぎる( =~ 1msec/sync) とおもています。
>
> Amazon では基本的には常に sync させているっぽくて，どうしても速度が必要なときのみ遅延書き込みをさせているらしい．
>
>>> - get は dets のが速い
>>> - ファイルサイズは dets のが小さい
>>> 壊れにくさはよく分からないですが，dets には修復機能が付いているようです．
>>
>> こっちは実装依存なので分からんです f(--)
>> couchDB のほうが性能が悪いだけ、という可能性もあるですかね。
>>
>>> ひとつ気になるのが，CouchDB がわざわざ自前の tree を作った理由です．
>>> ソースをみると範囲検索が必要だったのはわかるのですが，それにしても ordered_set dets ではいけなかったんだろうか?
>>
>> これは気になります。couchDB の人に聞いてみるのが、、、
>> # といいつつ、このスレッドを英語でやれ、といわれると f(--)
>
> 単純に ordered_set dets を使ってない理由を聞いてみるという手はあるけど，Kai 的には直接役に立たない情報なんだよな
> (ordered である必要がない)．
>
>>> Kai も Merkle tree を考えると set dets でいいのか? という疑問がないわけではないのですが，Merkle tree
>>> は外付けで作る可能性もあるので，ひとまず無視していいかなぁ．
>>>
>>>>> 64bit erlang だったら、ets でも容量制限は事実上無い、みたいな話が
>>>>
>>>> あれ？
>>>> ets って昔から容量制限が無いと思い込んでいたのですが
>>>> 容量制限ってあるんでしたっけ？
>>>
>>> 工夫がなければ 32bit アーキテクチャなら 4GB で頭打ちになりそう，ということかな?
>>
>> 仮想アドレス空間のうち、アプリが使えるのが、32bit Win なら 2GB、32bit Linux だったら
>> 3GB なので、メモリ上に単純に置くならその制限にひっかかるでしょうねぇ。
>> 64bit Linux なら、制限はほぼない、と思っていいはず。
>
> 3GB なんだ．
> 知らなかった．．
>
>>>> dets と Mnesia は、1テーブルの最大サイズが 2GByte ですよね？
>>>> （Mnesia は、内部で dets を利用）
>>>
>>> ですね．
>>> これが面倒の元凶．．
>>
>> dets の実装は知らないのですが、file で 2GB と聞くと、いわゆる large file の問題
>> な気がするのですが、それと一緒?
>
> たぶん，そうじゃないのかな．
> ドキュメントに 2GB まで，って書いてあったので，鵜呑みにしてる．
>
>> # 制限がどこでついてるのか、自分で分かってないので調べます
>> # OS なのか、erlang なのか、dets なのか??
>>
>> --
>> shino
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] Polymorphism

[Takeru I. <tak...@gm...>]

書き忘れましたが，dets を使うためには，次の設定項目を追加してください．

  store: ets or dets
  dets_dir: dets テーブルを置くディレクトリ
  number_of_tables: dets のテーブル数 (2 x number_of_tables [GB] が容量になる)


2008/10/22 Takeru INOUE <tak...@gm...>:
> shino さん提案の「1 プロセスで多態」をやってみました．
>
> kai_store を，設定によってets と dets に切り替えられるようにしました．
> コードは branches/takemaru_store_dets/src/kai_store*.erl にあります．
>
> これまで，gen_server を実装した kai_store がストレージ機能を提供していました．
> 今回の変更で，kai_store_ets と kai_store_dets が gen_server を実装し，kai_store
> ではそれらを起動し・呼び出すように変更されています．
>
> メカニズムは次のような感じです．
> kai_store は，設定に合わせて kai_store_ets/dets のいずれかを start させます．
> このとき，プロセス名として kai_store を渡します．
> kai_store_ets/dets は，指定されたプロセス名で動作を開始します．
> RPC 呼び出しは，これまで通り kai_store に実装してあります．
> つまり，呼び出し元の変更は不要です．
> ところが，RPC の呼び出し先はプロセス名で解決されるため，実際に実行されるのは kai_store_ets/dets の関数になります．
> 最後のトリックによって，多態を実現しています．
>
> この方法で，かなり簡単に多態を実装できました．
> また，RPC 呼び出し時に if のような条件分岐がないため，性能的にも問題ないと思われます．
>
> なお，kai_store_ets と kai_store_dets には似たようなコードが出てきますが，今のところは重複を省くようなことはしていません．
> kai_store はかなり簡単なモジュールなので，頑張らなくてもいいかなと．．
> behaviour を使うとキレイに重複のないコードが書けるような気はしていますが，呼び出し先を動的に解決する (Mod:function
> のような書き方をする) ことになるので，性能的には少し不利かもしれません (気になるほどではないと思うけど)．
>
>
> 2008/9/28 Takeru INOUE <tak...@gm...>:
>> 2008/9/23 shunichi shinohara <shi...@gm...>:
>>> しのはらです。
>>>
>>> 2008/9/21 Takeru INOUE <tak...@gm...>:
>>>>> たぶん、思いついているだろうなぁ、と思いつつ、3 つ書いてみます。
>>>>> 1. プロセスとメッセージパッシングで多態
>>>>> 2. モジュールで多態
>>>>> 3. プリプロセッサで多態
>>>>
>>>> どうもありがとうです．
>>>> 地味に if 的な分岐をするくらいしか考えてませんでした．
>>>>
>>>>> 1. プロセスで多態
>>>> そうかそうか，register 名を共通にしてしまえばよいのか．
>>>> RPC 呼び出し関数 (gen_server:call を呼ぶための関数) は，kai_store で定義したほうがいいのかな．
>>>> そうすれば，呼び出し側のコードにまったく影響を与えないで済むなぁ．
>>>> これが一番いいかも．
>>>
>>> 僕も(は)、Erlang で多態をやったことないので、最初のお試しとしては、
>>> この「Erlang 的」に正しいアプローチ(だと思っている)は正解なきがしますね。
>>
>> ひとまず，これでやってみるかぁ．
>> 簡単そうだし．
>>
>>> ひとつ気になっているのは、どの程度多態の中に共通のコードが出てくるか? です。
>>> 多態の良くあるパターンだとおもうのですが、今でいうと下回りの実装特有なコードを
>>> 多態にする場合、Java を例にとると、
>>> - interface 切って、
>>> - AbstractAdapter みたいなので、共通のエラーハンドリングを入れて、
>>> - HogeAdapter, FugaAdapter みたいな特有実装をいくつか作る
>>> という形だとおもいます。
>>>
>>> 「プロセスで多態」の場合、エラーハンドリングみたいな部分をどう捌くのか?
>>> という部分がどうなるのか、楽しみにしてます (o^<^)o
>>
>> ↓ の beahviour を使うのがセオリーなんだろうか?
>>
>>>>> 2. モジュールで多態
>>>>
>>>> RPC 呼び出し関数は kai_store で定義して，その中でモジュール名を動的に決定することになるかな．
>>>> RPC 呼び出し関数に状態を持たせることは難しいので，呼び出しのたびにモジュール名を決定しなければならない?
>>>> そうすると，あまりよくないかも．
>>>
>>> Erlang and polymorphism
>>> ====
>>>  erlang uses 'behaviour' as its proxy for polymorphism. You pass in
>>> the atom representing a module when you make an instance of a process.
>>> As long as the interfaces are the same you can use interchangeable
>>> modules.
>>> ====  http://www.kimbly.com/blog/000052.html
>>>
>>> ググってみたらこんなページがありました。
>>> kai_store を behaviour にして、kai_store_ets みたいなモジュールでそれを利用する、
>>> という形になるでしょうか。
>>> kai_store_ets の名前は設定ファイルで指定するのが自然だとおもいます。
>>> プロセスの登録名は kai_store にしておけば、呼び出し側は kai_store で
>>> アクセスできる、という利点は残るとおもいました。
>>> # kai_store_ets が上で書いた HogeAdapter そのものな感じ
>>>
>>> 慣れないパラダイムでの抽象化はムズかしいなぁ :-<
>>
>> あぁ，behaviour を使うのが Erlang 流ってことかぁ．
>> tcp_server で使っておきながら，気づかないとは… orz
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] Polymorphism

[Takeru I. <tak...@gm...>]

shino さん提案の「1 プロセスで多態」をやってみました．

kai_store を，設定によってets と dets に切り替えられるようにしました．
コードは branches/takemaru_store_dets/src/kai_store*.erl にあります．

これまで，gen_server を実装した kai_store がストレージ機能を提供していました．
今回の変更で，kai_store_ets と kai_store_dets が gen_server を実装し，kai_store
ではそれらを起動し・呼び出すように変更されています．

メカニズムは次のような感じです．
kai_store は，設定に合わせて kai_store_ets/dets のいずれかを start させます．
このとき，プロセス名として kai_store を渡します．
kai_store_ets/dets は，指定されたプロセス名で動作を開始します．
RPC 呼び出しは，これまで通り kai_store に実装してあります．
つまり，呼び出し元の変更は不要です．
ところが，RPC の呼び出し先はプロセス名で解決されるため，実際に実行されるのは kai_store_ets/dets の関数になります．
最後のトリックによって，多態を実現しています．

この方法で，かなり簡単に多態を実装できました．
また，RPC 呼び出し時に if のような条件分岐がないため，性能的にも問題ないと思われます．

なお，kai_store_ets と kai_store_dets には似たようなコードが出てきますが，今のところは重複を省くようなことはしていません．
kai_store はかなり簡単なモジュールなので，頑張らなくてもいいかなと．．
behaviour を使うとキレイに重複のないコードが書けるような気はしていますが，呼び出し先を動的に解決する (Mod:function
のような書き方をする) ことになるので，性能的には少し不利かもしれません (気になるほどではないと思うけど)．


2008/9/28 Takeru INOUE <tak...@gm...>:
> 2008/9/23 shunichi shinohara <shi...@gm...>:
>> しのはらです。
>>
>> 2008/9/21 Takeru INOUE <tak...@gm...>:
>>>> たぶん、思いついているだろうなぁ、と思いつつ、3 つ書いてみます。
>>>> 1. プロセスとメッセージパッシングで多態
>>>> 2. モジュールで多態
>>>> 3. プリプロセッサで多態
>>>
>>> どうもありがとうです．
>>> 地味に if 的な分岐をするくらいしか考えてませんでした．
>>>
>>>> 1. プロセスで多態
>>> そうかそうか，register 名を共通にしてしまえばよいのか．
>>> RPC 呼び出し関数 (gen_server:call を呼ぶための関数) は，kai_store で定義したほうがいいのかな．
>>> そうすれば，呼び出し側のコードにまったく影響を与えないで済むなぁ．
>>> これが一番いいかも．
>>
>> 僕も(は)、Erlang で多態をやったことないので、最初のお試しとしては、
>> この「Erlang 的」に正しいアプローチ(だと思っている)は正解なきがしますね。
>
> ひとまず，これでやってみるかぁ．
> 簡単そうだし．
>
>> ひとつ気になっているのは、どの程度多態の中に共通のコードが出てくるか? です。
>> 多態の良くあるパターンだとおもうのですが、今でいうと下回りの実装特有なコードを
>> 多態にする場合、Java を例にとると、
>> - interface 切って、
>> - AbstractAdapter みたいなので、共通のエラーハンドリングを入れて、
>> - HogeAdapter, FugaAdapter みたいな特有実装をいくつか作る
>> という形だとおもいます。
>>
>> 「プロセスで多態」の場合、エラーハンドリングみたいな部分をどう捌くのか?
>> という部分がどうなるのか、楽しみにしてます (o^<^)o
>
> ↓ の beahviour を使うのがセオリーなんだろうか?
>
>>>> 2. モジュールで多態
>>>
>>> RPC 呼び出し関数は kai_store で定義して，その中でモジュール名を動的に決定することになるかな．
>>> RPC 呼び出し関数に状態を持たせることは難しいので，呼び出しのたびにモジュール名を決定しなければならない?
>>> そうすると，あまりよくないかも．
>>
>> Erlang and polymorphism
>> ====
>>  erlang uses 'behaviour' as its proxy for polymorphism. You pass in
>> the atom representing a module when you make an instance of a process.
>> As long as the interfaces are the same you can use interchangeable
>> modules.
>> ====  http://www.kimbly.com/blog/000052.html
>>
>> ググってみたらこんなページがありました。
>> kai_store を behaviour にして、kai_store_ets みたいなモジュールでそれを利用する、
>> という形になるでしょうか。
>> kai_store_ets の名前は設定ファイルで指定するのが自然だとおもいます。
>> プロセスの登録名は kai_store にしておけば、呼び出し側は kai_store で
>> アクセスできる、という利点は残るとおもいました。
>> # kai_store_ets が上で書いた HogeAdapter そのものな感じ
>>
>> 慣れないパラダイムでの抽象化はムズかしいなぁ :-<
>
> あぁ，behaviour を使うのが Erlang 流ってことかぁ．
> tcp_server で使っておきながら，気づかないとは… orz
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] 複数バージョン時のレスポンス

[Takeru I. <tak...@gm...>]

井上です．

> 初めまして。橋本と申します。
>
> ポータルサイトでSNS関連のサイトの開発や運営をしています。どうぞよろしくお願いします。

こちらこそよろしくです．

> 早速質問させていただきます。
>
> 井上さんのサイトで、
>
>>バージョンの不一致を発見すると，Kai はすべてのバージョンをクライア
>>ントに返します．複数のデータを受信したクライアントは，必要に応じて
>>不一致を解消し，書き戻してください．
>
> とあるのですが、クライアント側からみると具体的にはどのように見えるのでしょうか。
> memcachedのプロトコル仕様には複数バージョンを考慮した部分はなかったと思います。
>
> [user@localhost ~]$ telnet localhost 11211
> Trying 127.0.0.1...
> Connected to localhost (127.0.0.1).
> Escape character is '^]'.
> get hogekey
> VALUE hogekey 0 939
> バージョン１
> END
> VALUE hogekey 0 939
> バージョン2
> END
> quit
> Connection closed by foreign host.
>
> こんな感じかと勝手に想像しています。

ほぼ当たりです．
正確には，END はレスポンスの最後のみになります．

---
VALUE hogekey 0 939
バージョン１
VALUE hogekey 0 939
バージョン2
END
---

実際には，複数バージョンが存在する確率はかなり低いと思います．
データサイズや負荷状況にもよりますが，数ミリ秒の間に同時に書き込まない限りは，そのようなことにはなりません (それでも発生しないかもしれません)．

ところで，おそらく多くの memcache client は，このようなレスポンスを受信しても，バージョン１しか返さないと思われます．
この点は課題となっていまして，memcache client を少し修正しなければならないと考えています．

-- 
  Takeru INOUE <tak...@gm...>

[Kai-devel-ja] 複数バージョン時のレスポンス

[Tomoya H. <tom...@gm...>]

初めまして。橋本と申します。

ポータルサイトでSNS関連のサイトの開発や運営をしています。どうぞよろしくお願いします。

早速質問させていただきます。

井上さんのサイトで、

>バージョンの不一致を発見すると，Kai はすべてのバージョンをクライア
>ントに返します．複数のデータを受信したクライアントは，必要に応じて
>不一致を解消し，書き戻してください．

とあるのですが、クライアント側からみると具体的にはどのように見えるのでしょうか。
memcachedのプロトコル仕様には複数バージョンを考慮した部分はなかったと思います。

[user@localhost ~]$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
get hogekey
VALUE hogekey 0 939
バージョン１
END
VALUE hogekey 0 939
バージョン2
END
quit
Connection closed by foreign host.

こんな感じかと勝手に想像しています。

--
Tomoya Hashimoto

Re: [Kai-devel-ja] Polymorphism

[Takeru I. <tak...@gm...>]

2008/9/23 shunichi shinohara <shi...@gm...>:
> しのはらです。
>
> 2008/9/21 Takeru INOUE <tak...@gm...>:
>>> たぶん、思いついているだろうなぁ、と思いつつ、3 つ書いてみます。
>>> 1. プロセスとメッセージパッシングで多態
>>> 2. モジュールで多態
>>> 3. プリプロセッサで多態
>>
>> どうもありがとうです．
>> 地味に if 的な分岐をするくらいしか考えてませんでした．
>>
>>> 1. プロセスで多態
>> そうかそうか，register 名を共通にしてしまえばよいのか．
>> RPC 呼び出し関数 (gen_server:call を呼ぶための関数) は，kai_store で定義したほうがいいのかな．
>> そうすれば，呼び出し側のコードにまったく影響を与えないで済むなぁ．
>> これが一番いいかも．
>
> 僕も(は)、Erlang で多態をやったことないので、最初のお試しとしては、
> この「Erlang 的」に正しいアプローチ(だと思っている)は正解なきがしますね。

ひとまず，これでやってみるかぁ．
簡単そうだし．

> ひとつ気になっているのは、どの程度多態の中に共通のコードが出てくるか? です。
> 多態の良くあるパターンだとおもうのですが、今でいうと下回りの実装特有なコードを
> 多態にする場合、Java を例にとると、
> - interface 切って、
> - AbstractAdapter みたいなので、共通のエラーハンドリングを入れて、
> - HogeAdapter, FugaAdapter みたいな特有実装をいくつか作る
> という形だとおもいます。
>
> 「プロセスで多態」の場合、エラーハンドリングみたいな部分をどう捌くのか?
> という部分がどうなるのか、楽しみにしてます (o^<^)o

↓ の beahviour を使うのがセオリーなんだろうか?

>>> 2. モジュールで多態
>>
>> RPC 呼び出し関数は kai_store で定義して，その中でモジュール名を動的に決定することになるかな．
>> RPC 呼び出し関数に状態を持たせることは難しいので，呼び出しのたびにモジュール名を決定しなければならない?
>> そうすると，あまりよくないかも．
>
> Erlang and polymorphism
> ====
>  erlang uses 'behaviour' as its proxy for polymorphism. You pass in
> the atom representing a module when you make an instance of a process.
> As long as the interfaces are the same you can use interchangeable
> modules.
> ====  http://www.kimbly.com/blog/000052.html
>
> ググってみたらこんなページがありました。
> kai_store を behaviour にして、kai_store_ets みたいなモジュールでそれを利用する、
> という形になるでしょうか。
> kai_store_ets の名前は設定ファイルで指定するのが自然だとおもいます。
> プロセスの登録名は kai_store にしておけば、呼び出し側は kai_store で
> アクセスできる、という利点は残るとおもいました。
> # kai_store_ets が上で書いた HogeAdapter そのものな感じ
>
> 慣れないパラダイムでの抽象化はムズかしいなぁ :-<

あぁ，behaviour を使うのが Erlang 流ってことかぁ．
tcp_server で使っておきながら，気づかないとは… orz

-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] Polymorphism

[shunichi s. <shi...@gm...>]

しのはらです。
# 配送エラーのメールがきてたのでもう一度送ります。重複したらごめんなさい。

2008/9/21 Takeru INOUE <tak...@gm...>:
>> たぶん、思いついているだろうなぁ、と思いつつ、3 つ書いてみます。
>> 1. プロセスとメッセージパッシングで多態
>> 2. モジュールで多態
>> 3. プリプロセッサで多態
>
> どうもありがとうです．
> 地味に if 的な分岐をするくらいしか考えてませんでした．
>
>> 1. プロセスで多態
> そうかそうか，register 名を共通にしてしまえばよいのか．
> RPC 呼び出し関数 (gen_server:call を呼ぶための関数) は，kai_store で定義したほうがいいのかな．
> そうすれば，呼び出し側のコードにまったく影響を与えないで済むなぁ．
> これが一番いいかも．

僕も(は)、Erlang で多態をやったことないので、最初のお試しとしては、
この「Erlang 的」に正しいアプローチ(だと思っている)は正解なきがしますね。

ひとつ気になっているのは、どの程度多態の中に共通のコードが出てくるか? です。
多態の良くあるパターンだとおもうのですが、今でいうと下回りの実装特有なコードを
多態にする場合、Java を例にとると、
- interface 切って、
- AbstractAdapter みたいなので、共通のエラーハンドリングを入れて、
- HogeAdapter, FugaAdapter みたいな特有実装をいくつか作る
という形だとおもいます。

「プロセスで多態」の場合、エラーハンドリングみたいな部分をどう捌くのか?
という部分がどうなるのか、楽しみにしてます (o^<^)o

>> 2. モジュールで多態
>
> RPC 呼び出し関数は kai_store で定義して，その中でモジュール名を動的に決定することになるかな．
> RPC 呼び出し関数に状態を持たせることは難しいので，呼び出しのたびにモジュール名を決定しなければならない?
> そうすると，あまりよくないかも．

Erlang and polymorphism
====
 erlang uses 'behaviour' as its proxy for polymorphism. You pass in
the atom representing a module when you make an instance of a process.
As long as the interfaces are the same you can use interchangeable
modules.
====  http://www.kimbly.com/blog/000052.html

ググってみたらこんなページがありました。
kai_store を behaviour にして、kai_store_ets みたいなモジュールでそれを利用する、
という形になるでしょうか。
kai_store_ets の名前は設定ファイルで指定するのが自然だとおもいます。
プロセスの登録名は kai_store にしておけば、呼び出し側は kai_store で
アクセスできる、という利点は残るとおもいました。
# kai_store_ets が上で書いた HogeAdapter そのものな感じ

慣れないパラダイムでの抽象化はムズかしいなぁ :-<

--
shino

Re: [Kai-devel-ja] Polymorphism

[shunichi s. <shi...@gm...>]

しのはらです。

2008/9/21 Takeru INOUE <tak...@gm...>:
>> たぶん、思いついているだろうなぁ、と思いつつ、3 つ書いてみます。
>> 1. プロセスとメッセージパッシングで多態
>> 2. モジュールで多態
>> 3. プリプロセッサで多態
>
> どうもありがとうです．
> 地味に if 的な分岐をするくらいしか考えてませんでした．
>
>> 1. プロセスで多態
> そうかそうか，register 名を共通にしてしまえばよいのか．
> RPC 呼び出し関数 (gen_server:call を呼ぶための関数) は，kai_store で定義したほうがいいのかな．
> そうすれば，呼び出し側のコードにまったく影響を与えないで済むなぁ．
> これが一番いいかも．

僕も(は)、Erlang で多態をやったことないので、最初のお試しとしては、
この「Erlang 的」に正しいアプローチ(だと思っている)は正解なきがしますね。

ひとつ気になっているのは、どの程度多態の中に共通のコードが出てくるか? です。
多態の良くあるパターンだとおもうのですが、今でいうと下回りの実装特有なコードを
多態にする場合、Java を例にとると、
- interface 切って、
- AbstractAdapter みたいなので、共通のエラーハンドリングを入れて、
- HogeAdapter, FugaAdapter みたいな特有実装をいくつか作る
という形だとおもいます。

「プロセスで多態」の場合、エラーハンドリングみたいな部分をどう捌くのか?
という部分がどうなるのか、楽しみにしてます (o^<^)o

>> 2. モジュールで多態
>
> RPC 呼び出し関数は kai_store で定義して，その中でモジュール名を動的に決定することになるかな．
> RPC 呼び出し関数に状態を持たせることは難しいので，呼び出しのたびにモジュール名を決定しなければならない?
> そうすると，あまりよくないかも．

Erlang and polymorphism
====
 erlang uses 'behaviour' as its proxy for polymorphism. You pass in
the atom representing a module when you make an instance of a process.
As long as the interfaces are the same you can use interchangeable
modules.
====  http://www.kimbly.com/blog/000052.html

ググってみたらこんなページがありました。
kai_store を behaviour にして、kai_store_ets みたいなモジュールでそれを利用する、
という形になるでしょうか。
kai_store_ets の名前は設定ファイルで指定するのが自然だとおもいます。
プロセスの登録名は kai_store にしておけば、呼び出し側は kai_store で
アクセスできる、という利点は残るとおもいました。
# kai_store_ets が上で書いた HogeAdapter そのものな感じ

慣れないパラダイムでの抽象化はムズかしいなぁ :-<

-- 
shino

Re: [Kai-devel-ja] Polymorphism

[Takeru I. <tak...@gm...>]

2008/9/19 shunichi shinohara <shi...@gm...>:
> しのはらです。
>
> 2008/9/18 Takeru INOUE <tak...@gm...>:
>> kai_store を dets 対応させようと思っています．
>> ets の実装も残して，設定で ets と dets を選べるようにしたいです．
>>
>> オブジェクト指向のプログラミング言語だと，Interface を定義して，サブクラスで実装するのが一般的なのかなと思います (古い?)．
>> 似たようなことを Erlang でスマートにやる方法ってあるのでしょうか?
>
> たぶん、思いついているだろうなぁ、と思いつつ、3 つ書いてみます。
> 1. プロセスとメッセージパッシングで多態
> 2. モジュールで多態
> 3. プリプロセッサで多態

どうもありがとうです．
地味に if 的な分岐をするくらいしか考えてませんでした．

> 1. プロセスで多態
> ストレージを管理するプロセスを、 ets/dets で用意して、実際にはどちらかが
> 起動する。(例えば kai_store_ets, kai_store_dets)
> # ここは設定ファイルかな?
> register するときに名前を、kai_store で登録。
> メッセージ送信するときは、kai_store に対して送信。
> 多態は、メッセージの形式を決めることで実現。
>
> OOP との比較では、オブジェクトをプロセスに置き換えることになるので
> OOP 寄りのひと(ぼくもこっちだ)から見ても、結構自然な感じだとおもいます。

そうかそうか，register 名を共通にしてしまえばよいのか．
RPC 呼び出し関数 (gen_server:call を呼ぶための関数) は，kai_store で定義したほうがいいのかな．
そうすれば，呼び出し側のコードにまったく影響を与えないで済むなぁ．
これが一番いいかも．

> 2. モジュールで多態
> Module:Function の呼び出しは、こんなかんじで、動的にできるみたいなので、
> 1> lists:sort([b,a,c]).
> [a,b,c]
> 2> L = lists.
> lists
> 3> L:sort([b,c,a]).
> [a,b,c]
> モジュール名を実行時に渡すことで多態ができますね。
> モジュールをインスタンスと見たダックタイピングと見れば(ぼくには)自然かな。
> たとえば、今、 kai_store:some_func(..) と書いているところを、
> StoreModule = kai_config:get(store_module),
> StoreModule:some_func(..)
> とかけばいいのかな。
> # 実際には試していないです f(--)

RPC 呼び出し関数は kai_store で定義して，その中でモジュール名を動的に決定することになるかな．
RPC 呼び出し関数に状態を持たせることは難しいので，呼び出しのたびにモジュール名を決定しなければならない?
そうすると，あまりよくないかも．

> 3. プリプロセッサで多態
> 古典的に(?)、kai_store と書いているところを
> ?kai_store にして、kai.hrl で定義。
> これだと、変更するときにはコンパイルしなおさなくていけないのが
> めんどくさそうな気がします。

再コンパイルは避けたいですね．

というわけで，僕が検討したところ 1 が良さそうな気がしました．
どうでしょうか?

-- 
 Takeru INOUE <tak...@gm...>

[Kai-devel-ja] Polymorphism

[Takeru I. <tak...@gm...>]

kai_store を dets 対応させようと思っています．
ets の実装も残して，設定で ets と dets を選べるようにしたいです．

オブジェクト指向のプログラミング言語だと，Interface を定義して，サブクラスで実装するのが一般的なのかなと思います (古い?)．
似たようなことを Erlang でスマートにやる方法ってあるのでしょうか?

-- 
 Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] 0.2 リリースに向けて

[Takeru I. <tak...@gm...>]

ありがとうございます．

2008/8/29 masahito ikuta <coo...@gm...>:
> 修正内容の確認と OSX 10.4 10.5、FreeBSD 6.3 での動作確認を行ないました。
> 問題なく動いてます。
>
> 2008/8/28 Takeru INOUE <tak...@gm...>:
>>> とりあえず、trunk に kai_tcp_server の修正だけ入れてしまい
>>> 二回目のリリース後に検討するという事で如何でしょう？
>>
>> この線で 0.2.0 をリリースしました．
>> SASL は 0.3 に向けて考えていきましょう．
>>
>> 0.3 の目標は
>>
>> - SASL
>> - Vector Clocks
>> - dets
>>
>> といったところでしょうか．
>>
>>
>> 2008/8/24 Takeru INOUE <tak...@gm...>:
>>> 0.1 のリリースから一ヶ月半が経つので，そろそろ Kai 0.2 をリリースしたいなと考えてます．
>>>
>>> cooldaemon さんが取り組んでくれている SASL が落ち着いたら，connection pool をマージして，それを 0.2
>>> にしようと思ってますが，いかがでしょうか．
>>>
>>> 0.1 からの差分は，次のようになる予定です．
>>>
>>> - Better stability under high load
>>>   - Introducing connection pooling
>>>   - Avoidance of deadlock
>>>   - Fixing a bug of node list in the consistent hash
>>> - Preparation for vector clocks
>>>   - Routing requests to the coordinator
>>> - Operability issues
>>>   - SASL
>>>   - EDoc and dialyzer
>>>
>>>
>>> 2008/8/21  <tak...@gm...>:
>>>> はい、詳しい人にやってもらったほうがよさそうなので、お願いしますm(__)m
>>>>
>>>> On 8/21/08, masahito ikuta <coo...@gm...> wrote:
>>>>>> みんな，show のような関数を定義して使ってるんですかねぇ．
>>>>>
>>>>> ELOG は、yaws の source を見て盗んだような記憶があります。
>>>>> show は、何となく私が適当に作ったものです。
>>>>> 試しに、私のほうで branch を作って SASL を組み込んでみましょうか？
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Kai-devel-ja mailing list
>> Kai...@li...
>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>
>
>
>
> --
> cooldaemon
>



-- 
 Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] 0.2 リリースに向けて

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

修正内容の確認と OSX 10.4 10.5、FreeBSD 6.3 での動作確認を行ないました。
問題なく動いてます。

2008/8/28 Takeru INOUE <tak...@gm...>:
>> とりあえず、trunk に kai_tcp_server の修正だけ入れてしまい
>> 二回目のリリース後に検討するという事で如何でしょう？
>
> この線で 0.2.0 をリリースしました．
> SASL は 0.3 に向けて考えていきましょう．
>
> 0.3 の目標は
>
> - SASL
> - Vector Clocks
> - dets
>
> といったところでしょうか．
>
>
> 2008/8/24 Takeru INOUE <tak...@gm...>:
>> 0.1 のリリースから一ヶ月半が経つので，そろそろ Kai 0.2 をリリースしたいなと考えてます．
>>
>> cooldaemon さんが取り組んでくれている SASL が落ち着いたら，connection pool をマージして，それを 0.2
>> にしようと思ってますが，いかがでしょうか．
>>
>> 0.1 からの差分は，次のようになる予定です．
>>
>> - Better stability under high load
>>   - Introducing connection pooling
>>   - Avoidance of deadlock
>>   - Fixing a bug of node list in the consistent hash
>> - Preparation for vector clocks
>>   - Routing requests to the coordinator
>> - Operability issues
>>   - SASL
>>   - EDoc and dialyzer
>>
>>
>> 2008/8/21  <tak...@gm...>:
>>> はい、詳しい人にやってもらったほうがよさそうなので、お願いしますm(__)m
>>>
>>> On 8/21/08, masahito ikuta <coo...@gm...> wrote:
>>>>> みんな，show のような関数を定義して使ってるんですかねぇ．
>>>>
>>>> ELOG は、yaws の source を見て盗んだような記憶があります。
>>>> show は、何となく私が適当に作ったものです。
>>>> 試しに、私のほうで branch を作って SASL を組み込んでみましょうか？
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>



-- 
cooldaemon

Re: [Kai-devel-ja] 0.2 リリースに向けて

[Takeru I. <tak...@gm...>]

0.2 に合わせて，Wiki を修正しました．
最低限の修正ですが．．

  http://kai.wiki.sourceforge.net/

性能評価結果も書いておかないとなぁ．
あと，edoc 用にもドキュメントを書かないと．．


2008/8/28 Takeru INOUE <tak...@gm...>:
>> とりあえず、trunk に kai_tcp_server の修正だけ入れてしまい
>> 二回目のリリース後に検討するという事で如何でしょう？
>
> この線で 0.2.0 をリリースしました．
> SASL は 0.3 に向けて考えていきましょう．
>
> 0.3 の目標は
>
> - SASL
> - Vector Clocks
> - dets
>
> といったところでしょうか．
>
>
> 2008/8/24 Takeru INOUE <tak...@gm...>:
>> 0.1 のリリースから一ヶ月半が経つので，そろそろ Kai 0.2 をリリースしたいなと考えてます．
>>
>> cooldaemon さんが取り組んでくれている SASL が落ち着いたら，connection pool をマージして，それを 0.2
>> にしようと思ってますが，いかがでしょうか．
>>
>> 0.1 からの差分は，次のようになる予定です．
>>
>> - Better stability under high load
>>   - Introducing connection pooling
>>   - Avoidance of deadlock
>>   - Fixing a bug of node list in the consistent hash
>> - Preparation for vector clocks
>>   - Routing requests to the coordinator
>> - Operability issues
>>   - SASL
>>   - EDoc and dialyzer
>>
>>
>> 2008/8/21  <tak...@gm...>:
>>> はい、詳しい人にやってもらったほうがよさそうなので、お願いしますm(__)m
>>>
>>> On 8/21/08, masahito ikuta <coo...@gm...> wrote:
>>>>> みんな，show のような関数を定義して使ってるんですかねぇ．
>>>>
>>>> ELOG は、yaws の source を見て盗んだような記憶があります。
>>>> show は、何となく私が適当に作ったものです。
>>>> 試しに、私のほうで branch を作って SASL を組み込んでみましょうか？
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
 Takeru INOUE <tak...@gm...>