NoSQLと他のSQL Drupal設定
DrupalでMySQL、PostGRE SQL、またはMSSQLよりもNoSQL（ex MongoDB）を実行する利点は何ですか？単にストレージを使用することで得られる利点はありますか、それともDrupal構成を変更する必要がありますか？
MongoDBを使用すると、ほとんどまたはすべてのエンティティをドキュメント指向の高速ストレージに格納できます。このタイプのストレージは、Drupalコア（これは「フィールドごとに1つのテーブル」スキーマに基づいています）にある標準のSQLベースのストレージよりも優れています。
Drupal 7の現在の状態では、次のようになります。
- SQLに格納されているエンティティのベーステーブル（つまり、usersテーブル、nodeテーブルなど）
- SQLに格納されているすべてのフィールド
- MongoDBで複製されたベーステーブルのエンティティのプロパティ
これにより、MongoDB上のエンティティに対して高速なクエリを実行でき、オープンソースSQLデータベースがサポートしていない複雑なインデックス（テーブル間のインデックスを含む）を追加できます。同時に、エンティティのベーステーブルはSQLに保存されているため、SQL専用のモジュール（フラグなど）で結合できるため、相互運用性が失われることはありません。
このタイプの高速クエリは、エンティティ、そのプロパティ、およびフィールドに対するクエリを抽象的な方法で作成する方法であるEntityFieldQueryメカニズムのおかげで利用できます。コアのデフォルト実装はこれらのクエリをSQLに変換しますが、MongoDBモジュールには、MongoDBからのこれらのクエリを直接満たすことができるフル機能の実装があります。
EntityFieldQuery backend for Views のおかげで、慣れ親しんだツールを使用して、この機能を簡単に活用できます。唯一の欠点は、リレーションシップがサポートされていないことです（ただし、実際にそれらが必要になることはめったにありません。これは、エンティティオブジェクトに追加のデータをプッシュし、エンティティの追加のプロパティとして公開することで回避できます）。
簡単に言えば、クエリのパフォーマンスがプロジェクトの問題であり、重要なデータセット（特定のエンティティタイプの数万個のエンティティから開始するとします）が発生するとすぐに、MongoDBは純利益になります非常に少数の欠点。強くお勧めします。
MongoDBなどは、比較的柔軟な方法で構造化（階層）データを格納するように設計されています。
たとえばDrupal 7では、field_sql_storageを使用すると、すべてのフィールドが独自のテーブルになります。コンテンツタイプに10個のフィールドをアタッチすると、データベースに10個のテーブルが作成されます。そのノードをロードすると、field_sql_storageはフィールドごとおよびノードごと（またはnode_load_multipleを使用する場合は複数のノードごと）にクエリを実行します。
mongodb_field_storage を使用すると、ノードのすべてのフィールドを単一のドキュメントに格納し、単一のクエリで取得できます。
ウォッチドッグ、セッション、キャッシュ、ブロックなどの他のものをMongoDBに保存することもできます。
ただし、MySQLは引き続き必要ですが、MongoDBはそれを置き換えません（特定の部分のみ）。
もう1つの利点は、MongoDBを使用するとスケーリングが容易になることです。多くのサーバーをクラスターに追加して、サーバー間でデータを共有できます。
プロには短所があります。
Drupalは全体としてMongoDbに切り替えることができないため、2つのデータベースをサポートし、それらが連携して機能することを確認する必要があります。
多くのモジュールはmongodbで機能しないため、相互運用性が失われます。
緊急の必要がない限り（システムの一部が要求の数やデータの量に対応していないなど）、私は切り替えません。そして、限界に近づき始めたときでさえ、切り替える前に、問題にハードウェアを投げたり、チューニングしたりすることを見てください。
私は以前にこれに答えたことがあると思いました、SOには ほぼ重複 があります