在Learning网站看到一段关于NoSQL的详细论述，感觉很好，这里总结分享出来。
NoSQL 是一个相当宽泛的术语，仅表示非关系。 NoSQL（非关系）数据库通常分为四个类别：键值存储、文档数据库、列系列数据库和图形数据库。 以下各节讨论这些类型的 NoSQL 数据库。
类别一：键值存储
键值存储是用于插入和查询数据的最简单（通常也是最快）的 NoSQL 数据库类型。 键值存储中的每个数据项都有两个元素：一个键和一个值。 键唯一标识项，而值保存项的数据。 值对数据库管理系统是不透明的。 项按键顺序进行存储。“不透明”表示数据库管理系统仅将值视为非结构化块。 只有应用程序可识别值中的数据结构以及其包含的字段。 与“不透明”相反的是“透明”。 如果数据是透明的，则数据库管理系统可识别字段在数据中的组织方式。 关系表是透明结构的示例。
写入操作仅限于插入和删除。 如果需要更新项，则必须检索该项，在内存中（在应用程序中）对其进行修改，然后将其写回到数据库，覆盖原始项（实际上是删除和插入）。键值存储的重点是能够非常快速地读取和写入数据。 搜索功能是次要的。 当大量数据以连续流的形式到达且必须立即存储时，键值存储是数据引入的极佳选择。
类别二：文档数据库
在文档数据库中，每个文档都有唯一的 ID，但文档中的字段对数据库管理系统是透明的。文档数据库通常以 JSON 格式存储数据，也可使用其他格式（例如 XML、YAML、JSON、BSON）对其进行编码。 文档甚至可以存储为纯文本。 文档中的字段向存储管理系统公开，使应用程序能够使用这些字段中的值查询和筛选数据。
通常，文档包含实体的全部数据。 构成实体的项特定于应用程序。 例如，实体可以包含客户、订单或两者组合的详细信息。 单个文档可能包含在 RDBMS（关系数据库管理系统）中跨多个关系表的信息。
文档存储不要求所有文档都具有相同的结构。 这种自由格式的方法提供很大的灵活性。 随着业务需求的变化，应用程序可在文档中存储不同的数据。
应用程序可以使用文档键来检索文档。 键是文档的唯一标识符。 一些文档数据库会自动创建文档键。 另一些文档数据库可指定要用作键的文档的属性。 应用程序还可根据一个或多个字段的值来查询文档。 一些文档数据库支持索引编制，以便基于一个或多个索引字段快速查找文档。
一些文档数据库管理系统支持就地更新，使应用程序能够在不重写整个文档的情况下修改文档中特定字段的值。 另一些文档数据库管理系统（如 Cosmos DB）只能读取和写入整个文档。 在这些情况下，更新会用新版本替换整个文档。 这种方法有助于减少数据库中的碎片，从而可以提高性能。
与关系数据库相比，大多数文档数据库将更快地引入大量数据，但对于此类处理来说，并不如键值存储那样理想。 文档数据库的重点是其查询功能。
类型三：列式数据库
列式数据库将数据组织成行和列。 此结构的示例包括 ORC 和 Parquet 文件。在最简单的形式中，列式数据库至少在概念上与关系数据库非常相似。 列式数据库的真正强大之处在于其构造稀疏数据的非规范化方法。
例如，如果需要在关系数据库中存储有关客户及其地址的信息，则可以设计类似于下面所示的架构。 此图还显示了一些示例数据。 在此示例中，客户 1 和客户 3 共享同一地址，且架构确保此地址信息不重复。 这是实现一对多关系的标准方法。
关系模型支持一种非常通用的方法来实现此类型的关系，但要查找任何给定客户的地址，应用程序需要运行联接两个表的查询。 如果这是应用程序执行的最常见的查询，则在存在大量请求且表本身很大的情况下，与执行此联接操作相关的开销会迅速增加。
列式数据库的目的是有效处理此类情况。 可以将列式数据库视为包含行和列的表格数据，但能将这些列分为称为列系列的组。 每个列系列包含一组逻辑上相关的列。 下图显示了构造与上一幅图像相同信息的方法，即通过使用列式数据库将数据分组为包含客户名称和地址信息的两个列系列。 在这种情况下，检索客户地址的查询可以提取的数据比相应关系数据库中所需的读取次数少；这些查询可以直接从 AddressInfo 列系列中提取数据。
上面的插图是概念性的而不是物理的，旨在显示数据的逻辑结构，而不是物理上的组织方式。 列式数据库中的每一行都包含一个键，可以使用此键来提取一行的数据。
在大多数列式数据库中，列系列是单独存储的。 在前面的示例中，CustomerInfo 列系列以简单的垂直分区形式保存在物理存储的一个区域中，而 AddressInfo 列系列则保存在另一区域中。 实际上应该根据列系列而不是行来考虑结构。 跨多个列式的单个实体的数据在每个列系列中都具有相同的行键。 作为前面所示的概念布局的替代方法，可以将显示的数据可视化为以下一对物理结构。
列式数据库管理系统使用得最广泛的是 Apache Cassandra。
（四）图形数据库
利用图形数据库可以存储实体，但主要侧重于这些实体之间的关系。 图形数据库存储两种类型的信息：可视为实体实例的节点以及指定节点间关系的边缘。 图形数据库的目的是使应用程序能够有效地执行遍历节点和边缘网络的查询，以及分析实体之间的关系。 下图显示了组织的人事数据库，其结构为图形。 实体是组织中的员工和部门，边缘表示汇报关系和员工所在的部门。 在此图中，边缘上的箭头表示关系的方向。
此类结构使查询变得简单，如“找到直接或间接为 Sarah 工作的所有员工”或“谁与 John 在同一部门工作？” 对于具有大量实体和关系的大型图形，可以很快速地执行非常复杂的分析，并且许多图形数据库都可提供查询语言，用于有效遍历关系网络。 通常可以在关系数据库中存储相同的信息，但查询此信息所需的 SQL 可能需要许多昂贵的递归联接操作和嵌套的子查询。
