私はMySQLやPostgreSQLなどのリレーショナルデータベースを使用することに慣れており、Symfony、RoR、DjangoなどのMVCフレームワークと組み合わせて使用しているので、うまく機能すると思います。
しかし最近、非リレーショナルデータベースであるMongoDBについて多くのことを聞きました。または、公式の定義を引用すると、
スケーラブル、高性能、オープンソース、スキーマフリー、ドキュメント指向のデータベース。
私は最先端にいることに本当に興味があり、次のプロジェクトで使用できるすべてのオプションを認識し、そこから最高のテクノロジーを選択したいと思っています。
MongoDB（または同様のデータベース）を使用する方が「クラシック」リレーショナルデータベースを使用するよりも優れているのはどのような場合ですか？また、MongoDBとMySQLの一般的な利点は何ですか？または、少なくとも、なぜそんなに違うのですか？
ドキュメントや例へのポインタがある場合、それも非常に役立ちます。
回答:
以下は、Webアプリケーションを構築するためのMongoDBの利点の一部です。
あなたはそれについてもっと読んで、より良いアイデアを得るためにそれをいじる必要があります。ここにオンラインデモがあります：
数多くの利点があります。
たとえば、データベーススキーマはよりスケーラブルで、移行について心配する必要はありません。コードを書くのがより快適になります...たとえば、ここに私のモデルのコードの1つを示します。
class Setting
include MongoMapper::Document
key :news_search, String, :required => true
key :is_availaible_for_iphone, :required => true, :default => false
belongs_to :movie
endキーの追加は、コード行を追加するだけです。
優れた呼び出し可能性と速度など、長期的に見られる他の利点もあります。
... ただし、非リレーショナルデータベースは、リレーショナルデータベースよりも優れているわけではないことに注意してください。データベースに多くの関係と正規化がある場合、MongoDBのようなものを使用しても意味がありません。仕事に適したツールを見つけることがすべてです。
読むべきことについては、「Mongoがデータベースに対してRailsがフレームワークであったのはなぜだと思うのか」またはmongodb Webサイトのこの投稿を参照することをお勧めします。興奮してフランス語を話す場合は、MongoDBを最初からセットアップする方法を説明したこの記事をご覧ください。
編集：ライアンによるこのレールキャストについてお話しするのをほとんど忘れていました。それは非常に興味深く、すぐに始めたくなるでしょう！
スキーマフリーの利点は、負荷が何であってもダンプできることであり、誰もそれについて不平を言ったり、それが間違っていたと言ったりする根拠がありません。
それはまた、あなたがそれに投げ込んだものは何でも、あなたがそうした後も全く意味を持たないままであることを意味します。
全体的に不利だと言う人もいれば、そうでない人もいます。
リレーショナルデータベースに確立されたスキーマがあるという事実は、データベースに記録されているものに意味を付けることができる拡張述語の確立されたセットがあるという事実の結果です。また、そうするために必要な前提条件でもあります。
確立されたスキーマがなければ、拡張述語はなく、拡張精度がなければ、ユーザーはその中に詰め込まれたものから意味を理解することができません。
MongoDBは今週FLOSSウィークリーで特集されました-http ://twit.tv/floss105 同様のコンセプトを使用しているデータベースは、別のFLOSSウィークリーで紹介されたCouchDBです：http : //twit.tv/floss36
@marcggが提供するリンクに加えて、それらを聞く価値があると思います
プロジェクトで両方のデータベースを操作した後のPostgresとMongoでの私の経験。
Postgres（RDBMS）
Postgresは、将来のアプリケーションに多数の結合を必要とする複雑なスキーマがある場合、またはすべてのデータに関係がある場合、または大量の書き込みがある場合に推奨されます。Postgresはオープンソースで、高速で、ACIDに準拠しており、ディスク上のメモリ使用量が少なく、JSONストレージのパフォーマンスも優れており、3レベルのトランザクション分離によるトランザクションの完全な直列化が可能です。
Postgresを利用する最大の利点は、両方の長所があることです。制約、一貫性、速度を備えたJSONBにデータを保存できます。一方、他のタイプのデータにはすべてのSQL機能を使用できます。基盤となるエンジンは非常に安定しており、さまざまなデータ量に対応できます。また、選択したハードウェアとオペレーティングシステムで動作します。PostSQLは、NoSQL機能と完全なトランザクションサポートを提供し、フィールドデータの制約付きのJSONドキュメントを格納します。
Postgresの一般的な制約
Postgresを水平方向にスケーリングすることはかなり困難ですが、実行可能です。
Postgresでは、高速な読み取り操作を完全に実現することはできません。
SQLデータベースなし
Mongo DB（ワイヤードタイガー）
MongoDBは、「水平スケール」の次元でPostgresを上回る可能性があります。JSONの保存は、Mongoが最適化するものです。Mongoは、データをBSONbと呼ばれるバイナリ形式で保存します。BSONbは、（おおよそ）JSONのスーパーセットのバイナリ表現にすぎません。MongoDBはオブジェクトを設計どおりに保存します。MongoDBによると、書き込みが多いアプリケーションの場合、新しいエンジン（Wired Tiger）を使用すると、書き込みパフォーマンスが最大10倍になり（私はこれを試す必要があります）、ストレージ使用率が80％削減され、ストレージコストの削減につながります。 、ハードウェアの利用率を高めます。
MongoDbの一般的な制約
スキーマレスストレージエンジンを使用すると、暗黙的なスキーマの問題が発生します。これらのスキーマは、ストレージエンジンによって定義されるのではなく、アプリケーションの動作と期待に基づいて定義されます。
スタンドアロンのNoSQLテクノロジは、非構造化アプリケーションの高スループットパフォーマンスを優先して、重要なデータ保護を犠牲にするため、ACID標準を満たしていません。NoSQLデータベースにACIDを適用することは難しくありませんが、データベースが遅くなり、ある程度柔軟性がなくなります。「NoSQLの制限のほとんどは、以前の制限を大幅に克服した新しいバージョンとリリースで最適化されました。」
それはすべてトレードオフです。MongoDBは高速ですが、ACIDではなく、トランザクションがありません。一部のユースケースではMySQLよりも優れており、他のユースケースではさらに悪い場合があります。
MongoDBで書かれた怒鳴るライン：決定的なガイド。
いくつかの理由があります。
- 異なる種類のドキュメントを同じコレクションに保持することは、開発者と管理者にとって悪夢になる可能性があります。開発者は、各クエリが特定の種類のドキュメントのみを返すこと、またはクエリを実行するアプリケーションコードが異なる形状のドキュメントを処理できることを確認する必要があります。ブログ投稿をクエリする場合、著者データを含むドキュメントを削除するのは面倒です。
- コレクション内の型のリストを抽出するよりも、コレクションのリストを取得する方がはるかに高速です。たとえば、コレクションにタイプキーがあり、各ドキュメントが「スキム」、「全体」、または「分厚い猿」のドキュメントであるかどうかを示している場合、単一のコレクションでこれらの3つの値を見つけるのは、 3つの別個のコレクションがあり、それらの名前を照会する
- 同じコレクション内の同じ種類のドキュメントをグループ化すると、データの局所性が可能になります。投稿のみを含むコレクションから複数のブログ投稿を取得する場合、投稿と著者データを含むコレクションから同じ投稿を取得するよりも、ディスクシークが少なくなる可能性があります。
- インデックスを作成するときに、ドキュメントに何らかの構造を課し始めます。（これは、一意のインデックスの場合に特に当てはまります。）これらのインデックスは、コレクションごとに定義されます。同じタイプのドキュメントのみを同じコレクションに入れることで、コレクションをより効率的にインデックス化できます
テキスト形式のストレージを備えたデータベースについて質問した後、MongoDBや類似のシステムをちらっと見ました。
私が正しく理解していれば、それらは使いやすく、セットアップも簡単で、はるかに速いはずです。SQLの欠如がSQLインジェクションを防ぐので、おそらくより安全です...
どうやら、MongoDBは主にWebアプリケーションに使用されています。
基本的に、これらのデータベース自体は、複雑なクエリやデータマイニングなどには適していないと述べています。