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

いまさら？今から？
とりあえずキーバリュー型データストアという名詞を今知ったばかりなので個人的にファーストインプレッション。

なぜキーバリュー型データストアが必要か

適当にぐぐって２，３個人ブログを読んだだけなんだけど、この辺り明記されてる方の記事に出会えなかったので、もっとぐぐればあるんだろうけど書いてみます。

RDBMSじゃダメなの？

全然OKです。
RDBMS使ってて捌ききれる処理数でコストもそれ程かかっていないのなら問題なしです。
そうじゃなくなってきた色んな意味で限界が来た時にRDBMS以外の使用を考えればいいと思います。

RDBMSじゃダメな理由って何なの？

一言で言うと、
インターネットのおかげでRDBMSでは頭打ちになってしまう程の情報量が集まってしまう場合が出てきたから、です。

↑よりは細かく説明すると

一般的に広く使われているRDBMSというのはOracleだったりMySQLだったりPostgreSQLだったりしますね。
お金が唸ってるPJが信頼性と責任分担を求めて高額なOracle、ってなったり、そうでないPJがライセンスのしばりのきつくないPostgreSQLを選んだり、というのが最初の段階。
使っているうちにユーザ数が拡大したりなんだりで、パフォーマンスの改善を行う必要が出てきます。
その時に考慮される手法をDB寄りで考えると、

DBサーバをスケールする
DBを早いものに入れ替える

サーバのスケールには単純にスペックの増強/サーバ台数の増強などを行います。
DBの入れ替えは単純に処理速度の速いRDBMSを使用する、という事になりましょう。
開発にはいろんな縛りがあるので、そういう変数を全部ぶっ飛ばしてやれる事をやろうとするなら、
まず1サーバでやっていたならRDBMSを入れ替える。当然サーバをスケール（この場合は複数台）にした場合にそのRDBMSが対応するか、を考慮する必要はありますが、スケールさせた場合にどういう手法で可用性を確保するにしろ今時のRDBMSはそれなりにスケールに対応していますので単純に「処理の早いRDBMS」を選定するとしましょう。

で、元々早いRDBMSを使ってたよ！とか入れ替え済みだよ！ってなったら次にサーバをスケールするわけです。
これもそのRDBMSが元々持っている機能やサードパーティが作った拡張機能なんかで何とかします。
その使い方を調べて構築、設定、はい再起動、できたー！ですね。

そしてここです。
それでも対応できないくらい処理が増加した場合は？
ここで言う「対応できないくらいの処理」というのはWEBサービスを考えると分かりやすいと思います。
Twitterみたいなユーザ数が膨れあがってるけどデータを格納するタイプのサービスですね。
何かもうどうにもならなくなる訳です。
確かにサーバをスケールすれば負荷も分散できて結果的に処理速度も向上します。
しかし、負荷を分散するためにサーバを増やす事によって各DBが連携する負荷が増えている事や、RDBMS自体の処理の限界値は変化しない、という現実が目の前に突きつけられます。
そもそもレコード数の増加し続けるテーブルなどは水平/垂直分割して複数サーバに格納される事になるのでメンテナンスが大変です。

この状態になってもまだ着手していないならできる事はまだあります。
memcacheなどを使用してメモリを有効に利用し、1処理辺りの処理時間を短縮しようという試みです。
コードのリファクタリングを行ってSQL発行回数を減らしたり、使用しているSQLやその結果バッファがRDBMS側のキャッシュに乗るようにしたりなども同じような意味を持ちます。

このように、サービスをスケールして行く事によってユーザ数を捌くという事を続けていくと、コードの改変、運用維持、スケールテストとその実施、NEも鯖缶もPGもSEも全員てんてこ舞い。そしてある日気付くんですね。
「あれ、これいつ終わるの？」
と。

ここで出てくるのがキーバリュー型データストア、って訳です。
つまりここまで来ないならお好きなRDBMSを使っててOKだと思います。

キーバリュー型データストアの実際

GoogleやAmazonなどの大規模サイトが以前から使用しているのを気付かずに使用されているかも知れませんが、どうでしょうか使い心地は？
その反応（処理）速度がキーバリュー型データストアの実際です。

キーバリュー型データストアの長所/短所

一言で言うとアプリケーションなので、その他のアプリケーションと同じ特性を持っています。
処理が早いという事は、その速度に比例して「複雑な処理を行っている回数が少ない」という事です。
つまり当然RDBMSに比べると機能が少ないです。

所感

キーバリュー型データストア、使える部分ではがっつり使っちゃっていいと思います。
幸い大手だからこそぶち当たる壁で出てきはじめたものなので、すでに大手で採用されている技術、ともなると使いどころを間違えさえしなければ採用する事自体には特に問題もないでしょう。

2年前くらいにキーバリュー型データストアっぽいもの（当時は名前も知りませんでしたが）の実装を行った事があります。データ保存型のシステムだったのでバックエンドではしっかりRDBMSが黙々と動いてくれていましたが、memcacheとキーバリュー型データストアを足してストア部分をRDBMSに任せたようなそのサーバアプリで、負荷軽減としては恐ろしい程の結果が出ました。
当たり前ですよね、RDBMSが持つ豊富な機能のうち必要な部分のみの実装を行ったのですから。

残念ながらその時の仕事は日の目を見る事はありませんでしたが、そういう意味でもキーバリュー型データストアは面白いなぁと思ったのでした。