kai-devel-ja

[Kai-devel-ja] multiple (confilicting) data in single node

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

kai-devel-ja のみなさん

しのはらです。
単一ノードで複数バージョンを格納するように kai_store 層を変更してみました。
幾田さんの gihyo.jp の解説がとってもすばらしいので start_kai.sh とか早速ぱくって
detach してやってみました (o^<^)o

基本的な修正は以下 3 点です
1. kai_store_(ets|dets) を set から bag へ変更
2. kai_store の get を data から [data] を返すように変更
3. kai_store の put を、バージョン衝突が起きても ok を返すよう変更

2. のインターフェイス変更にともない、上に向かって kai_coordinator/kai_sync
あたりまでちょこちょこと修正を入れました。
memcached 層での修正はありません。
% たけるさんのテストケースリファクタ&強化のおかげで安心して作業できました m(_ _)m

1. に伴う性能低下をちょっと気にしていたのですが、kai_store_SUITE の perf で見たところ、
大きな変化はないようです。が、心配なのでもしちゃんとしたクラスタ環境での測定が出来る
ようでしたら、どなたかよろしくお願いします。 # 他力本願ですんません (T-T)

実装以外の問題として、dets ファイルと、 kai_store:get の 2 つの部分で、
後方互換性を保たないようになっているので、バージョンアップのパスをどうするか?
という点があるとおもいます。
例えば、クラスタ内のノードにたいして、ローリングアップデートが出来るような
バージョンアップ方法が必要であれば、それをちゃんとかんがえなくてはいけません。

ここは運用している方のご意見を是非!欲しいところです。

以上、ご意見、コメントおまちしています。

-- 
shino

Re: [Kai-devel-ja] multiple (confilicting) data in single node

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

コミットログをざっと眺めて，テストが通ることを確認しました (R12, R13 とも)．

ローリングアップデートは難しい (というかテストを考えると面倒…) なので，バージョン0.x のうちは見送りたいなぁと思ってるのですが．．
dets の変換スクリプトを用意するくらいが簡単かなと思ってるのだけど，運用してる方のご意見待ちかな．


2009/6/23 shunichi shinohara <shi...@gm...>:
> kai-devel-ja のみなさん
>
> しのはらです。
> 単一ノードで複数バージョンを格納するように kai_store 層を変更してみました。
> 幾田さんの gihyo.jp の解説がとってもすばらしいので start_kai.sh とか早速ぱくって
> detach してやってみました (o^<^)o
>
> 基本的な修正は以下 3 点です
> 1. kai_store_(ets|dets) を set から bag へ変更
> 2. kai_store の get を data から [data] を返すように変更
> 3. kai_store の put を、バージョン衝突が起きても ok を返すよう変更
>
> 2. のインターフェイス変更にともない、上に向かって kai_coordinator/kai_sync
> あたりまでちょこちょこと修正を入れました。
> memcached 層での修正はありません。
> % たけるさんのテストケースリファクタ&強化のおかげで安心して作業できました m(_ _)m
>
> 1. に伴う性能低下をちょっと気にしていたのですが、kai_store_SUITE の perf で見たところ、
> 大きな変化はないようです。が、心配なのでもしちゃんとしたクラスタ環境での測定が出来る
> ようでしたら、どなたかよろしくお願いします。 # 他力本願ですんません (T-T)
>
> 実装以外の問題として、dets ファイルと、 kai_store:get の 2 つの部分で、
> 後方互換性を保たないようになっているので、バージョンアップのパスをどうするか?
> という点があるとおもいます。
> 例えば、クラスタ内のノードにたいして、ローリングアップデートが出来るような
> バージョンアップ方法が必要であれば、それをちゃんとかんがえなくてはいけません。
>
> ここは運用している方のご意見を是非!欲しいところです。
>
> 以上、ご意見、コメントおまちしています。
>
> --
> shino
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>



-- 
Takeru INOUE

