シンプルかつ単機能であること、拡張性が高い事など。
おいちゃん的に「らう゛りぃ」この上ないKVSですが。
＜余談＞
根本的に。RDBはもの凄くスケールアウトさせにくいものなので。で…スケールアップが以下略なのは周知の通りなので。
結果、限定的な状況を除いて、おいちゃんは「RDBの機能をフルッフルに使う」のを、とことん忌避する習性があります。
＜/余談＞
ただ…そうは言っても。もうちょっとだけ、機能が増えると嬉しいんですよね。
イメージしているのは。
・基本、key <-> value のペアの値を持つ
・ただ、keyは複数持てる
感じ。えと…「keyテーブルがｎ」に対して「valueテーブルが１」という感じかな。
alertよろしくkeyテーブル増やしてもいいけど、増やす時は相応にマシンリソース使う感じ。
これにすると、現状の、特にWeb系で使っている「シンプルな」SQLのおおよそがフォローできるんじゃないかなぁ、と。
あとは…特殊なkeyテーブルもってみるとか。えと…
・数値比較が可能な、数値をkeyにもつkeyテーブル
・いわゆるLIKE句が使える、文字を直接keyにもつkeyテーブル(いやだってKVSって普通ハッシュなんぢゃないの？
って感じ。
こっちに関しては「使ったら重くなるから相応に覚悟を決めてから使ってね」って感じ？
で…実装イメージｗ
とりあえず「name=value&」の、CGIではおなじみの書式を前提にする、と仮定します。
「クライアント(顧客)テーブル」の構築イメージってことで。テーブル名はclient。いわゆるPKに相当するclient_idと、時々keyで使うemail、keyとしては使わないaddress(住所)、があるとします。
// メインというか基本になる定義 + key定義 create main_definition client ( client_id key, email key, address, );
こげな感じ。
…データ型？ なにそれおいしい？ データって「バイナリ」でしょ？ 全部。
そうすると、実際には「メインになるvalueが一式入ってるテーブル」「client_idのハッシュを持ってるハッシュテーブル(いや別にハッシュぢゃなくてもいいけどさ)」「emailのハッシュを持ってるハッシュテーブル(略)」ができる感じ。
別にmemcacheよろしく、分散して情報持ってもいいだろうし。keyテーブルもvalueテーブルも、レコード毎にばらんばらんに持てるはづ。
かってに銘々「拡張キー・バリュー型データストア(Extend Key-Value Store)」ｗ
こゆの誰か作らない？
memcacheを土台にして作れそうだしなぁ………
こっそり追記：
おいちゃん、実装その他あんまりまじめに調査してません。
なので「え？ ンなもん現状あるKVSで普通にできるよド阿呆」って突っ込みあったらよろです ノ
