在本书的第一部分和第二部分,我们从头开始组装进入分布式数据库的所有主要因素,从磁盘的数据布局一直到出现故障时分布式一致性的极限。但是,这些讨论假定应用中只有一个数据库

实际上,数据系统通常更加复杂。在大型应用中你经常需要通过不同的方式获取和处理数据,没有单一的数据库可以满足所有不同的需求。应用因此使用多种存储产品的组合,比如数据存储,索引,缓存,分析系统等,并且实现从一个存储移动到另一个存储的机制

在本书的最后一部分,我们将围绕多个不同的数据系统(可能具有不同的数据模型,并针对不同的访问模式进行优化)集成到一个一致的应用程序体系结构中的问题。供应商常常忽略系统构建这一方面,他们声称产品可以满足您的所有需求。实际上,集成不同的系统是非平凡应用中最重要的事情之一。

记录系统和派生数据系统

在一个高层次上,存储和处理数据的系统可以被分为两个大类:

  • 记录系统(OLTP, Online Transaction Processing) 记录系统(也称为事实来源)保存数据的权威版本。当输入新数据时(例如,用户输入)首先写入记录系统。每个事实仅表示一次(通常已经标准化)。如果另一个系统与记录系统中的数据存在差异,以记录系统为准
  • 派生数据系统(OLAP, Online Analytical Processing) 派生系统中的数据是从另一个系统获取一些现有数据并以某种方式对其进行转换或处理的结果。如果丢失了派生数据,还可以重建。典型的例子就是缓存:可以从缓存中提供数据,但是如果缓存中没有需要的数据,可以使用基础数据库中的数据。非规范化的值,索引和实例化视图也属于此类。在推荐系统中,预测性摘要数据通常来自使用日志。

从技术上来讲,派生的数据是冗余的,是信息的复制。然而,会在查询时提供良好的性能。通常将其归一化。你可以从单一数据源派以不同角度生出不同的数据集

不是所有的系统在体系结构上对记录和派生系统又严格的区分,但是区分它们是有帮助的,因为可以梳理你的系统中的数据流:将系统中哪些是输入,哪些是输出,以及之间的依赖关系展示清楚

大多数数据库,存储引擎,和查询语言本身都不是记录或者派生系统。数据库仅仅是工具:如何使用取决于你。它们之间的区别不在于工具,而是你在应用中如何使用它们。

通过清楚地知道哪些数据是从其他数据中得出的,可以使得本来令人困惑的系统体系结构更清晰。这一点将贯穿本部分

章节概览

我们将在第 10 章讨论批处理数据流的系统,比如 MapReduce,并了解它们如何向我们提供了构建大型数据系统的工具和原理。在第 11 章,我们将采用这些思路来应用到数据流,这使得我们可以以较低的延迟来做到同样的事。第 12 章通过探讨如何使用这些工具来构建可靠,可扩展以及可维护的应用总结了本书。