kiyoka.2009_02_22 RSSPLAIN

Related pages: !kiyoka.blog.list !kiyoka.blog.2009_02
53555555555555555555555552222415
5

[プログラミング] Key-Value Store勉強会に行きたかった...

3

1-1208707554nqU5

5
 Key-Value Store勉強会に行ってきました - blog.katsuma.tvEXT
5
 greeさんで開催されたKey Value Store勉強会に行ってきました。時間にして
5
 4時間超え、内容も国内のKey-Value Storeなソフトウェアの最前線の話ばかり
5
 で相当なボリューム。以下、メモってたのを残しておきたいと思います。
5

それにしても、このメモすごい情報量。

5

 

5

自分の興味としては、Key-Valueストレージエンジンの実装よりも、Key-Valueのデータベースの応用事例の方にある。

5

リレーショナルDBなら事例は山ほどあり、論理設計、物理設計ともに設計手法も確立している。

5

Key-Valueの場合はどんな分野で使えるんだろう。

5

例えば、Sumibi.orgをTokyoCabinetベースで作るとなると、どんな設計になるのかなとか。

5

もしかしたら、いまMySQLにメモリ3GByteも割当てているけどTokyoCabinetなら圧縮がかかってメモリ節約出来るんだろうかとか。

5

はたまた、一般的なCRMをKey-Valueで作るとどんな点に気を付けないといけないのかとか。そもそも、そういう分野には向いていないのではないかとか。

5

たぶん将来はAmazonのインフラ上で作品を作りたいと思っているので、この辺勉強しないといけないなと思っていた所。

5

作品を作る時は、KahuaのObject DBをAmazon S3とかDynamo対応する方向なのかなと漠然と思っているけど、もっと勉強すると各エンジンのトレードオフとかも肌で分かるようになるのかな。

5

 

5
 KVS 勉強会に出て、自分でも書いてみたいなと思ったり。 - 生駒日記EXT
5
 かな漢字変換的にはやはり key-value store (hash 的なもの)ではなく Trie
5
 があるといい(common prefix search が使えると検索効率がよい)のだが、やっ
5
 ぱり自分で1回は書いておいたほうがいいのだろうなー、と思った。いつになる
5
 か分からないけど……。
5

id:mamorukEXTさんも書いておられるように『自分で1回は書いておいたほうがいいのだろうなー』という気持もあるけど、自分はWebアプリケーションを作るほうに時間を使いたいのでちょっとそこまで時間はかけられないかなと思ったりもする。

5

ちょっと自分はRDBとSQL脳に傾いているのでもっと引出しを増やす意味でもいろいろ見ておこう。

5

 

2

追記:Key-Value Store勉強会については首藤さん所が、リンクが沢山で便利。

2
 Shudo's Notes (2009/2)EXT
2

 

2

 

4

COMMENTmamoruk

ChaIME は TokyoCabinet ベースですが、8000万(bigram)+200万(unigram)でコストは int で持っていて、全部でちょうど 2GB 程度のメモリ消費量です。Tx で作ったこともありますが、せいぜい1.6GBくらいだった記憶があり、Tx は TokyoCabinet と比べると辞書引きがかなり遅いので、安直には TokyoCabinet でいいんじゃないかなという気はします。ただ、やはり辞書引きでもかな漢字変換だったら文頭から引くので、上にも引用されているように、Trie だったら検索回数を抑えられるので、筋的には Trie で作るのがいいんじゃないかなーとは思います。Darts もあれば Tx もあるので、勉強という以外には、あえて自分で書く必要はないですね……。

Key-value にしても、自然言語処理を含めて多くの場合データアクセスには局所性とか類似性があって、この単語を引いたら次はこれを引きやすいとか、もしくは全体の1割とか数%のデータだけはやたらアクセスが高く、残りはすごく頻度が少ないとか、そういう特徴があるので、この特徴をうまく使って負荷を分散するのが勘所でしょうね。よく使うのだけメモリに置いて、あとはディスクとか、ネットワーク上に置いとくとか、階層的な構造にするのが一般的でしょうが……(そのあたり考えないで2GBぼーんとメモリに確保してなんとかなるというのも、ちょっと前では考えもつかなかったすごい時代ですね)

1

COMMENTkiyoka

mamorukさん、情報ありがとうございます。

今TokyoCabinetの仕様を見返したら、Sumibiのデータベースとしてすんなり使えそうな感じですね。

SumibiはMySQLを使っていますが、特にtableのJOINを多様しているわけではなくKey-Valueで十分だと思っています。

TokyoCabinetはIndex領域などの容量のオーバヘッドも少なそうなので、多分MySQLよりもメモリ使用量が減らせるかもしれませんね。

よく使うのだけメモリに置いてというのがうまくいけば2GByte程度のレンタルサーバとかでもそこそこ動かせるかも...

最近、レンタルサーバの値段が安くなって4GByteメモリが普通になるのを待つか、Sumibiを改造して少ないメモリでも動くようになるかを時々考えるのですが、考えているうちに4GByteのレンタルサーバが普通になってきそうで怖いです。

Sumibiを作った時は4GByteのサーバが必要というのは驚かれたものですが、最近ではあまり驚かれなくなってきました。

それにしても、SSDとかも出てきたりしてハードウェアの進化は早いですね。

統計的手法は数学の固まりだと思いきや、いざソフトウェアとして実装しようとすると、そんなハードウェアの進化を横目で見ながら手段を選択しているんだなとあらためて感じます。

5

...comment disabled...