NoSQLのデータストアは、もともと「Just Say No to SQL」という概念1980年代の抗薬物広告キャンペーン）、これらは（SQLベースの）リレーショナルデータベースの認識された限界への反応でした。これらの人々はSQLを嫌っているわけではありませんが、リレーショナルデータベースが設計されていない問題を解決することで四角いペグを丸穴に押し込むことに疲れていました。
<！リレーショナルデータベースは強力なツールですが、いくつかの種類のデータ（キーと値のペアやグラフなど）といくつかの使用パターン（非常に大規模なストレージなど）では、リレーショナルデータベースは、実用的です。また、大容量ストレージの場合、リレーショナル・データベースは、データベースのライセンス・コストとハードウェア・コストの両方で高価になる可能性があります。 （リレーショナルデータベースは、エンタープライズグレードのハードウェアで動作するように設計されています。）<！ - 2 - >
NoSQLの動きにより、クリエイティブプログラマーは、さまざまな種類の厄介なデータの格納と処理の問題に対して、数十のソリューションを開発しました。これらのNoSQLデータベースは、通常、クラスタリングによって大規模なスケーラビリティを提供し、高スループットと低遅延を実現するように設計されています。NoSQLの名前は、
カテゴリ のカテゴリに適合するデータベースの多くが（NoSQLのサポートではなく）SQLサポートを持っているため、誤解を招くことがあります。代わりにその名前を「SQLだけではない」と考えてください。 " <！今日のNoSQL製品は、その設計と目的に応じて4つの異なるカテゴリに分類できます。
Key-Valueストア：この提供は、スキーマを使用する必要はありません。これは、データが挿入される前にスキーマ（テーブル構造）を定義する必要があるリレーショナルデータベースとは対照的です。キー値ストアはスキーマを必要としないため、さまざまな形式でデータを格納することができます。キー値ストアでは、行は単純にキー（識別子）と値で構成されます。値は整数値から大きなバイナリデータ文字列までです。キーバリューストアの多くの実装は、AmazonのDynamoペーパーに基づいています。
-
列ファミリストア： 列が列ファミリにグループ化され、ディスクにまとめて格納されるデータベースがあります。
厳密に言えば、これらのデータベースの多くは、データを多次元ソートマップとして格納するGoogleのBigTableの論文に基づいているため、列指向ではありません。
-
ドキュメントストア： このサービスは、効率を向上させるために、同様にエンコードされ、フォーマットされたドキュメントのコレクションに依存しています。ドキュメントストアでは、コレクション内の個々のドキュメントにフィールドのサブセットのみを含めることができるため、必要なデータだけが格納されます。多くのフィールドにデータが格納されていない疎なデータセットの場合、スペースを大幅に節約できます。対照的に、リレーショナルデータベーステーブルの空の列はスペースを占有します。ドキュメントストアを使用すると、必要なフィールドのみが格納され、新しいフィールドを追加できるため、スキーマの柔軟性も可能になります。リレーショナルデータベースとは対照的に、テーブル構造はデータが格納される前に定義され、列の変更はデータセット全体に影響を与える退屈な作業です。
グラフデータベース：
-
ここでは、 グラフ構造
- エンティティ（頂点または節点）とそれらの関係（エッジ）の集合をお互いに示す表現を格納するデータベースがあります。これらの構造により、グラフデータベースは、既知のすべてのWebページ間のリンク関係など、複雑な構造を格納するのに非常に適しています。 （たとえば、個々のWebページはノードであり、それらをつなぐエッジはページ間のリンクです。）
-
もちろん、Googleはグラフ技術を駆使しており、PageRankを実行するためにPregelというグラフ処理エンジンを発明しましたアルゴリズム。 Hadoopのコミュニティには、HDFSに格納されたグラフを処理するために設計されたグラフ処理エンジンであるGiraph（Pregelの論文に基づく）というApacheプロジェクトがあります（これはPregelのホワイトペーパーです）。 Hadoopで利用可能なデータ格納および処理オプションは、多くの場合、ここにリストされているNoSQLカテゴリの実装です。これにより、利用可能なソリューションをよりよく評価し、Hadoopが従来のデータウェアハウスをどのように補完できるかを理解するのに役立ちます。
