gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

KVS(Key-Value Store)かぁ…

シンプルかつ単機能であること、拡張性が高い事など。
おいちゃん的に「らう゛りぃ」この上ないKVSですが。


<余談>
根本的に。RDBはもの凄くスケールアウトさせにくいものなので。で…スケールアップが以下略なのは周知の通りなので。
結果、限定的な状況を除いて、おいちゃんは「RDBの機能をフルッフルに使う」のを、とことん忌避する習性があります。
</余談>


ただ…そうは言っても。もうちょっとだけ、機能が増えると嬉しいんですよね。
イメージしているのは。
・基本、key <-> value のペアの値を持つ
・ただ、keyは複数持てる
感じ。えと…「keyテーブルがn」に対して「valueテーブルが1」という感じかな。
alertよろしくkeyテーブル増やしてもいいけど、増やす時は相応にマシンリソース使う感じ。
これにすると、現状の、特にWeb系で使っている「シンプルな」SQLのおおよそがフォローできるんじゃないかなぁ、と。


あとは…特殊なkeyテーブルもってみるとか。えと…
・数値比較が可能な、数値をkeyにもつkeyテーブル
・いわゆるLIKE句が使える、文字を直接keyにもつkeyテーブル(いやだってKVSって普通ハッシュなんぢゃないの?
って感じ。
こっちに関しては「使ったら重くなるから相応に覚悟を決めてから使ってね」って感じ?


で…実装イメージw
とりあえず「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)」w
こゆの誰か作らない?
memcacheを土台にして作れそうだしなぁ………


こっそり追記
おいちゃん、実装その他あんまりまじめに調査してません。
なので「え? ンなもん現状あるKVSで普通にできるよド阿呆」って突っ込みあったらよろです ノ