MongoDBまたはCouchDB-本番環境に適していますか？[閉まっている]

MongoDBまたはCouchDBが本番環境に対応する準備ができているかどうかを誰かが教えてくれるかどうか疑問に思っていました。

現在、これらのストレージソリューションを調べています（現時点ではMongoDBを支持しています）が、これらのプロジェクトは非常に若いため、これを採用する必要があることを上司に説得するために、かなり努力する必要があると予測しています。新技術。

私が知りたいのは：

1. 今日、本番環境で誰がMongoDBまたはCouchDBを使用していますか？

2. MongoDB / CouchDBをどのように使用していますか？

3. この新しいストレージメカニズムを採用したときに、どのような問題（ある場合）に遭遇しましたか（そしてどのようにしてそれらを克服しましたか）？

4. 対処しなければならない移行の問題にどのように対処しましたか？

5. これらのソリューションのいずれかについて、共有したい良い/悪い経験はありますか？

私は10gen（MongoDBの開発者）のCTOなので、少し偏見がありますが、本番環境でMongoDBを使用しているいくつかのサイトも管理しています。

businessinsiderはmongoを1年以上プロダクションで使用しています。ユーザーやブログの投稿からサイト上のすべての画像まで、あらゆるものに使用しています。

ショップウィキは、リアルタイム分析やキャッシングレイヤーなど、いくつかの目的でそれを使用しています。彼らはかなり大きなデータベースに対して毎秒1000回を超える書き込みを行っています。

mongodb Production Deploymentsページに移動すると、本番環境で mongoを使用している人々が表示されます。

運用展開の規模や範囲について質問がある場合は、ユーザーリストに投稿してください。サポートさせていただきます。

BBCと meebo.comは生産でのCouchDBを使用するので、私のクライアントの一つはありません。以下は、Couchを使用している他のユーザーのリストです。CouchDBin the wild

主な課題は、ドキュメントを整理し、リレーショナルデータの観点から考えるのをやめる方法を知ることです。

SourceForgeはMongoDBを使用しています。このプレゼンテーションを参照するか、こちらをお読みください。

私たちはショップのMySQLの置き換えとしてCouchDBを実行しています（70.0000アイテム/ショップ、すべてのアイテムの合計400万の属性、アイテム間の相互接続）。

私たちの目標は：

1. master-dbから異なるドキュメントを持つ複数のクライアントへの簡単なレプリケーション。

2. 「この属性とそのフィルターを使用して部品をいくつ持っているか、それらの条件に適合する」などの高速の事前計算データ

事実：

1. 私たちのショップは現在、MySQL（およびmysql-databaseに追加で1〜3日間の事前計算が必要だったため（更新は月に2回でした）、非常に高速で実行されているため、データを製品のカウントとフィルタリングに使用できるようになり、CouchDBには5時間必要です。製品データを毎晩更新できます）
2. ショップノードへの（フィルタリングされた）データ配布とバックアップのセットアップは迅速かつ簡単です

だけでなく：

1. map / reduceと、結合を持たないことの限界を理解することは非常に困難です
2. 外部プログラムなしでは、「場所の削除」や「場所の更新」などのデータの操作はありません
3. 問題がない限り、レプリケーションは適切に機能します。その理由が何であるかを見つけるのは本当に難しい（初心者にとって）
4. Linuxオタクでないと、バイナリなしでCouchDBをインストールすることができます（実際にはいくつかありますが、すべてのOS /バージョンに対応しているわけではありません）。しかし、CouchDBコミュニティーは役に立ちます（#couchdb）。幸運なことに、無料から大規模なビジネスまでサービスを提供している企業（cloudant、iriscouch）があります。
5. CouchDBは前進しているため、作業方法を変更する可能性のある多くの変更（改善）が行われています。しかし、基本的なものは安定しています。

結果として、データの作成と維持のためのデータベースとしてのMySQLは信頼性が高く、理解と取り扱いが簡単です。これは変更しないと思います。しかし、CouchDBビューの力とレプリケーションのセットアップの容易さも見逃したくないです。

