@fetus_hina うん。結局RDBしか使ったこと無かったので、いまいち具体的な運用方法がわかってない。(キーどんな感じにするのかとか)
2012-08-30 00:11:06@kyubuns RDBベースで考えるなら、まず主キー(たとえばuser_id)とそれ以外を分離して、「それ以外」をまず JSON でエンコードするとする(JSON 部分はなんでもいい)、その主キーと JSON データが K-V。
2012-08-30 00:12:20なんかDBの分散ーとかなんだーって話をDQXの時に聞いたので、それってKVSが分散分散言ってるし、うまいこといったりするんじゃねーと思った次第
2012-08-30 00:12:50@kyubuns 「ユーザ 42 にデータほしいなー memcached1,2さん 42 さんのデータあるー?」『ないよ』「じゃ、DB さんに聞くわー」。「ユーザ 123 のデータあるー?」『はいよ』「じゃこれ使うから DB さんには聞かなくて済むわー、ありがとー」
2012-08-30 00:14:18@kyubuns ユーザ A さんに 1, B さんに 2 の ID が振られているなら、たとえば KVS に "user:1" "user:2" と登録するだけ。 Key が Unique なら Value が適切に取り出せるでしょ
2012-08-30 00:15:12@hudepen おお、まじですか。まーったくKVSに触れたこと無くてメリットがちゃんと分かってなかったので今redis突っ込んで遊んでます。
2012-08-30 00:19:43@fetus_hina ひなせんせー、これどうやって分散するんですかー http://t.co/Xo1sNdCa これだったらどうやって後からサーバー増やすんですかー
2012-08-30 00:23:33@kyubuns 何を問題にしてるのかよくわからんけど、分散するのは複数サーバを立てるとかしたら自動でやってくれる(ように設定する)、どのサーバに入るか/入っているかはたとえばこういうアルゴリズムで解決されたりする http://t.co/X7FpHwe2
2012-08-30 00:27:17@kyubuns 「分散しやすい」っていうのは、KVSが一般にRDBのような一貫性の保障をしない、ただたんにKVのペアをやり取りするだけだから独立して動かしやすいとかそういうアレ
2012-08-30 00:29:21@kyubuns よく引き合いに出されるけど、お金を扱うような場合はKVS使わないほうがいい。Twitterとかmixiのあしあとみたいに、すぐに同期させる必要はないけれど、瞬時に多くの小さな情報を捌く必要があるときはKVSが向いてる、とうちの研究室で(ry
2012-08-30 00:32:51@kyubuns KVSを使う上で考えておかないといけないのは、Keyをベースにした検索は当然できるからユーザ42のデータは取得できる。アプリケーションは42の性別が男であるか確認できる。でも、KVSで男の一覧を取得することはできない。(そういうKVを作った場合を除く)
2012-08-30 00:34:02@kyubuns そんなわけで、DBのテーブルの行をキャッシュするのには向いてる、DBの実行結果をキャッシュすることもできる(この時のKeyはたとえばSQL):有効期限に注意が必要、RDBの代わりとするのには向いていない。
2012-08-30 00:35:03@kyubuns 中間的な性質を持ったデータベースに MongoDB とかあるけど、諸々どうなのかは試したことないから知らない。
2012-08-30 00:35:44