MongoDBまたは他のドキュメント指向データベースシステムをいつ使用するのですか？[閉まっている]

ビデオクリップとオーディオクリップ、写真、ベクターグラフィックスのプラットフォームを提供しています。データベースのバックエンドとしてMySQLから始め、最近、ファイルのすべてのメタ情報を格納するためのMongoDBを含めました。これは、MongoDBが要件によりよく適合するためです。たとえば、写真にはExif情報が含まれている場合があり、動画には、メタ情報を保存するオーディオトラックが含まれている場合があります。ビデオとベクターグラフィックスは共通のメタ情報などを共有しないため、MongoDBはこの非構造化データを保存して検索可能に保つのに最適です。

ただし、プラットフォームの開発と機能の追加は継続しています。次のステップの1つは、ユーザーにフォーラムを提供することです。ここで発生する質問は、MySQLデータベースを使用することです。MySQLデータベースは、フォーラムやフォーラム投稿などを保存するのに適していますか、それともMongoDBを使用しますか？

したがって、問題は、MongoDBをいつ使用し、RDBMSをいつ使用するかです。mongoDBまたはMySQLのどちらを選択しますか？

NoSQL：それは簡単だった場合にのみ、 MongoDBの程度、著者の書き込み：

MongoDBはキー/値ストアではなく、かなり多くの機能を備えています。間違いなくRDBMSでもありません。私は本番環境でMongoDBを使用していませんが、テストアプリの構築に少し使用しました。これは非常に優れたキットです。それは非常にパフォーマンスが高いようで、フォールトトレランスと自動シャーディング（別名はスケーリング）を備えているか、すぐに備えます。Mongoは、これまでに見たRDBMSの置き換えに最も近いものだと思います。すべてのデータセットとアクセスパターンで機能するわけではありませんが、一般的なCRUD向けに作成されています。本質的に巨大なハッシュであるものを格納し、それらのキーのいずれかを選択できることは、ほとんどの人がリレーショナルデータベースを使用するためのものです。DBが3NFであり、結合を行わない場合（一連のテーブルを選択してすべてのオブジェクトをまとめるだけで、ほとんどの人がWebアプリで何をしているのか）、MongoDBはおそらくお尻を蹴ります。

次に、結論として：

指摘すべき本当のことは、データベースを選択できないために何かを非常に素晴らしいものにすることを妨げられている場合、それは間違っているということです。mysqlを知っている場合は、それを使用してください。実際に必要なときに最適化します。それをak / vストアのように使用し、rdbmsのように使用しますが、神のためにキラーアプリを作成してください！これはほとんどのアプリにとって重要ではありません。FacebookはまだMySQLを多く使用しています。ウィキペディアはMySQLをよく使用しています。FriendFeedは、MySQLをよく使用します。NoSQLは優れたツールですが、確かに競争力になることはなく、アプリを熱くすることはありません。何よりも、ユーザーはこれについて気にしません。

次のアプリは何に基づいて構築しますか？おそらくPostgres。NoSQLを使用しますか？多分。HadoopとHiveを使用することもあります。すべてをフラットファイルに保存する場合があります。たぶん、マグレブのハッキングを始めるでしょう。仕事に最適なものを使用します。 レポートが必要な場合は、NoSQLを使用しません。キャッシングが必要な場合は、Tokyo Tyrantを使用します。ACIDityが必要な場合は、NoSQLを使用しません。大量のカウンターが必要な場合は、Redisを使用します。トランザクションが必要な場合は、Postgresを使用します。 1種類のドキュメントが大量にある場合は、おそらくMongoを使用します。1日に10億のオブジェクトを書き込む必要がある場合は、おそらくヴォルデモートを使用します。全文検索が必要な場合は、おそらくSolrを使用します。揮発性データの全文検索が必要な場合は、おそらくSphinxを使用します。

私はこの記事が好きです。非常に有益であり、NoSQLの展望と誇大宣伝の概要がわかります。しかし、それが最も重要な部分であり、RDBMSとNoSQLのどちらを選択するかについて、適切な質問をすることは非常に役立ちます。読む価値がある私見。

記事への代替リンク

ソーシャルアプリにMongoDbを使用して2年後、SQL RDBMSなしで生活することが本当に何を意味するのかを目の当たりにしました。

1. 結局、RDBMSが自動的に行うような、さまざまなテーブル/コレクションからのデータの結合などを行うジョブを記述します。
2. NoSQLのクエリ機能は大幅に機能しなくなります。MongoDbはSQLに最も近いものかもしれませんが、それでも非常にはるかに遅れています。私を信じて。SQLクエリは非常に直感的で、柔軟で強力です。MongoDbクエリはそうではありません。
3. MongoDbクエリは、1つのコレクションからのみデータを取得し、1つのインデックスのみを利用できます。そして、MongoDbはおそらく最も柔軟なNoSQLデータベースの1つです。多くのシナリオで、これは関連するレコードを見つけるためにサーバーへのラウンドトリップが増えることを意味します。次に、データの非正規化を開始します。これは、バックグラウンドジョブを意味します。
4. リレーショナルデータベースではないという事実は、データの整合性を確保するための外部キー制約がないことを意味します（一部のユーザーはパフォーマンスが悪いと考えています）。これにより、最終的にデータベースにデータの不整合が生じることを保証します。準備して。ほとんどの場合、データベースの整合性を維持するためのプロセスまたはチェックの作成を開始します。これは、RDBMSに任せるよりもパフォーマンスが良くない可能性があります。
5. hibernateのような成熟したフレームワークについては忘れてください。

すべてのプロジェクトの98％は、通常のSQL RDBMSの方がNoSQLよりもはるかに優れていると思います。

