526

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

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

問題は、いつ MongoDB を使用し、いつ RDBMS を使用するかということです。選択できるとしたら、mongoDB と MySQL のどちらを選びますか? また、なぜそれを選ぶのですか?

4

10 に答える 10

668

In NoSQL: If Only It Was That Easyで、著者は 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 億個のオブジェクトを作成する必要がある場合は、おそらく Voldemort を使用します。全文検索が必要な場合は、おそらく Solr を使用します。揮発性データの全文検索が必要な場合は、おそらく Sphinx を使用します。

私はこの記事が好きです。非常に有益であり、NoSQL のランドスケープと誇大広告の概要をよく説明しています。しかし、それが最も重要な部分であり、RDBMS と NoSQL のどちらを選択するかに関して、適切な質問を自問することが本当に役立ちます。私見を読む価値があります。

記事への代替リンク

于 2009-09-25T13:42:49.907 に答える
196

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

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

すべてのプロジェクトの 98% は、おそらく NoSQL よりも典型的な SQL RDBMS の方がはるかに優れていると思います。

于 2012-10-07T17:00:14.397 に答える
27

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

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

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

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

この種のフォーラムを作成するには、 MySQLを選択します。これは大規模にはならないからです。これは、データ間の関係を構造化した非常に単純な (一般的な) アプリケーションです。

于 2009-09-25T10:52:59.177 に答える
9

分散型のシャード フォーラムが必要なのは誰ですか? Facebook かもしれませんが、Facebook の競合相手を作成している場合を除き、Mysql、Postgres、または最も使い慣れたものを使用してください。MongoDB を試してみたい場合は、それで問題ありませんが、魔法がかかるとは思わないでください。他のすべてのものと同じように、癖と一般的な厄介さがあります.

確かに、MongoDB は誇大宣伝され、表面的には簡単に見えるかもしれませんが、より成熟した製品が既に克服している問題に遭遇するでしょう。簡単に誘惑されるのではなく、「nosql」が成熟するか死ぬまで待ってください。

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

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

ところで、なぜゼロからフォーラムを作成しているのですか? 次世代のフォーラムを実際に作成している場合を除き (私には疑問です)、ほとんどの要件に合わせて調整できるオープン ソース フォーラムがたくさんあります。

于 2010-11-19T03:02:35.437 に答える
7

複雑なトランザクションが必要な場合は、RDBMS を使用することをお勧めします。それ以外の場合は、MongoDB を使用します。より柔軟に作業でき、必要に応じてスケーリングできることがわかります。（私は偏見があります-私はMongoDBプロジェクトに取り組んでいます）

于 2009-09-25T13:33:17.780 に答える
6

Mongo を好む 2 つの主な理由は次のとおりです。

  • スキーマ設計の柔軟性 (JSON 型ドキュメント ストア)。
  • スケーラビリティ - ノードを追加するだけで、水平方向に非常にうまくスケーリングできます。

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

于 2013-06-21T05:16:35.143 に答える
4

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

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

于 2012-12-28T09:53:35.713 に答える