okuyamaについて教えてもらったよ

かなり手の込んだ実装が為されている事に驚くばかり
22
くまぎ @kumagi

JavaはGCなどの為にメモリ効率がそんなに良くないので、オンメモリなデータストアを構築する言語としては向いてないと思ってたんだけどokuyamaがどういう哲学でJavaを選んだのかどこかに転がってないかな。

2011-06-15 11:28:03
Kenji Yoshida @xuwei_k

Javaが得意とか好きとかいってたような・・・ RT @kumagi JavaはGCなどの為にメモリ効率がそんなに良くないので、オンメモリなデータストアを構築する言語としては向いてないと思ってたんだけどokuyamaがどういう哲学でJavaを選んだのかどこかに転がってないかな。

2011-06-15 11:30:53
くまぎ @kumagi

@xuwei_k 好みの問題だったんですか…!

2011-06-15 11:31:39
Shunsuke Nakamura @sunsuk7tp

@kumagi 開発者本人に直接聞いたらいいんじゃないですかw >okuyama

2011-06-15 12:10:21
くまぎ @kumagi

@sunsuk7tp 既に情報が転がってたらわざわざ本人の手を煩わせる事になってしまう!

2011-06-15 13:32:01
Muga Nishizawa @muga_nishizawa

@okuyamaoo okuyama はオンメモリなのですか? RT @kumagi: JavaはGCなどの為にメモリ効率がそんなに良くないので、オンメモリなデータストアを構築する言語としては向いてないと思ってたんだけどokuyamaがどういう哲学でJavaを選んだのか…

2011-06-15 13:12:41
くまぎ @kumagi

@muga_nishizawa @okuyama http://t.co/4XObaBa を読んだところ、オンメモリもファイルも明示的に選択できるという記述を読んで納得が行きました。お騒がせしました。

2011-06-15 13:25:59
Shunsuke Nakamura @sunsuk7tp

@kumagi 確かokuyamaはもともと勉強のために作って、仕事ではJavaを使う機会が多いという話を伺った記憶があるので、自分が慣れた言語で書きたかったのではないかと勝手に想像します...

2011-06-15 13:42:02
くまぎ @kumagi

@sunsuk7tp 僕がC++使うのと大まかに似たような状況ですね…

2011-06-15 13:47:35
iwase @okuyamaoo

@muga_nishizawa @kumagi おっ!?okuyamaが話題に! okuyamaはKeyとValueの場所をそれぞれメモリとディスク自由に選択できます。@kumagiさんの指摘通りメモリ効率は悪いと思います。

2011-06-15 16:37:32
iwase @okuyamaoo

@muga_nishizawa @kumagi メモリに保存しているKeyとValueのメモリ占有率より入れているクラスのガラの占有率が多いです。次バージョンでその辺を若干緩和するシリアライズMapという機能を追加します。Javaを選んだ理由は私が好きだからというだけでして。。。

2011-06-15 16:42:05
Muga Nishizawa @muga_nishizawa

@okuyamaoo @kumagi なるほど、ありがとうございます。ディスクを選択したとしても、GC (特に Full GC)の影響でスループットが著しく落ちたりしますか??

2011-06-15 16:44:35
Muga Nishizawa @muga_nishizawa

@okuyamaoo @kumagi GC が動いていると、Cassandra だとスループット低下だけではなく、障害の誤検知(というのでしょうか?Node Down)を起こしたりするのです。

2011-06-15 16:47:30
くまぎ @kumagi

@okuyamaoo @muga_nishizawa なるほど、そのような物も有るんですね。オンメモリストアとしてのMapは具体的に何を使っているのでしょうか?Java.util.concurrentのhashmapでしょうか?

2011-06-15 16:50:56
iwase @okuyamaoo

@muga_nishizawa @kumagi メモリ、ディスク関係なくFullGCが動くと障害の誤検知はあり得ます。基本はVMパラメータでチューニングしますが、ある程度までメモリを使ったタイミングで内部でSystem.gcを実行したりしています。GCが動くかどうかはおいておいて

2011-06-15 16:51:21
iwase @okuyamaoo

@muga_nishizawa @kumagi 後はFullGCが起こりやすい、データ移行のタイミングなどは、ダウン検知の時間を若干延ばすように各ノードに伝搬したりはしています。

2011-06-15 16:53:56
くまぎ @kumagi

@okuyamaoo @muga_nishizawa なんと…細かい配慮まで為されているのですね…!

2011-06-15 16:54:38
iwase @okuyamaoo

@kumagi @muga_nishizawa ConcurrentHashMapをそのまま使うのと、ConcurrentHashMapを内部に持ってそこに入れる値をある程度まとまった単位で別のMapに入れてそれをシリアライズしたbyte配列にしてして、 (続く)

2011-06-15 17:00:26
Muga Nishizawa @muga_nishizawa

@okuyamaoo @kumagi 確かに、そのタイミングで障害検知の閾値を緩めるのはよいですねー なるほど!

2011-06-15 17:00:34
iwase @okuyamaoo

@kumagi @muga_nishizawa (続き)Zipで圧縮して格納する2タイプを選べます。後者は遅いですが持てるデータ量は結構増えます。小さいデータの場合に特に有効でした。

2011-06-15 17:01:53
iwase @okuyamaoo

@muga_nishizawa @kumagi 大量に知らせるノードがいた場合に、そこの伝搬失敗したらどうしようとか、色々面倒ではありますが。。。とりあえずこれでいってます。

2011-06-15 17:03:44
くまぎ @kumagi

@okuyamaoo @muga_nishizawa シリアライズ後Zip圧縮…!検索はともかく挿入・削除の速度が心配ですが具体的にどの程度の差になるのかの情報はどこかに出ていますか?

2011-06-15 17:04:00
Muga Nishizawa @muga_nishizawa

@okuyamaoo @kumagi アクセスの度に圧縮・解凍が行われるってことですよね… ふーむ、なるほど。。。

2011-06-15 17:07:22
iwase @okuyamaoo

@kumagi @muga_nishizawa これ自体僕が勝手に実装したものなので、 まだあまり数値てきなものは出ていないです。。すいません。 速度的には正直遅いですね。。okuyamaをKeyメモリ、Valueをディスクで動かした場合にメモリ上にはKeyとセットで(続く)

2011-06-15 17:11:05
iwase @okuyamaoo

@kumagi @muga_nishizawa (続き)Valueのディスク上の保存されている位置(ファイル中のバイト位置)を持つんですが、これを持つのに結構適してるかなと。圧縮する対象がKeyと位置(数値)なんであまり大きくならないので、圧縮処理もそこそこ速いようです

2011-06-15 17:14:45