MongoDBに関する基本的な内容をまとめてみたものです。MongoDBに関する、Web上にすでにある良識な解説コンテンツをまとめたまとめサイトの抜粋です。
MongoDBにおけるスキーマ

スキーマレスで柔軟にデータ処理を行うことができる

MongoDBはスキーマレスで動的なスキーマをもちます。
・同じコレクションにあるドキュメントの構造が異なっていても可
・更新ごとにドキュメントの構造を変更させることも可能

従って、カラムを固定できないような用途/開発時などのスキーマの変更が頻繁に行われる場合には便利なデータベースです。RDBMSで開発を行っている場合には、テーブルのスキーマが変更になるたびにデータベース側とアプリ側の双方で修正を行わなければなりませんが、MongoDBを使っていればアプリケーション側の修正のみですみます。

MongoDBにおけるスキーマのデザイン (RDBとの比較)

MongoDBはRDBMSと違ってJOINはできません。代わりに基準となるオブジェクトに別のオブジェクトをあらかじめembedded（埋め込み）させておくことで，ある程度同じように扱うことができるようにすることができます。

また，MongoDBではリレーションの概念はもっていません。集約できる情報は関連テープルに分散するのではなく、同じドキュメントのサブドキュメントとして集約します。

基本的に、RDBMSではデータを正規化します。データの集約、整形を経て、アプリケーションが扱いやすい形にした上に加工します。
一方で、MongoDBでは、はじめからアプリケーションで取り扱う形でそのままデータベースに格納します。

MongoDBにおけるスキーマデザインとパフォーマンス

MongoDBではデータファイルを仮想メモリにマッピング（Linuxではmmapという機能を利用）し，MongoDBのプロセスは仮想メモリにアクセスします。アクセスするデータが物理メモリに乗っている場合には高速にアクセスできますが，アクセスするデータが物理メモリに乗っていない場合（ページフォルト発生時）は，ディスクからデータを物理メモリに読み込み，その後アクセスする必要があります。そのため，アクセスするデータ（インデックスを含む）がメモリ上にあるかどうかが処理性能を大きく左右します。

MongoDBのコレクションは、アプリケーションが一番よくアクセスするパターンを意識して設計すべきです。一方で、RDBSでは正規化すれば基本的によく、どのようにアクセスされるかを考慮してスキーマの設計を変える必要はありません。

たとえば、データベースに顧客の個人情報が格納されていて、アプリケーションにて顧客の全個人情報を表示するというのが主要な機能であれば、同じコレクションに各顧客の全個人情報を格納するスキーマが適しています。データベースに対するランダムアクセスも一回ですみますし、アクセス頻度の高いデータがメモリ上にのっている確率に高くなり、パフォーマンスが向上します。