在本书的第一部分和第二部分中,我们自底向上地把所有关于分布式数据库的主要考量都过了一遍。从数据在磁盘上的布局,一直到出现故障时分布式系统一致性的局限。但所有的讨论都假定了应用中只用了一种数据库。
现实世界中的数据系统往往更为复杂。大型应用程序经常需要以多种方式访问和处理数据,没有一个数据库可以同时满足所有这些不同的需求。因此应用程序通常组合使用多种组件:数据存储,索引,缓存,分析系统,等等,并实现在这些组件中移动数据的机制。
本书的最后一部分,会研究将多个不同数据系统(可能有着不同数据模型,并针对不同的访问模式进行优化)集成为一个协调一致的应用架构时,会遇到的问题。软件供应商经常会忽略这一方面的生态建设,并声称他们的产品能够满足你的所有需求。在现实世界中,集成不同的系统是实际应用中最重要的事情之一。
从高层次上看,存储和处理数据的系统可以分为两大类:
记录系统,也被称为真相源(source of truth),持有数据的权威版本。当新的数据进入时(例如,用户输入)首先会记录在这里。每个事实正正好好表示一次(表示通常是标准化的(normalized))。如果其他系统和记录系统之间存在任何差异,那么记录系统中的值是正确的(根据定义)。
衍生系统中的数据,通常是另一个系统中的现有数据以某种方式进行转换或处理的结果。如果丢失衍生数据,可以从原始来源重新创建。典型的例子是缓存(cache):如果数据在缓存中,就可以由缓存提供服务;如果缓存不包含所需数据,则降级由底层数据库提供。非规范化的值,索引和物化视图亦属此类。在推荐系统中,预测汇总数据通常衍生自用户日志。
从技术上讲,衍生数据是冗余的(redundant),因为它重复了已有的信息。但是衍生数据对于获得良好的只读查询性能通常是至关重要的。它通常是非规范化的。可以从单个源头衍生出多个不同的数据集,使你能从不同的“视角”洞察数据。
并不是所有的系统都在其架构中明确区分记录系统和衍生数据系统,但是这是一种有用的区分方式,因为它明确了系统中的数据流:系统的哪一部分具有哪些输入和哪些输出,以及它们如何相互依赖。
大多数数据库,存储引擎和查询语言,本质上既不是记录系统也不是衍生系统。数据库只是一个工具:如何使用它取决于你自己。记录系统和衍生数据系统之间的区别不在于工具,而在于应用程序中的使用方式。
通过梳理数据的派衍生关系,可以清楚地理解一个令人困惑的系统架构。这将贯穿本书的这一部分。
我们将从第十章开始,研究例如MapReduce这样**面向批处理(batch-oriented)的数据流系统。对于建设大规模数据系统,我们将看到,它们提供了优秀的工具和思想。第十一章将把这些思想应用到流式数据(data streams)**中,使我们能用更低的延迟完成同样的任务。第十二章将对本书进行总结,探讨如何使用这些工具来构建可靠,可扩展和可维护的应用。
上一章 | 目录 | 下一章 |
---|---|---|
第九章:一致性与共识 | 设计数据密集型应用 | 第十章:批处理 |