KVS再考

KVS

前日の日記に続き、KVSについて、もう少し考えてみることにしました。
KVSは、これまで登場したDBMSと比べると管理システム（Management System）を持たない分、機能縮退しています。では、なぜ機能縮退したKVSが価値を持ちはじめたのか？
これについては次の2点が考えられます。

  • KVSには暗黙の了解として、高速処理に加え、高いスケーラビリティと可用性を持つシステムが想定される。
  • DBのように固定したスキーマを持たない。key-valueのvalue部にはアプリケーションが自由にスキーマを設定できる。

後者から、KVSは機能縮退したのではなく、DBMSが2層に分割され、下層が独立したものと見ることができます。下層は、型（スキーマ）付けされる前のバイナリー値を扱うためのシステムで、これはユーザが自由に型付け可能であることを示しています。しかし、これだけではKVSの説明として不十分です。スタンドアローンなシステムでは、スキーマ設定はDBMSがやってくれていたからです。
これについては利用要件の変化が考えられます。以下が新しく出てきた利用要件です。

  1. KVSを占有するが複雑なスキーマ設定が不要な場合。
  2. KVSを占有し、scale outが求められる場合。この場合、scale outを阻害するDBMSは選択から外れる。1のような利用形態が多い。
  3. KVSを大多数のユーザで共有する場合。大多数のユーザに提供するKVSには、scale outと高可能性が求められる。また、KVSの各key-valueを再利用させるためにはスキーマを固定的に割り付けることはできない。

1だけのケースは例外と考えて、KVSがDBMSのManagement Systemをはずした状態で価値を持つためには、scale outと高可能性は必須の条件になると考えられます。

先にも書きましたが、KVS（key-value store）という言葉には、key-valueの組を格納する入れ物としての意味しかありません。拡大解釈すると、アドレスを使って値の読み書きができるメモリやディスク装置などもKVSと呼ぶことができます。このままだと、KVSという言葉が必要以上に広く使われてしまう恐れがあります。上での考察を元にすると、KVSは以下の文脈で使用されるべきと言えそうです。

  • DBMSの下層を機能として切り出したもの。アプリケーションがスキーマを設定して使用する前提。
  • scale outと高可能性を備える。


KVSについてTwitterで盛り上がった後、日経BP社の中田さんから、Cassandraは、"A highly scalable, eventually consistent, distributed, structured key-value store" だよ、と教えていただきました。修辞句はいろいろつくとして（私には冗長に見えますがw）、こういう使われ方が一般的なんでしょうね。

Bigtableの場合

Bigtableの場合ですが、これは、提供される表に対して、ユーザがスキーマを設定してアクセスできる、という機能が用意されています。次の2点が純粋なKVSと異なるところで、KVSの発展形と見ることができます。

Google Bigtableに限らず、Amazon SimpleDB, Windows Azure Tableも同様な形態になっています。クラウドの商用サービスはこの形態に固まるのではないかと考えています。これをKVSと呼ぶかどうかは、まだ？ですが。。

関連資料

KVSについて理解を深めるためには、次の資料も参考にされるとよいと思います。