さて、ここ最近、全然更新してなかったので、今年からは少しずつ書いていこうかと思います。
この間まではSQL Server 2014 の機能の一つである
AlwaysOn を駆使したシステムの開発をしたいたわけですが、
今回は Kii Cloud をフルに使ったアプリ開発に従事することとなりました。
今まで NoSQL DB を使った案件に従事したことがなかったのですが、
今回のケースを見ていて感じたことを綴ろうかと思います。
- NoSQL と RDB は用途によって使うべし！
Facebook でも採用された NoSQL ですが、NoSQL 何にでも使える最強なDBではないと思います。
将来的にどうなるのかはわかりませんが、（トランザクション管理機能を持つNoSQL DBも増えたため）
用途によって、RDB が威力を発揮する場面と、NoSQL が威力を発揮する面と、
それぞれシーンは異なると思います。
今回、BaaS のシステムとしてKii Cloud が採用されていますが、
Kii Cloud ではBucket という単位でKVS のデータを管理することができます。
Kii 上に、RDB が存在しないからといって、全てKii 上のBucket にデータを保持しなくてはならない。
というわけではありません。
RDB のメリットは割愛しますが、NoSQL がパワーを発揮するシーンとしては、こんな事例だと思います。
・最新データのみ一時領域に管理したい。
・ゲームの１ゲームデータだけを保持したい。
・ユーザーに届くメッセージ機能の既読・未読データの管理をしたい。
・セッション管理を行うデータ領域を作りたい。
など、キャッシュやワークとして利用する際には、猛烈に効果を発揮します。
例えば、何千万件のデータが格納されていたとしても、
キーの設計がきちんとされていれば、NoSQL 内に格納されたデータの取得時間は
造作もないくらい短時間で取得することもできます。
ただし、インデックスのかからないクエリを発行した際は、パフォーマンスは著しく低下します。
データベースの定義を事前に行っていないため、好きなデータを好きな形式で好きな時に格納できる。
また、好きな時にその領域を破壊することができる。
というのがメリットです。
- NoSQL を使わないほうがいいケース
○○テーブルといったように、Entity 定義書を書き起こしたくなる場合、
それはもはやすでに、RDBで格納するためのテーブルとなります。
テーブルとかEntity という概念でDBをイメージしてしまってること自体、
NoSQL での利用メリットはありません。
無理になれないDBを使うのであれば、慣れた（枯れた）技術を採用すべきです。
ご存知の通り、NoSQL は通常Map の構造となっており、Key と Value の入れ物になっています。
そのため、中にどのような値でも自由に入れることができるのがメリットでもあり、デメリットでもあります。
このメリット部分を活かすことができないなら、NoSQL を採用すべきではないですね。
開発が進む上で、この時に強烈に便利だったという事例があったら、またご紹介します。
↧
NoSQL DBが最強に威力を発揮するケース
↧