数カ月の作業の後に、構成ミスとlogrotateの忘れ（ビューの構築に時間がかかりすぎるか、ハングし、レプリケーションが停止する）のため、運用ソファーは時々問題を引き起こしましたが、データを失うことはなく、常に簡単にリセットできました。

本番環境ではCouchDBを使用しています。現在、元のDBスキーマにはなかった「オプション」フィールドがすべて格納されています。そして今、私はすべてのデータをCouchDBに移動することを考えています。

それは非常に危険なステップだと私は認めます。まず、まだv1.0ではないためです。2つ目は、ドライブスペースを大量に消費するためです。私の計算では、CouchDBファイル（インデックス付き）は、同じ行を持つMySQLデータベースよりも最大30倍大きくなっています。しかし、私はそれがうまくいくと確信しています。

CouchDB 0.11（3月末にリリース）は、1.0の機能フリーズリリースです。これは、1.0の現在のAPIとの互換性を維持することを意味します。そのため、しばらくしていない場合は、CouchDBをもう一度確認する良い機会です。

CouchDBの0.11ソースコードのリリースはこちらです。ここには、バイナリインストーラーやその他の便利な機能がリンクされています。

MongoDBについては何も知りませんが、CouchDB FAQから：

CouchDBは本稼働の準備ができていますか？

はい、CouchDBを使用するプロジェクトの部分的なリストについては、InTheWildを参照してください。もう1つの優れた概要は、CouchDBのケーススタディです。

また、いくつかのリンク：

• Re：現在のCouchDBの状態？
• SimpleDB、CouchDBおよびその他の「新しい」データストア-フィードバック

私たちは本番環境でcouchdbを使用しており、プロジェクトがApache傘下に入る直前になりました。

それを使用して、他の方法ではdbmsを使用する可能性のあるすべてのものと、あらゆる種類の非構造化データを格納します。個人的には、あらゆる種類のデータをそれに投入し、ビューを使用して状況に応じて不要なものを間引く方法が本当に好きです。

最も難しいのは、dbmsの考え方から離れることでした。安全のためにストレージ形式が変更されたときに、独自の移行ユーティリティを作成しました。これは、実際には問題ではありませんでした。

ネガティブな経験はまだありませんが、それでも、大きな負荷のもとでのセットアップはありません。私が考えて、我々はすべての書き込みを取得し、単一のマスターサーバーから複製2台のスレーブ型サーバを持っているので、物事はかなりうまく動作します。レプリケーションが正しく機能するためにそのようにする必要はないと確信していますが、それは最初にセットアップしてスタックした方法です。

CouchDBを使用して、モバイルのインバウンドメッセージとアウトバウンドメッセージを保存し、私が書いたいくつかのカスタムビューを介してこのトラフィックについてレポートします。フロントエンドはPythonで記述されています。技術的な問題はなく、12月末から稼働しています。私が遭遇した唯一のハードルは、最初はMapReduceに関して考えることでしたが、その方法を学んだ後は、他のすべてがスムーズに進みました。

現在、MongoDBをキャッシングレイヤーとして、また製品のインポートと製品データの操作のためのストレージエンジンとして使用しています。私たちは、200万以上の製品（1億以上の属性）を管理し、10以上のディストリビューターにまたがるeコマース企業であり、MongoDBなしでは、このタスクはほぼ不可能です。

現在、LANを介したコラボレーションのファイルストレージサービスとしてmongodbを使用しています。また、trelloなどのプロジェクトでは、mongodbをバックエンドデータストアとして使用しています。以前にcouchdbを使用しましたが、本番環境では使用していません。

モバイルバックエンドサービスであるNetmeraの MongoDBを本番環境で使用しています。すべてのユーザーとコンテンツデータを格納するために使用しています。

CouchDBを本番環境で2年近く使用しています。プロジェクトはCouchDBの実装で直接開始されたため、移行作業はありません。単一の電子製品のデータを最初からパッケージングまで保存するデータベースとして機能します。

高精度が要求されるセンサーを販売しているため、さまざまな段階で多くのテストを行い、これらすべてをCouchDBの1つのドキュメントに保存します。

