Meetup #1 Couchbase Serverのここが知りたい！

[Koji Kawamura]

河村です。

2/10に実施したMeetup #1で挙がった質問事項についてまとめました。
Couchbase, IncのMattさんにご回答いただきました。

今後もCouchbase Serverに関する質問はCouchbaseのメンバに問い合わせていきますので、
何かあればお気軽にこのグループに投稿してください。


1：同期レプリケーション
--------------------------------------------
Q: 3つのサーバ、A、BおよびCがあるとします。クライアントは、 "同期レプリケーション"を使用してDOC1の "set"要求を送信し、サー
バAがDOC1のバケットを処理します。サーバAはRAM上のDOC1を更新し、Bにレプリケーションしようとします。
ここでサーバーBが、ハードウェアまたはネットワーク障害のために応答しない場合はどうなりますか？
サーバは、複製するための別のサーバーを探しますか？（この場合はC）
サーバAはレプリケーションが失敗した旨のエラーを返すでしょうか？

A: サーバーBがダウンしている場合、上記の記述シナリオでは、レプリケーションは発生しません。クラスタはサーバBがダウンしているとアラートし、
UIにそれが表示されるでしょう。この時点で安全性の欠如があることは明らかです。（レプリケーションが無いため）

フェールオーバーおよびリバランスが開始されれば、レプリケーションは、新しいノードで再度有効になるでしょうし、すべてのデータが安全にレプリケート
されることになります。



2：オンラインバックアップ
-------------------------------------------------
Q: マニュアルには、Couchbase Serverクラスタのバックアップを作成するために、クラスタに属しているすべてのノード上で
"cbbackup"を実行する必要がある、と記載されています。これを行うベストプラクティスはありますか？

A: 特別なものはありません。これは単純なユーティリティであり、環境毎に有効な手段と統合することができます。

Q: まだディスクに永続化されておらず、RAMにのみ存在しているような最新のデータを確保するための最良の方法は何ですか？

A: すべてのデータはできるだけ早く永続化されているので、cbbackupを実行すれば、できるだけ多くのデータを得られます。RAM内の全てが
バックアップされることを保障するものではありませんが、バックアップが起動された時点で取得可能なものを全てバックアップしようとします。

Q: 基本的に何も共有していないので、各サーバ上で実行時間の差を考慮する必要はないでしょうか？

A: いいえ、cbbackupsのセットはある一時点での一貫した結果ではないという事実を考慮する必要があります。ある時点での一貫したバックアッ
プを取得するということは、システム全体における同期ポイントを作成する必要があり、分散システムにとって大きなオーバヘッドになります。我々の現在の
アプローチは一貫性を得るためにオーバヘッドを追加することをせず、多くの顧客が満足するものとなっています。ほとんどの場合、アプリケーションはアイ
テムごとの一貫性を懸念しています。

Q: cbbackupは、データと同様にViewインデックスのバックアップを作成していますか？

A: cbbackupは現在の2.0DP3では使用できません。2.0DP3のバックアップは、ファイルシステムレベルのバックアップです。View
インデックスは、そのバックアップの一部です。cbbackupはインデックスとデータをバックアップするはずですが、この機能についての確実に説明す
るには、多少調査が必要です。



3：Couchbase ServerはMVCCですか？
---------------------------------------------------------------
Q: Couchbase Serverは、データセンター間レプリケーションを提供しているとのことですが、どのように実行するのか分かりませんでし
た。
誰かがしようとしていますが、失敗した様です。
http://www.couchbase.com/issues/browse/MB-4432?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel#issue-tabs

A: そのバグは、私たちのQAグループによって報告され、かなり古いビルドを利用しています。現在のビルドでは、データセンター間のレプリケーション
機能がありますが、いくつかの既知の問題があるので、UI内ではデフォルトで無効になっています。クロスデータセンターのレプリケーションがすぐに
devのプレビューで利用可能になることを期待しています。

Q: この "データセンター間レプリケーション"は、CouchDBのレプリケーションと同様のHTTPによるMVCCですか？

A: 関連する概念を使用していますが、同じではありません。CouchDBのレプリケーションは、分散システム全体の複製を許可しないので、いくつか
の大きな違いがあります。

Q: これは、SuncPointと同じですか？

A: 現段階ではSyncPointは計画中です。同様の概念をいくつか再利用することが考えられますが、SyncPointはモバイルユースケースに
固有のいくつかの追加のフィルタリング機能を備たものです。たとえば、その特定のデバイスに特定のユーザーのデータを同期するなど。



4：データモデリング
--------------------------------------
Q: Couchbase Serverでのデータモデリング方法については、何か良いドキュメントはありますか？
いつ複数のバケットを使用するかなど
# J ChrisがCouchConfで良い発表をしてくれたけど、もし他にあれば :)

A: Benjaminのブログがあります（まもなく続編が更新予定！）。
http://blog.couchbase.com/intro-couchbase-document-design
それ以外ではJChrisがCouchConfで使った資料が一番でしょう [ 実際は私が書いた :) ] 。



5: vBucketは信頼できますか？
----------------------------------------------------
Q: 今までにクライアントが正しいバケットにアクセスできなくなるような大きな問題がvBucketがらみでありましたか？

A: 私はフェイルオーバで修復可能なノード障害を除いてvBucketがクライアントから利用できなくなるような状況に遭遇したことはありません。



6: Couchbase Serverの設計思想
---------------------------------------------------------
Q: Couchbase Serverは高負荷時にどのように振舞いますか？

A: Couchbase Serverは、非常に上手く、高負荷を処理します。Zyngaや他の大規模サイトと仕事をしてきて、高負荷に対して非常に
堅牢なシステムを築くことができました。スケーラブルで高性能なシステムをモデルとしたCouchbase Serverの設計があります（例えば、オ
ペレーション速度を落とすより、一時的なOOM [ out of memory ]を返すなど）。

Q: Couchbase Serverはもうアクセスを処理できないことを示すエラーを返しますか？

A: 操作によって異なりますが、前述の一時的なOOMはこのようなシナリオの一例です。リソースがある限り負荷を処理し続けられるように設計されてい
るため、非常に稀です。通常は、Couchbase Server自体が利用できなくなる以前にネットワークかメモリリソースが不足するでしょう。

Q: 最大コネクション数のような制限の設定はありますか？
Couchbase Serverは無制限に要求を受け入れますか？

A: デフォルト値としてノード毎に10Kの最大コネクション数があります、しかしこれは極端なケースではこれを調整することができます。これは実際に
は、それほどのコネクション数を処理できるかどうかの、ベースとなるOSのメモリ使用量の問題です。大規模なサービスの中でも、コネクションの上限に達
するのは極めて少数です。


以上