#はじめに
私が「NoSQL」というキーワードを聞いたのは、2013年ぐらいだったと思います。ちょうど自分がIoTの分野で仕事をし始めたこともあり、IoTと相性の良いNoSQLに取り組み、今も使っています。
ただこの「NoSQL」、周りを見回しても、それほど利用が広がっているようには見えません。
何人かのエンジニアに聞いてみると、キーワードとしては知っているけど、そもそもどこが便利なのか分からない、なんとなく難しそう、といった声がありました。
このAdvent Calenderには、河村さんを始め、テクニカルな方々が揃っていらっしゃいますので、私は、今一度、「そもそも」というところに立ち返って、できるだけ簡単にNoSQLを説明してみたいと思います。
#「NoSQL」とは
Couchbaseの話をする前に、まずはNoSQLです。
##「NoSQL」の定義
諸説あるのですが、よくわかりません。そもそも「NoSQL」の「No」は、”SQL文でアクセスしない”という意味だったような気がするのですが、CouchbaseのN1QL始め、多くのNoSQLがSQL（ライクなツール）でのアクセスに対応してきているので、そもそももうあまり意味のない議論なのかもしれません。
ここでは、「（Oracleなど）リレーショナルではないデータベース」、としておきます。
「NoSQL」の分類
RDBの場合はOracle始めPostgreSQL、MySQLと、いくつかのプロダクトが思い浮かぶと思うのですが、NoSQLは未だ群雄割拠の為、数多くのプロダクトがあり、150～200以上の種類があると言われています。
分類方法もいくつかの分け方があるようなのですが、一般的にはデータモデルで分けることが多いようです。
- キー・バリュー型（KVS型）
- カラム指向型
- グラフ型
- ドキュメント指向型
この分類方法でいくと、Couchbaseは、JSON形式でそのままデータが登録できる「ドキュメント指向型」となります。
###参考
知らないなんて言えないNoSQLまとめ（1）：KVS系NoSQLのまとめ（Hibari、Dynamo、Voldemort、Riak編） (1/4) - ＠IT
http://www.atmarkit.co.jp/ait/articles/1211/05/news007.html
NoSQLの現状。これまでの成功と失敗 － Publickey
http://www.publickey1.jp/blog/13/nosql_2.html
#Couchbaseについて
##Couchbaseを使うと便利なこと
Couchbaseの特長を勝手に書いてみると、
- モバイル向け機能の充実
- エンタープライズ機能の充実
- ドキュメント指向型の利便性
というところかと思います。
###1．モバイル向け機能の充実
同じドキュメント指向型NoSQLでよく比較されるであろうMongoDbと比べ、優れているのがモバイル向け機能、SDKの充実です。iOSやAndroid、Windows向けのSDKが提供されているので、それを使うことで、簡単に、Couchbaseサーバとの通信を任せることが出来ます。
参考：
Mobile Database
http://www.couchbase.com/nosql-databases/couchbase-mobile
iOS/Androidに対応したモバイルデータベース「Couchbase Mobile」正式版登場。無料のコミュニティ版も － Publickey
http://www.publickey1.jp/blog/14/iosandroidcouchbase_mobile.html
###2．エンタープライズ機能の充実
NoSQLは大量データを得意としています。RDBの場合、レコード数が万のオーダーになってくると、レスポンスが一気に悪化してくる可能性がありますが、元々大量データをターゲットとしているNoSQLでは、平気です。
Couchbaseでは、複数ノードが協調動作することを基本としており、ノード間のりバランスや相互バックアップなど、基本機能が充実しており、しかもそれを操作するのも簡単です。
参考：
Couchbase Japan KK | SlideShare
http://www.slideshare.net/CouchbaseJapan?utm_campaign=profiletracking&utm_medium=sssite&utm_source=ssslideview
Couchbase 101 ja
http://www.slideshare.net/CouchbaseJapan/couchbase-101-ja
###3．ドキュメント指向型の利便性
JSONでそのままデータ登録できたらどういう便利さがあるのでしょう。
Couchbaseでは、Bucket（バケット）というところにデータを蓄えます。JSONでデータ登録するとは、例えば
｛
firstname: "shuzo",
lastname: "matsuoka"
｝
という構造、そのままの形式で格納できるということです。｛から始まって｝で閉じていれば、中が複数レコードで配列になっていても構いません。
また、JSONであれば、中身は気にせず、同じBucket内にどんどんとデータを放り込んでいくことが出来ます。
｛
detect-time: "2015/12/12 00:15:30",
detected: "false"
｝
という短いJSONも、
｛
detect-time: "2015/12/12 00:30:15",
detected: "true",
bodycount: "2",
bodydata: [
｛age: "36", sex: "f", direction: "145", rr: "023"},
｛age: "27", sex: "m"},
｛age: "24", sex: "f", ll: "023"}
]
｝
という長いJSONも、気にしなくてOK。
これ、とても便利です。
例えば、人感センサーが定期的に検知データをサーバに蓄積するシステムを考えてみましょう。
データは、男女や推定性別年齢など、検知できたデータだけで組み立てられ、さらに、複数人検知したら、複数人のデータを送信するとします（上の例）
このデータをRDBで格納する事を考えると、
- テーブルを事前に定義する
- 送信される可能性があるすべてのデータ項目を定義
- それぞれの項目について、Null／Not Null、データ型などを定義
- 送信データの仕様が変われば、テーブル構造も変更が必要（システム変更が必要）
- 複数名データは個人ごとにバラす必要がある
ということになります。
これが、Couchbase始め、ドキュメント指向型のNoSQLの場合、
- 事前にどんなデータが登録されるかを定義する必要が無い
- データ構造が変わっても問題ない
- 配列データ（複数名データ）であってもそのまま登録できる
ということになります。
特にセンサーなどは、ファームウェアのバージョンアップなどで、データ構造もしょっちゅう変わります。その都度テーブル構造を見なおさなくても良いのは非常に便利です。
###参考
モノのインターネットになぜNoSQLが必要なのか | ReadWrite Japan
http://readwrite.jp/archives/17764
##つづく!?
長くなってしまいました。
元々は、Bucketに対するI/F（データの入出力）から、システムの中でどう活かすことができるかを書きたかったのですが、ついつい。。
また時間があれば書きます。