Question

数据或逻辑的不变性是这两类大型系统（以及系统开发语言）的核心区别，如图 49 所示的两种“PD 模型” 6 ：

图 49　两种 “PD 模型”：数据或逻辑的不变性

函数式语言，例如 Erlang 和 MapReduce，主张第一种系统模型（另一种模型在后文中另作讨论），因此适宜于编写逻辑确定的系统。它使数据 D 穿过逻辑，形成 D’，这一过程是确定的；而由 D’与其他的、后续的逻辑构成的部分（子系统或领域），并不影响当前系统的确定性。

但是我们也可能会注意到，在网络上产生数据（例如发表博客或提交回复）时，数据是动态产生的；而当这些数据被收集起来之后，我们展示它们时数据却是静态的。简单地说，数据收集和规格化，与基于数据的应用程序开发看起来并不是一回事。在后者，即对于我们一般意义上的应用程序开发（而非数据处理），我们通常还是会选择第二种模型——让逻辑作用于数据。

而这一模型事实上并不简单。例如，即使我们的数据是确定的，但如果它本身是海量的、分布的、复杂结构的，又应当如何处理呢？仍以我们在上一小节讨论过的“搜索”为例，如果一个搜索引擎已经获得了数以亿计的网页，分布在不同物理位置的存储设备中，又如何能让一个关键字搜索快速得到响应呢？

首先，真正发生一个“按 Key 搜索”的行为时，事实上是不会到具体网页中去“逐字节查找”的。关于“Search Keys”与“Page Keys”的关系以及“Page Keys”与存储的部署关系，将涉及非常多的系统策略，在此我们不细讨论。我们这里只关注“如何发生查找逻辑”这一个问题。而这个问题的本质是：如果逻辑所需处理的数据是不可迁移的，那么逻辑可否迁移？例如，如果我们的“按 Key 搜索”行为可以被分拆为多个子处理，那么能否将这些子处理“送入到”数据所在的集群（Cluster）并完成运算呢？

传递逻辑而不是传输数据，是海量数据运算的另一个思路，而这一思路依赖的条件是：逻辑的子过程的分拆是可能的、可控的 7 。在类似 MapReduce 的方案中，Map/Reduce Jobs 的执行就具有类似的特点。也就是说，我们必须关注另一个事实：

语言选型与系统架构在“数据与逻辑的可变性”上是可以互为补充的。