KVSの定義とDBMSの再レイアリング

KVS NoSQL

気がついたら、KVSの定義から始まって、NoSQLの自然なニーズ、そして、DBMSの再レイアリングの必要性についてつぶやいてました。

    • -
  • 某所で、 BigTableはKVSか議論勃発なう。私個人はvalueを入れる箱があって、それに対してkeyを介したアクセスが可能ならKVSでいいと思っている。箱を2次元に構成できるのがBigTableで、key指定に範囲が使えるのがSkip Graphを応用したもの。
  • valueを入れる箱同士の関係を定義したり、整合性を保証したりするのはKVSの上位概念かと。箱を表形式に編成し、関係を決めているのがRDBで、それに従い整合性を保証するための手段としてトランザクションがある。
  • NoSQLが出てきたのは自然な流れだと思います。KVSが登場する前からそのニーズはとても高かった。1990年代に登場したオブジェクト指向DBやその後続くXMLDBはNoSQLの前身のようなもの。
  • SQLを使ってて困るのは、DB層より上のデザイン（通常はオブジェクト指向デザイン）とDBそのもののデザイン（ERD）のギャップ（セマンティックギャップと呼んでました）。トランザクションを必要としないケースでもRDBを使っていた。
  • SQLが有用なのは、データスキーマが表形式に決まる定型的な業務システム。厳格なデータスキーマの元には表間の関係があり、トランザクションにより関係の整合性を保つことが必須の条件となる。
  • 情報システムには護りのシステムと攻めのシステムの2種類がある。顧客や商品データを扱うような基幹業務システムが前者で、Webを活用し、サービスを多方面に展開するシステムが後者。SQLは前者に向いたが、後者には向かない。
  • RDBスキーマが向かない攻めのシステムでも実際にはRDBMSが使われていた。しかも、ほとんどKVSとして。それは選択肢がこれしかなかったため。考えてみればとてもロスの多い話だ。
  • システムにおける一貫性および耐障害性の保証はシステム実装者にとってとても頭の痛い課題。RDBMSはこの部分を担うことで価値を高めてきた。（2フェーズコミット、リプリケーション管理、バッチ処理を運用中に行うなど）
  • RDBMSが維持してきたこの付加価値を脅かすものとして出てきたのがscale outという概念。実用的なKVSの登場により、DBMSが内包していた一貫性と耐障害性について、scale out前提の基盤の上で捉え直す必要が出てきた。
  • KVSの登場を契機に、RDBMSの分解と一歩進んだDBMSへの再構成（再レイヤリング）が行われようとしていることを感じる。
    • -

(追記) KVSの定義について
その後、kazunori_279さんより、Google App Engine - How Entities and Indexes are Stored に "Bigtable, a large, distributed key-value store" の記載があることを教えてもらいました。でも、Bigtableの持つ表としてスキーマはKVSをやっている人達には受け入れにくいようにも感じます。例によって用語の定義は定まらない予感が...

スキーマレスかどうかは意見の分かれるところではありますが、KVSが技術用語として生まれた背景を考えると、分散形態であること、それによるscale out、冗長構成を使った高可用性の3つはKVSを特徴付ける性質であると思います。けれど、KVS（key-value store）という用語からは、分散もスケーラビリティも可用性も読み取れません。用語が一人歩きすると、そのままの意味で使われることになるだろうとも思います。（うーん）
あと、KVSがKVDBやKVDBMSと呼ばれなかったことも用語の定義を探る鍵になると考えています。
これ以上は偉い人に...