この非構造化データを保存する

あなたが言ったように、MongoDBは非構造化データを保存するのに最適です。これにより、データをドキュメント形式に整理できます。NoSQLデータストア（MongoDB、CouchDB、Voldemort）と呼ばれるこれらのRDBMS代替は、大規模にスケーリングし、これらのビッグデータストアからの高速データアクセスを必要とするアプリケーションに非常に役立ちます。

また、これらのデータベースの実装は、通常のRDBMSよりも簡単です。これらは単純なキー値またはドキュメントスタイルのバイナリオブジェクトであるため、ディスクに直接シリアル化されます。これらのデータストアは、ACIDプロパティとスキーマを適用しません。これはトランザクション機能を提供しません。したがって、これは大規模に拡張でき、より高速なアクセス（読み取りと書き込みの両方）を実現できます。

しかし対照的に、RDBMはデータにACIDとスキーマを適用します。構造化データを操作したい場合は、RDBMを使用できます。

この種のフォーラムを作成するには、MySQLを選択します。これは大規模に拡大するつもりはないので。そして、これはデータ間の構造化された関係を持つ非常にシンプルな（一般的な）アプリケーションです。

Mongoは基本的にJSONを格納することに注意してください。アプリが多くのJSオブジェクト（入れ子を含む）を処理していて、これらのオブジェクトを永続化したい場合は、Mongoを使用するための非常に強力な議論があります。DALレイヤーとMVCレイヤーは、すべてのJSオブジェクトプロパティをアンパックせず、自然に収まらない構造（スキーマ）にそれらを強制的にはめようとしないため、超薄型になります。

私たちはいくつかの複雑なJSオブジェクトを中心に持つシステムを持っており、すべてを本当に簡単に永続化できるので、Mongoが大好きです。私たちのオブジェクトもかなりアモルファスで構造化されておらず、モンゴは瞬きすることなくその複雑さを吸収します。私たちには、人間が消費するためのアモルファスデータを解読するカスタムレポートレイヤーがあり、開発はそれほど難しくありませんでした。

複雑なトランザクションが必要な場合は、RDBMSを使用すると思います。それ以外の場合は、MongoDBを使用します-より柔軟に操作でき、必要に応じて拡張できることをご存知でしょう。（私は偏っています-私はMongoDBプロジェクトに取り組んでいます）

分散した分割フォーラムが必要なのは誰ですか？たぶんFacebookかもしれませんが、Facebookの競争相手を作成しているのでなければ、MysqlやPostgresなど、最も使いやすいものを使用してください。MongoDBを試してみたい場合は、承知しましたが、MongoDBが魔法のように動作するとは思わないでください。それは他のすべてと同じように、その奇妙さと一般的な美しさを持っています。あなたが本当にそれに取り組んでいるのなら、あなたはすでに発見していると思います。

確かに、MongoDBは誇大広告で表面上は簡単に見えるかもしれませんが、より成熟した製品がすでに克服している問題に遭遇します。そんなに簡単に誘惑されるのではなく、 "nosql"が成熟するか死ぬまで待ちます。

個人的には、（ほとんどの場合定義による）基準が設定されていないため、「nosql」は枯渇して断片化によって死ぬと思います。したがって、長期的なプロジェクトについては、個人的には賭けません。

私の本で "nosql"を節約できる唯一のことは、Rubyまたは類似の言語にシームレスに統合でき、コーディングと設計のオーバーヘッドがほとんどなく、言語を "永続的"にできるかどうかです。それは実現するかもしれませんが、私はそれまで待って、今ではなく、もちろんもっと成熟する必要があります。

ところで、なぜフォーラムを最初から作成するのですか？あなたが本当に次世代のフォーラムを作成しているのでない限り、ほとんどの要件に合わせて微調整できるオープンソースのフォーラムはたくさんあります（これは私が疑っています）。

多くの企業がアプリケーションログからのリアルタイム分析にMongoDBを使用しているのを見てきました。そのスキーマフリー性は、レコードスキーマが時々変更される傾向があるアプリケーションログに本当に適しています。また、Capped Collection機能は、古いデータを自動的にパージして、データをメモリに収めておくのに役立ちます。

これは、MongoDBが本当に適していると思う領域の1つですが、MySQL / PostgreSQLの方が一般的に推奨されています。Webには、機能性と堅牢性だけでなく、多くのドキュメントと開発者向けリソースがあります。

あなたがモンゴを好むかもしれない2つの主な理由は、

• スキーマ設計の柔軟性（JSONタイプのドキュメントストア）。
• スケーラビリティ-ノードを追加するだけで、水平方向に非常に適切にスケーリングできます。

ビッグデータアプリケーションに適しています。RDBMSはビッグデータには適していません。

ご存知のとおり、結合と「複雑なトランザクション」に関するすべてのものですが、何年も前に、COMMIT / ROLLBACKの「必要性」を説明したのはモンティ自身でした。 （データベースではなく）とにかく '-繰り返しますが、同じことです。必要なのは、Webアプリの機能の99％に対応する、ダムでありながら非常に整頓された高速のデータストレージ/検索エンジンです。

以前に述べたように、あなたは多くの選択肢から選ぶことができ、それらすべての選択肢を見てみましょう：http : //kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

MySQL + Memcacheは、ACIDが必要で、いくつかのテーブルを結合したい場合、本当に優れています。MongoDB+ Redisは、ドキュメントストアに最適です。Neo4Jは、グラフデータベースに最適です。

私がしていること：慣れているので、MySQl + Memcacheから始めて、他のデータベースフレームワークを使い始めます。1つのプロジェクトで、たとえばMySQLとMongoDBを組み合わせることができます。