MongoDBまたはCouchDB - プロダクションに適していますか？
MongoDBまたはCouchDBと誰かが教えてくれるかどうか疑問に思いましたプロダクション環境の準備ができています。
私は今、これらのストレージソリューションを検討しています（現時点ではMongoDBを支持しています）が、これらのプロジェクトは非常に若いので、採用するべきだと私のマネージャーに納得させるために一生懸命努力しなければならないと思います新技術。
私が知りたいのは、
本番環境で現在MongoDBまたはCouchDBを使用しているのは誰ですか？
MongoDB/CouchDBをどのように使用していますか？
この新しいストレージメカニズムを採用したときに、（もしあれば）どのような問題に遭遇しましたか？
どのようにして対処しなければならなかった移行の問題に対処しましたか？
あなたが共有したいと思うこれらの解決策のどちらかに関して何か良い/悪い経験がありますか？
私は10gen（MongoDBの開発者）のCTOなので、少し偏っていますが、本番環境でMongoDBを使用しているサイトもいくつか管理しています。
businessinsider 1年以上前から本番でmongoを使っています。ユーザーやブログ投稿からサイト上のすべての画像まで、あらゆる用途に使用されています。
shopwiki リアルタイム分析やキャッシングレイヤなど、いくつかの用途に使用されています。彼らはかなり大きなデータベースに対して毎秒1000回以上の書き込みを行っています。
mongodb Production Deploymentsページ にアクセスすると、本番でmongoを使用している人たちがいるでしょう。
本番展開の規模や範囲についてご質問がある場合は、当社のユーザーリストに投稿してください。お役に立てば幸いです。
BBC と meebo.com は本番環境でCouchDBを使用しているので、私のクライアントの1人も同様です。これはCouchを使用している他の人々のリストです： CouchDB in the wild
主な課題は、ドキュメントをどのように整理してリレーショナルデータの観点から考えるのをやめるかを知ることです。
SourceForge はMongoDBを使用しています。 このプレゼンテーション または ここを読む を参照してください。
私達は私達の店のためにMySQLの代わりとしてCouchDBを動かしています（70.0000項目/店、すべての項目の合計400万の属性、項目間の相互接続）。
私たちの目標は次のとおりです。
Master-dbから異なる文書を持つ複数のクライアントへの簡単な複製。
「この属性とそのフィルタを使用して、それらの条件に適合する部品がいくつあるか」など、事前に計算された高速データ
事実：
- CouchDBはMySQLを使用するよりはるかに速く稼働しています（そしてmysql-databaseはさらに1〜3日の事前計算を必要とし（更新は月に2回）、製品のカウントとフィルタリングの準備ができました）。毎晩商品データを更新できます。
- 店舗ノードへの（フィルタリングされた）データ配信とバックアップの設定は、迅速で簡単です。
だけでなく：
- Map/reduceを理解し、参加しないことの限界を理解するのは非常に困難です。
- 外部プログラムなしで "where whereを削除"や "whereを更新"などのデータを操作しない
- 問題がない限り、レプリケーションはうまく機能します。それで、その理由が何であるかを見つけるのは本当に難しいです（初心者向け）
- あなたがLinuxのオタクでないなら、バイナリなしでCouchDBをインストールすること（確かにいくつかのワイルドがありますが、すべてのOS /バージョンのためにあるわけではありません）は難しいかもしれません。しかしCouchDBコミュニティは役に立ち（#couchdb）、幸いなことに無料から大企業までサービスを提供している会社（cloudant、iriscouch）があります。
- CouchDBは前進しているので、あなたの仕事の仕方を変えるかもしれない多くの変更（改良）があります。しかし、基本的なことは安定しています。
結果として、データの作成と管理のためのデータベースとしてのMySQLは信頼でき、理解しやすく取り扱いが簡単です。私達はこれを変えないと思います。しかし、私はCouchDBのビューのパワーとレプリケーションの設定の容易さも見逃したくありません。
プロダクションソファーは、設定ミスやログの回転忘れ（ビューの構築に時間がかかりすぎる、ハングアップする、レプリケーションが停止するなど）が原因で作業に支障をきたすことがありましたが、データを失うことはなく、いつでも簡単にリセットできます。
私は本番環境でCouchDBを使用しています。現在それは元のDBスキーマになかったすべてのそれらの「オプションの」フィールドを格納します。そして今、私はすべてのデータをCouchDBに移動することを考えています。
これはかなり危険な一歩です、と私は認めます。それはまだv1.0ではないからです。そして第二に、それはドライブスペースを必要とするからです。私の計算では、CouchDBファイル（インデックス付き）は、同じ行を持つMySQLデータベースの30倍の大きさです。しかし、私はそれがちょうどうまくいくと確信しています。
CouchDB 0.11（3月末にリリース）は、1.0用の機能フリーズリリースです。これは、1.0の現在のAPIとの互換性を維持することを意味しますので、しばらくしていないのであれば、CouchDBをもう一度見てみるのがよいでしょう。
CouchDB 0.11ソースコードリリースはこちらから入手可能です。バイナリインストーラやその他の便利なリンクはこちらから
私はMongoDBについて何も知りませんが、 CouchDB FAQ から：
CouchDBの運用準備はできていますか？
はい、CouchDBを使用しているプロジェクトの部分的なリストについては、 InTheWild を参照してください。もう1つの良い概要は CouchDBケーススタディ
また、いくつかのリンク：
本番環境ではcouchdbを使用していますが、プロジェクトがApacheの傘下に入る直前からです。
そうでなければdbmsを使用する可能性があるものすべてに加えて、あらゆる種類の非構造化データを格納するためにそれを使用します。個人的には、あらゆる種類のデータをその中に入れて、ビューを使って状況に応じて不要なものを削除する方法が本当に好きです。
最も困難な部分は、dbmsの考え方から離れていったことです。安全を期するためにストレージフォーマットが変更されたときに、独自のマイグレーションユーティリティを作成しましたので、それほど問題にはなりませんでした。
私たちはまだ否定的な経験をしたことがありませんが、それから私達はどんな種類の大きな負荷の下でもセットアップを持っていませんでした。 I thinkすべての書き込みを取得する単一のマスターサーバーから複製する2つのスレーブタイプのサーバーがあるので、うまくいくでしょう。レプリケーションを正しく機能させるためにそのようにする必要はないと確信していますが、最初に設定した方法で問題が解決しません。
私たちはCouchDBを使ってモバイルのインバウンドとアウトバウンドのメッセージを保存し、私が書いたいくつかのカスタムビューを通してこのトラフィックについて報告します。フロントエンドはPythonで書かれています。私達は本当の技術的な問題を持っていませんでした、そしてそれは12月末から続いています。私が遭遇した唯一のハードルは、当初MapReduceの観点から考えていましたが、その方法を学んだら、他のすべては順調に進みました。
現在、MongoDBを本番環境でキャッシングレイヤとして使用し、製品のインポートおよび製品データの操作用のストレージエンジンとして使用しています。私たちは、10以上のディストリビュータにまたがり、MongoDBがなければ、200万を超える製品（1億以上の属性）を管理するeコマース企業です。
私たちは現在、LANを介したコラボレーションのためのファイルストレージサービスとしてmongodbを使用しています。また、 trello のようなプロジェクトはバックエンドのデータストアとしてmongodbを使用しています。私は以前にcouchdbを使ったことがありますが、生産能力では使いません。
この質問はすでに答えを受け入れていますが、もう1日後NoSQL DBはその優れた機能の多くでトレンドになっています。それはCouchbaseです。これは、モバイルプラットフォームではCouchbaseLite、サーバーサイドではCouchbase Serverとして実行されます。
これがCouchbase Liteの主な機能の一部です。
Couchbase Liteは、モバイルアプリへの組み込みに適した、軽量でドキュメント指向（NoSQL）の同期可能データベースエンジンです。
軽量という意味：
組み込み - データベースエンジンはアプリにリンクされたライブラリであり、独立したサーバープロセスではありません。コードサイズが小さい - 携帯アプリで重要です。携帯アプリは、携帯ネットワーク経由でダウンロードされることがよくあります。モバイル機器は比較的遅いCPUを持っているので、素早い起動時間 - 重要です。メモリ使用量が少ない - 典型的なモバイルデータセットは比較的小さいですが、文書によっては大きなマルチメディア添付ファイルがある場合があります。優れたパフォーマンス - 正確な数値は、もちろんデータとアプリケーションによって異なります。
ドキュメント指向の意味：
事前定義されたスキーマや正規化を必要とせずに、柔軟なJSON形式でレコードを格納します。ドキュメントには、マルチメディアコンテンツなど、任意のサイズのバイナリ添付ファイルを含めることができます。アプリケーションデータフォーマットは、明示的な移行を必要とせずに時間の経過とともに進化する可能性があります。 MapReduceインデックスは特別な問い合わせ言語を使用する必要なしに速い検索を提供します。
同期可能という意味：
データベースの任意の2つのコピーは、効率的で信頼性が高く、実績のある複製アルゴリズムを介して同期させることができます。同期はオンデマンドまたは連続的（数秒の待ち時間）にすることができます。デバイスは、リモートサーバー上の大規模データベースのサブセットと同期できます。同期エンジンは断続的で信頼性の低いネットワーク接続をサポートします。競合を検出して解決することができ、アプリロジックをマージの完全な制御下に置くことができます。リビジョンツリーを使用すると、データの損失や誤った競合が発生することなく、サーバー間（複数のデータセンター用）やピアツーピアなどの複雑なレプリケーショントポロジを実現できます。 Couchbase Liteは、シームレスなiOS（Objective-C）およびAndroid（Java）開発用のネイティブAPIを提供します。さらに、PhoneGap用のCouchbase Liteプラグインが含まれています。これにより、慣れ親しんだWebアプリケーションプログラミング技術とPhoneGapモバイル開発フレームワークを使用して開発したiOSおよびAndroidアプリケーションを構築できます。
もっと詳しく調べることができます Couchbase Lite
そして Couchbase Server
これは次の大きなことになります。
私達は生産のためにmongodbを使用しています
www.beachfront.io - 1秒あたり5kの書き込み要求に近いwww.beachfrontbuilder.com - 1秒あたり500の読み取り/書き込み要求、10mのユーザーデータを維持します。
唯一の課題はデータのアーカイブ化にありますが、カスタムコンポーネントを実装することで克服しました。
Adobe は、Adobe Experience Managerの今後のリリースでMongoDBを使用しています（コアDBエンジンとして以前はDay CQ）。
私が働いている代理店のいくつかのクライアントは、大規模なクライアントのためのプロジェクトでCouchDBを使っています。
私の考えでは、どちらも優れた実行可能なDBです。 :)
私はCouchDBを本番環境で2年近く使っています。プロジェクトがCouchDBの実装で直接開始されたため、移行作業はありません。それは最初から包装までの単一の電子製品のデータを格納するデータベースとして機能します。
私達は高精度を要求するセンサーを販売しているので、私達は異なった段階でたくさんのテストをし、これらすべてはCouchDBの1つの文書に保存されます。
私が私の経験から学んだ学習曲線がいくつかあります。それは、見解を最大限に活用することです（または、常設見解としても知られています）。ビューは、頻繁に呼び出されるデータベースの一部の「小さなフィルタ」である必要があります。
私のCouchDBデータベースは他の巨大企業ほどクレイジーではありません。しかし、これまでのところ、私はまだ元気です。現在私は700MBで24000の文書を持っています。
私が気に入っているCouchDBの特徴は '複製'、 '文書のリビジョンの保存'です。
私はMongoDBでたくさんの良いレビューを読んでいたでしょう、そしてもし機会があれば私はそれを試したいと思うでしょう。
MongoDBをモバイルバックエンドサービスの実運用で使用しています。 Netmera すべてのユーザーおよびコンテンツデータを格納するために使用しています。
プロダクションと言えば、シームレスなフェイルオーバー/リカバリは両方ともベビーシッターを必要とします
1- Couchbase、シームレスなフェイルオーバー/リカバリはありません。手動操作が必要です。
リバランスには時間がかかりすぎ、複数のノードが失われるとリスクが高すぎます。
2-破片を含むMongo、設定サーバを失うことからのデータ復旧、は簡単な作業ではない