key-value storeは、最も単純なデータモデルを提供し、その名前が示すとおりのものです。これは、キーでインデックス付けされた値を格納するストレージシステムです。キーによるクエリに制限され、値はopaqueであり、ストアはそれらについてanythingを知りません。これにより、非常に高速な読み取りおよび書き込み操作（単純なディスクアクセス）が可能になり、このモデルは一種の不揮発性キャッシュと見なされます（つまり、キーによる長寿命データへの高速アクセスが必要な場合に適しています）。
ドキュメント指向データベースは以前のモデルを拡張し、値は構造化形式（ドキュメント、つまり名前）で保存され、データベースはそれを理解できます。たとえば、ドキュメントはブログ投稿andコメントand非正規化された方法で保存されたタグ。データはtransparentなので、ストアはより多くの作業（ドキュメントのフィールドのインデックス付けなど）を実行でき、キーによるクエリに限定されません。私がほのめかしたように、そのようなデータベースは単一のクエリでページ全体のデータを取得することができ、コンテンツ指向のアプリケーションに非常に適しています（FacebookやAmazonのような大きなサイトがそういう理由です）。
他の種類のNoSQLデータベースには、列指向ストア、グラフデータベース、さらにはオブジェクトデータベースが含まれます。しかし、これは問題を超えています。
こちらもご覧ください
さて、私は過去1ヶ月ほど自分でNoSQLを調査してきました。私はそれが一般的に次のように述べられると思う
- KVストアは、キーに対して実際に保存されている値の内容を知りません
- ドキュメントベースでは、dbがドキュメント構造（ブログ投稿のタグなど）を認識しているため、値のコンテンツ内にセカンダリインデックスを定義できます。
- NoSQLソリューションにはそれぞれ、などの考慮すべき特定の機能があります。
- KVストアの特別なデータ型（例：左/右ポップ/プッシュのようなredisのセット）
- riakが言うように、クラスターを簡単にスケールアップ/ダウンします（まだ試していない...まだ）
- ヴォルデモートのようなプラグ可能なデータストア
- couchDB/couchappなどの組み込みWeb構成とWebアプリのサポート
文書指向データベース、または文書ストアは、半構造化データである文書指向情報を格納、取得、および管理するためのものです。キーバリューストアは、文書指向データベースを継承します。違いは、データの処理方法にあります。キーバリューストアでは、データはデータベースに対して本質的に不透明であると見なされますが、ドキュメント指向システムは、データベースエンジンがさらに最適化するために使用するメタデータを抽出するためにドキュメントの内部構造に依存します。
MOngoDbとCassandraの違いについて扱う場合。 MongoDBは、リレーショナルデータベースのように機能します。そのデータモデルは、トップレベルのデータベース、MySQLのテーブル（たとえば）のようなコレクション、およびMySQLの行のようなコレクションに含まれるドキュメントで構成されます。各ドキュメントにはフィールドと値があり、MySQLの列と値に似ています。フィールドは、単純なキー/値にすることができます。 {'name'： 'David Mytton'}ただし、他のドキュメントを含めることもできます。 {'name'：{'first'：David、 'last'： 'Mytton'}}。 In Cassandraドキュメントは「列」として知られ、実際には単一のキーと値にすぎません。例：{'key'： 'name'、 'value'： 'David Mytton'}。内部複製と一貫性のためのタイムスタンプフィールド値は単一の値でも、別の「列」を含むこともできます。これらの列は、キーによって参照される列の特定の値に基づいてデータを並べる列ファミリ内に存在します。
しかし、最上位にはキースペースがあり、これはMongoDBデータベースに似ています。