MongoDBはスケーリングに問題があると聞いたことがあるかもしれない。 アウト.ViberがMongoDBをCouchbase Serverに置き換えるという話を聞いたことがあるかもしれません。MongoHQでスケーリングする方法を聞いたことがありますか？
ひとつだけMongoHQと同意見だ。それは 上.スケーリング中 上 はMongoDBにとって唯一の解決策かもしれないが、正しい解決策ではない。スケールの余地がなくなったらどうなるか 上?MongoHQはスケールアウトを望んでいると思うが、MongoDBはそのために設計されていないことに気づいた。
その結果、機能性が失われてしまう...。
たとえば、MongoDBでは、水平スケールは、特定のコレクションに対する一意のセカンダリインデックス（MongoDBが現在サポートしている数少ないスキーマ制約の1つ）を失うことを意味します。
難しい決断を迫られる...。
MongoDBでは、この選択は、経験豊富なMongoDBユーザーが恐る恐る話す「シャードキーの決定」である。
コンフィギュレーションもメンテナンスも複雑だ。
しかし、いったんシャード化されたデータベースを本番稼動させると、システムには理想的とは言えないほど多くの「可動部分」があるという現実が根底にある。
その結果、パフォーマンスが低下する...。
シャード設定では、Mongo ルーター、設定サーバー、各シャード間のネットワーク接続が全体のパフォーマンスに影響します。
一方、Couchbase Serverはスケールアウトするように設計されている。機能が失われることはありません。難しい決断は必要ありません。構成やメンテナンスが複雑ではありません。パフォーマンスが低下することはありません。
- Couchbase Serverはシャーディングを手動で設定する必要はありません。自動で行われます。
- Couchbase Serverには多くの可動部分はない。ノードタイプは1つです。
- Couchbase Serverがスケールアウトされると、パフォーマンスが向上します。
oplogのtaillingのセクションはかなり厄介だったと思う。MongoDBはスケールアウトするように設計されていないという事実を浮き彫りにしていると思う。管理者と開発者は、洞察と統合のためにログファイルに依存していることがわかった。MongoDBのスケーリングの問題は、開発者が複数のログファイルを追いかける必要があることだ。 ノードごとにログファイルがある。
一方、Couchbase Serverは、管理者と開発者が洞察と統合のためにログファイルを尾行する必要はありません。管理者はどのノードからでもCouchbase Serverを監視できる。開発者は、個々のCouchbase Serverノードと対話することなく、ElasticsearchやApache Hadoopと統合することができます。トポロジーは透過的です。これは、共有ナッシングアーキテクチャを持つ分散システムの利点です。
Couchbase Serverがクロスデータセンターレプリケーションをサポートしていることは注目に値する。これは、クラスタ内のデータを別のクラスタにレプリケートすることを可能にします。実際、これは我々がElasticsearchと統合する方法です。Couchbase Serverがデータをレプリケートできるのは、別のクラスタとしてです。それがElasticsearchクラスタであることは関係ありません。単にデータをレプリケートするための別のクラスタです。
redditで会話に参加しよう(リンク).
Hacker News (リンク).
さらに読む
なぜ私たちは垂直スケーリングを始めるのか（Google Web Cache）
注：MongoHQは元の投稿を削除し、現在は新しい投稿にリダイレクトしています。
注：これには 可動部 をスケールアウトしたMongoDBデプロイメント内で使うことができます。
Couchbase Server Elasticsearch Integration (ページ | ドク)
Couchbase Server Apache Hadoop Integration (ページ | ドク)
カウチベースの方がいいのか？
どちらが良いとか悪いとか言うつもりはない。本当にニーズ次第です。十分に調べれば、すべてのNoSQLベンダーが、ある可能性のあるデータストアから別のデータストアへのさまざまな移行に関する話を持っていることがわかるでしょう（Riakを含む）。2セントだけ...
{芭蕉社員｝
これは素晴らしいトピックだ。いくつか考えてみた：
しかし、Couchbaseがノードを追加するにつれて、vBucketsのレプリカが平等な参加者ではないことを考えると、様々な作業負荷のパフォーマンスはどのようにスケールするのでしょうか（つまり、書き込み/読み取り比率）、2つのレプリケーション戦略があります：1:nマスター/スレーブと1...nチェーン。
大規模になると故障が多くなるが（ノードタイムアウト、スプリットブレイン、部分故障など）、故障にどのように対処し、どの程度の人的介入を必要とするのか。
このコメントは、Riakを挑発したり、有利な立場に置いたりするつもりはない。Riakには、JSONフィールドクエリなどの制限事項があり、CouchbaseはMemcache APIを使用している人にとっては素晴らしい。
結局のところ、テクノロジーは単なるツールであり、用途やケースごとに評価されるべきものだ。ラルーカのお役に立てれば幸いです。ありがとう。）
やあ、フランク、
Riakについて悪いことを言ったことはないし、今もない。とはいえ、あなたのコメントを完全に理解しているわけではない。ノードを追加すると、vBucketsはクラスタに均等に分散される。ノードを追加すると、各ノードがより少ないvBucketの読み取りと書き込みを処理するため、パフォーマンスが向上します。レプリケーション戦略は1つだけです。すべてのレプリカに書き込みます（1対多）。レプリカへの書き込みをデイジーチェーン接続しません。
でも、僕の言葉を鵜呑みにする必要はないよ。MongoDBのパフォーマンスの問題はよく知られていると思います。
MongoDBコミュニティで、シャーディングは必要ないと言っている人を探すのに、あまり遠くを探す必要はない。誰かが何かを必要ないと言うとき、それは彼らがそれをできないからだ。最初に思いつくのはiPhoneのコピー＆ペーストの例だ。）
まあ、インフォマーシャルみたいだけど......。
CouchbaseとMongoDBを比較するのは難しい。
MongoDBが汎用NoSQLであるのに対して、Couchbaseはキャッシュのために設計されている：ほとんどのデータセットは、メモリ上にある必要があり、複雑なクエリなどはありません。
また、Couchbaseのハッシュは、ノードがダウンするとデータセット全体が影響を受けるため、可用性の低下を意味する。
1.Couchbase Serverはキャッシュ用に設計されていません。キャッシュとして、キー/バリューストアとして、ドキュメントデータベースとして、またはこれら3つすべてとしてデプロイできる。それは優れたアーキテクチャの利点であり、最初に正しく取得しなければならないものだ。それが、MongoDBが問題を抱えている理由だ。
2.ハッシュは可用性とは関係ない。いいえ、故障したノードがデータセット全体に影響を与えることはありません。レプリカを構成できる。ノードに障害が発生した場合、レプリカの1つを推進することができます。可用性は失われません。レプリカがない場合でも、ノードに障害が発生すると、当該ノード上のデータが失われる だけです。
1.Couchbaseが実行するためにデータセットのほとんどがメモリ上にある必要がある場合、キャッシュに最適化される。
2.私はCouchbaseの一貫したハッシュのためにデータがどこにあるかを制御する方法がありません（私は範囲パーティショニングを使用することができますMongoDBとは異なります）。したがって、ノードがダウンすると、ドキュメントがノードに分散されるため、多くのリクエストが失敗する可能性があります（30秒後にフェイルオーバーが完了するまで）。ハッシュアルゴを追加することで、この問題を解決することができます。
1.なぜデータのほとんどがメモリ上になければならないと言い続けるのですか？MongoDBはメモリマップファイルを使わないの？"cacheache "は、データが一時的であるか、別のデータベースに永続化されることを意味します。Couchbase Serverがキー/バリューストアとして、またはドキュメントデータベースとして使用される場合、どちらも当てはまりません。
2.レンジ・パーティショニングの問題は、データベースが一杯になるまでパフォーマンスが制限されることだ。これが、ほとんどの（NoSQL）データベースが一貫性のあるハッシュに依存している理由である。
3.Couchbase ServerはCP分散システムである。それは一貫性を維持します。はい、ノードをフェイルオーバーする前に30秒待ちます。これは、問題のノードが遅いのではなく、ダウンしていることを確認するためです。ノードが遅い場合、そのノードが所有するデータが利用可能になることもあれば、そうでないこともあります。リクエストに応答するのに時間がかかりすぎるたびに、すべてのノードをフェイルオーバーさせたくはないだろう。不安定になる。問題のあるノードが所有するデータが30秒間利用可能かどうかわからないが、他のノードが所有するデータは利用可能である。