開発者が知っておくべき Couchbase についての 10項目
はじめに
公式ブログによって、こうやってまとめておいてくれると、読みやすいし初学者にとって助かります。
blog.couchbase.com
第10位
Document access in Couchbase is strongly consistent, query access is eventually consistent
Couchbase のデータには強い一貫性があると主張されています。
key / value アクセスなので、そこは保証されやすいところなのかと思います。
View （恐らくインデックス）についても、最終的には一貫性が保たれるということですが、逆に言うと一貫性がない瞬間（インデックスが生成されるまで）もあるということですね。
第9位
Writes are asynchronous by default but can be controlled
書き込み処理は基本的に非同期で行われるようです。
レプリカの生成と、データの永続化（メモリからディスクへの書き込み）はバックグラウンドで行われ、クライアント側はその結果の通知を受け取れるようです。
クライアント側で先に通知を受け取るか、通知よりも先に非同期にレプリカを作成させるかなどはクライアント側で選べるようです。
第8位
Couchbase has atomic operations for counting and appending
カウント処理と追加処理において、不可分操作をサポートしているようです。
例にあるように、incr は書き込み処理と結果を返す処理を行います。
要は追加に失敗したのに、追加されたものとしてカウントされてしまったりすることは無いということかと思います。
cb.set(“mykey”, 1) x = cb.incr(“mykey”) puts x #=> 2
第7位
Start with everything in one bucket
Bucket というものがデータベースのようなものであり、RDBMSでいうところテーブルというわけではない。
そのため、RDBMSからそのままデータを移すとしたら、複数のテーブルが１つのBucket に全て投入されることになります。
ただし、"typte" という属性が恐らくデータ毎に設定が可能であるため、それを設定することで同じBucket内にあるデータであっても差別化ができるようです。
とにかく１つのBucketでスタートすることが推奨されているようですね。
第6位
Try to use 5 or less buckets in Couchbase. Never more than 10.
データは固定のスキーマを持つわけではないので、色々なスキーマのデータを同じBucketに入れることが可能。
ソフトウェアとして限界値は定められていないものの、10 Bucketにもなると、CPUやDiskIOに問題が発生することが確認されているようです。
この辺りは Couchbase のバージョンアップによって、改善される可能性はあるかもしれませんが、出来る限り少ない数の Bucket で運用する方が良さそうですね。
まぁ、もしどうしても Bucket をたくさん作って管理を分けたいのであれば、別のクラスタに切り離してしまった方が良いのかもしれません。
第5位
Use CAS over GetL almost always
CAS は "Check and Set"の略のようです。
KVSにおけるトランザクション処理を行うために必要な操作のようです。
要は楽観的ロックと悲観的ロックの話をしていますが、基本的に楽観的ロックを使用するべきだということでしょうか。
Couchbaseにおけるロック機能というものを知らないので、これ以上は理解が出来ていません。
第4位
Use multi-get operations
Couchbase には、キーのリストから複数のレコードを同時に？検索できるようです。
個々のキーを一つずつ検索するよりも、高パフォーマンスが期待できるようです。
第3位
Keep your client libraries up-to-date
これは、Couchbase に特化した話でもないと思いますが、使用するライブラリは最新のものが良いよということですね。
バージョンアップが頻繁に行われている製品であれば、何であっても同じことが言えると思います。
第2位
Model your data using JSON documents
格納するデータはJSON形式で。
CouchbaseはJSON形式や、バイナリ形式のドキュメントをサポートしていますが、まずはJSON形式で試すことを推奨しているようです。
JSON形式で保存しておくと、インデックスが作成できたり、特殊な？クエリを投げられるなどメリットがありそうです。
第1位
Use indexes effectively
インデックスを効果的に使うこと。
出来る限り、プライマリキーでのアクセスを行うこと。キーとメタデータをメモリ上に持っているので、アクセスは速いはず。
セカンダリ・インデックスでのアクセスは、パフォーマンスを必要としない分析用などで使用するべきとのこと。
この時点で、セカンダリ・インデックスのパフォーマンスは、それ程期待しない方が良いのかもしれません。
4つの design documents と、1つの design documents あたり、view は10個以下に抑えること。
それでも多いようなきもしますが。
インデックスデータに対して、何の "reduce" 処理を行う必要がないのであれば、value に "null" を設定しておきべきとのこと。
おわりに
これを読んだだけでは表面的な部分しか分かりませんが、使用していく内に「あれはそういう意味だったのか」のように、それぞれの意味をより深く知ることが出来るのかもしれません。
”Use indexes effectively” というのが一見当たり前のように見えて、Couchbase を使う上で実はとても大切なことのような気がします。
新しく使用する技術に対して、「取り合えず使ってみる」アプローチと、「概念をまず理解する」アプローチどちらが良いかは人それぞれかと思います。
自分の場合、取り合えず使ってみて、分からないところが出てきたら調べることが多いように思います。
ただ、エラーを回避することに精一杯になってしまって、結局その製品のことをあまり理解できていない事に後で気づくので、手を少し止めてインプットする時間も意識して作れるといいなと思います。
