NoSQLはRDBMS以外のデータ管理ソフトウェアの総称であるので、さまざまな種類が存在する。その1ではNoSQLを概要と用途に応じた種類の製品を選択すべきであると説明し、その2ではNoSQLの代表的な種類であるキー・バリュー型、カラム指向型の特徴を説明した。本稿では残りの代表的な種類であるドキュメント型とグラフ型の特徴を解説する。
ドキュメント型NoSQLは、JSON（JavaScript Object Notation）で記述されたドキュメントをデータとして管理することを目的としている。ドキュメント型の特徴を解説する前に、格納データであるJSONについて簡単に触れておく。JSONはXMLなどと同様のテキストベースのデータフォーマットある。Webでの動的なコンテンツ生成を行うAjaxでは、XMLが動的なWebコンテンツの生成のためのデータ交換フォーマットとして利用されていたが、現在では、より簡潔にデータを記述でき、JavaScriptとの親和性が高く、さらにJavaScript以外のさまざまなプログラミング言語でも利用可能なJSONがデータ交換の主流フォーマットとなっている。
ドキュメント型の代表的な製品としてはCouchDBやMongoDBなどがあるが、いずれも基本的にJSONのフォーマットに基づいたデータ構造を持っている。図1はMongoDBのデータ構造を表したものである。データベース内には1つ以上のコレクションが含まれており、コレクションには1つ以上のドキュメントが含まれている。ドキュメントには必ず一意のキーとフィールドを含んでおり、フィールドはフィールド名と値で構成される。RDBMSとの対比で考えてみた場合、コレクションはRDBMSのテーブルに相当し、ドキュメントは行に、そしてフィールドはカラムに相当する。しかし、RDBMSと異なるのは、各ドキュメントに含まれるフィールドの個数や内容は必ずしも同じ構成である必要はない。したがって、RDBMSのように事前にカラムを定義する必要はなく、データ構造を意識せずにデータを格納することが可能なスキーマレス構造となっている。
文章データやWebコンテンツのように、必ずしも構造化されていないデータを取り扱う場合、このスキーマレス構造はデータを格納する上での自由度が高いということが、RDBMSに比べて大きな利点となる。
また、同じドキュメント型でも製品によって適合する要件が異なり、例えばCouchDBでは、CAP定理データでのAP型（可用性と分断耐性を重視）に属し、MongoDBはCP型（一貫性と分断耐性を重視）に属している（ITR Insight 2015年冬号「ビッグデータ活用を推進させる次世代データ管理基盤とは」#I-315013）。したがって、CouchDBは複数のマスタが互いに同じデータを保持するマスタ・マスタ型の構造を採用することで可用性を維持しているが、その反面、データ整合性を保証していない。一方、一貫性を重視するMongoDBは、マスタ・スレーブ型を採用し、書き込みは常にマスタのみに行われるため、強い整合性を得ることが可能である。
MongoDBは「コレクション」というRDBMSのテーブルに相当する2次元データ構造を持ち、SQLとは異なるがSQLエンジニアが比較的理解しやすいコマンドベースのデータ検索言語をもっている。一方、CouchDBには「コレクション」はなく、データベースは複数のドキュメントが含まれるというよりシンプルな構造であり、Viewと呼ばれる検索機能もMapReduceの考え方に従ってJavascriptを記述する方式となっている。このように同じドキュメント型の製品であっても、製品ごとの機能や特性の違いが大きい。したがって、同じ形式のNoSQLであっても製品ごとの機能や特性を十分理解しておかなければ、十分な利点を享受できないということに注意が必要である。