私の経験から学んだいくつかの学習曲線があります。それは、ビュー（または永続ビューとも呼ばれます）を最大限に活用することです。ビューは、頻繁に呼び出されるデータベースの一部の「小さなフィルター」である必要があります。

私のCouchDBデータベースは、他の巨大な会社ほどおかしくありません。しかし、これまでのところ、私はまだ元気です。現在、700MBで24000のドキュメントがあります。

私が気に入っているCouchDBの機能は、「レプリケーション」、「ドキュメントのリビジョンの保存」です。

MongoDBで良いレビューをたくさん読んだので、機会があれば試してみたいと思います。

私たちはmongodbを生産に使用しています

www.beachfront.io-1秒あたり5kの書き込みリクエストwww.beachfrontbuilder.com-1秒あたり500の読み取り/書き込みリクエスト。

データのアーカイブに関して直面した唯一の課題は、カスタムコンポーネントを実装することで克服しました。

この質問はすでに答えを受け入れていますが、今日、もう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プラグインが含まれています。

あなたはもっと探検することができます Couchbase Liteで

そして Couchbase Server

これは次の大きなことになります。

本番環境と言えば、シームレスなフェイルオーバー/リカバリーにはどちらもベビーシッターが必要です
1- Couchbase。シームレスなフェイルオーバー/リカバリーはなく、手動での介入が必要です。
複数のノードが失われた場合、リバランスには時間がかかりすぎ、リスクも大きくなります。

2-シャードを使用したMongo、構成サーバーを失うことからのデータ回復は簡単な作業ではありません

アドビは、MongoDBを次のリリースに使用しています Adobe Experience Managerの（以前はDay CQ）にます、コアDBエンジンとして、）にます。

私が働いている代理店のいくつかのクライアントが使用しています 大規模なクライアントのプロジェクトでCouchDBをしています。

私の意見では、どちらも素晴らしい、実行可能なDBです。:)

これは、mongoDBを使用して本番環境にデプロイされたサイトのリストです

• ニューヨークタイムズ：写真提出用のフォーム作成アプリケーションで使用します。Mongoにはスキーマがないため、プロデューサーはカスタムフォームフィールドの任意の組み合わせを定義できます。
• SourceForge：SourceForgeのフロントページ、プロジェクトページ、およびすべてのプロジェクトのダウンロードページのバックエンドストレージに使用されます。
• Bit.ly
• Etsy
• IGN：IGNのリアルタイムトラフィック分析とRESTfulコンテンツAPIを強化します。
• Justin.tv：すぐに使えるソリューションでは提供できないバイラル性、ユーザー維持率、一般的な使用状況に関するJustin.tvの内部分析ツールを強化します。
• 後発
• 直感
• Foursquare：Sharded Mongoデータベースは、foursquareのほとんどのデータに使用されます。
• Business Insider：2008年の初めから使用しています。投稿、コメント、画像など、サイトのすべてのデータはMongoDBに保存されています。
• Github：内部レポートアプリケーションに使用されます。
• Examiner：Cold FusionとSQL ServerからDrupal 7とMongoDBにサイトを移行しました。
• Grooveshark：現在、Mongoを使用して、1日に100万を超えるユニークユーザーセッションを管理しています。
• バズフィード
• 円盤投げ
• Evite：分析とクイックレポートに使用されます。
• Squarespace
• Shutterfly：Shutterfly内のさまざまな永続的なデータストレージ要件に使用されます。MongoDBは、Shutterflyが比類のないサービスを構築するのを支援し、顧客と生活の中で最も重要な顧客との間のより深い、より個人的な関係を可能にします。
• トプシー
• これを共有
• Mongohq：MongoDBのホスティングプラットフォームを提供し、MongoDBをそのサービスのバックエンドとして使用します。ホスティングセンターのページには、MongoHQおよびその他のMongoDBホスティングオプションに関する詳細情報が記載されています。

もっと...

から抽出： http //lineofthought.com/tools/mongodb

そこで他のデータベースやツールをチェックすることもできます。

MongoDBには企業へのライセンス供与に関していくつかの問題があります。詳細はわかりませんが、法務部門は、どのような製品でもMongoDBの使用が許可されていないことを特定の条件で教えてくれませんでした。