Re: [Kai-devel-ja] multiple (confilicting) data in single node

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

橋本です。

後方互換が保てない場合のアップデートを考えてみました。

運用中なのでサービスを停止せずにアップデートできるのが望ましいです。たとえば、ノードを１台毎に止めてアップデートできれば全体としては停止しないのでいいかと思います。

いったん全てのノードを止めてアップデートして、それから起動する方法もあるかと思います。手順が複雑でなく、許容できそうな停止時間に収まればこれもありかと思います。

事実上不可能と思われるアップデート方法は、すべてのオブジェクトをgetしてどこかに取っておいて、すべてをsetして元に戻す方法です。すべてのオブジェクトを知る方法がなかったりします。

こんなところです。

2009/06/23 16:40 に shunichi shinohara<shi...@gm...> さんは書きました:
> kai-devel-ja のみなさん
>
> しのはらです。
> 単一ノードで複数バージョンを格納するように kai_store 層を変更してみました。
> 幾田さんの gihyo.jp の解説がとってもすばらしいので start_kai.sh とか早速ぱくって
> detach してやってみました (o^<^)o
>
> 基本的な修正は以下 3 点です
> 1. kai_store_(ets|dets) を set から bag へ変更
> 2. kai_store の get を data から [data] を返すように変更
> 3. kai_store の put を、バージョン衝突が起きても ok を返すよう変更
>
> 2. のインターフェイス変更にともない、上に向かって kai_coordinator/kai_sync
> あたりまでちょこちょこと修正を入れました。
> memcached 層での修正はありません。
> % たけるさんのテストケースリファクタ&強化のおかげで安心して作業できました m(_ _)m
>
> 1. に伴う性能低下をちょっと気にしていたのですが、kai_store_SUITE の perf で見たところ、
> 大きな変化はないようです。が、心配なのでもしちゃんとしたクラスタ環境での測定が出来る
> ようでしたら、どなたかよろしくお願いします。 # 他力本願ですんません (T-T)
>
> 実装以外の問題として、dets ファイルと、 kai_store:get の 2 つの部分で、
> 後方互換性を保たないようになっているので、バージョンアップのパスをどうするか?
> という点があるとおもいます。
> 例えば、クラスタ内のノードにたいして、ローリングアップデートが出来るような
> バージョンアップ方法が必要であれば、それをちゃんとかんがえなくてはいけません。
>
> ここは運用している方のご意見を是非!欲しいところです。
>
> 以上、ご意見、コメントおまちしています。
>
> --
> shino
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>

Re: [Kai-devel-ja] multiple (confilicting) data in single node

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

しのはらです。

2009/6/24 Tomoya Hashimoto <tom...@gm...>:
> 後方互換が保てない場合のアップデートを考えてみました。
>
> 運用中なのでサービスを停止せずにアップデートできるのが望ましいです。たとえば、
> ノードを１台毎に止めてアップデートできれば全体としては停止しないのでいいかと思います。
>
> いったん全てのノードを止めてアップデートして、それから起動する方法もあるかと思います。
> 手順が複雑でなく、許容できそうな停止時間に収まればこれもありかと思います。

例えば、モジュールの入れ替えだけであれば、全ノード停止、という選択肢も
(まぁ)許容できる、となりそうですね。とても参考になります :-)
変更をうまく分離すれば、プロトコル変更部分だけを先に全ノード停止で行って、
その後に dets ファイルの変換をノード毎に行う、という方法が可能かと思いました。

今後のことをかんがえると、プロトコル的に非互換になる場合もあるとおもうので、
複数バージョンが共存できるようなプロトコル実装を考えておきたいですね。
そうすれば、試験的に一部のノードだけアップデートして、様子を見る、という
ことができるので、自分だったら嬉しいです。

> 事実上不可能と思われるアップデート方法は、すべてのオブジェクトをgetしてどこかに取っておいて、
> すべてをsetして元に戻す方法です。すべてのオブジェクトを知る方法がなかったりします。

