NoSQL数据商店最初订阅的"只是对SQL表示否"(从20世纪80年代中的禁毒AD活动释放)，并且它们是对(SQL为基础的)关系数据库的感知局限性的反应。
这并不是说这些人讨厌SQL，但是他们厌倦了通过解决关系数据库没有设计的问题来迫使方形钉进入圆孔。

关系数据库是一个强大的工具，但对于某些类型的数据(如键值对，或者图形)以及一些使用模式(如非常大的尺度存储)，一个关系数据库只是不实用。
当涉及高批量存储时，关系数据库可能昂贵，无论是在数据库许可成本和硬件成本方面。
(关系数据库旨在使用企业级硬件。
)

因此，通过NoSQL运动，创意程序员为不同种类的棘手数据存储和处理问题开发了数十个解决方案。
这些NoSQL数据库通常通过聚类提供大量可扩展性，并且通常旨在实现高吞吐量和低延迟。

NoSQL名称有点误导，因为适合该类别的许多数据库都有SQL支持(而不是"NoSQL"支持)。
将其名称视为"不仅仅是SQL"。

今天可用的NoSQL产品可以分为四个不同的类别，基于他们的设计和目的：

• 键值存储：此产品提供了一种在不必使用架构的情况下存储任何类型的数据。这与关系数据库相比，我们需要在插入任何数据之前定义模式(表结构)。由于键值存储不需要模式，因此我们可以灵活地存储多种格式的数据。
  在键值存储中，一行仅由密钥(标识符)和值组成，该值可以是从整数值到大二进制数据字符串的任何内容。许多键值存储的实现基于亚马逊的Dynamo纸张。

• 列族商店：其中我们有数据库，其中列将列分成列族并在磁盘上存储在一起。
  严格来说，许多这些数据库不是面向列的，因为它们基于Google的BigTable纸张，将数据存储为多维分类地图。

• 文档存储：此产品依赖于类似编码和格式化文档的集合来提高效率。文档存储在集合中启用单个文档仅包含一个字段的子集，因此只存储所需的数据。对于稀疏数据集，许多字段通常不会填充，这可以转化为显着的节省空间。
  相比之下，关系数据库表中的空列确实占用空间。文档存储还支持架构灵活性，因为只存储所需的字段，可以添加新字段。同样，与关系数据库相比，表结构在存储数据之前定义为前面，更改列是影响整个数据集的繁琐任务。

• 图表数据库：在此处拥有存储图形结构的数据库 - 显示实体(顶点或者节点)的集合及其关系(边缘)的表示。这些结构使得Graph数据库非常适合存储复杂结构，如所有已知网页之间的链接关系。 (例如，单个网页是节点，连接它们的边缘是从一页到另一页的链接。)当然，谷歌全部是图形技术，并发明了一个名为PREGER的图形处理引擎来为其PageRank算法供电。 (是的，在Pregel上有一篇白皮书。)在Hadoop社区中，有一个名为Giraph(基于预注钢纸)的Apache项目，这是一个旨在处理存储在HDF中的图形的图形处理引擎。

Hadoop中可用的数据存储和处理选项位于此处列出的NoSQL类别的许多情况下。
这将更好地评估我们可以使用的解决方案，并查看Hadoop如何补充传统数据仓库。