MongoDBでCouchDBを使用する場合とその逆の場合

これら2つのNoSQLデータベースの間に行き詰まっています。

私のプロジェクトでは、データベース内にデータベースを作成します。たとえば、動的テーブルを作成するソリューションが必要です。

したがって、ユーザーは列と行を含むテーブルを作成できます。MongoDBとCouchDBのどちらがこれに適していると思いますが、どちらが良いかわかりません。また、効率的なページングも必要です。

C、A、P（整合性、可用性、パーティション許容度）のうち、どちらがより重要ですか？クイックリファレンス、NoSQLシステムのビジュアルガイド

• MongodB：一貫性とパーティションの許容度
• CouchDB：可用性とパーティション許容度

ブログ投稿、Cassandra対MongoDB対CouchDB対Redis対Riak対HBase対Membase対Neo4jの比較には、比較された各NoSQLデータベースの「最もよく使用される」シナリオがあります。リンクを引用して、

• MongoDB：動的クエリが必要な場合。関数をマップ/縮小するのではなく、インデックスを定義したい場合。大きなDBで優れたパフォーマンスが必要な場合。CouchDBが必要だが、データの変更が多すぎると、ディスクがいっぱいになります。
• CouchDB：事前定義されたクエリが実行されるデータを蓄積し、時々変更します。バージョン管理が重要な場所。

最近（2012年2月）、Riyad Kallaによるより包括的な比較、

• MongoDB：マスター/スレーブレプリケーションのみ
• CouchDB：マスター-マスターレプリケーション

両方を試した人によるブログ投稿（2011年10月）で、MongoDB Guy Learns CouchDBはCouchDBのページングがそれほど役に立たないことについてコメントしました。

Kristina Chodorow（MongoDBを支えるチームの一部）による日付（2009年6月）のベンチマーク、

MongoDBに行きます。

それが役に立てば幸い。

上記の答えはすべて話を複雑にします。

1. モバイルコンポーネントを計画している場合、またはデスクトップユーザーがオフラインで作業し、その作業をサーバーに同期する必要がある場合は、CouchDBが必要です。
2. コードがサーバーでのみ実行される場合は、MongoDBを使用します

それでおしまい。モバイルおよびデスクトップデバイスに複製するCouchDBの（素晴らしい）機能が必要でない限り、MongoDBには現在、パフォーマンス、コミュニティ、およびツールの利点があります。

非常に古い質問ですが、それはGoogleの上にあり、私が見る回答があまり好きではないので、ここに私自身の質問があります。

CouchDBには、CouchAppを開発する機能以外にも多くの機能があります。ほとんどの人は、古典的な3層WebアーキテクチャでCouchDbを使用します。

実際には、ほとんどの人にとって決定的な要因は、MongoDbがSQLに似た構文でアドホッククエリを許可し、CouchDbが許可しないという事実です（これらのビューを作成しても、マップ/リデュースビューを作成して、一部のユーザーを無効にする必要があります）迅速なアプリケーション開発に対応-ストアドプロシージャとは関係ありません）。

受け入れられた回答で指摘されたポイントに対処するには：CouchDbには優れたバージョン管理システムがありますが、バージョン管理が重要な場所にのみ適している（またはより適している）とは限りません。また、couchdbは追加専用の性質により、書き込みが非常に簡単です（書き込み操作はすぐに返され、データが失われないことが保証されます）。

誰にも言及されていない非常に重要なことの1つは、CouchDbがbツリーインデックスに依存しているという事実です。つまり、「行」が1つであっても200億であっても、クエリ時間は常に10ミリ秒未満のままです。これはCouchDbを低レイテンシで読みやすいデータベースにするゲームチェンジャーであり、これは見過ごされるべきではありません。

公平かつ網羅的にするために、MongoDbがCouchDbよりも優れている点は、ツールとマーケティングです。彼らは、すべての主要な言語とプラットフォーム向けの第一級の市民ツールを備えており、オンボーディングを簡単にしており、アドホッククエリにこれを追加すると、SQLからの移行がさらに簡単になります。

CouchDbには、このレベルのツールはありません。現在利用できるライブラリはたくさんありますが、CouchDbはHTTP APIとして公開されているため、好きな言語でラッパーを作成して簡単に話すことができます。私は個人的には、このアプローチが肥大化を回避し、必要なものだけを取ることができるため（インターフェース分離の原則）、このアプローチが好きです。