たしかに、KVS では一般に難しいですよね。インデックスみたいなものはないので...

-- 
shino

Re: [Kai-devel-ja] multiple (confilicting) data in single node

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

遅くなりましたが，簡単に性能試験を行いました．
大きな変化はないようです．

というわけで，trunk/ に取り込んでもいいと思います．


2009/6/24 Takeru INOUE <tak...@gm...>:
> コミットログをざっと眺めて，テストが通ることを確認しました (R12, R13 とも)．
>
> ローリングアップデートは難しい (というかテストを考えると面倒…) なので，バージョン0.x のうちは見送りたいなぁと思ってるのですが．．
> dets の変換スクリプトを用意するくらいが簡単かなと思ってるのだけど，運用してる方のご意見待ちかな．
>
>
> 2009/6/23 shunichi shinohara <shi...@gm...>:
>> kai-devel-ja のみなさん
>>
>> しのはらです。
>> 単一ノードで複数バージョンを格納するように kai_store 層を変更してみました。
>> 幾田さんの gihyo.jp の解説がとってもすばらしいので start_kai.sh とか早速ぱくって
>> detach してやってみました (o^<^)o
>>
>> 基本的な修正は以下 3 点です
>> 1. kai_store_(ets|dets) を set から bag へ変更
>> 2. kai_store の get を data から [data] を返すように変更
>> 3. kai_store の put を、バージョン衝突が起きても ok を返すよう変更
>>
>> 2. のインターフェイス変更にともない、上に向かって kai_coordinator/kai_sync
>> あたりまでちょこちょこと修正を入れました。
>> memcached 層での修正はありません。
>> % たけるさんのテストケースリファクタ&強化のおかげで安心して作業できました m(_ _)m
>>
>> 1. に伴う性能低下をちょっと気にしていたのですが、kai_store_SUITE の perf で見たところ、
>> 大きな変化はないようです。が、心配なのでもしちゃんとしたクラスタ環境での測定が出来る
>> ようでしたら、どなたかよろしくお願いします。 # 他力本願ですんません (T-T)
>>
>> 実装以外の問題として、dets ファイルと、 kai_store:get の 2 つの部分で、
>> 後方互換性を保たないようになっているので、バージョンアップのパスをどうするか?
>> という点があるとおもいます。
>> 例えば、クラスタ内のノードにたいして、ローリングアップデートが出来るような
>> バージョンアップ方法が必要であれば、それをちゃんとかんがえなくてはいけません。
>>
>> ここは運用している方のご意見を是非!欲しいところです。
>>
>> 以上、ご意見、コメントおまちしています。
>>
>> --
>> shino
>>
>> ------------------------------------------------------------------------------
>> Are you an open source citizen? Join us for the Open Source Bridge conference!
>> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
>> Need another reason to go? 24-hour hacker lounge. Register today!
>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
>> _______________________________________________
>> Kai-devel-ja mailing list
>> Kai...@li...
>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>
>
>
>
> --
> Takeru INOUE
>



-- 
Takeru INOUE

Re: [Kai-devel-ja] multiple (confilicting) data in single node

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

たけるさん

性能試験ありがとうございます。
trunk にマージしました。

以下、kai と関係ない、蛇足な質問で申し訳ないのですが、、、、
git-svn をはじめて使ってみて、マージ & dcommit してみたのですが、
svn dcommit のコミット先を変更せずに、ブランチへのコミット単位で
マージする方法をご存知の方はいらっしゃれば、教えていただけるとありがたいです。

今回は、svn/git branch での複数コミットを、 svn trunk への一つのコミットに
まとめて commit してしまいました。
悪いわけではないのですが、kai くらいのコミット頻度であれば(そうでなくても?)
trunk のログを追いかけるだけで、細かく違いが追えたほうが良いと思っています。
# 個々の diff の意図が追えないと、後で痛い目に会うはず

