MongoDBに関する基本的な内容をまとめてみたものです。MongoDBに関する、Web上にすでにある良識な解説コンテンツをまとめたサイトの抜粋です。
MongoDB - OOS ドキュメント指向 noSQL DB

結果整合性保証モデルとし、高い可用性と水平スケールを実現

MongoDBは、「結果整合性」しか保証しないことにより、水平スケールさせることを目指した、分散コンピューティング環境にマッチしたデータベース。

結果整合性:
誰かがデータを更新し、そのデータが複製されるのに十分な時間が過ぎ、その後更新が加えられなければ、必ずその新しいデータにアクセスできる

つまり、MongoDBでは、データの更新リクエストが完了しても、分散環境にコピーされている全データの更新が終了しているとは限らず、そのタイミングで外部からデータ読み込みをすると、更新後のデータを読み出せるとは限りません。

従って、MongoDBでは、トランザクション処理を行わせることはできません。また、テーブルのJOIN操作もできません (複数のドキュメントをDB側で結合できない)。

しかし、この完全には一貫性を保証しないという割り切りは、RDBSでは実現することが難しいレベルでの水平スケールを可能とするだけでなく、複数のデータコピーを持たせることも容易にし、高い可用性も実現します。

ドキュメント指向のデータベース

MongoDBは、ドキュメント指向のデータベースであり、スキーマレス。つまり、あらかじめ定義された型にデータを登録するのではなく、さまざまな型のデータをそのまま登録していくことが可能です。

MongoDBでは、以下の概念でデータを操作します。

・DB (データベース)
・コレクション (Collection)
・ドキュメント (Document = Object)

「ドキュメント」と呼ばれる構造的データをJSONライクな形式で表現し、そのドキュメントの集合を「コレクション」として管理します(RDBのテーブルに対応)。コレクションはRDBMSのような固定的なスキーマを持ちません。ドキュメントには複雑な階層構造を持たせることもでき、それらの構造に含まれるフィールドを指定したクエリやインデクス生成も簡単な指定によって行えます。

RDBMSのように高度な結合操作を効率的に行うことはできませんが、データの追加・更新・削除・クエリは高速に行うことができます。

なお、MongoDBはスキーマを定義しなくてもよいのですが、パフォーマンス面を考えると、スキーマを定義することが多く、作りながらスキーマを定義・修正していくという柔軟な開発を可能とするデータベースといえます。

noSQLでありながら、多彩なクエリに対応

Mongoクエリ言語という、SQLライクな操作言語によりデータベースにアクセスします。

データ構造がDB -> コレクション -> Documentとなっていて、取り扱うDocumentデータがJSON形式のデータとはなりますが、JOINを除く、ほとんどのSQLを再現することができます。

また、変数・制御構造なども記述することができますので、集計等の高度なクエリも記述することが可能です。

[制御構造を使用した例]
MongoDBでは、JavaScriptの制御構造を使用することができます。たとえば、以下のようにforループでデータを挿入することができます。
for (var i = 1; i <= 20; i++) db.col1.insert( { x : 4 , j : i } )

レプリカセット: 高い可用性を実現できる仕組み

MongoDBは、マスタ/スレープ方式のレプリケーションに対応しています。簡単な仕組みで高可用性を実現することができます。

MongoDBではマスターのことをプライマリ，スレーブのことをセカンダリと呼びます。セカンダリは，プライマリのデータのコピーを保持します。レプリケーション構成としておけば、マスターノードに障害が起きても、自動フェイルオーバーの機能がありますので、データロストやサービス停止期間を最小にすることが可能です。MongoDBのレプリケーションの最小構成は，3つのノードが必要です。

また、レプリケーションを使用すれば，読み取り（Read）の負荷をノード間で分散させることができます。負荷のほとんどがReadで占められているようなアプリケーションの場合，Readの負荷をスレーブに分散させることによりシステムをスケールさせることが可能です。

オートシャーディング: DBデータを水平スケールさせる

シャーディングとは，データを複数のサーバに分散させる機能です。データを複数のサーバに分散させることにより，CPUやI/O負荷を分散させることが可能となります。

シャード:
実際にデータが格納されているmongodプロセス。1つのドキュメントは1つのシャードに格納され，シャード間でデータの複製は行わない

MongoDBのシャーディングはレンジパーティション方式を採用しています。シャードキーを指定することで，各サーバに格納されるデータの範囲が決定されます。サーバ間で重複データは持たず，1つのデータが格納されるサーバはシャードキーの範囲によって1つに決定されます。

キー範囲の調整と，調整に伴うサーバ間のデータの移動まで全部MongoDBが行う自動バランシングという機能を備えています。自動バランシングにより，サーバ間のデータの偏りをユーザが意識しなくてもよいように設計されています。また，新たにサーバを追加した場合も，同様にデータの移動を行い偏りがなくなるように自動調整します。

MongoDBを構成するコンポーネント

MongoDBは、マスタ/スレーブ方式のレプリケーション機能をもっていますが、MongoDBは自動フェイルオーバーを実装しており、マスタに障害が発生しても自動的にフェイルオーバーとリカバリが可能です。そのための構成要素として、MongoDBでは、マスターである「プライマリ」、フレーブである「セカンダリ」およびフェイルオーバーの際に新しいプライマリノードを選択する役割をはたす「アービター」というコンポーネントがあります。セカンダリは、プライマリのデータのコピーを保持し、アービターはデータのコピーは保持しません。自動的にフェイルオーバーするレプリカセットを構成するためには、最低でも三つのノードが必要となります。

プライマリ: レプリケーションのマスタ。データのマスタを保持

セカンダリ: レプリケーションのスレーブ。プライマリ上のデータのコピーを保持

アービター: 自動的にフェイルオーバーする際に新しいプライマリノードを選択

MongoDBのシャーディングはサーバ間のデータの移動を自動で行う自動バランシングの機能を備えていますが、そのデータ管理を行うために、configサーバとmongosサーバというコンポーネントがあります。

configサーバ:
シャーディングのメタデータを管理しているmongodプロセスです。単一障害点となるので，複数のconfigサーバで構成することが推奨されています。

mongosサーバ:
シャーディングにおけるルーティングプロセスです。シャードとクライアントを連携させます。必要があれば複数のmongosサーバをたてることが可能です。