Float on the flow

とあるエンジニアのブログ。「ゆったり・しっかり」がモットー。

キー・バリュー型データストア

キー・バリュー型データストア(Key-Value Stores:KVS)というのが、クラウドコンピューティング、分散コンピューティングとの親和性から注目されている。


「キー・バリュー型データストア」開発者が大集合した夜:ITpro
http://itpro.nikkeibp.co.jp/article/OPINION/20090226/325527/


しかし、上記記事のブクマ(http://b.hatena.ne.jp/shozzy/20090227#bookmark-12305654)でもコメントしたように、自分にはどうもわからない部分がある。特に「データストアがキー・バリュー型」というポイントが。
分散化、クラウド化という文脈では必須になってくることはわかるんだけど。使い勝手というか開発効率的にどうなの?みたいな。


以下、自分の現時点での理解

    • キー・バリュー型データストアとは、Javaで言えばMapのようなもの。
    • MapReduceとかHadoopとかは、計算を分散化させるための仕組み。何らかの計算をさせるための引数をMapに詰めて渡したら、分散処理して返してくれるイメージ。


この理解が正しいとすると、キー・バリュー型データストアはかなりプリミティブなAPIしか提供しないことになる。プログラミング言語が提供するコレクション・インタフェースと同等の。*1


つまり、SQLのような集合指向の便利な*2APIは提供してくれないものと思われる。


そう考えると、先にも書いたとおり「開発効率という点でどうなのかなぁ?」と思ってしまう。Javaで業務アプリ書くときに、「RDBSQLは使わないで、Mapをファイルに永続化させるようにしてね」とか縛られたら泣けるもんね!RDBが提供してるアトミックなトランザクション機能とか自分で全部実装するのかよ!とか。そういうミドルウェアを考えて書くのは面白そうだけど、実戦投入はためらっちゃうなぁ*3、という感じ。


業務アプリにありがちな「1伝票の中には複数の項目があって、中には入れ子でヘッダ−アイテム型の構成になってるデータ構造もあるし…」というのを、RDBならデータ構造として表現できるわけです。だけども、キー・バリュー型ではそれがないですよね?なんでも入れられる代わりに、データ構造はシンプル&フラット。

そうだとすると、それをラップするような仕組みが必要になるのかな、と。
RDB/SQL的なインタフェースで呼び出したら、実際のデータ永続化はキー・バリュー型でクラウド内で実行されるとか。でも、ラップしたらそこがボトルネックになってクラウド化のメリットを享受できなくなるのでは?とか…



…という問題意識と同様の考えを、もっとスッキリと表現されているエントリがありますので引用します。


Key-Value Store(s)という流れ
http://www.isisaka.com/blog/archives/2009/02/keyvalue_stores.html

スケールアウトによる負荷分散を前提とする大規模なWebサービスやユーティリティコンピューティングにとってRDBMSを前提とするOLTPの考え方はそれがボトルネックになり、パフォーマンスと冗長性に対する傷害になりやすく、KVSのようなネットワーク透過で高速な分散ストレージの方が適している。ただそこで問題になるのはいわゆるATOMの部分で、ようはトランザクションがかけられない。

そこで最も重要なのはこういった KVSに合わせた新しいソフトウェアアーキテクチャパターン、それよりももっと純粋な技術背景となる思想といった物(そもそもデータの一貫性は本当に必要なのか?)で、それでも過去RDBMSがそうだったようにKVSに合わせた新しい概念が登場する物と思っている。

そうだろうと思います。自分ではまだ「どういうものになるのか?」がイメージできてないですが、なにかパラダイムシフトが起きるんでしょう。一貫性が重要なシーンと、そうでないシーンの峻別とか。アプリケーションの要件によって、使う技術も変わってきますよ、とか。

*1:実際になんらかの実装を見て、コード書いてみろよって話だな

*2:だけど重い

*3:枯れてないコードだからきっとbuggy