今回は、最初、
  git-svn merge shino_data_in_bag_local   (trunk を反映したローカルブランチで)
と --no-ff を付けずにマージして、 git-svn dcommit の先がブランチ
に変わってしまい困りました。
--no-ff でコミットがマージされることは分かったのですが、trunk へのコミットが
一つにまとまってしまいました。

# 慣れないのはしんどいですが、 git インターフェイスのほうが便利なのでこっちに移行したい...

しのはら

2009/7/13 Takeru INOUE <tak...@gm...>:
> 遅くなりましたが，簡単に性能試験を行いました．
> 大きな変化はないようです．
>
> というわけで，trunk/ に取り込んでもいいと思います．
>
>
> 2009/6/24 Takeru INOUE <tak...@gm...>:
>> コミットログをざっと眺めて，テストが通ることを確認しました (R12, R13 とも)．
>>
>> ローリングアップデートは難しい (というかテストを考えると面倒…) なので，バージョン0.x のうちは見送りたいなぁと思ってるのですが．．
>> dets の変換スクリプトを用意するくらいが簡単かなと思ってるのだけど，運用してる方のご意見待ちかな．
>>

-- 
shino

Re: [Kai-devel-ja] multiple (confilicting) data in single node

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

cherry-pick は如何でしょうか？

2009/7/19 shunichi shinohara <shi...@gm...>:
> たけるさん
>
> 性能試験ありがとうございます。
> trunk にマージしました。
>
> 以下、kai と関係ない、蛇足な質問で申し訳ないのですが、、、、
> git-svn をはじめて使ってみて、マージ & dcommit してみたのですが、
> svn dcommit のコミット先を変更せずに、ブランチへのコミット単位で
> マージする方法をご存知の方はいらっしゃれば、教えていただけるとありがたいです。
>
> 今回は、svn/git branch での複数コミットを、 svn trunk への一つのコミットに
> まとめて commit してしまいました。
> 悪いわけではないのですが、kai くらいのコミット頻度であれば(そうでなくても?)
> trunk のログを追いかけるだけで、細かく違いが追えたほうが良いと思っています。
> # 個々の diff の意図が追えないと、後で痛い目に会うはず
>
> 今回は、最初、
>  git-svn merge shino_data_in_bag_local   (trunk を反映したローカルブランチで)
> と --no-ff を付けずにマージして、 git-svn dcommit の先がブランチ
> に変わってしまい困りました。
> --no-ff でコミットがマージされることは分かったのですが、trunk へのコミットが
> 一つにまとまってしまいました。
>
> # 慣れないのはしんどいですが、 git インターフェイスのほうが便利なのでこっちに移行したい...
>
> しのはら
>
> 2009/7/13 Takeru INOUE <tak...@gm...>:
>> 遅くなりましたが，簡単に性能試験を行いました．
>> 大きな変化はないようです．
>>
>> というわけで，trunk/ に取り込んでもいいと思います．
>>
>>
>> 2009/6/24 Takeru INOUE <tak...@gm...>:
>>> コミットログをざっと眺めて，テストが通ることを確認しました (R12, R13 とも)．
>>>
>>> ローリングアップデートは難しい (というかテストを考えると面倒...) なので，バージョン0.x のうちは見送りたいなぁと思ってるのですが．．
>>> dets の変換スクリプトを用意するくらいが簡単かなと思ってるのだけど，運用してる方のご意見待ちかな．
>>>
>
> --
> shino
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>



-- 
cooldaemon

Re: [Kai-devel-ja] multiple (confilicting) data in single node

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

幾田さん

> cherry-pick は如何でしょうか？

おおぉ、初めて知りました。次回試してみます!

しのはら


2009/7/20 masahito ikuta <coo...@gm...>:
> cherry-pick は如何でしょうか？
>

-- 
shino