-
marblejenka
- 5523
- 0
- 8
- 1
-
- いいね！1
浅海智晴
@asami224
ログ＆Hadoopが基本として、それ以外にはユースケースに対応した個別データを事前に計算した結果を格納しておくDatabase View的な使い方はあるかな。これは分散キャッシュ的な使い方。
2011-05-21 07:06:35
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
昨日の発表したメモを上げました。～Hbase第一回勉強会メモ http://slidesha.re/jNXeSa #hbaseworkshop
2011-05-21 07:07:10
浅海智晴
@asami224
RDBMSで管理する正規データから、ユースケース毎のViewデータをSQLやHadoopなどを用いて非正規データとして作成しておいてKVSに置いておくというパターンはあるね。データの整合性はRDBMS側で担保。更新はCQRSなので、キャッシュ的な運用。
2011-05-21 07:10:36
浅海智晴
@asami224
モデリング的にはユースケースが重要。ユースケースセットに耐えるドメインデータをRDBMSで管理、個々のユースケース向けのViewデータを参照性能系KVSで公開。更新はCQRSで更新性能系KVSのロギング経由でRDBMSへ反映。
2011-05-21 07:12:54
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
@asami224 各業務ドメインのTXモデルを考えていけば行けると思いますが、モデリングのノウハウ・コストが高いですね。やっている方はなかなか面白いとは思いますが、ノウハウがいる感じです。ただ、この種の「実装を意識したモデリング」はクラウド環境では非常に多い気がします。
2011-05-21 07:13:51
Takashi Shitamichi
@shita
HBaseのこの種のスライドは業界初なのでは？”受発注”とか例にしている等も含めて。 RT @okachimachiorz1: 昨日の発表したメモを上げました。～Hbase第一回勉強会メモ http://slidesha.re/jNXeSa #hbaseworkshop
2011-05-21 07:14:53
浅海智晴
@asami224
Viewデータの公開は、運用性を考えるとCouchDBのようなDocument系がよいかも。普通に格納するだけでREST/JSONで簡単に参照できる。
2011-05-21 07:15:06
浅海智晴
@asami224
@okachimachiorz1 DBの選択がキーの設計に直接影響するとか、相当意識が必要ですよね。JOINなしに加えて、KVSは複数レコード更新のatomic性が担保されないので、TX必要なアプリにはそうとう難しいのかなと感じています。
2011-05-21 07:19:04
浅海智晴
@asami224
MySQLをNoSQL的に使うという技術があるけど、これを使えば参照データの格納庫としてはRDBMSも十分いける。 http://goo.gl/U0PC 事前計算したViewの格納といったような、単発のルックアップをスケールさせる目的ならこれで十分かも。
2011-05-21 07:23:22
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
@asami224 いやほんとコレは難しいなというのが印象ですね。ただドメインモデルが決められれば非常に有用な仕組みになりますね。分散書き込みは割とどこでもボトルネックなんで。
2011-05-21 07:25:02
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
KVS系で意識するのはheader＋body構造の時のbody部分で、勉強会で指摘もあって「rowじゃなくてcolumnじゃないかね（多分column-family的なもののことだと思う）説」もあるけど、内容的にちょっと無理があるな～という印象で、（続
2011-05-21 07:31:12
浅海智晴
@asami224
ログデータ追記のユースケースはあるかも。ここからHadoopだと普通だけど、CQRS的にRDBMSに反映というユースケースに優位性があるかないか。RDBMSで同様のアーキテクチャを組む場合と比較して。
2011-05-21 07:31:18
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
特にbodyの繰り返し数が保証されない、または実モデルではbody数は割とパターンが多い、あるいはそもそもfamily数に制限があるよ的な話もある・・・のでrowで足し込むのが、まぁ無難な気がしてます。
2011-05-21 07:33:22
浅海智晴
@asami224
@okachimachiorz1 確かに、伝票の追記とかそういうような切り口で、ユースケースを絞ればメリットが活かせるかもしれません。
2011-05-21 07:37:47
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
.@asami224 特に「同時にN箇所でデータ発生が起こるTXデータ」を分散書き込みをするユースケースでは強いと思いますね。
2011-05-21 07:46:46
浅海智晴
@asami224
@okachimachiorz1 TXデータということは複数のレコードの同時更新にアトミック性が必要とされるということでしょうか。あるいは、1レコード単位のTXでよくてクライアントからの参照で昔のデータが見えないのを保証したい方面でしょうか。
2011-05-21 07:53:43
浅海智晴
@asami224
KVSのメリットとしてコストというのはあるね。これはappengineのアプローチ。ただ、appengineとec2のコストがそれほど変わらないとなると、この点でのKVSのメリットは活かせない。
2011-05-21 08:07:56
Tatsuya Kawano
@tatsuya6502
@ashigeru HBase 0.92ですが、HBaseのlibディレクトリにある hadoop- .jar を、CDH3u0 のもので入れ替えたら動くかもしれないです。試しました？
2011-05-21 08:31:10
御徒町＠MultiVersionConcurrentClimber(MVCC)
@okachimachiorz1
@asami224 同時更新は普通はかからない（よほど変な間違いをしない限り）ケースですね。むしろ1レコード単位でrefをrとる時に正確にupdateされたデータが読みたいということがほとんどだと思います。
2011-05-21 08:58:08