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 を使用している他のユーザーのリストは次のとおりです。
主な課題は、ドキュメントを整理する方法を知り、リレーショナル データの観点から考えるのをやめることです。
SourceForgeは MongoDB を使用しています。このプレゼンテーションを参照するか、こちらをお読みください。
私たちのショップでは、MySQL の代替として CouchDB を実行しています (70.0000 アイテム/ショップ、全アイテムの合計 400 万の属性、アイテム間の相互接続)。
私たちの目標は次のとおりです。
master-db から異なるドキュメントを持つ複数のクライアントへの簡単な複製。
「これらの条件に適合する、この属性とそのフィルタを使用して部品をいくつ持っているか」などの事前計算された高速データ
事実:
だけでなく：
その結果、データの作成と維持のためのデータベースとしての MySQL は、信頼性が高く、理解しやすく、扱いやすいものになっています。これは変えないと思います。しかし、CouchDB ビューのパワーとレプリケーションのセットアップの容易さも見逃したくありません。
プロダクション カウチは、構成の誤りや logrotate の忘れ (ビューの構築に時間がかかりすぎたり、ハングしたり、レプリケーションが停止したりする) が原因で、数か月の作業の後に問題を引き起こすことがありましたが、データが失われることはなく、常に簡単にリセットできました。
本番環境で CouchDB を使用しています。現在、元の DB スキーマにはなかったすべての「オプション」フィールドが格納されています。そして今、すべてのデータを CouchDB に移動することを考えています。
これは非常に危険なステップであることは認めます。まず、まだ v1.0 ではないためです。そして第二に、ドライブスペースを大量に消費するためです。私の計算では、CouchDB ファイル (インデックス付き) は、同じ行を持つ MySQL データベースよりも最大 30 倍大きくなります。しかし、私はそれがうまくいくと確信しています。
CouchDB 0.11（3月末にリリース）は、1.0の機能フリーズリリースです。これは、1.0の現在のAPIとの互換性を維持することを意味します。しばらくしていない場合は、CouchDBをもう一度確認する良い機会です。
CouchDB0.11ソースコードリリースはこちらから入手できます。ここにリンクされているバイナリインストーラーやその他のグッズがあります。
プロジェクトが Apache の傘下に入る直前から、couchdb を本番環境で使用しています。
それ以外の場合は dbms を使用する可能性があるすべてのものに加えて、あらゆる種類の非構造化データを格納するために使用します。個人的には、あらゆる種類のデータをそこに投げ込み、ビューを使用して状況に応じて必要のないものを選別できる方法が本当に気に入っています。
最も困難だったのは、dbms の考え方から離れることでした。安全のためにストレージ形式が変更されたときに独自の移行ユーティリティを作成したため、実際には問題はありませんでした。
まだネガティブな経験はありませんが、大きな負荷がかかった状態でセットアップを行ったことはありません。すべての書き込みを取得する単一のマスター サーバーからレプリケートする 2 つのスレーブ タイプのサーバーがあるため、問題なく動作すると思います。レプリケーションが正しく機能するためにそのようにする必要はないと確信していますが、最初に設定した方法で動かなくなってしまいました。
CouchDB を使用して、モバイルのインバウンドおよびアウトバウンド メッセージを保存し、私が作成したいくつかのカスタム ビューを介してこのトラフィックをレポートします。フロントエンドは Python で書かれています。実際の技術的な問題はなく、12 月末から稼働しています。私が遭遇した唯一のハードルは、最初は MapReduce の観点から考えることでしたが、その方法を学ぶと、他のすべてがスムーズに進みました。
現在、MongoDB を製品のインポートと製品データの操作のためのキャッシング レイヤーおよびストレージ エンジンとして本番環境で使用しています。私たちは 200 万を超える製品 (1 億以上の属性) を管理する e コマース企業であり、10 以上のディストリビューターにまたがっています。MongoDB がなければ、このタスクはほぼ不可能です。
現在、LAN を介したコラボレーションのファイル ストレージ サービスとして mongodb を使用しています。また、 trello などのプロジェクトは、バックエンド データストアとしてmongodbを使用しています。以前はcouchdbを使用していましたが、本番環境では使用していません.
本番環境でmongodbを使用しています
www.beachfront.io - 1 秒あたり 5,000 近くの書き込みリクエスト www.beachfrontbuilder.com - 1 秒あたり 500 件の読み取り/書き込みリクエスト、1000 万ユーザーのデータと OLAP を維持します。
データのアーカイブに関して直面する唯一の課題は、カスタム コンポーネントを実装することで克服しました。
Adobeは、 Adobe Experience Manager (以前の Day CQ )の今後のリリースでコア DB エンジンとしてMongoDBを使用しています。
私が働いている代理店のクライアントの何人かは、大規模なクライアント向けのプロジェクトでCouchDBを使用しています。
私の意見では、どちらも優れた実行可能な DB です。:)
私たちは、モバイル バックエンド サービスであるNetmera の運用環境で MongoDB を使用しています。これを使用して、すべてのユーザーとコンテンツ データを保存しています。
この質問はすでに回答を受け入れていますが、現在、その優れた機能の多くで、もう 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サーバー
これは次の大きなことにつながります。
私は本番環境で CouchDB を約 2 年間使用しています。プロジェクトは CouchDB の実装から直接開始されたため、移行作業はありません。単一の電子製品のデータを最初からパッケージングまで保存するデータベースとして機能します。
高精度が要求されるセンサーを販売しているため、さまざまな段階で多くのテストを行い、これらすべてが CouchDB の 1 つのドキュメントに格納されます。
私が経験から学んだいくつかの学習曲線があります。それは、ビュー (または永続的なビューとも呼ばれます) を最大限に活用することです。ビューは、頻繁に呼び出されるデータベースの一部の「小さなフィルター」である必要があります。
私の CouchDB データベースは、他の巨大企業ほどクレイジーではありません。しかし、これまでのところ、私はまだ元気です。現在、700MB で 24000 のドキュメントがあります。
私が気に入っている CouchDB の機能は、「レプリケーション」、「ドキュメントのリビジョンの保存」です。
MongoDB の良いレビューをたくさん読んだので、機会があれば試してみたいと思います。
MongoDB は企業へのライセンス供与に関していくつかの問題を抱えています。詳細はわかりませんが、当社の法務部門は、当社の製品で MongoDB を使用することは許可されていないという明確な条件はありませんでした。