KVS入門にまつわるKVSな議論

Tatsuya Kawano @tatsuya6502

ネットワークの分断は非常にやっかいな問題で、先ほどの HBase の例でも、Cが完全に保障されているとはいえない。なぜなら、ZooKeeperがネットワークの分断を検出するまでに数十秒のタイムラグがあるから。

Tatsuya Kawano @tatsuya6502

その間に、ネットワークの向こう側にある HBase Region Server が更新をコミットしてしまう可能性は十分ある。大抵は、HDFSでエラーになって、コミット前に弾かれそうだけど、通ってしまうものもあるかもしれない。

E. Nakai @enakai00

@yssk22 入門としていかがかは別ですが・・・（根がインフラ屋なので？）下から上に抽象化して理解するとすっきりする性分で、私の頭の中ではこうです。１段目:Row Keyを指定するとValue(Row)が決まるもの。２段目:Value(Row)に持たせるデータ構造でさらに分類。

E. Nakai @enakai00

@yssk22 この意味で１段目に入る物を広義のKVSと呼ぶと、memchacedもBigtableも広義のKVSです。ここまで広げるとKVSではないものをKVSとして使うこともできるので（RDBで2列だけのテーブルを作るとか）、本当に意味のある定義か不明ですが。。。

E. Nakai @enakai00

CAPの件がすっきりしたので、KVS入門にCAPの定理を紹介する参考ページを追加ししておきます。あと、Cassandraの説明がひどいという声があるので・・・Dynamoの論文読んで考え直してみます。。。。

yssk22.tar.gz @yssk22_tar_gz

@enakai00 しかし私が違和感をもったのは、KVSとは何か、の定義ではなくて、「KVSとは」の章の内容そのものです。 memcached のページには distributed という重要なキーワードがあるのにそこが書かれていない点。KeyとValue という話は結果論かと。

E. Nakai @enakai00

@yssk22 分散させて大量データを扱うためには、Key-Value形式でStoreするのが手っ取り早くて、よく考えるとWeb系のシステムでは、単一Keyで検索できれば十分なデータがやまほどあった。と。。。。。

E. Nakai @enakai00

@yssk22 このストーリーでいくとmemcachedを出さずに、いきなりGoogleがBigtableを使い始めた、から入っても納得感はありますね。

E. Nakai @enakai00

@yssk22 では、memcachedとBigtable系のKVSは、たまたまKey-ValueでStoreするという点が同じだっただけ？歴史の根底で、memcachedの経験でKey-Valueで分散させればうまくいくことが認知されて、Bigtable系に至った気もしてます。

E. Nakai @enakai00

｢memcachedの経験から、一般に、大量のデータを分散保存するには、(Key, Value) 方式が適していると考えられるようになりました。｣は、話をつくりすぎ？？？？

E. Nakai @enakai00

｢memcachedの経験から、(Key,Value)形式で大量のデータを分散保存するという方法の有用性が認知されるようになりました。｣ぐらいが現実か？？？　詳しい方、ヘルプをください。。。

E. Nakai @enakai00

Cassandraは、RとWを大きくするとStrongConsistencyと言ってますが、それでも、ノード構成が変わったらGossipが伝搬しおわるまでは、Consistentにはならない？

E. Nakai @enakai00

http://bit.ly/JUAa 読んで自己解決です。ClientSideConsistencyとServerSideConsistencyの区別、平常時のConsistencyと分断時のConsistencyを区別して考えないとだめですね。

E. Nakai @enakai00

@tatsuya6502 @shot6 もろもろコメントありがとうございました。KVS 入門アップデートしました。 http://bit.ly/d3ld95　（誤字脱字はこの後こっそり修正します。）まだまだアップデートしていきますので、この後も改善コメントあれば、お願いします。

E. Nakai @enakai00

@shot6 @tatsuya6502 http://bit.ly/JUAa のコメント（Juan Loaiza said・・・）に分かりやすいたとえがありますね。"HDDのRAID1(N=2)は平常時はW=2,R=1だけど一本飛んだら自動的にW=1,R=1に変わるよね"

yssk22.tar.gz @yssk22_tar_gz

@enakai00 それは開発者に聞いてください、という感じですが、少なくとも論文では、database の実装戦略をとりつつ、Parallel Database と main-memory database のようなものとはデータモデルが違うんだよ、といってますよね...

yssk22.tar.gz @yssk22_tar_gz

NoSQLだからスケールするとかKVSだからスケールする、という紹介は後々痛い目にあうので勘弁を。

yssk22.tar.gz @yssk22_tar_gz

あと、Webのデータが向く、じゃなくて、Webだからスケールする可能性がある、という話。WebはURIとハイパーリンクを搭載したドキュメントデータベース。スケールしているかどうかは現状を参照。

E. Nakai @enakai00

@yssk22 Webの様に使えば、KVSでなくてもいろいろなものがスケールする可能性はあるが、｢Webの様に使ってスケールさせること｣を前提につくったデータストアがKVS、という感じですか？（なのでWebの様に使わなければスケールしない。）

E. Nakai @enakai00

@yssk22 （｢Webの様に｣=｢RESTの精神で｣と解釈してます。。。）

yssk22.tar.gz @yssk22_tar_gz

@enakai00 いいえ。Webのように使う、はスケールさせるための一つの手段です。 Web は distributed system の一つの形態。 distributed system の一つが memcached であり、 bigtableであり。KVSは関係ないです。

E. Nakai @enakai00

@yssk22 あああああ。理解できました。しかし、その心をあのレベルの文書で表す技量は、私にはまだまだないですね。しばし、あたためます。

Shinpei Ohtani @shot6

@enakai00 wを小さくするってどういう意味でしょうか？replication factorを3から2に引き下げるとかそういう話ですか？

E. Nakai @enakai00

@shot6 はい。HDDが2本生きている時は、2本書き終わるまで返事をしないけれど、１本壊れると、１本書いて返事をするようになる、ということなので、正確には、N=2 -> N=1　かつ W=2 -> W=1 ですね。

E. Nakai @enakai00

@shot6 ので、Cassandraの話でいうと、Replication Factor を自発的に引き下げることです。