数据密集型应用系统设计（2）

数据模型与查询语言

大多数应用程序是通过一层层叠加数据模型来构建的。例如：

1. 应用程序开发人员观测现实世界，通过对象或者数据结构，以及操作这些数据结构的API对其建模。这些数据结构往往特定于该应用。
2. 当需要存储这些数据结构时，可以采用通用数据模型（例如JSON或者XML文档、关系数据库中的表或者图）来表示。
3. 数据库工程师接着决定用何种内存、磁盘或者网络的字节格式来表示上述JSON/XML/关系/图形数据。数据表示需要支持多种方式的查询、搜索、操作和处理数据。
4. 在更下一层，硬件工程师需要考虑电流、光脉冲、磁场等表示字节。

NoSQL

直到现在，关系数据库依然支撑这互联网上的大多数内容，例如在线发布、论坛、社交网络、电子商务、游戏、SaaS等。

NoSQL数据库的驱动因素有：

1. 比关系数据库更好的扩展性需求，例如支持超大数据集或者超高写入吞吐量
2. 支持免费和开源软件
3. 关系模型不能很好地支持一些特定的查询操作
4. 对关系模型一些限制性感到沮丧，渴望更具有动态和表达力的数据模型

所谓混合持久化指的是将关系数据库和各类非关系数据库一起使用。

数据库历史

一些开发人员认为JSON模型减少了应用程序代码和存储层的阻抗失配，具有更好的局部性。

即使应用程序的初始版本非常适合采用无联结的文档模型，比如简历，随着应用支持越来越多的功能，数据也变得更加互联一体化。

最早的数据库采用的是层次模型，类似于文档数据库中的JSON模型，将所有的数据表示为嵌套的树，可以很好地支持一对多关系，但是支持多对多关系困难，而且不支持联结。

网络模型是层次模型的推广。在网络模型中，一个记录可能有多个父结点。记录之间的链接类似于指针，访问记录的唯一方式是选择一条始于根记录的路径，沿着相关链接依次访问。带来的问题是查询和更新数据库变得非常复杂且不灵活，修改访问路径非常困难且麻烦。

关系模型的一个核心要点是只需要构建一次查询优化器，然后所有使用该数据库的应用程序都可以从中获益。查询优化器自动决定了以何种顺序执行查询，以及使用哪些索引，实际上等价访问路径。

关系数据库与文档数据库现状

文档数据库具有模式灵活性，由于局部性带来较好的性能，对于某些应用来说，更接近应用程序所使用的数据结构。关系模型抢在联结操作，多对一和多对多关系表达简洁。

文档数据库的模式灵活性
模式灵活性有时被称作无模式，但是具有误导性，因为读数据的代码通常采用某种结构所以存在某种隐形模式，而不是由数据库强制执行。更准确的术语是读时模式（数据的结构是隐式的，只有在读取时才解释），与写时模式（关系数据库的传统方法之一，模式是显示的，数据库确保写入时必须遵守）对应。

查询的数据局部性
局部性优势适用需要同时访问文档大部份内容的场景。因此建议文档尽量小且避免写入时增加文档的大小。

融合
随着时间推移，关系数据库和文档数据库变得越来越接近或许代表数据模型可以互相补充。例如MySQL支持JSON，大多数关系数据库（除了MySQL）支持XML。

数据查询语言

SQL查询、Web查询：略

MapReduce查询
MapReduce是一种编程模型，用于在许多机器上批量处理海量数据。一些NoSQL存储系统支持有限的MapReduce方式在大量文档上执行只读查询。
MapReduce是一个介于声明式查询语言和命令式查询API之间的查询方式。它主要基于许多函数编程语言中的map和reduce函数。

例子 你每看到一个海洋动物都会在数据库中添加记录，现在你想生成一份报告，来说明每个月看到多少鲨鱼。

步骤

1. 过滤器声明式指定鲨鱼种类
2. 对于每一个匹配查询的文档，都会调用一次JavaScript的map函数，并将其设置为文档对象
3. map函数发射一个键值对，键是由年份月份组成的字符串，值代表观察的动物数量
4. map函数发射的键值按键分组，对于相同键的所有键值对，调用reduce函数
5. reduce函数将特定月份内所有观察到的动物数量相加
6. 最终的输入写入到集合中

图状数据模型

适合多对多数据的建模。

小结

文档数据库的目标用例是数据来自于自包含文档，且一个文档与其他文档关联很少。
图数据库的目标用例是所有数据都有可能互相关联。

文档数据库和图数据库的共同点是它们通常不会对存储的数据强加某个模式，这可以使应用程序更容易适应不断变化的需求。