Advent Calendarなのに、信長の野望にハマって書くの忘れててすみません
そもそもCouchbaseとは？
CouchbaseはCouchDB、Membase、Memcachedの３つを統合したプロダクトで、「開発者がリラックスして、 カウチソファに座っているようにデータベースの 設計・構築・運用ができるように」という CouchDBの思想を引き継ぎつつ、
- Simple (シンプル)
- Fast (高速性)
- Elastic (柔軟)
をコンセプトにして作られているNoSQL Databaseです。
RDBMSとCouchbaseの違い
| DB | RDBMS | Couchbase |
|---|---|---|
| クエリ | SQL | N1QL（SQL準拠） |
| インデックス | ◯ | ◯ |
| ジョイン | ◯ | ◯ |
| 取得/保存形式 | テーブル（一階層のKey/Value） | JSON |
| 多階層構造 | △（*1） | ◯ |
| スキーマ設計 | 必要 | 不要 |
| スケールアップ | ◯ | ◯ |
| スケールアウト | △（*2） | ◯ |
| サーバ構成 | master-slave master-master |
マルチマスタ |
| オフライン設計 | ✕ | ◯ |
| サーバ設定 | CLI & 設定ファイル | Web GUI & API（*3） |
*1: MySQL5.7以上で、JSONカラムを使えばそれっぽくできる
*2: マルチマスタな分散はできない。master-slaveでミラーリング的な同期ならできる
*3: 設定ファイルはあることはあるので、直接いじることも可能でしょうが、複雑すぎてそんな気にはならない。
Couchbaseであるあるな勘違い
スキーマレス != データベース設計しない
スキーマレスは、 データベース設計しない という意味ではありません。
スキーマ設計をしなければいけない場合、（特に静的言語では）アプリケーション側とDB側でスキーマ設計をして、両方で整合性を取る必要があります。
スキーマレスなDBはスキーマ設計をアプリケーション側に寄せられるという意味です。
IndexはあくまでもRDBMSと同等なイメージで
Couchbaseは自由にIndexをはれる という説明を自分もしてしまうのですが、これはある意味で嘘です。
自由にはれるというのは、例えば、DynamoDBみたいな制限はないという意味で、RDBMSと同等に第一階層にIndexをはれるという意味で、基本的にRDBMSだとできないと思っていただいたほうがいいです。
自由にはれない例でいうと、配列になっているデータにIndexがはれるArrayIndexがありますが、1インデックスないでArrayIndexを定義できるのは1つのみです。リクエストで複数の種類の配列の中身をWhere句で指定してるので、それにマッチしたIndexを貼りたいと思っても無理です。（自分もこのパターンに陥ったことあるけど、この場合はそもそもデータ設計見直したほうがいいです。）
あと階層化したデータを第一階層にKey-Value形式で持ってくるUNNESTというものがN1QLにありますが、あれを使うととたんにIndexがかからなくなるケースがありました。
JOINは最終手段
N1QLはRDBMS同等にJOINができます。正し、最終手段と考えてください。
まず、目に見えて遅くなる場合があります。またはIndexがうまくかからなくなる場合もあります。JOINはできなくはないです。INNER JOINもLeft JOINもRight JOINもできるのです。仕様上は。
ただしパフォーマンスは落ちるので、よく使用する場合は設計を見直すか、別のDBにしましょう。Couchbaseは階層構造もてるので、非正規化して、第2階層とかにしたらなんやかんやで対応できるケースが多いです。
CouchbaseとRDBMSの使い所
基本的にCouchbaseのアンチパターンに陥りそうだったら、RDBMSや他のNoSQLのDBを使ったらいいと思います
一対多のデータを持ちたい
A. Couchbaseを使う
一対多のデータを作る場合、RDBMSだと関連テーブルを作って、IDでテーブルをJOINするという方法を使いますが、CouchbaseはJSONで、多階層構造を作れるので、そもそもデータを分ける必要がありません。
データの設計も管理も楽になります。
いろんなソート、絞り込みをしたい
A. RDBMSを使う
Couchbaseはあくまでも、NoSQLです。
データは柔軟に持てますが、RDBMSほど、柔軟なクエリには対応できません。対応できないというかパフォーマンスが落ちます。データが柔軟であるがゆえにひどいN1QLも見たことがあります。
Couchbaseだけではないですが、NoSQLを使う場合は、絞り込み項目やソートの仕方はキチンと決めた上で設計しましょう。これはできる・これはやらないをしっかり決めた上でやらないと本来のパフォーマンスが出せません。
日本のサービスで、これもやりたい・あれもやりたいと言われてソートや絞り込みにエッジを効かせられていないサービスを見ますが、あぁいうのにはNoSQLは向きません。（例え、ソートや絞り込みができたとしても）
第3階層以上の多階層を持ちたい
A. 検索対象になりうるなら、RDBMSを使う
基本的に階層構造を持っていたら、Couchbaseでもいいです。
しかしながらユースケースで、下位の階層に直接リクエストするケースもあります。
例えば、カテゴリツリー。
リクエストは大カテゴリにも下位のカテゴリにも、アクセスするケースがあります。この場合は、RDBMSで木構造とかつくって対応したほうが、パフォーマンスがいいです。
アプリにデータ同期が必要。もしくは、オフライン時でも利用できるアプリを作りたい
A. Couchbaseを使う
Couchbaseの売りの一つでもあるので、Couchbaseを使うべきです。
データ同期の際にデータの競合解決をどうするかという問題に当ります。
本来ならアプリ側でロジックを組んで対応しないといけないのですが、Couchbase Sync Gatewayを使うと自動で解決します。
（解決のロジックはGitが自動で競合解決するロジックに近いので、それをイメージしてもらえるとわかりやすいかと思います。）