Question

对这个问题的思考将数据处理带入了 NoSQL 数据库的领域。其中具有一定代表性的是 Key-Value 型的非关系型数据存储方案，即基于 Keys 的分布来存储数据项，这使得数据项在 Rows 维度上是无关系的。对于类似日志这样“天然存在 Rows 关系”的数据，Key-Value 的解决方案是分段/区存储，这其实是在规划阶段对数据进行了横向拆分，而这事实上又导致了小规模处理此类数据时的不便。

Key-Value 数据很好地从纵向规划的角度将大数据切分成多个数据簇。在这个过程中，Key-Value 是允许存在冗余开销的。对于关系型数据库来说，这类似于索引的存储开销。但正因为一笔数据在多个位置冗余，所以 Key-Value 面临同一数据的多点更新问题，这使得数据的 Update 周期变长。这一策略换取的收益是：通过一个单一入口获取信息变得迅速而简洁，并且可以用较小代价来应付多层 Key-Value 关系，而后者正是关系型数据库的弱项。

如果 SQL 是被视为一门语言（事实上它既是语言，也是一类数据库系统的称谓），那么 NoSQL 就是另一类与之本质上存有不同的语言的统称。SQL 的语言特性就是基于批量数据的提取与后续操作，它在定义上总是基于“一个数据子集”来思考的。与之相对照，NoSQL 却是基于“如果数据子集的获取是一个过程，那么这个过程本身是否可以被分布”来思考。

在 NoSQL 的思维方式中，数据是通过一大批获取过程、在一系列被分布的数据中“收集”而最终得到的一个结果集。在这一过程中，将“数据获取”分成多个逻辑以及多个匹配路径是必需的。NoSQL 的这一设问，正好与我们此前讨论的“是数据的拆分，还是逻辑的拆分”不谋而合。在 NoSQL 环境下，大数据将不再是一个中心，而是一个被提前规划、提取与规格化的“数据广场”。一个很好的比喻是这样的：关系型数据库将数据理解为矩阵化的养鸡场，而 NoSQL 环境下面对的数据环境则如同鸽子广场。要在这样的数据环境中实现运算，“从不同维度来规划、标识与筛选鸽子”将是数据处理者的责任，而不再是数据库厂商的“不传之秘”。

这些（既是负担，也是自由的）责任在 NoSQL 方案下仍然是通过语言来实现的，例如 MapReduce（如果我们把它看成是一种编程范式的话）。在这一模型下，Map 过程用于从一个数据系列中获得数据子集，而 Reduce 过程则将些子集再次规格化为新数据：如果还需要后续处理，则持续进行 Map/Reduce 以得到适合应用层处理的数据。这一设计思想是基于（比结构化编程范式）更为原始的数据流编程范式（Data flow programming paradigm），从本质上来说，这也是函数式的思维模式。这些对程序设计语言范式的考察揭示了大数据处理下的新思维体系与传统体系的差异。将 NoSQL 与 SQL 对比来看：

• NoSQL 代表对“数据可变”的理解，而 SQL 代表对“逻辑可变”的理解；
• NoSQL 认为逻辑（例如 MapReduce 的数据规格化过程）是不变的，应当让数据“流过”逻辑，进而得到数据某些方面的映像；而 SQL 认为数据（例如关系型数据的既定结构）是不可变的，应当让逻辑“作用于”数据，进而得到一个可呈现的观察。