したがって、どちらか一方を使用することは、主にパラダイムの快適さと好みの問題だと思います。CouchDbのアプローチは特定の人にとっては「ぴったり」ですが、データベースの機能について（完全な公式ガイドで）学習した後で「地獄」の瞬間がない場合は、おそらく先に進む必要があります。

「適切な作業に適切なツール」を使用したいだけの場合は、CouchDbを使用しないでください。あなたはそれをそのまま使用することができないことがわかり、「CouchDbの結合はどこにあるのか」などのブログの投稿に腹を立てて書くことになってしまうからです。および「トランザクション管理はどこにありますか？」確かに、Couchdbは-逆説的に-非常に透過的ですが、同時にパラダイムシフトと、問題にアプローチして実際に輝く（そして実際に機能する）方法の変更が必要です。

しかし、それを実行したら、それは本当に報われます。私は個人的に、別のデータベースを選択するためにプロジェクトに非常に強力な理由または大きな取引ブレーカーを必要としていますが、これまでのところ、私はまだ会っていません。

この質問を自分でしますか？そして、あなたはあなたのDBの選択を決定します。

1. あなたはマスターマスターが必要ですか？次に、CouchDB。主にCouchDBは、マスターとマスターのレプリケーションをサポートしています。これにより、ノードが長期間切断されることが予想されます。MongoDBはその環境ではうまく機能しません。
2. 最大のR / Wスループットが必要ですか？その後、MongoDB
3. DBサーバーが1つしかないため、究極の単一サーバーの耐久性が必要ですか？次に、CouchDB。
4. 非常識なスループットを維持しながら、シャーディングが必要なMASSIVEデータセットを保存していますか？次にMongoDB。
5. データの強い整合性が必要ですか？次にMongoDB。
6. データベースの高可用性が必要ですか？次に、CouchDB。
7. マルチデータベースとマルチテーブル/コレクションを期待していますか？その後、MongoDB
8. あなたは持っているユーザーがオフラインのモバイルアプリを、サーバにその活動データを同期したいですか？次に、CouchDBが必要です。
9. 多種多様なクエリエンジンが必要ですか？その後、MongoDB
10. DBを使用するには大きなコミュニティが必要ですか？その後、MongoDB

その記事で見つかった答えを要約します。

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB：クエリの向上、BSONでのデータストレージ（高速アクセス）、データの一貫性の向上、複数のコレクション

CouchDB：マスターからマスターへのレプリケーションと競合の解決、JSONでのデータストレージ（人間が読める、RESTサービスを介したアクセス）、map-reduceを介したクエリによる、より優れたレプリケーション。

つまり、MongoDBの方が高速で、CouchDBの方が安全です。

また：http : //nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

MongoDBのスパースユニークインデックスの問題に注意してください。私はそれを打った、そしてそれは回避策に非常に面倒です。

問題はこれです-存在する場合に一意であるフィールドがあり、フィールドが存在しないすべてのオブジェクトを検索したい場合。Mongoでスパースユニークインデックスを実装する方法は、そのフィールドが欠落しているオブジェクトがインデックスにまったくないことです。それらは、そのフィールドに対するクエリでは取得できません- {$exists: false}機能しません。

私が思いついた唯一の回避策は、空の値がUUIDに連結された特別なプレフィックス（null：など）に変換される、特別なnull値のファミリーを持つことです。これは本当の悩みの種です。なぜなら、書き込み/クエリ/読み取りの際に、空の値との間の変換を行う必要があるからです。大きな迷惑。

MongoDBでサーバー側のjavascript実行を使用したことがなく（いずれにしてもお勧めしません）、Mongoノードが1つしかない場合、それらのmap / reduceのパフォーマンスは非常に高くなります。これらすべての理由により、私は今CouchDBをチェックアウトすることを検討しています。おそらくそれは私の特定のシナリオにより適しています。

ところで、まばらな一意インデックスの問題を説明するそれぞれのMongoの問題へのリンクを誰かが知っている場合は、共有してください。

あなたはモンゴでそれをよりよくすることができると確信しています（より慣れています）、そしてソファーでもできると確信しています。

どちらもドキュメント指向（JSONベース）なので、ドキュメントには「列」ではなくフィールドがありますが、完全に動的にすることができます。

彼らは両方ともあなたが使用する他の要因を見たいと思うかもしれないそれをします：あなたが気にかけている他の機能、人気など。Googleの洞察、deed.comの求人は人気を見るための方法でしょう。

5分でmongoを実行できるようになると思います。