设计数据密集型应用（第二版）

• 作者：Martin Kleppmann
• 译者：冯若航 / Vonng 与 DDIA 中文翻译贡献者
• 原作：Designing Data-Intensive Applications, Second Edition

不懂数据库的全栈工程师不是好架构师。

—— 冯若航 / Vonng

本书从数据模型与存储引擎出发，逐步进入复制、分片、事务、一致性、批处理与流处理，最后回到技术责任与社会影响。它关注的不是某一款产品，而是设计、实现和评价现代数据系统时可以反复使用的思维框架。

第二版中文译文按原书十四章持续校订。在线版本提供章节树导航、稳定图表编号与交叉引用、全文搜索、顺序阅读、整书打印以及适合工具读取的 Markdown / llms.txt 输出。

阅读本书

• 从序言了解全书目标与结构。
• 打开完整目录按章、节或图表定位内容。
• 从第一章开始顺序阅读，并使用每页末尾的上一章 / 下一章导航。
• 使用顶部版本与语言菜单，在第二版、第一版及简繁中文之间切换。

出版与授权说明

本译文仅供学习研究参考，不追求任何经济利益，不得公开传播发行或用于商业用途。译者保留译文署名权，其他权利以原作者与出版社的主张为准。有能力阅读英文的读者请购买正版支持作者与出版社。

翻译校订与完整贡献记录见贡献者页面；发现内容或排版问题，可前往 GitHub 提交反馈。

序言

如果近几年从业于软件工程，特别是服务器端和后端系统开发，那么你很有可能已经被大量关于数据存储和处理的时髦词汇轰炸过了： NoSQL！大数据！Web-Scale！分片！最终一致性！ACID！CAP 定理！云服务！MapReduce！实时！

在最近十年中，我们看到了很多有趣的进展，关于数据库，分布式系统，以及在此基础上构建应用程序的方式。这些进展有着各种各样的驱动力：

• 谷歌、雅虎、亚马逊、脸书、领英、微软和推特等互联网公司正在和巨大的流量 / 数据打交道，这迫使他们去创造能有效应对如此规模的新工具。
• 企业需要变得敏捷，需要低成本地检验假设，需要通过缩短开发周期和保持数据模型的灵活性，快速地响应新的市场洞察。
• 免费和开源软件变得非常成功，在许多环境中比商业软件和定制软件更受欢迎。
• 处理器主频几乎没有增长，但是多核处理器已经成为标配，网络也越来越快。这意味着并行化程度只增不减。
• 即使你在一个小团队中工作，现在也可以构建分布在多台计算机甚至多个地理区域的系统，这要归功于譬如亚马逊网络服务（AWS）等基础设施即服务（IaaS）概念的践行者。
• 许多服务都要求高可用，因停电或维护导致的服务不可用，变得越来越难以接受。

数据密集型应用（data-intensive applications） 正在通过使用这些技术进步来推动可能性的边界。一个应用被称为 数据密集型 的，如果 数据是其主要挑战（数据量，数据复杂度或数据变化速度）—— 与之相对的是 计算密集型，即处理器速度是其瓶颈。

帮助数据密集型应用存储和处理数据的工具与技术，正迅速地适应这些变化。新型数据库系统（“NoSQL”）已经备受关注，而消息队列，缓存，搜索索引，批处理和流处理框架以及相关技术也非常重要。很多应用组合使用这些工具与技术。

这些生意盎然的时髦词汇体现出人们对新的可能性的热情，这是一件好事。但是作为软件工程师和架构师，如果要开发优秀的应用，我们还需要对各种层出不穷的技术及其利弊权衡有精准的技术理解。为了获得这种洞察，我们需要深挖时髦词汇背后的内容。

幸运的是，在技术迅速变化的背后总是存在一些持续成立的原则，无论你使用了特定工具的哪个版本。如果你理解了这些原则，就可以领会这些工具的适用场景，如何充分利用它们，以及如何避免其中的陷阱。这正是本书的初衷。

本书的目标是帮助你在飞速变化的数据处理和数据存储技术大观园中找到方向。本书并不是某个特定工具的教程，也不是一本充满枯燥理论的教科书。相反，我们将看到一些成功数据系统的样例：许多流行应用每天都要在生产中满足可伸缩性、性能、以及可靠性的要求，而这些技术构成了这些应用的基础。

我们将深入这些系统的内部，理清它们的关键算法，讨论背后的原则和它们必须做出的权衡。在这个过程中，我们将尝试寻找 思考 数据系统的有效方式 —— 不仅关于它们 如何 工作，还包括它们 为什么 以这种方式工作，以及哪些问题是我们需要问的。

阅读本书后，你能很好地决定哪种技术适合哪种用途，并了解如何将工具组合起来，为一个良好应用架构奠定基础。本书并不足以使你从头开始构建自己的数据库存储引擎，不过幸运的是这基本上很少有必要。你将获得对系统底层发生事情的敏锐直觉，这样你就有能力推理它们的行为，做出优秀的设计决策，并追踪任何可能出现的问题。

本书的目标读者

如果你开发的应用具有用于存储或处理数据的某种服务器 / 后端系统，而且使用网络（例如，Web 应用、移动应用或连接到互联网的传感器），那么本书就是为你准备的。

本书是为软件工程师，软件架构师，以及喜欢写代码的技术经理准备的。如果你需要对所从事系统的架构做出决策 —— 例如你需要选择解决某个特定问题的工具，并找出如何最好地使用这些工具，那么这本书对你尤有价值。但即使你无法选择你的工具，本书仍将帮助你更好地了解所使用工具的长处和短处。

你应当具有一些开发 Web 应用或网络服务的经验，且应当熟悉关系型数据库和 SQL。任何你了解的非关系型数据库和其他与数据相关工具都会有所帮助，但不是必需的。对常见网络协议如 TCP 和 HTTP 的大概理解是有帮助的。编程语言或框架的选择对阅读本书没有任何不同影响。

如果以下任意一条对你为真，你会发现这本书很有价值：

• 你想了解如何使数据系统可伸缩，例如，支持拥有数百万用户的 Web 或移动应用。
• 你需要提高应用程序的可用性（最大限度地减少停机时间），保持稳定运行。
• 你正在寻找使系统在长期运行过程易于维护的方法，即使系统规模增长，需求与技术也发生变化。
• 你对事物的运作方式有着天然的好奇心，并且希望知道一些主流网站和在线服务背后发生的事情。这本书打破了各种数据库和数据处理系统的内幕，探索这些系统设计中的智慧是非常有趣的。

有时在讨论可伸缩的数据系统时，人们会说：“你又不在谷歌或亚马逊，别操心可伸缩性了，直接上关系型数据库”。这个陈述有一定的道理：为了不必要的伸缩性而设计程序，不仅会浪费不必要的精力，并且可能会把你锁死在一个不灵活的设计中。实际上这是一种 “过早优化” 的形式。不过，选择合适的工具确实很重要，而不同的技术各有优缺点。我们将看到，关系数据库虽然很重要，但绝不是数据处理的终章。

本书涉及的领域

本书并不会尝试告诉读者如何安装或使用特定的软件包或 API，因为已经有大量文档给出了详细的使用说明。相反，我们会讨论数据系统的基础 —— 各种原则与利弊权衡，并探讨了不同产品所做出的不同设计决策。

在电子书中包含了在线资源全文的链接。所有链接在出版时都进行了验证，但不幸的是，由于网络的自然规律，链接往往会频繁地破损。如果你遇到链接断开的情况，或者正在阅读本书的打印副本，可以使用搜索引擎查找参考文献。对于学术论文，你可以在 Google 学术中搜索标题，查找可以公开获取的 PDF 文件。或者，你也可以在 https://github.com/ept/ddia-references 中找到所有的参考资料，我们在那儿维护最新的链接。

我们主要关注的是数据系统的 架构（architecture），以及它们被集成到数据密集型应用中的方式。本书没有足够的空间覆盖部署、运维、安全、管理等领域 —— 这些都是复杂而重要的主题，仅仅在本书中用粗略的注解讨论这些对它们很不公平。每个领域都值得用单独的书去讲。

本书中描述的许多技术都被涵盖在 大数据（Big Data） 这个时髦词的范畴中。然而 “大数据” 这个术语被滥用，缺乏明确定义，以至于在严肃的工程讨论中没有用处。这本书使用歧义更小的术语，如 “单节点” 之于 “分布式系统”，或 “在线 / 交互式系统” 之于 “离线 / 批处理系统”。

本书对 自由和开源软件（FOSS） 有一定偏好，因为阅读、修改和执行源码是了解某事物详细工作原理的好方法。开放的平台也可以降低供应商垄断的风险。然而在适当的情况下，我们也会讨论专利软件（闭源软件，软件即服务 SaaS，或一些在文献中描述过但未公开发行的公司内部软件）。

本书纲要

本书分为三部分：

1. 在 第一部分 中，我们会讨论设计数据密集型应用所赖的基本思想。我们从 第一章 开始，讨论我们实际要达到的目标：可靠性、可伸缩性和可维护性；我们该如何思考这些概念；以及如何实现它们。在 第二章 中，我们比较了几种不同的数据模型和查询语言，看看它们如何适用于不同的场景。在 第三章 中将讨论存储引擎：数据库如何在磁盘上摆放数据，以便能高效地再次找到它。第四章 转向数据编码（序列化），以及随时间演化的模式。

2. 在 第二部分 中，我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可伸缩性通常是必需的，但带来了各种独特的挑战。我们首先讨论复制（第五章）、分区 / 分片（第六章）和事务（第七章）。然后我们将探索关于分布式系统问题的更多细节（第八章），以及在分布式系统中实现一致性与共识意味着什么（第九章）。

3. 在 第三部分 中，我们讨论那些从其他数据集派生出一些数据集的系统。派生数据经常出现在异构系统中：当没有单个数据库可以把所有事情都做的很好时，应用需要集成几种不同的数据库、缓存、索引等。在 第十章 中我们将从一种派生数据的批处理方法开始，然后在此基础上建立在 第十一章 中讨论的流处理。最后，在 第十二章 中，我们将所有内容汇总，讨论在将来构建可靠、可伸缩和可维护的应用程序的方法。

参考文献与延伸阅读

本书中讨论的大部分内容已经在其它地方以某种形式出现过了 —— 会议演示文稿、研究论文、博客文章、代码、BUG 跟踪器、邮件列表以及工程习惯中。本书总结了不同来源资料中最重要的想法，并在文本中包含了指向原始文献的链接。如果你想更深入地探索一个领域，那么每章末尾的参考文献都是很好的资源，其中大部分可以免费在线获取。

O‘Reilly Safari

Safari (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals.

Members have access to thousands of books, training videos, Learning Paths, interac‐ tive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Pro‐ fessional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others.

For more information, please visit http://oreilly.com/safari.

联系我们

有关本书的评论和问题，请联系出版社：

O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938（美国或加拿大）
707-829-0515（国际或本地）
707-829-0104（传真）

我们为本书提供了网页，会在上面列出勘误、示例以及任何补充信息。你可以访问：http://bit.ly/designing-data-intensive-apps。

如需发表评论或提出技术问题，请发送邮件至：bookquestions@oreilly.com。

有关 O’Reilly 图书、课程、会议和新闻的更多信息，请访问：http://www.oreilly.com。

• Facebook: http://facebook.com/oreilly
• Twitter: http://twitter.com/oreillymedia
• YouTube: http://www.youtube.com/oreillymedia

致谢

本书融合了学术研究和工业实践的经验，融合并系统化了大量其他人的想法与知识。在计算领域，我们往往会被各种新鲜花样所吸引，但我认为前人完成的工作中，有太多值得我们学习的地方了。本书有 800 多处引用：文章、博客、讲座、文档等，对我来说这些都是宝贵的学习资源。我非常感谢这些材料的作者分享他们的知识。

我也从与人交流中学到了很多东西，很多人花费了宝贵的时间与我讨论想法并耐心解释。特别感谢 Joe Adler, Ross Anderson, Peter Bailis, Márton Balassi, Alastair Beresford, Mark Callaghan, Mat Clayton, Patrick Collison, Sean Cribbs, Shirshanka Das, Niklas Ekström, Stephan Ewen, Alan Fekete, Gyula Fóra, Camille Fournier, Andres Freund, John Garbutt, Seth Gilbert, Tom Haggett, Pat Hel‐ land, Joe Hellerstein, Jakob Homan, Heidi Howard, John Hugg, Julian Hyde, Conrad Irwin, Evan Jones, Flavio Junqueira, Jessica Kerr, Kyle Kingsbury, Jay Kreps, Carl Lerche, Nicolas Liochon, Steve Loughran, Lee Mallabone, Nathan Marz, Caitie McCaffrey, Josie McLellan, Christopher Meiklejohn, Ian Meyers, Neha Narkhede, Neha Narula, Cathy O’Neil, Onora O’Neill, Ludovic Orban, Zoran Perkov, Julia Powles, Chris Riccomini, Henry Robinson, David Rosenthal, Jennifer Rullmann, Matthew Sackman, Martin Scholl, Amit Sela, Gwen Shapira, Greg Spurrier, Sam Stokes, Ben Stopford, Tom Stuart, Diana Vasile, Rahul Vohra, Pete Warden, 以及 Brett Wooldridge.

更多人通过审阅草稿并提供反馈意见在本书的创作过程中做出了无价的贡献。我要特别感谢 Raul Agepati, Tyler Akidau, Mattias Andersson, Sasha Baranov, Veena Basavaraj, David Beyer, Jim Brikman, Paul Carey, Raul Castro Fernandez, Joseph Chow, Derek Elkins, Sam Elliott, Alexander Gallego, Mark Grover, Stu Halloway, Heidi Howard, Nicola Kleppmann, Stefan Kruppa, Bjorn Madsen, Sander Mak, Stefan Podkowinski, Phil Potter, Hamid Ramazani, Sam Stokes, 以及 Ben Summers。当然对于本书中的任何遗留错误或难以接受的见解，我都承担全部责任。

为了帮助这本书落地，并且耐心地处理我缓慢的写作和不寻常的要求，我要对编辑 Marie Beaugureau，Mike Loukides，Ann Spencer 和 O’Reilly 的所有团队表示感谢。我要感谢 Rachel Head 帮我找到了合适的术语。我要感谢 Alastair Beresford，Susan Goodhue，Neha Narkhede 和 Kevin Scott，在其他工作事务之外给了我充分地创作时间和自由。

特别感谢 Shabbir Diwan 和 Edie Freedman，他们非常用心地为各章配了地图。他们提出了不落俗套的灵感，创作了这些地图，美丽而引人入胜，真是太棒了。

最后我要表达对家人和朋友们的爱，没有他们，我将无法走完这个将近四年的写作历程。你们是最棒的。

I 数据系统基础

本书前五章介绍了数据系统底层的基础概念，无论是在单台机器上运行的单点数据系统，还是分布在多台机器上的分布式数据系统都适用。

1. 第一章 将介绍 数据系统架构中的利弊权衡。我们将讨论不同类型的数据系统（例如，分析型与事务型），以及它们在云环境中的运行方式。
2. 第二章 将介绍非功能性需求的定义。可靠性，可伸缩性和可维护性，这些词汇到底意味着什么？如何实现这些目标？
3. 第三章 将对几种不同的 数据模型和查询语言 进行比较。从程序员的角度看，这是数据库之间最明显的区别。不同的数据模型适用于不同的应用场景。
4. 第四章 将深入 存储引擎 内部，研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化，选择合适的存储引擎对系统性能有巨大影响。
5. 第五章 将对几种不同的 数据编码 进行比较。特别研究了这些格式在应用需求经常变化、模式需要随时间演变的环境中表现如何。

第二部分 将专门讨论在 分布式数据系统 中特有的问题。

1. 数据系统架构中的权衡

• 分析型与事务型系统
• 云服务与自托管
• 分布式与单节点系统
• 数据系统、法律与社会
• 总结

2. 定义非功能性需求

• 案例研究：社交网络首页时间线
• 描述性能
• 可靠性与容错
• 可伸缩性
• 可维护性
• 总结

3. 数据模型与查询语言

• 关系模型与文档模型
• 图数据模型
• 事件溯源与 CQRS
• 数据框、矩阵与数组
• 总结

4. 存储与检索

• OLTP 系统的存储与索引
• 分析型数据存储
• 多维索引与全文索引
• 总结

5. 编码与演化

• 编码数据的格式
• 数据流的模式
• 总结

1 数据系统架构中的权衡

没有解决方案，只有权衡取舍。[…] 你只能尽力做出最佳权衡，也只能期望如此。

Thomas Sowell，与 Fred Barnes 的访谈（2005 年）

如今，数据是许多应用开发的核心。随着 Web 应用、移动应用、软件即服务（SaaS）和云服务的普及，在共享的服务器端数据基础设施中存储众多用户的数据，已经司空见惯。用户活动、业务交易、设备和传感器产生的数据都需要保存下来，以供分析。用户与应用交互时，既会读取已存储的数据，也会产生更多数据。

少量数据可以在单台机器上存储和处理，通常比较容易应付。然而，随着数据量或查询速率增长，数据就需要分布到多台机器上，由此带来许多挑战。应用需求变得更加复杂之后，把所有数据放在一个系统里也不再够用，往往需要组合多个能力各异的存储或处理系统。

如果数据管理是开发应用时面临的主要挑战之一，我们就称这种应用为 数据密集型（data-intensive）应用 ¹。计算密集型（compute-intensive）系统的难点在于如何将某项极其庞大的计算并行化；而对数据密集型应用来说，我们通常更关心如何存储和处理海量数据、如何管理数据变更、如何在故障和并发面前保证一致性，以及如何维持服务的高可用性。

这类应用通常由一些标准构件搭建而成，它们提供各种常用功能。例如，许多应用都需要：

• 存储数据，以便自己或其他应用日后能够再次找到（数据库，database）
• 记住开销昂贵的操作结果，加快读取速度（缓存，cache）
• 允许用户按关键字搜索数据，或以各种方式过滤数据（搜索索引，search index）
• 在事件和数据变更发生后立即处理（流处理，stream processing）
• 定期处理累积的大批量数据（批处理，batch processing）

构建应用时，我们通常会选用几个软件系统或服务（例如数据库和 API），再用应用代码把它们拼接起来。如果你的用途恰好是这些数据系统原本就为之设计的，整个过程可能相当容易。

但是，随着应用要实现的目标越来越高，挑战也随之而来。数据库系统种类繁多，特性各异，适用目的也各不相同——该选择哪一种？缓存有不同的做法，搜索索引也有多种构建方式，诸如此类——该如何权衡？你必须判断哪些工具和方法最适合手头的任务；而当一项工作无法由单个工具独立完成时，把多个工具组合起来也可能很困难。

本书将帮助你决定采用哪些技术，以及如何组合这些技术。正如你将看到的，并不存在一种从根本上优于其他方案的做法；每种方案都有利有弊。本书会教你提出恰当的问题来评估和比较数据系统，从而找出最能满足特定应用需求的方案。

我们的旅程从当今组织使用数据的一些典型方式开始。这里的许多思想源自 企业软件（enterprise software），也就是大型组织（例如大公司和政府机构）的软件需求与工程实践。因为在过去，只有大型组织才拥有如此庞大的数据量，需要复杂的技术方案；只要数据量足够小，用电子表格保存就行了！不过近年来，小公司和初创企业管理海量数据、构建数据密集型系统，也已变得十分普遍。

数据系统的一项关键挑战是：不同的人需要用数据做截然不同的事情。在一家公司里，你和你的团队有自己的一套优先事项；另一个团队即使在处理同一份数据，也可能有完全不同的目标。而且，这些目标未必得到明确表达，因而很容易造成误解，并引发对正确方案的争论。

为了帮助你了解有哪些选择，本章将比较几组相对的概念，并探讨它们之间的权衡：

• 事务型系统与分析型系统有何区别（“分析型与事务型系统”）；
• 云服务与自托管系统各有哪些利弊（“云服务与自托管”）；
• 何时应当从单节点系统转向分布式系统（“分布式与单节点系统”）；以及
• 如何在业务需求与用户权利之间取得平衡（“数据系统、法律与社会”）。

此外，本章还会提供阅读本书其余部分所需的术语。

分析型与事务型系统

如果你在企业中从事数据系统工作，很可能会遇到几类与数据打交道的人。第一类是 后端工程师（backend engineer），负责构建处理数据读取和更新请求的服务。这些服务通常直接面向外部用户，或通过其他服务间接为外部用户提供功能（参见“微服务与无服务器”）；有时也只供组织内其他部门使用。

除了管理后端服务的团队，通常还有两类人需要访问组织的数据：业务分析师（business analyst）根据组织的活动生成报表，帮助管理层做出更好的决策，这就是 商业智能（BI）；数据科学家（data scientist）则从数据中寻找新的洞见，或者利用数据分析和机器学习/AI 构建面向用户的产品功能，例如电商网站上“购买了 X 的人也购买了 Y”的推荐、风险评分或垃圾邮件过滤等预测分析，以及搜索结果排名。

业务分析师和数据科学家使用的工具不同，工作方式也不同，但仍有一些共同之处：两者都要进行 分析（analytics），也就是查看用户和后端服务产生的数据，但通常不会修改这些数据（纠正错误或许除外）。他们可能会创建衍生数据集，以某种方式处理原始数据。由此形成了两类相互分离的系统——本书将始终沿用这种区分：

• 事务型系统（operational system）由创建数据的后端服务和数据基础设施组成，例如直接为外部用户提供服务。应用代码根据用户执行的操作，读取和修改数据库中的数据。
• 分析型系统（analytical system）服务于业务分析师和数据科学家。它们保存事务型系统数据的只读副本，并针对分析所需的数据处理方式进行优化。

正如下一节将要说明的，事务型系统与分析型系统往往有充分的理由彼此分离。随着这两类系统日趋成熟，又出现了两个专业角色：数据工程师（data engineer）与 分析工程师（analytics engineer）。数据工程师懂得如何集成事务型系统和分析型系统，并对组织的数据基础设施承担更广泛的责任 ³。分析工程师则对数据进行建模和转换，使其更便于组织内的业务分析师和数据科学家使用 ⁴。

许多工程师专攻事务型或分析型系统中的一类。不过，本书会同时涵盖两者，因为它们都在组织的数据生命周期中扮演重要角色。我们将深入探讨为内部和外部用户提供服务所需的数据基础设施，帮助你更好地与分界线另一侧的同事合作。

事务处理与分析的特征

在商业数据处理的早期，每次写入数据库通常都对应一笔 商业交易：完成一笔销售、向供应商下订单、发放员工工资，等等。后来，数据库的应用扩展到不涉及金钱往来的领域，事务（transaction）这个名称却沿用下来，用来指构成一个逻辑单元的一组读写操作。

尽管数据库开始处理形形色色的数据——社交媒体帖子、游戏中的操作、地址簿联系人，等等——基本访问模式仍与处理商业交易相似。事务型系统通常按某个键查找少量记录（称为 点查询，point query），再根据用户输入插入、更新或删除记录。由于这些应用具有交互性，这种访问模式称为 联机事务处理（OLTP）。

与此同时，数据库也越来越多地用于分析，而分析的访问模式与 OLTP 大相径庭。分析查询通常会扫描海量记录，计算计数、总和或平均值等聚合统计量，而不是把一条条记录返回给用户。例如，连锁超市的业务分析师可能想回答下面的问题：

• 我们每家商店在一月份的总收入是多少？
• 在我们最近的促销期间，我们比平时多卖出了多少香蕉？
• 哪个品牌的婴儿食品最常与 X 品牌尿布一起购买？

这类查询产生的报表是商业智能的重要依据，可以帮助管理层决定下一步行动。为了把这种数据库使用模式与事务处理区分开来，人们称之为 联机分析处理（OLAP）⁵。OLTP 与分析之间的界线并不总是泾渭分明，但表 1-1列出了二者的一些典型特征。

事务型系统一般不允许用户自行编写 SQL 查询并提交给数据库执行，否则用户可能读取或修改自己无权访问的数据。用户也可能写出执行开销很高的查询，影响其他用户使用数据库。因此，OLTP 系统主要执行写在应用代码中的一组固定查询，只在维护或排查故障时偶尔运行一次性自定义查询。分析数据库则不同：它通常允许用户自由手写任意 SQL 查询，也可以通过 Tableau、Looker 或 Microsoft Power BI 等数据可视化或仪表盘工具自动生成查询。

还有一类系统专为分析型负载（即聚合大量记录的查询）而设计，却嵌入在面向用户的产品中。这类用途称为 产品分析（product analytics）或 实时分析（real-time analytics），为此设计的系统包括 Pinot、Druid 和 ClickHouse ⁶。

数据仓库

起初，同一套数据库既用于事务处理，也用于分析查询。事实证明，SQL 在这方面非常灵活，两类查询都能胜任。不过到了 20 世纪 80 年代末和 90 年代初，企业开始不再使用 OLTP 系统进行分析，转而在一个独立的数据库系统上运行分析查询。这个独立的数据库称为 数据仓库（data warehouse）。

一家大型企业可能拥有几十乃至上百个联机事务处理系统：支撑面向客户的网站，控制实体店的销售终端（收银系统），跟踪仓库库存，规划车辆路线，管理供应商和员工，以及执行许多其他任务。每个系统都很复杂，都需要专门的团队维护，因此最终大多彼此独立运行。

通常不宜让业务分析师和数据科学家直接查询这些 OLTP 系统，原因有以下几点：

• 所需数据可能散落在多个事务型系统中，很难通过一条查询组合这些数据集；这个问题称为 数据孤岛（data silo）。
• 适合 OLTP 的模式和数据布局不太适合分析（参见“星型与雪花型：分析模式”）。
• 分析查询的开销可能很高；在 OLTP 数据库上运行它们，会影响其他用户的性能。
• 出于安全或合规方面的考虑，OLTP 系统可能位于一个不允许用户直接访问的独立网络中。

相比之下，数据仓库 是一个独立的数据库，分析师可以尽情查询，而不会影响 OLTP 系统的运行 ⁷。正如第 4 章将要介绍的，数据仓库的存储方式往往与 OLTP 数据库截然不同，以便针对分析中常见的查询类型进行优化。

数据仓库保存着企业各个 OLTP 系统中数据的只读副本。数据先从 OLTP 数据库中抽取出来（通过定期转储或连续的更新流），再转换成便于分析的模式并加以清理，最后载入数据仓库。把数据送入数据仓库的这一过程称为 提取—转换—加载（ETL），如图 1-1所示。有时也会对调 转换 与 加载 两步的顺序，即先加载数据，再在数据仓库内转换；这便成了 ELT。

有时，ETL 流程的数据源是外部 SaaS 产品，例如客户关系管理（CRM）、电子邮件营销或信用卡处理系统。此时，你无法直接访问原始数据库，只能通过软件供应商的 API 获取数据。把这些外部系统的数据导入自己的数据仓库，就能进行 SaaS API 本身无法支持的分析。针对 SaaS API 的 ETL，通常由 Fivetran、Singer 或 AirByte 等专业数据连接器服务实现。

有些数据库系统提供 混合事务/分析处理（HTAP），目标是在单个系统中同时支持 OLTP 和分析，无需通过 ETL 把数据从一个系统送入另一个系统 ^{8 9}。然而，许多 HTAP 系统内部仍由一个 OLTP 系统和一个独立的分析系统耦合而成，只是共同隐藏在统一接口之后。因此，要理解这类系统的工作原理，二者的区别依然重要。

此外，即使已有 HTAP，由于事务型系统和分析型系统的目标与需求不同，把它们分开依然很常见。特别是，每个事务型系统各自拥有数据库通常被视为良好实践（参见“微服务与无服务器”），这样可能产生数百个独立的事务型数据库；而企业通常只设一个数据仓库，以便业务分析师在一条查询中组合多个事务型系统的数据。

因此，HTAP 并不能取代数据仓库。它适合的是另一类场景：同一个应用既要运行扫描大量数据行的分析查询，又要低延迟地读取和更新单条记录。例如，欺诈检测就可能具有这样的工作负载 ¹⁰。

事务型系统与分析型系统的分离，体现了一种更广泛的趋势：随着工作负载要求越来越高，系统也日益专门化，针对特定负载进行优化。通用系统应付少量数据绰绰有余；但规模越大，系统往往越专门化 ¹¹。

从数据仓库到数据湖

数据仓库通常采用 关系 数据模型，并通过 SQL 查询（参见第 3 章），有时还会配合专门的商业智能软件。这种模型很适合业务分析师所需的查询，却不太适合数据科学家的需求；他们可能需要完成下面的工作：

• 把数据转换成适合训练机器学习模型的形式。这通常要把数据库表中的行列转换为数值向量或矩阵，其中的数值称为 特征（feature）。以尽可能提高训练后模型性能的方式完成这种转换，称为 特征工程（feature engineering）；它通常需要编写难以用 SQL 表达的定制代码。
• 对文本数据（例如商品评论）应用自然语言处理技术，尝试从中提取结构化信息（例如作者表达的情绪，或提到了哪些主题）。同样，他们也可能要用计算机视觉技术从照片中提取结构化信息。

尽管人们一直尝试为 SQL 数据模型加入机器学习算子 ¹²，也在关系模型的基础上构建高效的机器学习系统 ¹³，许多数据科学家仍不愿在数据仓库这样的关系数据库中工作。他们往往更喜欢 pandas、scikit-learn 等 Python 数据分析库，R 等统计分析语言，以及 Spark 等分布式分析框架 ¹⁴。我们将在“数据框、矩阵与数组”中进一步讨论这些工具。

因此，组织需要以适合数据科学家使用的形式提供数据。解决方案是 数据湖（data lake）：一个集中的数据存储库，保存一切可能对分析有用的数据副本，这些数据通过 ETL 流程从事务型系统取得。数据湖与数据仓库的区别在于，它只保存文件，并不强制规定文件格式或数据模型。数据湖中的文件可以是一批数据库记录，以 Avro 或 Parquet 等文件格式编码（参见第 5 章）；也完全可以是文本、图像、视频、传感器读数、稀疏矩阵、特征向量、基因组序列，或任何其他类型的数据 ¹⁵。数据湖不仅更加灵活，而且往往比关系数据存储更便宜，因为它可以使用对象存储等廉价通用的文件存储（参见“云原生系统架构”）。

ETL 流程已经泛化为 数据管道（data pipeline）；在某些情况下，数据湖成为事务型系统通往数据仓库途中的一站。数据湖以事务型系统产生的“原始”形态保存数据，不把它们转换成关系数据仓库的模式。这种做法的好处是，每个数据消费者都可以把原始数据转换成最适合自己需求的形式。它有一个诙谐的名字——寿司原则（sushi principle）：“原始数据更好”¹⁶。

除了把数据从数据湖载入独立的数据仓库，也可以直接针对数据湖中的文件运行典型的数据仓库工作负载（SQL 查询和业务分析），并与数据科学和机器学习工作负载并存。这种架构称为 数据湖仓（data lakehouse）；它需要在数据湖的文件存储之上增加查询执行引擎和元数据层（例如模式管理）¹⁷。

Apache Hive、Spark SQL、Presto 和 Trino 都采用了这种方法。

超越数据湖

随着分析实践日益成熟，组织也越来越重视分析系统与数据管道的管理和运维，例如 DataOps 宣言就体现了这种趋势 ¹⁸。其中包括治理、隐私，以及遵守 GDPR、CCPA 等法规的问题；我们将在“数据系统、法律与社会”和“立法与自律”中讨论这些问题。

此外，分析数据的提供形式越来越多，不仅包括文件和关系表，还包括事件流（参见第 12 章）。采用基于文件的分析时，可以定期（例如每天）重新运行分析，以响应数据的变化；流处理则能让分析系统快得多，通常在几秒内便对事件作出响应。具体是否值得采用流处理，要看应用对时效性的要求。例如，它可以用来识别并阻止潜在的欺诈或滥用活动。

有时，分析系统的输出还会提供给事务型系统，这个过程有时称为 反向 ETL（reverse ETL）¹⁹。例如，在分析系统中训练好的机器学习模型可以部署到生产环境，向最终用户生成“购买了 X 的人也购买了 Y”之类的推荐。分析系统中这类投入实际应用的输出也称为 数据产品（data product）²⁰。机器学习模型可以借助 TFX、Kubeflow 或 MLflow 等专用工具部署到事务型系统。

权威记录系统与衍生数据

除了区分事务型系统与分析型系统，本书还区分 权威记录系统（system of record）与 衍生数据系统（derived data system）。这组术语很有用，可以帮助你理清数据在系统中的流向：

权威记录系统

权威记录系统也称 权威数据源（source of truth），保存某类数据的权威或 规范（canonical）版本。新数据到来时，例如用户输入，首先写入这里。每项事实只表示一次，通常采用 规范化（normalized）表示（参见“规范化、反规范化与连接”）。如果其他系统与权威记录系统的数据不一致，那么按照定义，应以权威记录系统中的值为准。

衍生数据系统

衍生系统中的数据，是以另一个系统中的现有数据为基础，经过某种转换或处理而得到的结果。衍生数据即使丢失，也可以从原始数据源重新创建。缓存就是一个典型例子：若数据在缓存中，便可直接返回；若缓存中没有所需数据，则可以退回底层数据库读取。反规范化值、索引、物化视图、转换后的数据表示，以及在数据集上训练的模型，也都属于这一类。

从技术上讲，衍生数据是 冗余（redundant）的，因为它复制了现有信息。但是，要让读查询获得良好性能，这种冗余往往不可或缺。你可以从同一个数据源衍生出多个不同的数据集，从不同“视角”观察数据。

分析型系统通常属于衍生数据系统，因为它们消费的是在别处创建的数据。事务型服务则可能同时包含权威记录系统和衍生数据系统：权威记录系统是数据首先写入的主数据库，衍生数据系统则是加快常见读取操作的索引和缓存，尤其适用于权威记录系统无法高效回答的查询。

大多数数据库、存储引擎和查询语言，本身并不天然是权威记录系统或衍生系统。数据库只是工具，如何使用由你决定。一个系统究竟属于哪一类，取决于它在应用中的用法，而不是采用了什么工具。明确哪些数据衍生自哪些其他数据，可以让原本令人困惑的系统架构变得清晰。

如果一个系统的数据衍生自另一个系统，那么每当权威记录系统中的原始数据发生变化，就需要有相应流程更新衍生数据。遗憾的是，许多数据库在设计时都假定应用只会使用这一个数据库，因而很难集成多个系统并传播这类更新。我们将在“数据集成”中讨论 数据集成（data integration）的各种方法；借助这些方法，可以组合多个数据系统，完成单个系统无法独力完成的任务。

至此，我们对分析与事务处理的比较告一段落。下一节要讨论的另一项权衡，你可能已经见过许多人反复争论。

云服务与自托管

无论组织要做什么，最先遇到的问题之一总是：应当由内部完成，还是外包出去？应当自建，还是购买？

归根结底，这取决于业务的优先事项。管理学中通常认为，属于组织核心能力或竞争优势的事情应当在内部完成；非核心、例行或司空见惯的事情则应交给供应商 ²¹。举一个极端的例子：大多数公司都不会自行发电（能源公司除外，这里也不考虑应急备用电源），因为从电网购电更加便宜。

对软件来说，有两个重要决定：由谁来构建，又由谁来部署。两项工作都可以按不同程度外包，从而形成图 1-2所示的一条连续谱。一个极端是完全定制的软件，由你自行编写并在内部运行；另一个极端是广泛使用的云服务或软件即服务（SaaS）产品，由外部供应商开发和运维，你只能通过 Web 界面或 API 使用。

这条连续谱的中间，是由你 自托管（self-hosted）的现成软件（可以是开源软件，也可以是商业软件），也就是由你亲自部署。例如，下载 MySQL 并安装到一台由你掌控的服务器上。这台服务器可以是你自己的硬件——通常称为 本地部署（on-premises），即使它实际位于租用的数据中心机架里，并不真的在你的自有场所——也可以是云中的虚拟机，即 基础设施即服务（IaaS）。这条连续谱上还有更多中间位置，例如采用开源软件，但运行自己修改过的版本。

与这条连续谱相互独立的另一个问题是：无论在云端还是本地，究竟要 如何 部署服务，例如是否采用 Kubernetes 之类的编排框架。不过，部署工具的选择不在本书讨论范围内，因为还有其他因素对数据系统架构的影响更大。

云服务的利弊

使用云服务而不是自行运行同类软件，本质上就是把软件的运维外包给云服务商。采用云服务既有充分的支持理由，也有充分的反对理由。云服务商声称，与自建基础设施相比，使用它们的服务能够节省时间和金钱，还能让你行动得更快。

云服务究竟是否比自托管更便宜、更省事，很大程度上取决于你掌握的技能和系统承受的工作负载。如果你已经熟悉所需系统的部署和运维，而且负载相当容易预测（也就是所需机器数量不会剧烈波动），那么购买自己的机器并自行运行软件，往往更加便宜 ^{22 23}。

反过来，如果你需要一个自己还不会部署和运维的系统，那么采用云服务，通常比从头学习如何自行管理更加容易、快捷。如果还必须专门招聘和培训人员来维护、运维这个系统，成本可能会非常高。使用云服务时仍然需要运维团队（参见“云时代的运维”），但把基础系统管理外包出去，可以让团队专注于更高层次的问题。

把系统运维外包给专门经营这项服务的公司，也可能得到更好的服务，因为供应商在服务众多客户的过程中积累了丰富的运维经验。另一方面，如果由你自行运维，就能针对自己的特定工作负载配置和调优服务；云服务商不太可能愿意为你进行这样的定制。

如果系统负载随时间大幅波动，云服务尤其有价值。假如机器按峰值负载配置，但计算资源在大多数时候都处于闲置状态，系统的成本效益就会很差。在这种情况下，云服务的优势在于，可以更加容易地随着需求变化增加或减少计算资源。

例如，分析型系统的负载通常变化极大：要快速执行一项大型分析查询，需要同时动用大量计算资源；但查询完成后，这些资源就会闲置，直到用户发出下一项查询。预定义查询（例如日报）可以排队并调度执行，从而平滑负载；但对交互式查询而言，越是希望迅速得到结果，工作负载的波动就越大。如果数据集庞大到必须投入大量计算资源才能快速查询，使用云服务可以节省成本，因为闲置资源可以归还服务商，而不必任其空置。数据集较小时，这种差别就没那么显著。

云服务最大的缺点是你无法掌控它：

• 如果服务缺少你需要的功能，你只能客气地询问供应商是否愿意添加；通常无法自己动手实现。
• 如果服务宕机，你只能等它恢复。
• 如果你的某种使用方式触发了缺陷或性能问题，诊断起来会非常困难。对于自行运行的软件，你可以从操作系统获取性能指标和调试信息，从而了解它的行为，还可以查看服务器日志；但服务由供应商托管时，你通常无法接触这些内部信息。
• 如果服务停止运营、价格高到无法接受，或供应商以你不喜欢的方式改动产品，你也只能任其摆布——继续运行旧版本通常不可行，因此只能被迫迁移到其他服务 ²⁴。如果存在提供兼容 API 的替代服务，这种风险会小一些；但是许多云服务并没有标准 API，切换成本很高，因而产生了供应商锁定问题。
• 你必须相信云服务商能够保护数据安全，这会增加遵守隐私和安全法规的难度。

尽管存在这些风险，组织在云服务之上构建新应用，或者采用只在系统某些部分使用云服务的混合方案，还是越来越普遍。不过，云服务不会取代所有内部数据系统：许多老系统诞生在云计算之前；只要某项服务有现有云服务无法满足的特殊需求，内部系统仍然不可或缺。例如，高频交易等对延迟极其敏感的应用，就需要完全掌控硬件。

云原生系统架构

云计算不仅采用了不同的经济模式——订阅服务，而不是购买硬件和软件许可证，再自行运行软件——它的兴起也从技术层面深刻影响了数据系统的实现方式。云原生（cloud-native）一词用来描述专为利用云服务优势而设计的架构。

原则上，几乎任何可以自托管的软件都能以云服务的形式提供；事实上，许多流行的数据系统如今都有相应的托管服务。然而，从一开始就按云原生思路设计的系统已经展现出若干优势：在相同硬件上性能更好，故障恢复更快，能够迅速调整计算资源以匹配负载，并且可以支持更大的数据集 ^{25 26 27}。表 1-2列出了两类系统的一些例子。

云服务的分层

许多自托管数据系统对运行环境的要求非常简单：在 Linux 或 Windows 等常规操作系统上运行，把数据存成文件系统中的文件，并通过 TCP/IP 等标准网络协议通信。少数系统依赖 GPU（用于机器学习）或 RDMA 网卡等特殊硬件，但总体而言，自托管软件使用的都是十分通用的计算资源：CPU、内存、文件系统和 IP 网络。

在云中，这类软件可以运行在基础设施即服务（IaaS）环境里，使用一台或多台虚拟机（也称为 实例，instance），每台实例分配一定数量的 CPU、内存、磁盘和网络带宽。与物理机器相比，云实例的开通速度更快，可选规格也更多；但除此之外，它们与传统计算机相似：你可以随意运行任何软件，也要自行负责管理。

与之相对，云原生服务的关键思想是：不仅使用操作系统管理的计算资源，还要在低层云服务的基础上构建更高层的服务。例如：

• Amazon S3、Azure Blob Storage 和 Cloudflare R2 等 对象存储（object storage）服务用于保存大型文件。它们的 API 比普通文件系统更受限，只提供基本的文件读写；但好处是隐藏了底层物理机器。服务会自动把数据分布到许多机器上，你不必担心其中某台机器的磁盘空间耗尽。即使某些机器或其磁盘彻底损坏，数据也不会丢失。
• 许多其他服务又建立在对象存储和其他云服务之上。例如，Snowflake 是一种云端分析数据库（数据仓库），依靠 S3 存储数据 ²⁷；还有一些服务进一步构建在 Snowflake 之上。

计算机领域的抽象一向如此：该选择哪一层，并没有唯一正确的答案。一般来说，层次越高的抽象，往往越面向特定用例。如果你的需求恰好符合某个高层系统的设计场景，那么直接使用现成系统，通常比自己用低层系统搭建省心得多，也足以满足需要。反过来，如果没有任何高层系统符合需求，那就只能用低层组件自行构建。

存储与计算的分离

在传统计算中，磁盘存储被视为持久存储：我们假定数据一旦写入磁盘，就不会丢失。为了容忍单块硬盘故障，人们通常使用 RAID（独立磁盘冗余阵列），在连接到同一台机器的多块磁盘上保存数据副本。RAID 既可以由硬件实现，也可以由操作系统通过软件实现；对于访问文件系统的应用来说，这一切都是透明的。

云中的计算实例（虚拟机）也可以连接本地磁盘，但云原生系统通常更愿意把它们当作临时缓存，而不是长期存储。原因在于：一旦相应实例发生故障，本地磁盘就无法访问；为了适应负载变化而把实例换成另一台物理机上的更大或更小规格时，本地磁盘同样无法访问。

作为本地磁盘的替代方案，云服务还提供虚拟磁盘存储，可以从一个实例卸载，再挂载到另一个实例上，例如 Amazon EBS、Azure 托管磁盘和 Google Cloud 持久磁盘。这种虚拟磁盘并不是真正的物理磁盘，而是由另一组机器提供的云服务，用来模拟磁盘的行为——也就是 块设备（block device），其中每个块通常为 4 KiB。这项技术让传统的磁盘软件可以在云中运行，但块设备模拟会引入额外开销；如果系统从一开始便针对云设计，这些开销本来可以避免 ²⁵。它还使应用对网络异常极为敏感，因为虚拟块设备上的每次 I/O 实际上都是一次网络调用 ²⁸。

为了解决这个问题，云原生服务通常避开虚拟磁盘，转而建立在针对特定工作负载优化的专用存储服务之上。S3 等对象存储服务适合长期保存较大的文件，大小从数百 KB 到数 GB 不等。数据库中的单行或单个值通常远小于这个范围；因此，云数据库通常在一个独立服务中管理较小的值，并把包含许多个值的较大数据块存入对象存储 ^{26 29}。我们将在第 4 章介绍相应的实现方法。

在传统系统架构中，同一台计算机同时负责存储（磁盘）和计算（CPU 与内存）；而在云原生系统中，这两项职责在一定程度上相互分离，或者说被 解耦（decoupled）了 ^{9 27 30 31}。例如，S3 只负责保存文件；如果要分析其中的数据，就必须在 S3 之外运行分析代码。这也意味着数据需要通过网络传输，我们将在“分布式与单节点系统”中进一步讨论。

此外，云原生系统往往采用 多租户（multitenant）模式：它并不为每个客户单独分配一台机器，而是由同一项服务在共享硬件上处理多个客户的数据和计算 ³²。

多租户可以提高硬件利用率，更容易实现可伸缩性，也便于云服务商管理；但要保证一个客户的活动不影响其他客户的性能或安全，就必须经过周密的工程设计 ³³。

云时代的运维

传统上，管理组织服务器端数据基础设施的人员称为 数据库管理员（DBA）或 系统管理员（sysadmin）。近年来，许多组织尝试把软件开发与运维角色融入同一个团队，让团队共同负责后端服务和数据基础设施；DevOps 理念推动了这一趋势。站点可靠性工程师（SRE）则是 Google 对这一理念的实践 ³⁴。

运维的职责是确保服务可靠地交付给用户，包括配置基础设施和部署应用；同时保障生产环境稳定，包括监控和诊断任何可能影响可靠性的问题。对自托管系统来说，传统运维有大量工作落在单台机器上，例如容量规划（监控可用磁盘空间，并在耗尽前增加磁盘）、开通新机器、在机器之间迁移服务，以及安装操作系统补丁。

许多云服务通过 API 隐藏了实际承载服务的一台台机器。例如，云存储不再提供固定容量的磁盘，而是采用 按量计费（metered billing）：你无需提前规划容量，就可以存储数据，然后按实际占用的空间付费。此外，即使个别机器发生故障，许多云服务仍然保持高可用性（参见“可靠性与容错”）。

关注点从单台机器转向服务，也伴随着运维角色的变化。可靠地提供服务这一高层目标没有改变，但流程和工具已经演变。DevOps/SRE 理念更强调：

• 自动化——采用可重复的流程，而不是手工执行一次性任务；
• 采用临时性的虚拟机和服务，而不是长时间运行的服务器；
• 支持频繁更新应用；
• 从事故中吸取教训；以及
• 即使人员来去更替，也要保留组织对系统的知识 ³⁵。

随着云服务兴起，运维角色也发生了分化：基础设施公司的运维团队专攻如何面向大量客户提供可靠服务；云服务客户则力求把投入基础设施的时间和精力降到最低 ³⁶。

云服务的客户仍然需要运维，只是关注的方面有所不同，例如为一项任务选择最合适的服务、集成不同服务，以及从一项服务迁移到另一项服务。尽管按量计费消除了传统意义上的容量规划，你依然必须清楚哪些资源被用在什么地方，免得为并不需要的云资源白白花钱：容量规划变成了财务规划，性能优化变成了成本优化 ³⁷。

而且，云服务仍有资源上限或 配额（quota），例如并发运行的进程数上限。你必须提前了解并做好规划，不能等到撞上限额才处理 ³⁸。

采用云服务或许比自行运行基础设施更加容易、快捷，但学习如何使用仍有成本，有时还得设法绕过它的限制。随着供应商越来越多，面向各种用例的云服务层出不穷，如何集成不同服务成了一项格外棘手的挑战 ^{39 40}。

ETL（参见“数据仓库”）只是其中一部分，事务型云服务同样需要彼此集成。目前还缺少简化这类集成的标准，因此往往要投入大量手工工作。

还有一些运维工作无法完全外包给云服务，例如维护应用及其依赖库的安全，管理自有服务之间的交互，监控服务负载，以及追查性能下降或服务中断等问题的根源。云计算固然正在改变运维的角色，但运维仍与以往任何时候一样重要。

分布式与单节点系统

由多台机器通过网络通信而构成的系统，称为 分布式系统（distributed system）。参与分布式系统的每个进程称为一个 节点（node）。采用分布式系统可能出于以下各种原因：

固有的分布式系统

如果一项应用涉及两个或更多相互交互的用户，而每个用户都使用自己的设备，那么这个系统不可避免地是分布式的：设备之间只能通过网络通信。

云服务之间的请求

如果数据存储在一个服务中，却要由另一个服务处理，就必须通过网络把数据从一个服务传到另一个服务。

容错/高可用性

如果应用需要在一台机器（乃至多台机器、网络或整个数据中心）发生故障时继续运行，可以用多台机器提供冗余：一台发生故障后，由另一台接管。参见“可靠性与容错”以及第 6 章关于复制的讨论。

可伸缩性

如果数据量或计算需求增长到单台机器无力承担，或许可以把负载分散到多台机器上。参见“可伸缩性”。

延迟

如果用户遍布世界各地，你可能希望在全球多个区域部署服务器，让每个用户都由地理位置较近的服务器提供服务。这样一来，用户就不必等待网络数据包绕过半个地球才得到响应。参见“描述性能”。

弹性

如果应用有时繁忙、有时空闲，云端部署可以随着需求扩大或缩小，让你只为正在使用的资源付费。这在单台机器上很难做到：即使大部分时间几乎没有负载，仍要按最大负载预先配置机器。

使用专用硬件

系统的各个部分可以采用与各自工作负载相匹配的硬件。例如，对象存储可以使用磁盘很多、CPU 很少的机器；数据分析系统可以使用 CPU 和内存很多、却没有磁盘的机器；机器学习系统则可以使用配备 GPU 的机器——训练深度神经网络及执行其他机器学习任务时，GPU 的效率远高于 CPU。

法律合规

一些国家制定了数据驻留法律，要求有关本国管辖范围内人员的数据，必须在该国境内存储和处理 ⁴¹。这类规定的适用范围不尽相同：有些只针对医疗或金融数据，有些则更加宽泛。因此，如果一项服务的用户分布在多个这样的司法管辖区，就不得不把用户数据分散到多个地点的服务器上。

可持续性

如果作业在何时、何地运行具有一定灵活性，就可以选择可再生电力充足的时间和地点，并避开电网负荷紧张的时候。这样既能减少碳排放，也能利用价格低廉的电力 ^{42 43}。

这些理由既适用于自行编写的服务（应用代码），也适用于由数据库等现成软件组成的服务。

分布式系统的问题

分布式系统也有缺点。每一个经过网络的请求和 API 调用，都必须面对失败的可能：网络可能中断，服务可能过载或崩溃，任何请求都有可能超时而收不到响应。此时，我们不知道服务究竟有没有收到请求，贸然重试未必安全。我们将在第 9 章详细讨论这些问题。

尽管数据中心网络很快，调用另一个服务仍然远远慢于在同一进程中调用函数 ⁴⁴。

处理海量数据时，与其把数据从存储位置传到另一台机器上处理，往往不如把计算带到已经保存数据的机器上来得快 ⁴⁵。

节点更多也不一定更快：有些情况下，一台计算机上简单的单线程程序，性能可以显著胜过拥有 100 多个 CPU 核心的集群 ⁴⁶。

分布式系统往往很难排查故障：如果系统响应缓慢，怎样才能找出问题在哪里？用于诊断分布式系统问题的技术统称为 可观测性（observability）^{47 48}。它收集系统的执行数据，并允许人们查询这些数据，从而既能分析高层指标，也能追查单个事件。OpenTelemetry、Zipkin 和 Jaeger 等 追踪（tracing）工具可以记录哪个客户端为了什么操作调用了哪个服务器，以及每次调用花了多长时间 ⁴⁹。

数据库提供了多种保证数据一致性的机制，我们将在第 6 章和第 8 章中看到。但是，当每个服务都有自己的数据库时，如何保持不同服务之间的数据一致，就成了应用自身的问题。分布式事务（参见第 8 章）是一种可能的手段，但很少用于微服务，因为它与服务彼此独立的目标背道而驰，而且许多数据库根本不支持分布式事务 ⁵⁰。

出于以上种种原因，只要一项工作能在单台机器上完成，通常就比搭建分布式系统简单得多，也便宜得多 ^{23 46 51}。CPU 越来越快，内存和磁盘的容量越来越大，硬件也越来越可靠。再加上 DuckDB、SQLite 和 KùzuDB 等单节点数据库，如今许多工作负载都可以在单个节点上运行。我们将在第 4 章进一步探讨这个话题。

微服务与无服务器

把系统分布到多台机器上，最常见的做法是将它划分为客户端和服务器，由客户端向服务器发送请求。这种通信最常使用 HTTP，我们将在“流经服务的数据流：REST 与 RPC”中进一步讨论。同一个进程既可以是服务器（处理传入的请求），也可以是客户端（向其他服务发出请求）。

这种构建应用的方式传统上称为 面向服务架构（SOA）；近年来，这一思想又进一步演化为 微服务（microservices）架构 ^{52 53}。在这种架构中，每项服务都有明确的用途（例如 S3 的用途就是文件存储）；服务通过 API 向客户端开放能力，由客户端经网络调用；每项服务还由一个团队负责维护。这样一来，复杂应用就可以拆分成多项相互交互的服务，分别由不同团队管理。

把复杂软件拆成多项服务有几个优点：各项服务可以独立更新，减少团队之间的协调；每项服务可以获得符合自身需要的硬件资源；实现细节隐藏在 API 后面，服务负责人可以自由改变实现，而不影响客户端。在数据存储方面，通常每项服务都有自己的数据库，服务之间不共享数据库。否则，整个数据库结构实际上都会成为服务 API 的一部分，很难再行修改；而且，一项服务发出的查询也可能拖累其他服务的性能。

另一方面，服务多了本身也会滋生复杂度：每项服务都需要相应基础设施，用来部署新版本、根据负载调整硬件资源、收集日志、监控服务健康状况，并在出现问题时向值班工程师告警。Kubernetes 等 编排（orchestration）框架为这类基础设施提供了基础能力，因此成了部署服务的常用方式。在开发过程中测试一项服务也可能很麻烦，因为它所依赖的其他服务必须一并运行。

微服务 API 也很难演化。调用 API 的客户端会期待其中存在某些字段；随着业务需求改变，开发者或许想要增删 API 字段，但这可能导致客户端出错。更糟的是，这类问题往往要到开发周期后期，更新后的服务 API 部署到预发布或生产环境时才被发现。OpenAPI 和 gRPC 等 API 描述标准有助于管理客户端 API 与服务器 API 之间的关系，我们将在第 5 章中进一步讨论。

微服务主要是用技术手段解决人员问题：让不同团队无需彼此协调，也能独立推进工作。这对大公司很有价值；但在团队不多的小公司里，微服务很可能只是没有必要的额外开销，此时最好采用最简单的方式实现应用 ⁵²。

无服务器（serverless），又称 函数即服务（FaaS），是另一种服务部署方式：它把基础设施管理进一步外包给云服务商 ³³。使用虚拟机时，你必须明确决定何时启动或关闭实例；无服务器模型则由云服务商根据发往服务的请求，自动分配和释放硬件资源 ⁵⁴。这种部署方式把更多运维负担转移给云服务商，并允许按使用量灵活计费，不再按机器实例收费。为了提供这些好处，许多无服务器基础设施会限制函数执行时长和运行时环境，而且函数第一次调用时可能启动缓慢。“无服务器”这个名称也容易误导：每次执行无服务器函数仍然要用到一台服务器，只是下一次执行可能换到另一台。此外，BigQuery 和各种 Kafka 产品也采用了“无服务器”这个说法，用来表示服务能够自动伸缩，并按使用量而不是机器实例收费。

正如云存储用按量计费取代了容量规划（提前决定购买多少磁盘），无服务器模式也把按量计费带到了代码执行：你只需为应用代码实际运行的时间付费，不必提前配置资源。

云计算与超级计算

云计算并非构建大规模计算系统的唯一方式，另一条路线是 高性能计算（HPC），也称为 超级计算（supercomputing）。尽管二者有所重叠，但与云计算和企业数据中心系统相比，HPC 的侧重点通常不同，采用的技术也不一样。差异包括：

• 超级计算机通常用于计算密集型的科学计算任务，例如天气预报、气候建模、分子动力学（模拟原子和分子的运动）、复杂优化问题，以及求解偏微分方程。云计算则更常用于在线服务、业务数据系统，以及其他需要以高可用性响应用户请求的系统。
• 超级计算机通常运行大型批处理作业，并不时把计算状态作为检查点写入磁盘。如果某个节点发生故障，一种常见做法是直接停止整个集群的工作负载，修复故障节点，再从最近的检查点重新开始计算 ^{55 56}。云服务通常不能这样停掉整个集群，因为服务必须持续响应用户，尽量减少中断。
• 超级计算机的节点通常通过共享内存和远程直接内存访问（RDMA）通信，既有高带宽，又有低延迟，但前提是系统用户彼此高度信任 ⁵⁷。在云计算中，网络和机器常由互不信任的组织共享，因此需要更强的安全机制，例如资源隔离（使用虚拟机等）、加密和认证。
• 云数据中心网络通常以 IP 和以太网为基础，采用 Clos 拓扑来提供较高的对分带宽——这是衡量网络整体性能的常用指标 ^{55 58}。超级计算机则常采用专门的网络拓扑，例如多维网格和环面 ⁵⁹；对于通信模式已知的 HPC 工作负载，这类拓扑可以提供更好的性能。
• 云计算允许节点分布在多个地理区域；超级计算机通常假定所有节点都彼此邻近。

大规模分析系统有时也具备超级计算的一些特征；如果你在这个领域工作，了解这些技术会很有价值。不过，本书主要关注必须持续可用的服务，正如“可靠性与容错”所讨论的那样。

数据系统、法律与社会

本章到目前为止已经说明，数据系统架构不仅受技术目标和要求影响，也受其所服务组织中人类需求的影响。越来越多的数据系统工程师开始认识到，只满足自己所在企业的需求还不够：我们也对整个社会负有责任。

其中一个特别值得关注的问题，是存储个人及其行为数据的系统。自 2018 年起，《通用数据保护条例》（GDPR）赋予许多欧洲国家的居民更大的个人数据控制权和更多法律权利；世界各地的不少国家和地区也采用了类似的隐私法规，例如《加州消费者隐私法案》（CCPA）。《欧盟人工智能法案》 等针对 AI 的法规，又进一步限制了个人数据的使用方式。

即使在没有直接受到监管的领域，人们也越来越清楚地认识到计算机系统对个人和社会的影响。社交媒体改变了人们获取新闻的方式，进而影响政治观点，甚至可能左右选举结果。自动化系统也越来越多地作出对个人影响深远的决定，例如谁能获得贷款或保险，谁能得到工作面试的机会，以及谁会成为犯罪嫌疑人 ⁶⁰。

每一个参与这类系统的人，都有责任考虑它们的伦理影响，并确保系统遵守相关法律。并非人人都要成为法律和伦理专家，但具备基本的法律与伦理常识，与掌握分布式系统的基础知识同样重要。

法律因素正在影响数据系统设计最根本的部分 ⁶¹。例如，GDPR 赋予个人要求删除其数据的权利，有时称为 被遗忘权（right to be forgotten）。然而，正如本书将要介绍的，许多数据系统的设计依赖仅追加日志等不可变结构；一个本应不可变的文件，要怎样从中间删除某些数据？如果数据已经纳入衍生数据集（参见“权威记录系统与衍生数据”），例如成为机器学习模型的训练数据，又该如何删除？回答这些问题带来了新的工程挑战。

目前，还没有明确指南说明哪些具体技术或系统架构算是“符合 GDPR”。法规有意不规定特定技术，因为技术进步可能很快就会使这些规定过时。法律文本给出的只是有待解释的高层原则。因此，如何遵守隐私法规并没有简单答案；不过，在讨论本书的一些技术时，我们会从这个角度加以审视。

一般来说，我们之所以存储数据，是因为相信它的价值高于存储成本。但不要忘记，存储成本不只是付给 Amazon S3 或其他服务的账单。成本效益分析还应计入这些风险：数据一旦泄露，或遭到攻击者窃取、破坏，可能承担法律责任并蒙受声誉损失；如果数据的存储和处理不符合法律规定，还可能产生诉讼费用和罚款 ⁵¹。

政府或警方也可能强迫企业交出数据。如果数据可能暴露某些在当地被法律定为犯罪的行为——例如，在一些中东和非洲国家，同性恋会受到刑事处罚；在美国一些州，寻求堕胎也可能受到刑事追究——那么存储这些数据会给用户带来切实的安全风险。例如，位置数据很容易暴露一个人曾前往堕胎诊所；哪怕只是一段用户 IP 地址的历史日志，也可能泄露其大致位置。

把所有风险都考虑在内之后，合理的结论可能是：某些数据根本不值得存储，因此应当删除。数据最小化（data minimization）原则（有时也用德语 Datensparsamkeit 表示）与“大数据”理念背道而驰；后者倾向于先存下大量数据，指望它们将来也许会派上用场 ⁶²。不过，数据最小化符合 GDPR：个人数据只能为具体、明确的目的而收集，日后不得用于其他目的，也不得在超出原定目的所需期限后继续保留 ⁶³。

企业同样开始重视隐私和安全问题。信用卡公司要求支付处理企业遵守严格的支付卡行业（PCI）标准；支付处理商要频繁接受独立审计机构的评估，验证是否持续合规。软件供应商面临的审查也日趋严格，许多采购方如今要求供应商符合服务组织控制（SOC）第 2 类标准。与 PCI 合规一样，供应商要通过第三方审计来验证是否符合要求。

总而言之，必须在业务需求与数据被收集、处理的人们的需求之间取得平衡。这个话题远不止于此；第 14 章将深入讨论伦理与法律合规问题，包括偏见和歧视。

总结

本章的主题是理解权衡：许多问题并没有唯一正确的答案，而是有几种不同的做法，各有利弊。我们探讨了影响数据系统架构的一些最重要的选择，也介绍了阅读本书其余部分所需的术语。

首先，我们区分了事务型系统（事务处理，即 OLTP）与分析型系统（OLAP），看到两者不仅管理着访问模式不同的各类数据，服务的群体也不相同。我们还认识了数据仓库与数据湖，它们通过 ETL 接收事务型系统送来的数据。第 4 章将会说明，由于要服务的查询类型不同，事务型系统与分析型系统的内部数据布局往往大相径庭。

接着，我们把出现时间较晚的云服务，与此前长期主导数据系统架构的自托管软件范式作了比较。哪种方式成本效益更高，很大程度上取决于具体情况；但不可否认的是，云原生方法正在深刻改变数据系统的架构，例如将存储与计算分离。

云系统天然就是分布式系统，我们也简要考察了分布式系统与单机方案之间的一些权衡。有些场景无法避免分布式；但只要系统还能保留在一台机器上，就不宜急着将其分布式化。第 9 章将更详细地讨论分布式系统带来的挑战。

最后，我们看到，数据系统架构不仅由部署系统的企业需求决定，也受隐私法规影响；这些法规保护着数据处理所涉及人员的权利，而许多工程师很容易忽视这一点。如何把法律要求转化为技术实现，目前还没有得到充分理解；但在阅读本书后续内容时，务必始终把这个问题放在心上。

参考文献

2 定义非功能性需求

互联网做得太好了，以至于大多数人将它看作像太平洋这样的自然资源，而不是什么人工产物。上一次出现这种规模且几乎不出错的技术，是什么时候？

艾伦・凯， 接受 Dr Dobb’s Journal 采访（2012 年）

构建应用程序时，你会面对一张需求清单。其中排在最前面的，很可能是应用必须提供的功能：需要哪些页面和按钮，每项操作要完成什么，才能实现软件的目的。这些就是 功能需求（functional requirements）。

此外，你可能还有一些 非功能性需求（nonfunctional requirements）：例如，应用应当快速、可靠、安全、符合法律规定，而且易于维护。这些要求未必会明确写下来，因为它们看似理所当然，但其重要性丝毫不亚于应用的功能：一个慢得让人无法忍受，或是很不可靠的应用，几乎等于不存在。

安全性等许多非功能性需求超出了本书的范围。不过，本章会讨论其中几项，并帮助你准确表述自己的系统需要达到什么要求：

• 如何定义和衡量系统的 性能（performance；参见“描述性能”）；
• 服务 可靠（reliable）意味着什么——也就是即使出了问题，仍能继续正确工作（参见“可靠性与容错”）；
• 随着系统负载增长，能否高效增加计算能力，使系统具备 可伸缩性（scalability；参见“可伸缩性”）；以及
• 如何让系统在长期使用中更易维护（参见“可维护性”）。

后续章节深入讨论数据密集型系统的实现细节时，还会用到本章引入的术语。不过，抽象定义读起来难免枯燥。为了让这些概念更加具体，我们先从一个社交网络服务的实现案例讲起，以此说明性能与可伸缩性在实践中意味着什么。

案例研究：社交网络首页时间线

假设你的任务是实现一个类似 X（原 Twitter）的社交网络，用户可以发帖，也可以关注其他用户。这里的实现会比真实服务简单得多 ^{1 2 3}，但足以说明大规模系统会遇到的一些问题。

假设用户每天发布 5 亿条帖子，平均每秒 5,700 条；偶尔，发帖速率会飙升至每秒 150,000 条 ⁴。再假设每位用户平均关注 200 人，也有 200 名关注者（实际分布范围非常广：大多数人只有寥寥几名关注者，而巴拉克・奥巴马等少数名人则有超过一亿名关注者）。

表示用户、帖子与关注关系

假设我们把所有数据都保存在关系数据库中，如图 2-1所示：一张表存储用户，一张表存储帖子，还有一张表存储关注关系。

假设这个社交网络需要支持的主要读操作是 首页时间线（home timeline），用来展示你所关注的人最近发布的帖子（为简单起见，我们忽略广告、来自未关注用户的推荐帖，以及其他扩展功能）。可以用下面这条 SQL 查询来获取某位用户的首页时间线：

SELECT posts.*, users.* FROM posts
    JOIN follows ON posts.sender_id = follows.followee_id
    JOIN users ON posts.sender_id = users.id
    WHERE follows.follower_id = current_user
    ORDER BY posts.timestamp DESC
    LIMIT 1000

执行这条查询时，数据库先用 follows 表找出 current_user 关注的所有人，再查找这些用户最近发布的帖子，并按时间戳排序，取出其中最新的 1,000 条。

帖子讲究时效，因此假设某人发帖之后，我们希望其关注者能在 5 秒内看到。一个办法是，只要用户在线，客户端就每隔 5 秒重复执行一次上述查询（这称为 轮询（polling））。如果同时在线且已登录的用户有 1,000 万，就意味着每秒要执行 200 万次查询。即使延长轮询间隔，这个数字仍然很大。

而且，这条查询本身开销不小：如果你关注了 200 人，数据库就要分别取出这 200 人最近发布的帖子，再把这些列表合并起来。每秒 200 万次时间线查询，意味着数据库每秒要查询某个发帖者的近期帖子 4 亿次——这是个惊人的数字，而且还只是平均情况。有些用户关注了数万个账户，为他们执行这条查询的代价极高，也很难保证速度。

时间线的物化与更新

怎样才能做得更好？首先，与其让客户端轮询，不如由服务器把新帖子主动推送给当前在线的关注者。其次，可以预先计算上述查询的结果，使首页时间线请求直接由缓存提供。

设想我们为每位用户保存一个数据结构，其中装着他们的首页时间线，也就是他们所关注的人最近发布的帖子。每当有人发帖，我们就找出他的所有关注者，把这条帖子插入每位关注者的首页时间线，就像把信投进一个个邮箱。这样，用户登录时只需把预先计算好的时间线交给他们即可。若要接收时间线上的新帖通知，客户端只需订阅不断加入其首页时间线的帖子流。

这种方法的缺点是，每次发帖都要完成更多工作，因为首页时间线是需要随之更新的 衍生数据（derived data）。整个过程如图 2-2所示。当一个初始请求引发多个下游请求时，我们用 扇出（fan-out） 来表示请求数量被放大的倍数。

以每秒 5,700 条帖子的速率计算，如果每条帖子平均要送达 200 名关注者（也就是扇出系数为 200），每秒就要完成略多于 100 万次首页时间线写入。这个数字依然很大，但与另一种方案每秒 4 亿次按发帖者查询近期帖子的操作相比，已经节省了很多工作。

如果某个特殊事件使发帖速率骤增，我们无须立刻完成所有时间线投递；可以先把投递任务放入队列，并接受帖子暂时要过一会儿才会出现在关注者的时间线上。即使出现这种负载高峰，时间线仍然可以快速加载，因为读取只需访问缓存。

这种预先计算并不断更新查询结果的过程称为 物化（materialization），时间线缓存就是一个 物化视图（materialized view） 的例子（我们会在“维护物化视图”中进一步讨论这个概念）。物化视图加快了读取，代价则是写入时要做更多工作。对大多数用户而言，写入成本并不高，但社交网络还必须考虑一些极端情况：

• 如果一位用户关注了非常多的账户，而且这些账户发帖频繁，那么写入其物化时间线的速率会很高。不过，这位用户多半也不会读完时间线中的所有帖子，因此可以丢弃其中一部分时间线写入，只向用户展示所关注账户发布帖子的一个样本 ⁵。
• 如果一位拥有海量关注者的名人发帖，我们就要完成大量工作，把这条帖子插入数百万人的首页时间线。在这种情况下，丢弃部分写入是不可接受的。一种解决办法是把名人帖子与其他人的帖子分开处理：不必费力把名人帖子加入数百万条时间线，而是将其单独存储，等读取时再与物化时间线合并。即使采用这类优化，社交网络要承载名人账户仍可能需要大量基础设施 ⁶。

描述性能

讨论软件性能时，通常会考虑两类主要指标：

响应时间（response time）

从用户发出请求到收到所需响应所经过的时间。计量单位是秒（或毫秒、微秒）。

吞吐量（throughput）

系统每秒处理的请求数或数据量。对于给定的硬件资源，系统能处理的吞吐量存在上限，也就是 最大吞吐量（maximum throughput）。计量单位通常写成“每秒多少个……”。

在社交网络案例中，“每秒帖子数”和“每秒时间线写入数”是吞吐量指标；“加载首页时间线所需的时间”和“帖子送达关注者所需的时间”则是响应时间指标。

吞吐量和响应时间之间往往存在联系，图 2-3勾勒了在线服务中二者的一种典型关系。请求吞吐量较低时，服务的响应时间也很短；随着负载增大，响应时间随之上升。这是 排队（queueing）造成的：当请求到达负载很高的系统时，CPU 很可能正在处理先前的请求，新来的请求只好等到前一个处理完毕。当吞吐量逐渐逼近硬件的处理极限时，排队延迟会急剧增加。

在各项性能指标中，用户通常最关心响应时间；吞吐量则决定了所需的计算资源（例如服务器数量），从而决定处理特定工作负载的成本。如果吞吐量可能增长到超出当前硬件的处理能力，就需要扩充容量。如果增加计算资源能够显著提高系统的最大吞吐量，我们就称这个系统具有 可伸缩性（scalability）。

本节主要关注响应时间；我们会在“可伸缩性”一节回头讨论吞吐量与可伸缩性。

延迟与响应时间

“延迟”和“响应时间”有时会被混为一谈，但本书将按下面的特定含义使用这几个术语（如图 2-4所示）：

• 响应时间（response time）是客户端看到的时间，其中包括系统各处产生的全部延误。
• 服务时间（service time）是服务真正用于处理用户请求的时间。
• 排队延迟（queueing delay）可能发生在流程中的多个位置。例如，请求到达后，也许必须等到 CPU 空闲才能开始处理；如果同一台机器上的其他任务正在通过出站网络接口发送大量数据，响应数据包也可能先在缓冲区中等待。
• 延迟（latency）泛指请求没有得到实际处理的时间，也就是请求处于 潜伏（latent） 状态的时间。具体来说，网络延迟（network latency）或 网络时延（network delay）是请求和响应在网络中传输所花的时间。

在图 2-4中，时间从左向右流逝；参与通信的每个节点用一条水平线表示，请求或响应消息则画成从一个节点指向另一个节点的粗斜箭头。本书后面还会经常遇到这种图示方式。

即使反复发送同一个请求，每次的响应时间也可能相差很大。许多因素都会带来随机的额外延迟，例如：上下文切换到后台进程、网络丢包和 TCP 重传、垃圾回收暂停、缺页迫使系统从磁盘读取数据、服务器机架的机械振动 ¹⁷，等等。我们会在“超时和无界延迟”中进一步讨论这个问题。

响应时间的波动很大一部分往往来自排队延迟。服务器同时能处理的任务数量有限（例如受 CPU 核数限制），因此只需少数几个慢请求，就足以阻碍后续请求，这种现象称为 队头阻塞（head-of-line blocking）。即使后续请求本身的服务时间很短，客户端看到的总体响应时间仍会很长，因为它们要等待先前的请求完成。排队延迟不属于服务时间，所以在客户端测量响应时间十分重要。

平均值、中位数与分位数

由于每次请求的响应时间都不一样，我们不能只把它看成一个数字，而应将其视为一组可测量数值的 分布（distribution）。在图 2-5中，每根灰色柱条代表一次服务请求，柱条的高度表示这次请求所花的时间。大多数请求都相当快，但偶尔会出现耗时长得多的 异常值（outlier）。网络延迟的变化也称为 抖动（jitter）。

服务通常会报告 平均（mean）响应时间，也就是 算术平均值（arithmetic mean）：把所有响应时间相加，再除以请求数。平均响应时间有助于估算吞吐量的上限 ¹⁸。不过，如果你想知道“典型”的响应时间，平均值就不是很好的指标，因为它没有告诉你究竟有多少用户实际经历了这样的等待。

通常，采用 分位数（percentile） 更合适。将响应时间从快到慢排列，中位数（median）就是位于正中间的值。例如，如果响应时间的中位数是 200 毫秒，就意味着一半请求用时不到 200 毫秒，另一半则需要更长时间。因此，如果想知道用户通常要等多久，中位数是个很好的指标。中位数也称为 第 50 分位数，有时缩写为 p50。

为了弄清异常值究竟有多糟，可以观察更高的分位数。常用的有第 95、99 和 99.9 分位数，分别缩写为 p95、p99 和 p999。它们对应这样一个响应时间阈值：分别有 95%、99% 或 99.9% 的请求快于这个阈值。例如，如果第 95 分位数的响应时间是 1.5 秒，就意味着每 100 个请求中，有 95 个用时不到 1.5 秒，另外 5 个则需要 1.5 秒或更久。图 2-5对此作了说明。

响应时间的高分位数也称为 尾延迟（tail latencies），它们十分重要，因为会直接影响用户对服务的体验。例如，亚马逊用第 99.9 分位数来描述内部服务的响应时间要求，尽管它只影响每 1,000 个请求中的一个。这是因为，响应最慢的客户往往是在账户中积累了最多数据的人——他们购买过很多商品，也就是最有价值的客户 ¹⁹。确保网站对这些客户同样快速，是维持其满意度的重要手段。

另一方面，亚马逊认为，针对第 99.99 分位数（每 10,000 个请求中最慢的一个）进行优化，成本过高，收益又不足。降低极高分位数处的响应时间非常困难，因为它很容易受到不可控随机事件的影响，而且越往后收益越小。

响应时间指标的应用

如果后端服务要为一次最终用户请求执行多次调用，那么高分位数尤其重要。即使这些调用并行发出，最终用户请求仍要等待其中最慢的一次完成。正如图 2-6所示，只需一个慢调用，就足以拖慢整个最终用户请求。即使后端调用中只有很小一部分速度较慢，一次最终用户请求所需的后端调用越多，其中出现慢调用的概率也就越大，最终会有更高比例的用户请求变慢。这种效应称为 尾部延迟放大（tail latency amplification） ²⁶。

分位数经常出现在 服务级别目标（SLO） 和 服务级别协议（SLA） 中，用来规定服务应达到的性能和可用性 ²⁷。例如，一项 SLO 可能要求服务的中位响应时间低于 200 毫秒、第 99 分位数的响应时间低于 1 秒，并要求至少 99.9% 的有效请求得到非错误响应。SLA 则是一份合同，规定未达到 SLO 时会怎样处理（例如，客户可能有权获得退款）。这至少是其基本思路；在实践中，要为 SLO 和 SLA 定义良好的可用性指标并不简单 ^{28 29}。

可靠性与容错

每个人对于一个东西是否可靠，都有直观的判断。人们对可靠软件的典型期望包括：

• 应用程序表现出用户所期望的功能。
• 允许用户犯错，或以出乎意料的方式使用软件。
• 在预期的负载和数据量下，性能足以满足所需的使用场景。
• 系统能防止未经授权的访问和滥用。

如果把这些合在一起称为“正确工作”，那么 可靠性（reliability） 可以粗略理解为“即使出了问题，也能继续正确工作”。为了更准确地描述所谓“出了问题”，我们要区分 故障（fault） 和 失效（failure） ^{35 36 37}：

故障

系统的某个 部分 停止正常工作。例如，单块硬盘发生故障、单台机器崩溃，或者系统所依赖的外部服务中断。

失效

整个系统 停止向用户提供所需的服务；换言之，系统没有达到服务级别目标（SLO）。

故障与失效之所以容易混淆，是因为二者其实是同一件事，只是观察的层次不同。例如，如果一块硬盘停止工作，我们会说这块硬盘失效了：若整个系统只有这一块硬盘，系统也就停止了提供所需服务。然而，如果我们谈论的是一个包含许多硬盘的系统，那么单块硬盘失效从整个系统的角度看只是一项故障；只要数据在另一块硬盘上还有副本，整个系统就可能容忍这项故障。

容错

如果某些故障发生时，系统仍能继续向用户提供所需服务，我们就称它是 容错的（fault-tolerant）。如果系统无法容忍某个部分出现故障，这个部分就称为 单点故障（SPOF），因为它一旦发生故障，就会升级为整个系统的失效。

以社交网络案例为例，扇出过程中可能发生这样一种故障：负责更新物化时间线的某台机器崩溃或变得不可用。要让这个过程具备容错能力，就必须确保另一台机器能接手这项任务，既不漏掉任何本应投递的帖子，也不会重复投递。（这个思想称为 恰好一次语义（exactly-once semantics），我们会在“数据库的端到端原则”中详细讨论。）

容错能力总是针对特定类型、特定数量的故障而言。例如，一个系统也许最多能容忍两块硬盘同时失效，或三个节点中有一个崩溃。要求系统容忍任意数量的故障没有意义：如果所有节点都崩溃了，任何办法都无济于事。如果整个地球（以及上面的所有服务器）都被黑洞吞噬，要容忍这项故障就得把网站托管到太空中——祝你好运，看看这笔预算能不能获批。

反直觉的是，在这类容错系统中，通过故意触发故障来 提高 故障率有时反而是合理的，例如毫无预警地随机杀死某个进程。这称为 故障注入（fault injection）。许多严重缺陷其实源于糟糕的错误处理 ³⁸；故意制造故障，可以让容错机制不断得到演练和检验，从而增强我们的信心：当故障自然发生时，系统确实能够正确处理。混沌工程（chaos engineering） 就是一门通过故障注入等实验来增强人们对容错机制信心的学科 ³⁹。

虽然比起预防故障，我们通常更倾向于容忍故障，但有时预防确实胜于治疗（例如根本无药可救时）。安全问题就是如此：如果攻击者已经攻破系统并获得敏感数据，这件事无法撤销。不过，本书主要讨论的是能够补救的故障类型，下面几节会作进一步说明。

硬件与软件故障

说到系统失效的原因，人们很容易首先想到硬件故障：

• 每年大约有 2%～5% 的机械硬盘发生故障 ^{40 41}；因此，在拥有 10,000 块硬盘的存储集群中，平均每天应该会有一块硬盘失效。近期数据表明硬盘越来越可靠，但故障率仍不容忽视 ⁴²。
• 每年大约有 0.5%～1% 的固态硬盘（SSD）发生故障 ⁴³。少量比特错误会自动得到纠正 ⁴⁴，但每块硬盘大约每年仍会发生一次无法纠正的错误，即使硬盘相当新（也就是磨损很少）也不例外；这个错误率高于机械硬盘 ^{45 46}。
• 电源、RAID 控制器和内存模块等其他硬件组件也会发生故障，只是没有硬盘那么频繁 ^{47 48}。
• 大约每 1,000 台机器中，就有一台的某个 CPU 核心偶尔会算出错误结果，原因很可能是制造缺陷 ^{49 50 51}。错误计算有时会导致崩溃，有时却只是让程序返回错误的结果。
• RAM 中的数据也可能损坏，原因既可能是宇宙射线等随机事件，也可能是永久性的物理缺陷。即使采用纠错码（ECC）内存，一年内仍会有超过 1% 的机器遇到无法纠正的错误，通常会导致机器崩溃，并且需要更换受影响的内存模块 ⁵²。此外，某些病态的内存访问模式很可能导致比特翻转 ⁵³。
• 整个数据中心可能变得不可用（例如停电或网络配置错误），甚至遭到永久摧毁（例如火灾、洪水或地震 ⁵⁴）。太阳喷发大量带电粒子所形成的太阳风暴，会在长距离导线中感应出很强的电流，可能破坏电网和海底网络电缆 ⁵⁵。这类大规模失效虽然少见，但如果服务不能容忍整个数据中心的丢失，后果可能是灾难性的 ⁵⁶。

这些事件相当少见，因此在小型系统中，只要故障硬件很容易更换，通常不必为之过分担心。然而，在大规模系统里，硬件故障发生得足够频繁，已经成了系统正常运行的一部分。

通过冗余容忍硬件故障

面对不可靠的硬件，我们通常首先想到为各个硬件组件增加冗余，以降低整个系统的失效率。磁盘可以组成 RAID（把数据分散到同一台机器的多块磁盘上，使单块磁盘失效不至于造成数据丢失）；服务器可以配备双路电源和可热插拔的 CPU；数据中心可以用电池和柴油发电机提供备用电源。这些冗余措施往往能让一台机器连续运行多年而不中断。

当各个组件的故障彼此独立时，冗余最有效；所谓独立，就是一项故障的发生不会改变另一项故障发生的概率。然而，实践表明，组件失效之间往往存在显著的相关性 ^{41 57 58}；整个服务器机架乃至整个数据中心不可用的情况，仍然比我们希望的更加常见。

硬件冗余可以提高单台机器的正常运行时间。不过，正如“分布式与单节点系统”中所述，采用分布式系统还有其他好处，例如能够容忍整个数据中心中断。因此，云系统往往不那么强调单台机器的可靠性，而是力求在软件层面容忍节点故障，让服务实现高可用。云提供商用 可用区（availability zone） 来标明哪些资源在物理上位于同一处；与地理位置分散的资源相比，同一地点的资源更可能同时失效。

本书讨论的容错技术，旨在容忍整台机器、整个机架或整个可用区的丢失。它们通常允许一个数据中心内的机器，在另一个数据中心内的机器发生故障或变得不可达时接替其工作。我们会在第 6 章、第 10 章以及本书其他多处讨论这类容错技术。

能够容忍整台机器丢失的系统，在运维上也有优势。如果需要重启机器（例如安装操作系统安全补丁），单服务器系统必须安排停机；而多节点容错系统可以逐个重启节点来安装补丁，不影响向用户提供服务。这称为 滚动升级（rolling upgrade），我们会在第 5 章进一步讨论。

软件故障

尽管硬件失效之间可能存在较弱的相关性，但大体上仍然相互独立。例如，一块硬盘失效以后，同一台机器上的其他硬盘很可能还能继续正常工作一段时间。相比之下，软件故障往往高度相关，因为许多节点通常运行同一套软件，也就带有同样的缺陷 ^{59 60}。这类故障更难预见，而且比互不相关的硬件故障更容易造成系统失效 ⁴⁷。例如：

• 一个软件缺陷在特定情况下导致所有节点同时失效。例如，2012 年 6 月 30 日的一次闰秒触发了 Linux 内核中的缺陷，使许多 Java 应用程序同时挂起，大量互联网服务随之中断 ⁶¹。另一个例子是，由于固件缺陷，某些型号的 SSD 会在恰好运行 32,768 小时（不到 4 年）后突然全部失效，盘上的数据再也无法恢复 ⁶²。
• 某个失控进程耗尽 CPU 时间、内存、磁盘空间、网络带宽或线程等共享而有限的资源 ⁶³。例如，进程在处理大型请求时消耗了过多内存，可能被操作系统杀死；客户端库中的缺陷也可能产生远高于预期的请求量 ⁶⁴。
• 系统所依赖的某项服务变慢、失去响应，或开始返回内容损坏的响应。
• 不同系统之间的交互产生涌现行为，而每个系统单独测试时都不会出现这种行为 ⁶⁵。
• 发生级联失效：一个组件的问题导致另一个组件过载并变慢，后者继而又拖垮下一个组件 ^{66 67}。

引发这类软件故障的缺陷往往会潜伏很久，直到一组不同寻常的条件将其触发。这时人们才发现，软件原来对运行环境作出了某种假设；这个假设通常都成立，却最终会出于某种原因不再成立 ^{68 69}。

软件中的系统性故障没有速效药，但许多小措施都能有所帮助：认真思考系统中的假设和交互，开展彻底的测试，隔离进程，允许进程崩溃并重启，避免重试风暴之类的反馈环路（参见“当过载系统无法恢复时”），并在生产环境中度量、监控和分析系统行为。

人类与可靠性

软件系统由人设计和构建，维持系统运行的运维人员同样也是人。与机器不同，人类不只是照章行事；他们的长处正是能够发挥创造力、随机应变，把工作完成。不过，这一特点也会带来不可预测性：即使出发点再好，人也会犯错，有时还会导致系统失效。例如，一项针对大型互联网服务的研究发现，运维人员修改配置是服务中断的首要原因，而硬件故障（服务器或网络）只在 10%～25% 的中断中起了作用 ⁷⁰。

人们很容易把这类问题归结为“人为错误”，并幻想通过更严格的流程和更严密的规则来约束人的行为，从而解决问题。然而，把错误归咎于个人往往适得其反。所谓“人为错误”其实并不是事故的根本原因，而是人与技术共同构成的 社会技术系统（sociotechnical system）出了问题的一种症状；身处其中的人只是在竭尽所能地完成工作 ⁷¹。复杂系统也常常表现出涌现行为，组件之间出人意料的交互同样可能导致失效 ⁷²。

多种技术手段都能减小人为失误的影响，包括：彻底测试（既包括手写测试，也包括用大量随机输入进行的 属性测试，property-based testing）³⁸；提供回滚机制，以便迅速撤销配置变更；逐步发布新代码；提供详细而清晰的监控，以及用于诊断生产问题的可观测性工具（参见“分布式系统的问题”）；精心设计界面，使“做正确的事”更加容易，“做错误的事”更加困难。

不过，这些措施都要投入时间和金钱。在日常经营的现实压力下，组织往往优先考虑能够创造收入的工作，而不是提高自身抵御失误能力的措施。如果必须在开发更多功能和开展更多测试之间选择，许多组织选择功能也不难理解。既然作出了这样的选择，当本可避免的错误不可避免地发生时，再去责怪犯错的人便毫无道理——真正的问题在于组织如何设定优先级。

越来越多的组织开始形成 无责复盘（blameless postmortem） 的文化：事故发生后，鼓励所有参与者毫无保留地讲清事情经过，不必担心受到惩罚；这样，组织中的其他人才能从中学习，避免今后再发生类似问题 ⁷³。复盘过程也许会发现，业务优先级需要调整，长期遭到忽视的领域需要投入，相关人员的激励机制需要改变，或者还有其他系统性问题需要提请管理层关注。

一般而言，调查事故时应当警惕过分简单的答案。“鲍勃部署这项变更时应该更加小心”无助于解决问题，“我们必须用 Haskell 重写后端”同样如此。管理层应当抓住机会，从每天使用这个社会技术系统的一线人员那里了解它究竟如何运作，再根据这些反馈采取措施加以改进 ⁷¹。

可伸缩性

系统今天能可靠运行，并不意味着将来也一定能够可靠运行。系统退化的一个常见原因是负载增加：也许并发用户从 10,000 人增长到了 100,000 人，或者从 100 万人增长到了 1,000 万人；也许系统现在处理的数据量比过去大得多。

可伸缩性（scalability） 是描述系统应对负载增长能力的术语。讨论可伸缩性时，人们有时会说：“你又不是 Google 或 Amazon。别再担心规模问题了，用关系数据库就好。”这句话是否适用于你，要看你构建的究竟是哪一类应用。

如果你正在构建一个目前用户不多的新产品，例如初创公司的新业务，压倒一切的工程目标通常是让系统尽可能简单、灵活；这样，随着你逐渐了解客户的需求，就能轻松修改和调整产品功能 ⁷⁸。在这种环境中，为将来或许才需要的假想规模忧心忡忡，只会适得其反：往好里说，对可伸缩性的投入是白费力气和过早优化；往坏里说，它会把你困在一个不灵活的设计中，让应用更难演化。

这是因为，可伸缩性并不是一个一维的标签。简单地说“X 是可伸缩的”或“Y 无法伸缩”毫无意义。讨论可伸缩性，真正要考虑的是下面这些问题：

*“如果系统按某种方式增长，我们有哪些应对选项？” *“我们如何增加计算资源来承载额外负载？” *“按当前的增长预期，什么时候会达到现有架构的极限？”

如果应用大受欢迎，因而需要处理不断增长的负载，你会逐渐知道性能瓶颈在哪里，也就清楚系统需要沿着哪些维度扩展。到那时，再开始认真考虑可伸缩性技术也不迟。

描述负载

首先，我们需要简明地描述系统当前的负载；只有这样，才能继续讨论增长问题（例如负载翻倍会发生什么）。这种描述通常是某项吞吐量指标，例如服务每秒收到的请求数、每天新增多少 GB 数据，或每小时完成的购物车结账次数。有时，我们关心的是某个变量的峰值，例如“案例研究：社交网络首页时间线”中的同时在线用户数。

负载往往还有其他统计特征，它们同样会影响访问模式，进而影响系统对可伸缩性的要求。例如，你可能需要知道数据库的读写比例、缓存命中率，或每位用户拥有的数据项数量（例如社交网络案例中的关注者人数）。有时平均情况最重要，有时瓶颈却由少数极端情况主导。一切都取决于具体应用的细节。

描述好系统负载以后，就可以研究负载增加时会发生什么。我们可以从两个角度来看：

• 以某种方式增加负载，而系统资源（CPU、内存、网络带宽等）保持不变，系统性能会受到什么影响？
• 以某种方式增加负载，而你希望性能保持不变，需要增加多少资源？

通常，我们的目标是在满足 SLA 性能要求（参见“响应时间指标的应用”）的同时，尽可能降低系统的运行成本。所需的计算资源越多，成本就越高。某些硬件也许比另一些更具性价比，而随着新型硬件出现，这些因素也会随时间变化。

如果资源增加一倍，就能在性能不变的情况下处理两倍负载，我们称系统具备 线性可伸缩性（linear scalability），这通常是一件好事。偶尔，由于规模经济或峰值负载分布得更加均匀，不到两倍的资源也能处理两倍的负载 ^{79 80}。更常见的情况是，成本增长得比线性更快，造成这种低效的原因可能有很多。例如，系统拥有大量数据时，即使写入请求本身大小相同，处理一次写入所需的工作也可能多于数据量较小时。

共享内存、共享磁盘与无共享架构

增加服务硬件资源最简单的办法，就是把服务迁移到更强大的机器上。单个 CPU 核心的速度已经不再显著提高，但你仍可以买到（或在云上租用）配有更多 CPU 核心、更大 RAM 和更多磁盘空间的机器。这种方法称为 纵向扩展（vertical scaling），也叫 向上扩展（scaling up）。

在单台机器上运行多个进程或线程，可以获得并行处理能力。同一进程中的所有线程都能访问同一块 RAM，因此这种方法也称为 共享内存架构（shared-memory architecture）。共享内存方案的问题在于，成本增长得比线性更快：硬件资源多一倍的高端机器，价格通常远远不止两倍；受各种瓶颈限制，一台规模翻倍的机器又往往处理不了两倍的负载。

另一种方案是 共享磁盘架构（shared-disk architecture）：多台机器分别拥有独立的 CPU 和 RAM，却把数据存储在共同访问的一组磁盘阵列中，机器与磁盘通过高速网络连接，例如 网络附加存储（NAS） 或 存储区域网络（SAN）。这种架构过去常用于本地部署的数据仓库工作负载，但资源争用和加锁开销限制了共享磁盘方案的可伸缩性 ⁸¹。

相比之下，无共享架构（shared-nothing architecture） ⁸²（也称为 水平扩展（horizontal scaling） 或 向外扩展（scaling out））已经广受欢迎。这种方案采用包含多个节点的分布式系统，每个节点都拥有自己的 CPU、RAM 和磁盘；节点之间的一切协调，都通过普通网络在软件层完成。

无共享架构的优势是：它有望实现线性伸缩；可以使用任何性价比最好的硬件，在云端尤其如此；负载增减时更容易调整硬件资源；还可以把系统分布到多个数据中心和地域，以获得更强的容错能力。缺点则是必须显式进行分片（参见第 7 章），并且要面对分布式系统的全部复杂性（参见第 9 章）。

一些云原生数据库系统把存储和事务执行拆分成不同的服务（参见“存储与计算的分离”），让多个计算节点共享同一项存储服务。这个模型与共享磁盘架构有几分相似，但避开了老式系统的可伸缩性问题：存储服务提供的不是文件系统（NAS）或块设备（SAN）抽象，而是一套针对数据库具体需求设计的专用 API ⁸³。

可伸缩性原则

大规模系统的架构通常高度依赖具体应用，不存在一套通用、放之四海而皆准的可伸缩架构（俗称 万金油（magic scaling sauce））。例如，处理每秒 100,000 个请求、每个请求 1 kB 的系统，与每分钟只处理 3 个请求、每个请求却有 2 GB 的系统，看起来会截然不同——尽管二者的数据吞吐量同为 100 MB/s。

而且，适合某个负载水平的架构，多半应付不了十倍于此的负载。如果你正在开发一个快速增长的服务，很可能每当负载增加一个数量级，就需要重新考虑架构。应用需求本身也很可能不断变化，因此提前为超过一个数量级之后的伸缩需求作规划，通常并不值得。

可伸缩性有一项很好的通用原则：把系统拆分成较小的组件，使它们大体上能够彼此独立地运行。这是微服务（参见“微服务与无服务器”）、分片（第 7 章）、流处理（第 12 章）和无共享架构背后的共同原则。不过，真正的挑战在于判断哪些东西应该放在一起，哪些东西应该拆开。其他书籍介绍了微服务的设计准则 ⁸⁴；本书则会在第 7 章讨论无共享系统中的分片。

另一项好原则是，不要让系统变得比必要的更加复杂。如果单机数据库足以完成任务，它很可能比复杂的分布式配置更可取。自动伸缩系统会根据需求自动增加或移除资源，的确很酷；但如果负载相当可预测，手动伸缩的系统在运维中也许更少出现意外（参见“运维：自动/手动再平衡”）。由 5 个服务组成的系统比由 50 个服务组成的系统更简单。优秀的架构通常务实地混合了多种方案。

可维护性

软件不会磨损，也不会像机械装置那样发生材料疲劳，因此它不会以同样的方式损坏。不过，应用程序的需求经常变化，软件运行的环境也会变化（例如依赖项和底层平台），而且软件中总有缺陷需要修复。

众所周知，软件的大部分成本不在最初的开发阶段，而在持续的维护阶段，包括修复缺陷、保持系统正常运行、调查失效、适配新的平台、为新的使用场景进行修改、偿还技术债和添加新功能 ^{85 86}。

然而，维护工作本身也很困难。一个成功运行多年的系统，很可能仍在使用如今已经没有多少工程师了解的过时技术，例如大型机和 COBOL 代码；随着人员离开组织，关于系统为何如此设计、怎样设计的组织知识可能已经丢失；维护者也许不得不修正前人留下的错误。而且，计算机系统往往与它所支撑的组织紧密交织在一起，这意味着维护这样的 遗留（legacy） 系统既是人的问题，也是技术问题 ⁸⁷。

我们今天构建的每个系统，只要足够有价值、能够长期存续，终有一天都会成为遗留系统。为了尽量减轻以后维护软件的人所承受的痛苦，我们设计软件时就应该考虑维护问题。虽然无法事先断定哪些决定会在未来制造维护难题，但本书会特别关注几项具有广泛适用性的原则：

可运维性（operability）

便于组织保持系统平稳运行。

简单性（simplicity）

采用人们熟知且前后一致的模式和结构，避免不必要的复杂度，使新工程师也能轻松理解系统。

可演化性（evolvability）

便于工程师将来修改系统，在需求变化时调整和扩展系统，以适应事先没有预料到的使用场景。

可运维性：让运维更轻松

我们已经在“云时代的运维”中讨论过运维的作用，并且看到，要实现可靠运维，人的流程至少与软件工具同等重要。事实上，有人认为：“良好的运维往往能绕开糟糕（或不完整）软件的局限，但即使软件很好，糟糕的运维也无法让它可靠运行” ⁶⁰。

大规模系统由成千上万台机器组成，纯靠人工维护，成本高得难以承受，因此自动化必不可少。然而，自动化是一把双刃剑：总会有一些边缘情况（例如罕见的故障场景）需要运维团队人工干预。自动化无法处理的恰恰是最复杂的问题，所以自动化程度越高，反而越需要一支技能 更强 的运维团队来解决这些问题 ⁸⁸。

而且，自动化系统一旦出错，往往比依靠运维人员手工完成某些操作的系统更难排查。因此，对可运维性而言，自动化并非总是越多越好。一定程度的自动化依然很重要，最佳平衡点则取决于具体应用和组织的情况。

良好的可运维性意味着让日常工作更加轻松，使运维团队能把精力集中在高价值的任务上。数据系统可以通过多种方式简化日常工作 ⁸⁹：

• 允许监控工具检查系统的关键指标，并支持可观测性工具（参见“分布式系统的问题”），以便深入了解系统运行时的行为。许多商业工具和开源工具都能在这方面提供帮助 ⁹⁰。
• 避免依赖任何一台机器，使机器可以下线维护，而整个系统仍能不间断地运行。
• 提供良好的文档和易于理解的操作模型（“如果我做 X，就会发生 Y”）。
• 提供良好的默认行为，同时允许管理员在必要时覆盖默认设置。
• 在适当的时候自动修复，同时也允许管理员在必要时手动控制系统状态。
• 表现出可预测的行为，尽量避免出人意料。

简单性：管理复杂度

小型软件项目可以拥有简单讨喜、富有表现力的代码；但随着项目不断扩大，代码往往变得非常复杂，难以理解。这种复杂度拖慢了每一个需要在系统上工作的人，进一步增加了维护成本。一个陷入复杂泥潭的软件项目有时被称为 大泥球（big ball of mud） ⁹¹。

当复杂度使维护变得困难时，预算和进度安排往往都会超支。修改复杂软件也更容易引入缺陷：系统越难理解和推理，开发人员就越容易忽略隐藏的假设、无意的后果和意外的交互 ⁶⁹。反过来，降低复杂度可以极大提高软件的可维护性，因此简单性应该成为我们构建系统时的一项关键目标。

简单的系统更容易理解，因此我们应该尽可能用最简单的办法解决给定的问题。可惜，说起来容易，做起来却很难。事物是否简单往往取决于主观品味，并不存在衡量简单性的客观标准 ⁹²。例如，一个系统可能把复杂实现隐藏在简单接口背后，另一个系统的实现本身很简单，却向用户暴露了更多内部细节——究竟哪一个更简单？

人们曾尝试把复杂度分成 本质复杂度（essential complexity） 和 偶然复杂度（accidental complexity） 两类，以此对复杂度进行推理 ⁹³。按照这种思路，本质复杂度是应用程序问题领域所固有的，而偶然复杂度只因工具的局限而产生。不幸的是，这种区分也有缺陷，因为随着工具不断演进，本质复杂度与偶然复杂度之间的界限也会发生变化 ⁹⁴。

管理复杂度最好的工具之一是 抽象（abstraction）。一个好的抽象可以把大量实现细节隐藏在干净、简单易懂的外观之下，也可以广泛用于各种不同的应用。复用抽象不仅比一遍遍重新实现类似功能更加高效，也能带来更高质量的软件，因为抽象组件的质量得到改进，所有使用它的应用都会从中受益。

例如，高级编程语言是一种抽象，隐藏了机器码、CPU 寄存器和系统调用。SQL 也是一种抽象，隐藏了复杂的磁盘和内存数据结构、其他客户端发出的并发请求，以及崩溃后产生的不一致。当然，使用高级语言编程时，我们仍然用到了机器码；只不过没有 直接 使用它，因为编程语言的抽象让我们不必考虑这些细节。

为了降低应用程序代码的复杂度，可以借助 设计模式（design pattern）⁹⁵ 和 领域驱动设计（DDD） ⁹⁶ 等方法来构建抽象。本书讨论的不是这类应用专用的抽象，而是数据库事务、索引和事件日志等通用抽象；你可以在它们之上构建应用。如果你想采用 DDD 等方法，也可以把它们实现于本书所述的基础之上。

可演化性：让变化更容易

系统的需求永远不变，基本是不可能的。更可能的情况是，需求总在变化：你了解了新的事实，出现了事先未曾预料的使用场景，业务优先级发生变化，用户要求新功能，新平台取代旧平台，法律或监管要求改变，系统增长迫使架构发生变化，等等。

在组织流程方面，敏捷（Agile） 工作模式为适应变化提供了框架。敏捷社区还发展出了适合在频繁变化的环境中开发软件的技术工具和流程，例如测试驱动开发（TDD）和重构。本书则会寻找一些办法，在由多个特性各异的应用程序或服务组成的系统层面上提高敏捷性。

修改数据系统、使其适应不断变化的需求有多容易，与系统的简单性和抽象密切相关：松耦合、简单的系统通常比紧耦合、复杂的系统更容易修改。这个概念如此重要，因此我们用一个不同的词来指代数据系统层面的敏捷性：可演化性（evolvability） ⁹⁷。

大型系统中的某些操作不可逆，因此必须极为谨慎地执行；这是让变更变得困难的一个主要因素 ⁹⁸。例如，假设你要从一个数据库迁移到另一个数据库：如果新系统出了问题却无法切回旧系统，风险就远高于能够轻松回退的情况。尽量减少不可逆性，可以提高系统的灵活性。

总结

本章考察了几种非功能性需求：性能、可靠性、可伸缩性和可维护性。在讨论这些主题的过程中，我们还遇到了贯穿全书都要用到的一些原则和术语。本章从社交网络首页时间线的实现案例入手，说明了系统规模增大时会出现的部分挑战。

我们讨论了如何衡量性能（例如采用响应时间分位数）、如何衡量系统负载（例如采用吞吐量指标），以及怎样在 SLA 中使用这些指标。可伸缩性与此密切相关：负载增加时，怎样确保性能保持不变。我们看到了一些关于可伸缩性的通用原则，例如把一项任务拆分成彼此可以独立运行的较小部分；后续章节还会深入探讨实现可伸缩性的技术细节。

为了实现可靠性，可以采用容错技术，使系统即使有某个组件（例如硬盘、机器或另一项服务）发生故障，仍能继续提供服务。我们考察了可能发生的各种硬件故障，并把它们与软件故障区分开来；软件故障往往高度相关，因此更难处理。提高可靠性的另一方面，是增强系统抵御人为失误的能力；我们还看到，无责复盘可以帮助组织从事故中学习。

最后，我们讨论了可维护性的几个方面，包括为运维团队的工作提供支持、管理复杂度，以及让应用程序的功能更容易随时间演化。实现这些目标没有简单的答案，但采用人们熟知、能够提供实用抽象的构件来搭建应用程序，确实会有所帮助。本书余下部分将介绍一系列已经在实践中证明颇有价值的构件。

参考文献

3 数据模型与查询语言

我的语言的边界，意味着我的世界的边界。

路德维希・维特根斯坦，《逻辑哲学论》（1922）

数据模型可能是软件开发中最重要的部分了，因为它们的影响如此深远：不仅仅影响着软件的编写方式，而且影响着我们的 解题思路。

多数应用使用层层叠加的数据模型构建。对于每层数据模型的关键问题是：它是如何用低一层数据模型来 表示 的？例如：

1. 作为一名应用开发人员，你观察现实世界（里面有人员、组织、货物、行为、资金流向、传感器等），并采用对象或数据结构，以及操控那些数据结构的 API 来进行建模。那些结构通常是特定于应用程序的。
2. 当要存储那些数据结构时，你可以利用通用数据模型来表示它们，如 JSON 或 XML 文档、关系数据库中的表，或者图中的顶点和边。这些数据模型正是本章的主题。
3. 构建数据库软件的工程师决定如何以内存、磁盘或网络上的字节来表示文档、关系或图数据。这类表示形式使数据有可能以各种方式来查询、搜索、操纵和处理。我们将在 第 4 章 讨论这些存储引擎的设计。
4. 在更低的层次上，硬件工程师已经想出了使用电流、光脉冲、磁场或者其他东西来表示字节的方法。

一个复杂的应用程序可能会有更多的中间层次，比如基于 API 的 API，不过基本思想仍然是一样的：每个层都通过提供一个明确的数据模型来隐藏更低层次中的复杂性。这些抽象允许不同的人群有效地协作，例如数据库厂商的工程师和使用数据库的应用程序开发人员。

实践中广泛使用着几种不同的数据模型，通常各有用途。某些类型的数据和查询在一种模型中很容易表达，在另一种模型中却很别扭。本章将比较 关系模型（relational model）、文档模型（document model）、图数据模型（graph data model）、事件溯源（event sourcing）和 数据框（dataframe），探讨其中的权衡。我们还将简要介绍操作这些模型的查询语言，帮助你判断何时应该使用哪种模型。

关系模型与文档模型

如今最广为人知的数据模型或许是 SQL 所采用的关系模型，它由 Edgar Codd 于 1970 年提出 ³：数据被组织成 关系（relation，SQL 称之为 表，table），每个关系都是由 元组（tuple，SQL 称之为 行，row）构成的无序集合。

关系模型最初只是一项理论提议，当时许多人怀疑它能否得到高效实现。然而到了 20 世纪 80 年代中期，对于大多数需要存储和查询具有某种规则结构的数据的人来说，关系数据库管理系统（RDBMS）和 SQL 已成为首选工具。几十年过去，关系数据仍主导着许多数据管理场景，例如商业分析（参见 “星型与雪花型：分析模式”）。

多年来，数据存储和查询领域涌现过许多彼此竞争的方法。20 世纪 70 年代至 80 年代初，网状模型（network model）和 层次模型（hierarchical model）是关系模型的主要对手，但最终都败下阵来。对象数据库在 20 世纪 80 年代末至 90 年代初兴起后又销声匿迹；XML 数据库于 21 世纪初出现，却始终只在少数场景中得到采用。关系模型的每个竞争者都曾盛极一时，但无一长久 ⁴。反倒是 SQL 在关系模型这个核心之上不断吸收其他数据类型，例如增加了对 XML、JSON 和图数据的支持 ⁵。

到了 2010 年代，NoSQL 成了试图撼动关系数据库统治地位的最新流行语。NoSQL 并非某项特定技术，而是围绕新数据模型、模式灵活性、可伸缩性和开源许可模式形成的一组宽泛理念。另一些数据库则以 NewSQL 自居，力图在保留传统关系数据库的数据模型和事务保证的同时，提供 NoSQL 系统的可伸缩性。NoSQL 和 NewSQL 的理念深刻影响了数据系统的设计；不过，随着这些原则被广泛吸收，两个术语本身已渐渐淡出。

NoSQL 运动留下的一项持久影响，是通常以 JSON 表示数据的 文档模型（document model）广受欢迎。这个模型最初由 MongoDB、Couchbase 等专用文档数据库推广，如今大多数关系数据库也已加入 JSON 支持。关系表的模式常被视为严格而僵化，相比之下，JSON 文档被认为更加灵活。

文档数据与关系数据孰优孰劣，已经引发过大量争论。下面来看看其中几个关键问题。

对象关系不匹配

如今，大量应用开发使用面向对象的编程语言，这也引出了针对 SQL 数据模型的一项常见批评：数据若存储在关系表中，就需要一个笨拙的转换层，在应用代码中的对象与数据库的表、行、列模型之间来回转换。两种模型之间的这种脱节，有时称为 阻抗不匹配（impedance mismatch）。

对象关系映射（ORM）

ActiveRecord、Hibernate 等对象关系映射（ORM）框架减少了转换层所需的样板代码，但也时常遭到批评 ⁶。常见问题包括：

• ORM 本身很复杂，也无法彻底掩盖两种模型的差异，开发者最终仍得同时考虑数据的关系表示和对象表示。
• ORM 一般只用于开发 OLTP 应用（参见 “事务处理与分析的特征”）。为了让数据可供分析，数据工程师仍须面对底层的关系表示，因此采用 ORM 并不意味着关系模式的设计不再重要。
• 许多 ORM 只面向关系型 OLTP 数据库。若组织还使用搜索引擎、图数据库、NoSQL 系统等多种数据系统，ORM 提供的支持可能远远不够。
• 有些 ORM 会自动生成关系模式，但生成的模式对直接访问关系数据的用户未必友好，在底层数据库上也可能效率不佳。要定制 ORM 生成模式与查询的方式，往往相当复杂，甚至会抵消采用 ORM 原本想获得的好处。
• 使用 ORM 很容易在无意中写出低效查询，例如触发 N+1 查询问题（N+1 query problem）⁷。假设你要在页面上显示用户评论列表：先用一条查询取回 N 条评论，每条都含有作者 ID；为了显示作者姓名，还要用这个 ID 查询用户表。手写 SQL 时，你大概会直接在查询中连接用户表，让每条评论连同作者姓名一起返回；使用 ORM 时，却可能对 N 条评论逐条查询用户表，最终一共执行 N+1 条数据库查询。这比在数据库内完成连接要慢得多。为避免这个问题，你可能必须明确要求 ORM 在获取评论的同时一并取回作者信息。

不过，ORM 也自有其优势：

• 对适合关系模型的数据来说，持久化的关系表示与内存中的对象表示之间总要进行某种转换，ORM 可以减少这类转换所需的样板代码。复杂查询或许仍须绕开 ORM 处理，但简单、重复的场景正适合交给它。
• 有些 ORM 可以缓存数据库查询结果，从而减轻数据库负载。
• ORM 还可以协助管理模式迁移和其他数据库管理工作。

用于一对多关系的文档数据模型

并非所有数据都适合用关系形式表示。下面用一个例子看看关系模型的局限。图 3-1 展示了如何用关系模式表示一份简历（LinkedIn 个人资料）。整份资料由唯一标识符 user_id 标识；first_name 和 last_name 等字段对每位用户只出现一次，因此可以建模为 users 表中的列。

大多数人的职业生涯中都不止有一份工作（即多个职位），每个人的教育经历数量也不相同，联系方式更可能有任意多项。这些 一对多关系（one-to-many relationship）可以这样表示：把职位、教育经历和联系信息分别放在单独的表中，再通过外键引用 users 表，如 图 3-1 所示。

同一份信息还可以表示为 JSON 文档，如 示例 3-1 所示。这种形式可能更为自然，也更贴近应用代码中的对象结构。

{
    "user_id": 251,
    "first_name": "Barack",
    "last_name": "Obama",
    "headline": "Former President of the United States of America",
    "region_id": "us:91",
    "photo_url": "/p/7/000/253/05b/308dd6e.jpg",
    "positions": [
        {"job_title": "President", "organization": "United States of America"},
        {"job_title": "US Senator (D-IL)", "organization": "United States Senate"}
    ],
    "education": [
        {"school_name": "Harvard University", "start": 1988, "end": 1991},
        {"school_name": "Columbia University", "start": 1981, "end": 1983}
    ],
    "contact_info": {
        "website": "https://barackobama.com",
        "twitter": "https://twitter.com/barackobama"
    }
}

一些开发者认为，JSON 模型减轻了应用代码与存储层之间的阻抗不匹配。不过，正如我们将在 第 5 章 看到的，JSON 用作数据编码格式时也有不少问题。没有模式常被视为它的一项优势，我们将在 “文档模型中的模式灵活性” 进一步讨论。

与 图 3-1 的多表模式相比，JSON 表示具有更好的 局部性（参见 “读写的数据局部性”）。在关系模型的例子中，要取回一份个人资料，要么执行多次查询（按 user_id 分别查询每张表），要么在 users 表及其下属表之间进行繁琐的多路连接 ⁸。而在 JSON 表示中，所有相关信息都集中在一处，查询既简单又快捷。

个人资料与职位、教育经历、联系信息之间的一对多关系，在数据中形成了一棵树；JSON 表示则明确呈现了这种树状结构（见 图 3-2）。

规范化、反规范化与连接

前一节的 示例 3-1 用 ID 表示 region_id，而没有直接写成纯文本字符串 "Washington, DC, United States"。为什么要这样做？

如果用户界面提供自由文本框让用户填写地区，那么把输入直接存成文本字符串很合理。不过，预先提供标准化的地理区域列表，让用户通过下拉列表或自动补全来选择，也有不少好处：

• 所有个人资料中的格式和拼写保持一致
• 避免同名地点造成歧义（若字符串只有 “Washington”，究竟是指华盛顿特区，还是华盛顿州？）
• 便于更新——名称只存储在一处，将来如有变动（例如因政治事件而更改城市名称），只改一处便能全局生效
• 支持本地化——网站翻译成其他语言时，可以本地化这份标准列表，让地区名称以浏览者使用的语言显示
• 改善搜索——例如，地区列表可以记录华盛顿位于美国东海岸这一事实（单看 "Washington, DC" 字符串无法得知），于是搜索美国东海岸的人时也能匹配这份资料

选择存储 ID 还是文本字符串，实质上是在决定是否 规范化（normalization）。使用 ID 时，数据更加规范化：对人有意义的信息（如 Washington, DC 这段文字）只存储一份，其他地方都用仅在数据库内有意义的 ID 来引用它。若直接存储文本，这段有意义的信息就会复制到每条使用它的记录中；这样的表示便是 反规范化（denormalized）的。

ID 的好处在于，它本身对人没有意义，因而永远不必改变：即使 ID 所标识的信息发生了变化，ID 仍可保持不变。凡是对人有意义的信息，将来都有可能需要修改；一旦这类信息被复制，所有冗余副本就都得随之更新。这不仅需要更多代码、写入操作和磁盘空间，还会带来不一致的风险——有些副本已经更新，另一些却没有。

规范化表示也有代价：每次显示含有 ID 的记录时，都要多做一次查找，把 ID 解析成人能读懂的信息。在关系数据模型中，这项工作通过 连接（join）完成，例如：

SELECT users.*, regions.region_name
    FROM users
    JOIN regions ON users.region_id = regions.id
    WHERE users.id = 251;

文档数据库既能存储规范化数据，也能存储反规范化数据，但人们往往把它与反规范化联系在一起。一方面，JSON 数据模型很容易加入额外的反规范化字段；另一方面，许多文档数据库对连接支持较弱，采用规范化表示很不方便。有些文档数据库完全不支持连接，只能在应用代码中自行完成：先取回含有 ID 的文档，再发起第二次查询，用 ID 找到另一个文档。MongoDB 也可以通过聚合管道中的 $lookup 算子执行连接：

db.users.aggregate([
    { $match: { _id: 251 } },
    { $lookup: {
        from: "regions",
        localField: "region_id",
        foreignField: "_id",
        as: "region"
    } }
])

规范化的权衡

在简历示例中，region_id 字段引用了标准化的地区集合，organization（任职的公司或政府机构）和 school_name（就读的学校）却只是字符串。这是一种反规范化表示：许多人或许曾在同一家公司工作，但这些记录并没有通过 ID 关联起来。

那么，是否应该把组织和学校也建模为实体，让个人资料引用其 ID，而不是直接写下名称？主张用 ID 引用地区的理由在这里同样成立。比如，假设除了名称之外，我们还想显示学校或公司的徽标：

• 采用反规范化表示时，每个人的个人资料都要包含徽标图片的 URL。这样固然让 JSON 文档自给自足，但徽标一旦更换，就必须找出旧 URL 出现的每个地方并逐一更新，十分麻烦 ⁹。
• 采用规范化表示时，可以建立一个代表组织或学校的实体，只在其中存储一次名称、徽标 URL，也许再加上简介、动态消息等属性。所有提及该组织的简历只引用其 ID，更新徽标便易如反掌。

一般来说，规范化数据写入较快（因为只有一个副本），查询却较慢（因为需要连接）；反规范化数据通常读取较快（连接更少），写入代价却更高（要更新更多副本，也占用更多磁盘空间）。把反规范化看作一种衍生数据或许很有帮助（参见 “权威记录系统与衍生数据”），因为你必须建立相应流程来更新那些冗余的数据副本。

除了更新本身的成本，还要考虑进程在更新中途崩溃时，数据库能否保持一致。支持原子事务的数据库（参见 “原子性”）更容易维护一致性，但并非所有数据库都能为跨多个文档的操作提供原子性。也可以利用流处理来保证一致性，我们将在 “保持系统同步” 讨论这种方法。

规范化往往更适合读写都要迅速完成的 OLTP 系统；分析系统通常更适合反规范化数据，因为它们会批量更新，首要关心的是只读查询的性能。此外，中小规模系统通常也更适合规范化数据模型：既不必费心维持多个副本的一致，执行连接的成本也还可以接受。不过到了超大规模，连接的代价就可能成为问题。

社交网络案例研究中的反规范化

在 “案例研究：社交网络首页时间线” 中，我们比较了规范化表示（图 2-1）和反规范化表示（预计算并物化的时间线）。在那个例子里，连接 posts 与 follows 的成本太高，于是物化时间线充当了连接结果的缓存；把新帖子扇出到关注者的时间线，正是维持这种反规范化表示一致的手段。

不过，X（原 Twitter）的物化时间线实际上并不保存每条帖子的正文。每个条目只存储帖子 ID、发帖用户的 ID，以及少量用于识别转帖和回复的附加信息 ¹¹。换句话说，它大致相当于预先算好了下面这条查询的结果：

SELECT posts.id, posts.sender_id 
    FROM posts
    JOIN follows ON posts.sender_id = follows.followee_id
    WHERE follows.follower_id = current_user
    ORDER BY posts.timestamp DESC
    LIMIT 1000

因此，每次读取时间线时，服务仍要做两次连接：按帖子 ID 取回正文，以及点赞数、回复数等统计信息；再按发帖用户 ID 取回其用户名、头像和其他资料。这个把 ID 补全为人类可读信息的过程称为 补全 ID（hydrating IDs），本质上就是在应用代码中完成连接 ¹¹。

预计算时间线之所以只存 ID，是因为 ID 所指向的数据变化很快：热门帖子的点赞数和回复数每秒都可能变化多次，有些用户也会经常更换用户名或头像。时间线在展示时应呈现最新的点赞数和头像，所以把这些信息反规范化到物化时间线中并不合理，而且还会大幅增加存储成本。

这个例子说明，读取数据时需要执行连接，并不像有些说法所称的那样，会妨碍我们构建高性能、可伸缩的服务。补全帖子 ID 和用户 ID 其实相当容易伸缩：这项工作很适合并行执行，而且成本既不取决于你关注了多少账户，也不取决于有多少人关注你。

如果要判断应用中的某项数据是否应该反规范化，社交网络案例表明答案并不显而易见：可伸缩性最好的方案，可能是把一部分数据反规范化，同时让另一部分保持规范化。你必须仔细权衡信息的变化频率与读写成本；而成本又可能由极端情况主导，例如社交网络中关注或被关注人数异常多的用户。规范化与反规范化本身无所谓好坏，不过是在读写性能和实现成本之间作取舍。

多对一与多对多关系

图 3-1 中的 positions 和 education 是一对多（或一对少）关系：一份简历有多个职位，但每个职位只属于一份简历。相比之下，region_id 字段表示 多对一（many-to-one）关系：许多人住在同一个地区，而我们假设任一时刻每个人只住在一个地区。

如果进一步把组织和学校建模为实体，让简历通过 ID 引用它们，就会出现 多对多（many-to-many）关系：一个人曾在多个组织任职，一个组织也有多名现任或前任员工。在关系模型中，这类关系通常用 关联表（associative table，也称 连接表，join table）表示，如 图 3-3 所示：每个职位把一个用户 ID 与一个组织 ID 关联起来。

多对一和多对多关系很难塞进一个自包含的 JSON 文档，它们更适合规范化表示。示例 3-2 给出了文档模型中的一种方案，图 3-4 则以图示说明：每个虚线框内的数据可以组成一份文档，但指向组织和学校的链接最好表示为对其他文档的引用。

{
    "user_id": 251,
    "first_name": "Barack",
    "last_name": "Obama",
    "positions": [
        {"start": 2009, "end": 2017, "job_title": "President", "org_id": 513},
        {"start": 2005, "end": 2008, "job_title": "US Senator (D-IL)", "org_id": 514}
    ],
    ...
}

多对多关系通常需要从“两个方向”查询：既要找出某人任职过的所有组织，也要找出曾在某组织任职的所有人。一种做法是在关系两端都保存 ID 引用：简历列出此人任职过的各个组织 ID，组织文档也列出提及该组织的简历 ID。由于同一关系存储了两份，这是一种反规范化表示，两边可能彼此不一致。

规范化表示只在一处存储关系，再依靠 二级索引（secondary index；将在 第 4 章 讨论）从两个方向高效查询。图 3-3 的关系模式中，可以让数据库分别为 positions 表的 user_id 列和 org_id 列建立索引。

在 示例 3-2 的文档模型中，数据库则需要索引 positions 数组内各对象的 org_id 字段。许多文档数据库以及支持 JSON 的关系数据库，都能为文档内部的值建立这种索引。

星型与雪花型：分析模式

数据仓库（参见 “数据仓库”）通常采用关系模型，其表结构有几种广泛使用的惯例：星型模式（star schema）、雪花模式（snowflake schema）、维度建模（dimensional modeling）¹²，以及 一张大表（OBT）。这些结构针对业务分析师的需求进行了优化，ETL 过程则负责把事务型系统中的数据转换成这种模式。

图 3-5 中的示例模式，可能出现在一家食品零售商的数据仓库中。模式的中心是所谓的 事实表（fact table；本例中名为 fact_sales）。事实表的每一行代表在特定时间发生的事件；在这里，每行代表客户购买了一件产品。如果分析的是网站流量而不是零售量，那么每行可能代表一次页面浏览或一次用户点击。

通常会把每项事实记录为独立事件，因为这样能为日后的分析保留最大的灵活性。不过，这也意味着事实表可能变得极其庞大。大型企业的数据仓库可能保存着许多 PB 的交易历史，其中大部分都以事实表表示。

事实表中的一些列是属性，例如产品的售价和从供应商处购入的成本（据此可以计算利润率）。另一些列是指向其他表的外键引用，这些表称为 维度表（dimension table）。由于事实表的每一行表示一个事件，各个维度便代表事件发生的对象、内容、地点、时间、方式和原因。

例如，图 3-5 中的一个维度是售出的产品。dim_product 表中的每一行代表一种待售产品，包括库存单位（SKU）、产品描述、品牌名称、类别、脂肪含量、包装尺寸等。fact_sales 表的每一行都用外键表明该笔交易售出了哪种产品。查询往往要连接多个维度表。

甚至日期和时间也常用维度表表示，以便编码公共假期等额外信息，让查询可以区分节假日与平日的销售情况。

图 3-5 展示的便是星型模式。这个名称源自表关系的可视化形状：事实表位于中央，周围环绕着维度表；连接这些表的线条就像星星的光芒。

这个模板的变体称为 雪花模式，其中的维度会进一步分解成子维度。例如，可以为品牌和产品类别分别建表，让 dim_product 的每一行以外键引用品牌与类别，而不再把它们作为字符串直接存入 dim_product 表。雪花模式比星型模式更规范化，但星型模式通常更受青睐，因为分析师使用起来更简单 ¹²。

典型数据仓库中的表通常非常宽：事实表往往超过 100 列，有时甚至有数百列。维度表也可能很宽，因为它们会收录所有可能与分析相关的元数据。例如，dim_store 表可能记录每家商店提供哪些服务、是否设有店内面包房、店面面积、首次开业日期、最近一次改造时间，以及离最近的高速公路有多远，等等。

星型模式和雪花模式主要由多对一关系构成，例如许多笔销售对应同一种产品、同一家商店。这些关系表现为事实表指向维度表的外键，或维度表指向子维度表的外键。原则上也可以存在其他类型的关系，但为了简化查询，通常会把它们反规范化。例如，顾客一次买了几种不同产品时，这笔多商品交易不会得到显式表示；事实表只是为每件商品各存一行，而这些事实恰好具有相同的顾客 ID、商店 ID 和时间戳。

有些数据仓库模式更进一步，完全省去维度表，把维度信息放进事实表的反规范化列中——实质上就是预先计算事实表与维度表的连接。这种方法称为 一张大表（OBT）；它虽然占用更多存储空间，有时却能让查询更快 ¹³。

在分析场景中，这样反规范化通常不成问题，因为数据往往是一份不会再改变的历史记录（偶尔纠正错误除外）。反规范化在 OLTP 系统中带来的数据一致性问题和写入开销，在分析系统里没有那么紧迫。

何时使用哪种模型

支持文档数据模型的主要论据是模式灵活性、因局部性而拥有更好的性能，以及对于某些应用程序而言，它更接近应用程序使用的对象模型。关系模型则以更好地支持连接、多对一和多对多关系作为回应。下面逐一详细考察这些论点。

如果应用程序中的数据具有类似文档的结构（即一对多关系树，通常一次性加载整棵树），那么使用文档模型可能是个好主意。把类似文档的结构 拆散 到多个表中（如 图 3-1 中的 positions、education 和 contact_info），可能导致繁琐的模式和不必要的复杂应用程序代码。

文档模型有一定的局限性：例如，不能直接引用文档中的嵌套项目，而是需要说“用户 251 的职位列表中的第二项”。如果确实需要引用嵌套项目，关系模型更合适，因为任何项目都能通过自身 ID 被直接引用。

有些应用允许用户自行安排项目顺序。例如，在待办事项清单或问题跟踪器中，用户可以拖放任务来重新排序。文档模型很适合这类应用，只需把项目（或项目 ID）按顺序存入 JSON 数组即可。关系数据库没有表示这种可重新排序列表的标准方式，只能借助各种技巧：按整数列排序（在中间插入时需要重新编号）、用 ID 构成链表，或者使用分数索引 ^{14 15 16}。

文档模型中的模式灵活性

大多数文档数据库以及关系数据库中的 JSON 支持，都不会强制文档中的数据采用何种模式。关系数据库的 XML 支持通常带有可选的模式验证。没有模式意味着可以向文档中添加任意键和值；读取时，客户端也无法确定文档究竟会包含哪些字段。

文档数据库有时称为 无模式（schemaless），但这具有误导性，因为读取数据的代码通常假定某种结构——即存在隐式模式，只是不由数据库强制执行 ¹⁷。一个更准确的术语是 读时模式（schema-on-read，数据结构是隐含的，只有读取时才会解释），与之相对的是 写时模式（schema-on-write，关系数据库的传统做法：模式是明确的，数据库确保写入的所有数据都符合模式）¹⁸。

读时模式类似于编程语言中的动态（运行时）类型检查，而写时模式类似于静态（编译时）类型检查。就像静态与动态类型检查孰优孰劣一直争议不断 ¹⁹，数据库是否应该强制执行模式也是个见仁见智的问题，通常并没有绝对的对错。

当应用程序想要改变数据格式时，两种方法的区别尤其明显。例如，假设原先把每位用户的全名存储在一个字段中，现在想把名和姓分开存储 ²⁰。在文档数据库中，只需开始写入带有新字段的文档，并在应用程序中加入代码来处理旧文档即可。例如：

if (user && user.name && !user.first_name) {
    // 2023 年 12 月 8 日之前写入的文档没有 first_name
    user.first_name = user.name.split(" ")[0];
}

这种方法的缺点是，应用中每个读取数据库的部分，从此都必须处理可能在很久以前写入的旧格式文档。另一方面，在写时模式数据库中，通常会执行下面这样的 迁移：

ALTER TABLE users ADD COLUMN first_name text DEFAULT NULL;
UPDATE users SET first_name = split_part(name, ' ', 1); -- PostgreSQL
UPDATE users SET first_name = substring_index(name, ' ', 1); -- MySQL

在大多数关系数据库中，即使面对大表，添加带默认值的列也又快又稳妥。不过，在大表上执行 UPDATE 可能很慢，因为每一行都必须重写；其他模式操作（例如修改某列的数据类型）通常也需要复制整张表。

有多种工具可以在后台完成这类模式变更而无须停机 ^{21 22 23 24}，但在大型数据库上进行这种迁移，运维起来依然颇具挑战。要避开复杂迁移，可以只快速添加一个默认值为 NULL 的 first_name 列，然后在读取时填充它，就像使用文档数据库那样。

如果集合中的项目因为某种原因并不都具有相同结构（即数据是异构的），读时模式更具优势。例如：

• 存在许多不同类型的对象，将每种对象分别放进一张表并不现实。
• 数据结构由你无法控制、且随时可能改变的外部系统决定。

在上述情况下，模式可能弊大于利，无模式文档反而是更自然的数据模型。但是，如果所有记录都应具有相同结构，那么模式就是记录并强制这种结构的有效机制。我们将在 第 5 章 更详细地讨论模式和模式演化。

读写的数据局部性

文档通常以单个连续字符串的形式存储，编码为 JSON、XML 或其二进制变体（如 MongoDB 的 BSON）。如果应用程序经常需要访问整个文档（例如把它渲染到网页上），这种 存储局部性 会带来性能优势。如果数据像 图 3-1 那样分散在多张表中，就需要多次查找索引才能检索完整，可能产生更多磁盘寻道并花费更长时间。

局部性优势只适用于同时需要文档绝大部分内容的情况。即使只访问大型文档的一小部分，数据库通常也要加载整个文档，这会造成浪费；更新时一般还要重写整个文档。因此，通常建议让文档保持较小，并避免频繁地对文档做小幅更新。

不过，为了局部性而把相关数据存储在一起，并非文档模型的专利。例如，Google 的 Spanner 数据库在关系模型中也提供同样的局部性属性，允许模式声明某张表的行应交错（嵌套）在父表之中 ²⁵。Oracle 也用名为 多表索引集群表（multi-table index cluster table）的功能提供类似能力 ²⁶。由 Google Bigtable 推广、并被 HBase 和 Accumulo 等系统采用的 宽列（wide-column）数据模型，则以 列族（column family）概念达到相似的局部性管理目的 ²⁷。

文档的查询语言

关系数据库和文档数据库的另一个区别，在于查询所用的语言或 API。大多数关系数据库使用 SQL，文档数据库则五花八门：有些只允许按主键进行键值访问，有些还提供二级索引来查询文档内部的值，还有些配有功能丰富的查询语言。

XML 数据库通常使用 XQuery 和 XPath；它们支持包括跨文档连接在内的复杂查询，还能把结果格式化为 XML ²⁸。JSON Pointer ²⁹ 和 JSONPath ³⁰ 则为 JSON 提供了与 XPath 相当的功能。

MongoDB 的聚合管道就是一种面向 JSON 文档集合的查询语言；我们在 “规范化、反规范化与连接” 中已经见过它用于连接的 $lookup 算子。

再看一个例子来体会这种语言，这次考察分析中尤为常见的聚合。假设你是一名海洋生物学家，每当在海中看到动物，就向数据库添加一条观察记录。现在你想生成一份报告，说明每个月观察到多少条鲨鱼。在 PostgreSQL 中，可以像这样表述查询：

SELECT date_trunc('month', observation_timestamp) AS observation_month, ❶ 
    sum(num_animals) AS total_animals
FROM observations
WHERE family = 'Sharks'
GROUP BY observation_month;

❶：date_trunc('month', timestamp) 函数确定 timestamp 所在的日历月份，并返回代表该月起点的另一个时间戳。换句话说，它把时间戳向下舍入到最近的月份。

这个查询首先过滤观察记录，只保留鲨鱼科的物种；然后按观察发生的日历月份分组；最后，把该月所有观察记录中的动物数量相加。同一个查询可以用 MongoDB 的聚合管道表示如下：

db.observations.aggregate([
    { $match: { family: "Sharks" } },
    { $group: {
    _id: {
        year: { $year: "$observationTimestamp" },
        month: { $month: "$observationTimestamp" }
    },
    totalAnimals: { $sum: "$numAnimals" }
    } }
]);

聚合管道语言的表达能力与 SQL 的一个子集相当，不过它采用基于 JSON 的语法，而不是 SQL 那种接近英语句式的语法；这种差异或许只是口味问题。

文档和关系数据库的融合

文档数据库和关系数据库最初采用截然不同的数据管理方法，但随着时间推移，两者变得越来越相似 ³¹。关系数据库增加了对 JSON 类型和查询算子的支持，也能够为文档内部的属性建立索引；MongoDB、Couchbase、RethinkDB 等文档数据库，则增加了连接、二级索引和声明式查询语言。

这种融合对应用程序开发人员来说是件好事，因为关系模型和文档模型能够在同一个数据库中结合使用时，最能发挥各自所长。许多文档数据库需要以关系模型的方式引用其他文档，许多关系数据库也有些部分会受益于模式灵活性。关系模型与文档模型的混合是一种强大的组合。

图数据模型

如我们之前所见，关系的类型是区分不同数据模型的一项重要特征。如果应用程序中的关系大多是一对多关系（树状结构数据），而记录之间很少存在其他关系，那么文档模型是合适的。

但是，如果多对多关系在数据中十分常见呢？关系模型可以处理简单的多对多关系，但随着数据之间的连接变得越来越复杂，将数据建模为图就显得更加自然。

一个图由两种对象组成：顶点（vertices，也称为 节点，即 nodes，或 实体，即 entities）和 边（edges，也称为 关系，即 relationships，或 弧，即 arcs）。多种数据都可以建模为图，典型的例子包括：

社交图

顶点是人，边表示哪些人相互认识。

网页图

顶点是网页，边表示指向其他页面的 HTML 链接。

道路或铁路网络

顶点是交叉点，边表示它们之间的道路或铁路线。

可以把许多众所周知的算法运用到这些图上。例如，地图导航应用会搜索道路网络中两点之间的最短路径；PageRank 可以用在网页图上，判断网页的流行程度，进而决定它在搜索结果中的排名 ³²。

图可以用几种不同的方式表示。在 邻接表（adjacency list）模型中，每个顶点都保存与它相隔一条边的相邻顶点 ID。另一种方式是 邻接矩阵（adjacency matrix）：这是一个二维数组，每行、每列各对应一个顶点；行顶点与列顶点之间没有边时，值为 0，有边时则为 1。邻接表适合图遍历，邻接矩阵则适合机器学习（参见 “数据框、矩阵与数组”）。

在刚才给出的例子中，图里的所有顶点都表示同一种事物，分别是人、网页或道路交叉口。不过，图并不局限于这种 同质（homogeneous）数据：图还有一项同样强大的用途，就是以一致的方式在单个数据库中存储截然不同的对象。例如：

• Facebook 维护着一个包含许多不同类型顶点和边的图：顶点表示人、地点、事件、签到和用户评论；边表示哪些人是朋友、某次签到发生在哪里、谁评论了哪篇帖子、谁参加了哪场活动，等等 ³³。
• 搜索引擎用知识图谱来记录查询中经常出现的组织、人物、地点等实体的事实 ³⁴。这些信息来自对网站的抓取与文本分析；Wikidata 等网站也会以结构化形式发布图数据。

有几种不同但彼此相关的方式，可以用来组织和查询图中的数据。本节将讨论 属性图（property graph）模型（由 Neo4j、Memgraph、KùzuDB ³⁵ 等系统实现 ³⁶）和 三元组存储（triple store）模型（由 Datomic、AllegroGraph、Blazegraph 等系统实现）。两种模型的表达能力相当接近，Amazon Neptune 等图数据库还同时支持二者。

我们还将介绍四种图查询语言（Cypher、SPARQL、Datalog 和 GraphQL），以及 SQL 对图查询的支持。其他图查询语言还有 Gremlin 等 ³⁷，不过这里选取的几种已足以给出一幅有代表性的全景。

为了说明这些语言和模型，本节将以 图 3-6 为贯穿全节的例子。它可以取自社交网络或家谱数据库：图中有两个人，来自爱达荷州的 Lucy 和来自法国圣洛的 Alain。他们已经结婚，现居伦敦。每个人和每个地点都表示为顶点，彼此之间的关系则表示为边。这个例子将展示一些在图数据库中很容易、在其他模型中却很难表达的查询。

属性图

在 属性图（也称 带标签属性图，labeled property graph）模型中，每个顶点包括：

• 唯一标识符
• 一个标签（字符串），描述该顶点所表示的对象类型
• 一组出边
• 一组入边
• 一组属性（键值对）

每条边包括：

• 唯一标识符
• 边的起点（尾部顶点，即 tail vertex）
• 边的终点（头部顶点，即 head vertex）
• 一个标签，描述两个顶点之间的关系类型
• 一组属性（键值对）

可以把图存储看成两个关系表：一张存储顶点，另一张存储边，如 示例 3-3 所示（该模式使用 PostgreSQL 的 jsonb 数据类型存储每个顶点或每条边的属性）。每条边都保存头部顶点和尾部顶点；如果想找出某个顶点的所有入边或出边，可以分别按 head_vertex 或 tail_vertex 查询 edges 表。

CREATE TABLE vertices (
    vertex_id integer PRIMARY KEY,
    label text,
    properties jsonb
);

CREATE TABLE edges (
    edge_id integer PRIMARY KEY,
    tail_vertex integer REFERENCES vertices (vertex_id),
    head_vertex integer REFERENCES vertices (vertex_id),
    label text,
    properties jsonb
);

CREATE INDEX edges_tails ON edges (tail_vertex);
CREATE INDEX edges_heads ON edges (head_vertex);

这个模型有几个重要特点：

1. 任何顶点都可以通过边连接到任何其他顶点。没有模式限制哪些事物可以关联，哪些不可以。
2. 给定任意顶点，都能高效地找到它的入边和出边，从而双向 遍历 图——即沿着一系列顶点构成的路径前后移动。（这正是 示例 3-3 同时为 tail_vertex 和 head_vertex 列建立索引的原因。）
3. 为不同类型的顶点和关系使用不同的标签，就可以在一个图中存储多种不同的信息，同时仍保持清晰的数据模型。

边表就像我们在 “多对一与多对多关系” 看到的多对多关联表（连接表），只不过经过了泛化，可以在同一张表中存储许多不同类型的关系。标签和属性也可以建立索引，以便高效查找具有某种属性的顶点或边。

这些特性为数据建模提供了很大的灵活性，如 图 3-6 所示。图中有一些传统关系模式难以表达的事物，例如不同国家采用不同的行政区划结构（法国有 省 和 大区，美国有 县 和 州）、国中之国这样的历史怪事（暂且忽略主权国家与民族错综复杂的关系），以及粒度不一的数据（Lucy 现在的住所具体到城市，而出生地只记录到州）。

可以想象，这个图还能够扩展出关于 Lucy、Alain 或其他人的许多事实。例如，可以用它表示食物过敏：为每种过敏原增加一个顶点，用人与过敏原之间的边表示过敏，再把过敏原连接到一组说明哪些食物含有哪些物质的顶点。这样就能写一条查询，找出每个人可以安全食用的东西。图在可演化性方面很有优势：随着应用程序不断增加功能，可以轻松扩展图来适应数据结构的变化。

Cypher 查询语言

Cypher 是属性图的查询语言，最初为 Neo4j 图数据库而创，后来以 openCypher 之名发展为开放标准 ³⁸。除了 Neo4j，Memgraph、KùzuDB ³⁵、Amazon Neptune、Apache AGE（数据存储在 PostgreSQL 中）等系统也支持 Cypher。它以电影《黑客帝国》中的角色命名，与密码学中的密码并无关系 ³⁹。

示例 3-4 展示了把 图 3-6 左侧部分插入图数据库的 Cypher 查询，图的其余部分也可以用同样方式加入。每个顶点都有一个 usa 或 idaho 之类的符号名称。该名称不会存入数据库，只在查询内部用来创建顶点之间的边。箭头记法 (idaho) -[:WITHIN]-> (usa) 会创建一条标签为 WITHIN 的边，以 idaho 为尾节点、usa 为头节点。

CREATE
    (namerica :Location {name:'North America', type:'continent'}),
    (usa :Location {name:'United States', type:'country' }),
    (idaho :Location {name:'Idaho', type:'state' }),
    (lucy :Person {name:'Lucy' }),
    (idaho) -[:WITHIN ]-> (usa) -[:WITHIN]-> (namerica),
    (lucy) -[:BORN_IN]-> (idaho)

把 图 3-6 的所有顶点和边加入数据库后，就可以提出一些有趣的问题。例如：找出所有从美国移居欧洲的人的姓名。更确切地说，我们要找出同时具有一条指向美国境内某地的 BORN_IN 边，以及一条指向欧洲境内某地的 LIVES_IN 边的顶点，并返回这些顶点的 name 属性。

示例 3-5 展示了如何用 Cypher 表述这个查询。MATCH 子句使用同样的箭头记法在图中寻找模式：(person) -[:BORN_IN]-> () 匹配由一条 BORN_IN 边相连的任意两个顶点；这条边的尾部顶点绑定到变量 person，头部顶点则不命名。

MATCH
    (person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (:Location {name:'United States'}),
    (person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (:Location {name:'Europe'})
RETURN person.name

这条查询可以这样解读：

找出满足以下 两个 条件的所有顶点（称为 person）：

1. person 顶点有一条指向某个顶点的 BORN_IN 出边。从那里沿着一系列 WITHIN 出边前进，最终能到达一个类型为 Location、name 属性为 "United States" 的顶点。
2. 同一个 person 顶点还有一条 LIVES_IN 出边。沿着该边，再沿一系列 WITHIN 出边前进，最终能到达一个类型为 Location、name 属性为 "Europe" 的顶点。

对每个这样的 person 顶点，返回其 name 属性。

执行这条查询有几种可行的方式。上面的描述暗示，可以先扫描数据库中的所有人，逐一检查出生地和居住地，只返回符合条件的人。

等价地，也可以从两个 Location 顶点开始反向查找。如果 name 属性建有索引，就能高效找到代表美国和欧洲的两个顶点。然后沿着所有 WITHIN 入边，分别找出美国和欧洲境内的所有地点（州、地区、城市等）。最后，再沿这些地点顶点的 BORN_IN 或 LIVES_IN 入边找到相应的人。

SQL 中的图查询

示例 3-3 表明，可以在关系数据库中表示图数据。但是，如果图数据采用关系结构存储，还能使用 SQL 查询它吗？

答案是肯定的，但有些困难。图查询每遍历一条边，实际上都相当于与 edges 表连接一次。在关系数据库中，通常事先就知道查询需要哪些连接；而在图查询中，找到目标顶点之前可能要遍历数量不定的边，也就是说，连接次数无法预先确定。

在我们的例子中，Cypher 查询里的 () -[:WITHIN*0..]-> () 模式便是如此。一个人的 LIVES_IN 边可能指向任何层级的地点：街道、城市、区、地区、州，等等。城市可能 WITHIN 某个地区，地区又 WITHIN 某个州，州再 WITHIN 某个国家。LIVES_IN 边可能直接指向待查地点，也可能还隔着好几层地点层次。

Cypher 用 :WITHIN*0.. 非常简洁地表达了这一点：“沿着 WITHIN 边走零次或多次”。它类似于正则表达式中的 * 运算符。

从 SQL:1999 开始，可以用所谓的 递归公用表表达式（recursive common table expression，WITH RECURSIVE 语法）在查询中表示长度可变的遍历路径。示例 3-6 用这种技术在 SQL 中写出了同一个查询——查找从美国移居欧洲者的姓名。只不过，与 Cypher 相比，它的语法十分笨拙。

WITH RECURSIVE

    -- in_usa 是美国境内所有位置的顶点 ID 集合
    in_usa(vertex_id) AS (
        SELECT vertex_id FROM vertices
            WHERE label = 'Location' AND properties->>'name' = 'United States' ❶ 
      UNION
        SELECT edges.tail_vertex FROM edges ❷
            JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
            WHERE edges.label = 'within'
    ),
    
    -- in_europe 是欧洲境内所有位置的顶点 ID 集合
    in_europe(vertex_id) AS (
        SELECT vertex_id FROM vertices
            WHERE label = 'location' AND properties->>'name' = 'Europe' ❸
      UNION
        SELECT edges.tail_vertex FROM edges
            JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
            WHERE edges.label = 'within'
    ),
    
    -- born_in_usa 是所有在美国出生的人的顶点 ID 集合
    born_in_usa(vertex_id) AS ( ❹
        SELECT edges.tail_vertex FROM edges
            JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
            WHERE edges.label = 'born_in'
    ),
    
    -- lives_in_europe 是所有居住在欧洲的人的顶点 ID 集合
    lives_in_europe(vertex_id) AS ( ❺
        SELECT edges.tail_vertex FROM edges
            JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
            WHERE edges.label = 'lives_in'
    )
    
    SELECT vertices.properties->>'name'
    FROM vertices
    -- 连接以找到那些既在美国出生 *又* 居住在欧洲的人
    JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id ❻
    JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id;

❶：首先找到 name 属性为 "United States" 的顶点，把它作为 in_usa 顶点集的第一个元素。

❷：从 in_usa 集合中的顶点出发，沿所有 within 入边反向前进，把到达的顶点加入同一集合，直到所有 within 入边都被访问。

❸：从 name 属性为 "Europe" 的顶点出发，执行同样的操作，建立 in_europe 顶点集。

❹：对 in_usa 集合中的每个顶点，沿 born_in 入边找到出生在美国境内某地的人。

❺：同理，对 in_europe 集合中的每个顶点，沿 lives_in 入边找到居住在欧洲的人。

❻：最后，通过连接让“出生在美国的人”与“居住在欧洲的人”两个集合取交集。

同一个查询用 Cypher 只需 4 行，用 SQL 却要写 31 行，这恰恰说明选对数据模型和查询语言会带来多大差别。而这还只是开始；还有更多细节需要考虑，例如如何处理环，以及选择广度优先还是深度优先遍历 ⁴⁰。

Oracle 为递归查询提供了另一套 SQL 扩展，称为 层次查询（hierarchical query）⁴¹。

不过，情况可能正在改善：在本书写作时，已有计划把一种名为 GQL 的图查询语言加入 SQL 标准 ^{42 43}，其语法借鉴了 Cypher、GSQL ⁴⁴ 和 PGQL ⁴⁵。

三元组存储与 SPARQL

三元组存储模型大体上与属性图模型相同，只是用不同的词汇描述同样的思想。不过它仍然值得单独讨论，因为三元组存储有许多现成的工具和语言，可以成为构建应用程序时的宝贵补充。

在三元组存储中，所有信息都以非常简单的三部分陈述来存储：（主语、谓语、宾语）。例如，在三元组（Jim、喜欢、香蕉）中，Jim 是主语，喜欢 是谓语（动词），香蕉 是宾语。

三元组的主语相当于图中的一个顶点，宾语则是以下两者之一：

1. 字符串、数字等原始数据类型的值。这时，三元组的谓语和宾语相当于主语顶点上某项属性的键和值。例如，沿用 图 3-6 的例子，三元组（lucy、birthYear、1989）相当于顶点 lucy 拥有属性 {"birthYear": 1989}。
2. 图中的另一个顶点。这时，谓语相当于图中的边，主语是尾部顶点，宾语是头部顶点。例如，在（lucy、marriedTo、alain）中，lucy 和 alain 都是顶点，谓语 marriedTo 则是连接二者的边标签。

示例 3-7 把 示例 3-4 中的同一份数据写成了三元组，使用的格式称为 Turtle，它是 Notation3（N3）的一个子集 ⁴⁸。

@prefix : <urn:example:>.
_:lucy a :Person.
_:lucy :name "Lucy".
_:lucy :bornIn _:idaho.
_:idaho a :Location.
_:idaho :name "Idaho".
_:idaho :type "state".
_:idaho :within _:usa.
_:usa a :Location.
_:usa :name "United States".
_:usa :type "country".
_:usa :within _:namerica.
_:namerica a :Location.
_:namerica :name "North America".
_:namerica :type "continent".

在这个例子中，图的顶点写成 _:someName。名称在当前文件之外没有任何意义；之所以需要它，只是为了分辨哪些三元组引用了同一个顶点。当谓语表示边时，宾语是另一个顶点，如 _:idaho :within _:usa；当谓语表示属性时，宾语则是字符串字面量，如 _:usa :name "United States"。

一遍遍重复同一个主语显得相当啰嗦，好在可以用分号连续陈述关于同一主语的多件事。这使 Turtle 格式颇为清晰易读，如 示例 3-8 所示。

@prefix : <urn:example:>.
_:lucy a :Person; :name "Lucy"; :bornIn _:idaho.
_:idaho a :Location; :name "Idaho"; :type "state"; :within _:usa.
_:usa a :Location; :name "United States"; :type "country"; :within _:namerica.
_:namerica a :Location; :name "North America"; :type "continent".

RDF 数据模型

示例 3-8 使用的 Turtle 语言，实际上是对 资源描述框架（RDF，Resource Description Framework）数据进行编码的一种方式 ⁵⁵；RDF 是专为 语义网（Semantic Web）设计的数据模型。RDF 数据也可以采用其他编码，例如用更为冗长的 XML 表示，如 示例 3-9 所示。Apache Jena 等工具可以在不同 RDF 编码之间自动转换。

<rdf:RDF xmlns="urn:example:"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

    <Location rdf:nodeID="idaho">
        <name>Idaho</name>
        <type>state</type>
        <within>
            <Location rdf:nodeID="usa">
                <name>United States</name>
                <type>country</type>
                <within>
                    <Location rdf:nodeID="namerica">
                        <name>North America</name>
                        <type>continent</type>
                    </Location>
                </within>
            </Location>
        </within>
    </Location>

    <Person rdf:nodeID="lucy">
        <name>Lucy</name>
        <bornIn rdf:nodeID="idaho"/>
    </Person>
</rdf:RDF>

RDF 有一些奇特之处，因为它是为互联网范围的数据交换而设计的。三元组的主语、谓语和宾语通常都是 URI。例如，谓语可能写成 <http://my-company.com/namespace#within> 或 <http://my-company.com/namespace#lives_in>，而不只是 WITHIN 或 LIVES_IN。这样设计是为了让不同来源的数据可以合并：即使别人赋予 within 或 lives_in 不同含义，也不会发生冲突，因为对方的谓语实际是 <http://other.org/foo#within> 和 <http://other.org/foo#lives_in>。

从 RDF 的角度看，URL <http://my-company.com/namespace> 不一定真能解析出什么内容，它不过是个命名空间。为避免与 http:// URL 混淆，本节示例使用 urn:example:within 之类不可解析的 URI。好在只须在文件开头声明一次前缀，后面便不必再操心。

SPARQL 查询语言

SPARQL 是一种面向 RDF 数据模型的三元组存储查询语言 ⁵⁶。（它是 SPARQL Protocol and RDF Query Language 的缩写，读作 “sparkle”。）SPARQL 早于 Cypher；Cypher 的模式匹配借鉴了 SPARQL，因此两者看起来十分相似。

之前那条查找从美国移居欧洲者的查询，用 SPARQL 表示时和用 Cypher 一样简洁（见 示例 3-10）。

PREFIX : <urn:example:>

SELECT ?personName WHERE {
 ?person :name ?personName.
 ?person :bornIn / :within* / :name "United States".
 ?person :livesIn / :within* / :name "Europe".
}

二者结构十分相似。下面两个表达式是等价的（SPARQL 中的变量以问号开头）：

(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (location) # Cypher

?person :bornIn / :within* ?location. # SPARQL

因为 RDF 不区分属性与边，而是把二者都当作谓语，所以匹配属性也可以使用同一种语法。在下面的表达式中，变量 usa 会绑定到任意 name 属性为字符串 "United States" 的顶点：

(usa {name:'United States'}) # Cypher

?usa :name "United States". # SPARQL

Amazon Neptune、AllegroGraph、Blazegraph、OpenLink Virtuoso、Apache Jena 以及其他多种三元组存储都支持 SPARQL ³⁶。

Datalog：递归关系查询

Datalog 是比 SPARQL 和 Cypher 更古老的语言，源自 20 世纪 80 年代的学术研究 ^{57 58 59}。它在软件工程师中不太知名，主流数据库也很少支持；但它表达能力很强，尤其擅长复杂查询，理应得到更多关注。Datomic、LogicBlox、CozoDB 以及 LinkedIn 的 LIquid ⁶⁰ 等几种小众数据库，都使用 Datalog 作为查询语言。

Datalog 实际上基于关系数据模型，而不是图模型；之所以把它放在图数据库一节，是因为 Datalog 尤其擅长对图进行递归查询。

Datalog 数据库由 事实 组成，每项事实对应关系表中的一行。假设有一张存储地点的 location 表，包含 ID、name 和 type 三列；“美国是一个国家”这项事实就可以写成 location(2, "United States", "country")，其中 2 是美国的 ID。一般来说，table(val1, val2, …​) 表示 table 中有这样一行：第一列为 val1，第二列为 val2，依此类推。

示例 3-11 展示了如何用 Datalog 写出 图 3-6 左侧的数据。图中的边（within、born_in 和 lives_in）表示为两列的连接表。例如，Lucy 的 ID 是 100，爱达荷州的 ID 是 3，因此“Lucy 出生在爱达荷州”这项关系表示为 born_in(100, 3)。

location(1, "North America", "continent").
location(2, "United States", "country").
location(3, "Idaho", "state").

within(2, 1). /* 美国在北美 */
within(3, 2). /* 爱达荷州在美国 */

person(100, "Lucy").
born_in(100, 3). /* Lucy 出生在爱达荷州 */

定义好数据之后，就可以写出与之前相同的查询，如 示例 3-12 所示。它看起来与 Cypher 或 SPARQL 中的等价查询颇为不同，但不必因此望而却步。Datalog 是 Prolog 的一个子集；如果学过计算机科学，你或许见过这种编程语言。

within_recursive(LocID, PlaceName) :- location(LocID, PlaceName, _). /* 规则 1 */

within_recursive(LocID, PlaceName) :- within(LocID, ViaID), /* 规则 2 */
 within_recursive(ViaID, PlaceName).

migrated(PName, BornIn, LivingIn) :- person(PersonID, PName), /* 规则 3 */
 born_in(PersonID, BornID),
 within_recursive(BornID, BornIn),
 lives_in(PersonID, LivingID),
 within_recursive(LivingID, LivingIn).

us_to_europe(Person) :- migrated(Person, "United States", "Europe"). /* 规则 4 */
/* us_to_europe 包含行 "Lucy"。 */

Cypher 和 SPARQL 一上来便使用 SELECT，Datalog 却每次只向前迈一小步。我们通过定义 规则，从底层事实派生出新的虚拟表。这些派生表类似于（虚拟的）SQL 视图：它们并不存储在数据库中，却可以像保存事实的表一样接受查询。

示例 3-12 定义了三个派生表：within_recursive、migrated 和 us_to_europe。每条规则中 :- 符号之前的部分，定义了虚拟表的名称与各列。例如，migrated(PName, BornIn, LivingIn) 是一张三列表，分别包含姓名、出生地名称和居住地名称。

虚拟表的内容由规则中 :- 符号之后的部分定义，它会尝试在各表中找出匹配特定模式的行。例如，person(PersonID, PName) 可以匹配 person(100, "Lucy") 这一行，此时变量 PersonID 绑定为 100，PName 绑定为 "Lucy"。只要系统能为 :- 右侧的 所有 模式找到匹配，规则便可以应用。应用规则的效果，就好像把 :- 左侧的内容加入数据库，并将其中的变量替换为各自匹配的值。

因此，可以按下面的方式应用规则（如 图 3-7 所示）：

1. 数据库中存在 location(1, "North America", "continent")，所以规则 1 可以应用，生成 within_recursive(1, "North America")。
2. 数据库中存在 within(2, 1)，上一步又生成了 within_recursive(1, "North America")，所以规则 2 可以应用，生成 within_recursive(2, "North America")。
3. 数据库中存在 within(3, 2)，上一步又生成了 within_recursive(2, "North America")，所以再次应用规则 2，生成 within_recursive(3, "North America")。

反复应用规则 1 和规则 2，within_recursive 虚拟表就能告诉我们，数据库中的哪些地点位于北美（或任何其他地点）之内。

图 3-7. 使用 示例 3-12 中的 Datalog 规则确定爱达荷州在北美。

接下来，规则 3 可以找出出生在 BornIn、现居 LivingIn 的人。规则 4 以 BornIn = 'United States' 和 LivingIn = 'Europe' 调用规则 3，只返回符合条件者的姓名。最后查询虚拟表 us_to_europe，Datalog 系统便会给出与先前 Cypher 和 SPARQL 查询相同的答案。

Datalog 需要一种不同于本章其他查询语言的思维方式。它允许逐条规则地搭建复杂查询，让一条规则引用其他规则，就像把代码拆成彼此调用的函数。函数可以递归，Datalog 规则也同样可以调用自身；示例 3-12 的规则 2 正是如此，由此实现了 Datalog 查询中的图遍历。

GraphQL

GraphQL 也是一种查询语言，但它在设计上比本章介绍的其他语言限制更多。GraphQL 的用途，是让运行在用户设备上的客户端软件（例如移动应用或 JavaScript Web 应用的前端）请求一份特定结构的 JSON 文档，其中恰好包含渲染用户界面所需的字段。借助 GraphQL 接口，开发者可以迅速修改客户端代码中的查询，而无须改动服务端 API。

GraphQL 的灵活性并非没有代价。采用 GraphQL 的组织通常需要一套工具，把 GraphQL 查询转换成对内部服务的请求，而这些内部服务往往使用 REST 或 gRPC（参见 第 5 章）。此外还要应对授权、限流和性能等问题 ⁶¹。GraphQL 查询来自不受信任的来源，因此查询语言本身也受到严格限制：它不允许任何执行成本可能很高的操作，否则用户就能大量提交昂贵查询，对服务器发动拒绝服务攻击。具体来说，GraphQL 不允许递归查询（Cypher、SPARQL、SQL 和 Datalog 都允许），也不能随意给出“查找出生在美国、现居欧洲的人”这样的搜索条件，除非服务所有者特意提供了相应搜索功能。

尽管如此，GraphQL 仍然很有用。示例 3-13 展示了如何用它实现 Discord 或 Slack 这类群聊应用。查询请求用户有权访问的所有频道，并取回每个频道的名称和最近 50 条消息。对每条消息，它请求时间戳、正文，以及发送者姓名和头像 URL。若某条消息是对另一条消息的回复，查询还会请求原消息的正文与发送者姓名；界面可以用较小字号把这些内容显示在回复上方，作为上下文。

query ChatApp {
    channels {
        name
        recentMessages(latest: 50) {
            timestamp
            content
        sender {
            fullName
            imageUrl
        }
    replyTo {
        content
        sender {
            fullName
        }
    }
    }
    }
}

示例 3-14 给出了 示例 3-13 中查询的一种可能响应。响应是一份与查询结构相呼应的 JSON 文档：请求了哪些属性，它就不多不少地返回哪些属性。这样一来，服务器无须预先知道客户端渲染界面需要什么；客户端直接提出所需内容即可。例如，这条查询没有请求 replyTo 消息发送者的头像 URL。若界面后来要显示该头像，客户端只需在查询中加入 imageUrl 属性，无须修改服务器。

{
"data": {
    "channels": [
        {
        "name": "#general",
        "recentMessages": [
        {
        "timestamp": 1693143014,
        "content": "Hey! How are y'all doing?",
        "sender": {"fullName": "Aaliyah", "imageUrl": "https://..."},
        "replyTo": null
        },
        {
            "timestamp": 1693143024,
            "content": "Great! And you?",
            "sender": {"fullName": "Caleb", "imageUrl": "https://..."},
            "replyTo": {
            "content": "Hey! How are y'all doing?",
            "sender": {"fullName": "Aaliyah"}
        }
},
...

示例 3-14 把消息发送者的姓名和头像 URL 直接嵌入消息对象。同一个用户若发送多条消息，这些信息会在每条消息中重复。原则上当然可以减少这种重复，但 GraphQL 选择接受更大的响应，以换取根据数据渲染界面时更加简单。

replyTo 字段也是如此：示例 3-14 中的第二条消息回复了第一条，因此第一条消息的内容（“Hey!…”）和发送者 Aaliyah 又在 replyTo 下重复了一遍。也可以只返回被回复消息的 ID，但如果该 ID 不在这次返回的最近 50 条消息之中，客户端就得向服务器再发一次请求。直接复制内容，处理起来简单得多。

服务器端数据库可以用更加规范化的形式存储数据，并在处理查询时执行必要的连接。例如，服务器可以把消息正文与发送者的用户 ID、被回复消息的 ID 存在一起；收到上述查询时，再解析这些 ID，找出它们引用的记录。不过，客户端只能要求服务器执行 GraphQL 模式中明确开放的连接。

尽管 GraphQL 的响应看起来很像文档数据库返回的结果，而且名称中还带有 “graph”，它其实可以构建在任何数据库之上，无论是关系数据库、文档数据库还是图数据库。

事件溯源与 CQRS

在我们迄今讨论过的所有数据模型中，数据都以写入时的形式接受查询——无论它是 JSON 文档、表中的行，还是图中的顶点和边。然而在复杂应用中，有时很难找到一种数据表示，能够满足所有查询和展现数据的需求。在这种情况下，可以用一种形式写入数据，再从中派生出多种针对不同读取方式优化的表示。

我们在 “权威记录系统与衍生数据” 中已经见过这种思路，ETL（参见 “数据仓库”）就是一种派生过程。现在让我们再往前走一步。既然无论如何都要由一种数据表示派生出另一种，那就可以分别选用针对写入和读取优化的表示。如果只需优化数据写入，丝毫不必考虑查询效率，你会如何对数据建模？

也许，写入数据最简单、最快且表意最清楚的方式，就是写入 事件日志（event log）：每次写入数据时，都将它编码成一个自包含的字符串（也许是 JSON），其中带有时间戳，再追加到事件序列中。日志中的事件是 不可变的（immutable）：你永远不会修改或删除它们，只会向日志追加更多事件（后来的事件可以取代早先事件的效力）。事件可以包含任意属性。

图 3-8 给出了一个可能来自会议管理系统的例子。会议管理是一个复杂的业务领域：不仅个人参会者可以报名并用信用卡付款，企业也可以批量预订座位，以发票结算，再把座位分配给个人。演讲者、赞助商和志愿者等人可能要占用一些预留座位。预订还可能取消；与此同时，会议组织者又可能因为更换场地，而改变活动的容量。这些事情叠加在一起，哪怕只是计算还有多少空余座位，也会变成一项颇具挑战的查询。

在 图 3-8 中，会议状态的每次变化（例如组织者开放报名，或参会者报名和取消报名），首先都会被存储为事件。每当日志追加一个事件，几个 物化视图（materialized view，也称为 投影，projection，或 读模型，read model）也会随之更新，以反映该事件带来的影响。在这个会议示例中，可以有一个物化视图汇总每笔预订状态的所有相关信息，另一个计算会议组织者仪表盘所需的图表，第三个则为制作参会者胸牌的打印机生成文件。

以事件作为权威数据源，并把每次状态变化都表达为事件，这种思路称为 事件溯源（event sourcing）^{62 63}。维护独立的读取优化表示，并从写入优化的表示中派生它们，这种原则称为 命令查询责任分离（Command Query Responsibility Segregation，CQRS）⁶⁴。这些术语源自领域驱动设计（DDD）社区，不过类似的思路由来已久，例如 状态机复制（state machine replication；参见 “使用共享日志”）。

当来自用户的请求刚到达时，它还是一个 命令（command），首先需要验证。只有在命令已经执行且确认有效之后（例如，请求的预订有足够的空余座位），它才会成为事实，相应的事件也才会追加到日志中。因此，事件日志中应当只有有效事件；消费事件日志来构建物化视图的组件，不允许拒绝事件。

以事件溯源的方式对数据建模时，建议用过去时来命名事件（例如“座位已预订”），因为事件记录的是已经发生的事实。即使用户后来更改或取消预订，他们曾经预订过的事实依然成立；更改或取消是之后另行追加的事件。

事件溯源与星型模式的事实表（参见 “星型与雪花型：分析模式”）有一个相似之处：它们都是过去所发生事件的集合。不过，事实表中每一行的列都相同，事件溯源中则可以有许多类型不同、属性各异的事件。此外，事实表是无序集合，而事件溯源中事件的先后顺序很重要：如果一笔预订先成立、后取消，颠倒顺序处理这两个事件就毫无意义。

事件溯源和 CQRS 有几个优点：

• 对系统开发者来说，事件能更清楚地表达某件事 为什么 发生。例如，理解“预订已取消”这个事件，要比理解“bookings 表第 4001 行的 active 列已设为 false，seat_assignments 表中与该预订相关的三行已被删除，payments 表中又插入了一行表示退款”容易得多。物化视图处理取消事件时，依然可能会对这些行执行修改；但由事件驱动这些更新，其原因就清楚得多。
• 事件溯源的一项关键原则，是物化视图应以可重现的方式从事件日志中派生：你应当随时能够删除物化视图，然后用同一套代码，按同样的顺序处理同样的事件，从而重新计算出视图。如果视图维护代码存在错误，只需删除视图，再用修正后的代码重算。错误也更容易查找，因为你可以反复重新运行视图维护代码，并检查它的行为。
• 你可以维护多个物化视图，分别针对应用所需的特定查询进行优化。它们可以与事件保存在同一个数据库中，也可以根据需要存入不同的数据库。这些视图可以使用任何数据模型，也可以通过反规范化来加快读取。只要服务重启时可以从事件日志重算视图，甚至可以只把它保留在内存中，根本不做持久化。
• 如果决定以新方式展现现有信息，可以很容易地根据现有事件日志构建新的物化视图。添加新的事件类型，或给现有事件类型添加新属性（旧事件保持不变），就能让系统演化并支持新功能。还可以在现有事件后触发新的行为，例如参会者取消预订后，将座位提供给等候名单中的下一个人。
• 如果误写了某个事件，可以把它删除，再重建不包含该事件的视图。相比之下，在直接更新和删除数据的数据库中，已经提交的事务往往很难撤销。因此，事件溯源可以减少系统中不可逆操作的数量，让变更更容易（参见 “可演化性：让变化更容易”）。
• 事件日志还可以作为审计日志，记录系统中发生的一切。在必须提供审计能力的受监管行业中，这一点很有价值。

然而，事件溯源和 CQRS 也有缺点：

• 涉及外部信息时必须小心。例如，假设事件中有一个以某种货币计价的价格，而某个视图需要把它兑换成另一种货币。由于汇率会波动，处理事件时再从外部数据源获取汇率就有问题：换一天重新计算物化视图，得到的结果就可能不同。为了让事件处理逻辑具有确定性，要么把汇率写入事件本身，要么提供一种方法，能查询事件时间戳所对应的历史汇率，并确保同一时间戳始终返回同一结果。
• 事件不可变这一要求，在事件包含用户个人数据时会带来问题，因为用户可能行使自己的权利（例如 GDPR 规定的权利），要求删除个人数据。如果每个用户各有一份事件日志，只需删除该用户的整份日志；但如果日志中的事件关系到多个用户，这种做法就行不通。可以尝试把个人数据存在事件之外，或者用一把密钥加密，以便日后删除密钥；但这也会让按需重算派生状态变得更困难。
• 如果处理事件会带来外部可见的副作用，那么重新处理事件时必须小心。例如，你大概不会希望每次重建物化视图时，都再发一遍确认邮件。

事件溯源可以构建在任何数据库之上，不过也有一些系统是专为这种模式设计的，例如 EventStoreDB、MartenDB（基于 PostgreSQL）和 Axon Framework。也可以使用 Apache Kafka 之类的消息代理来存储事件日志，并通过流处理器使物化视图保持最新；我们将在 “变更数据捕获与事件溯源” 中再次讨论这些主题。

唯一一项重要要求是：事件存储系统必须保证，所有物化视图都以事件在日志中出现的顺序处理它们。正如我们将在 第 10 章 中看到的，这在分布式系统中并不总是一件容易的事。

数据框、矩阵与数组

本章迄今介绍的数据模型，通常既用于事务处理，也用于分析（参见 “分析型与事务型系统”）。还有一些数据模型常见于分析或科学场景，却很少出现在 OLTP 系统中：数据框（dataframe），以及矩阵等多维数值数组。

R 语言、Python 的 pandas 库、Apache Spark、ArcticDB 和 Dask 等系统，都支持数据框这种数据模型。数据科学家经常用它为训练机器学习模型准备数据；它也广泛用于数据探索、统计分析和数据可视化等场景。

乍看之下，数据框很像关系数据库中的表，也像电子表格。它支持一系列类似关系运算符的批量操作：例如，对所有行应用某个函数，按条件筛选行，按某些列分组并聚合其他列，以及按某个键连接两个数据框中的行（关系数据库中的 连接，在数据框中通常称为 合并，merge）。

数据框通常不是通过 SQL 之类的声明式查询来操作，而是通过一系列命令逐步修改其结构和内容。这恰好符合数据科学家的典型工作流程：一点点地“整理”数据，直至它变成一种适合回答当前问题的形式。这些操作通常在数据科学家私有的数据集副本上进行，而且往往就在本机上；不过最终结果也可能会分享给其他用户。

数据框 API 提供的许多操作远远超出关系数据库的能力，其使用方式也往往与典型的关系数据建模大不相同 ⁶⁵。例如，数据框的一种常见用途，是把数据从类似关系模型的表示转换为矩阵或多维数组，而许多机器学习算法期望的输入正是这种形式。

图 3-9 展示了一个简单的转换示例。左侧是一张关系表，记录不同用户给各种电影打出的分数（1 到 5 分）；右侧则把这些数据转换成了矩阵，每一列代表一部电影，每一行代表一位用户（类似电子表格中的 数据透视表，pivot table）。这个矩阵是 稀疏（sparse）的，也就是说，很多用户与电影的组合都没有数据，但这并不碍事。矩阵可能有成千上万列，不太适合放在关系数据库中；数据框以及 Python 的 NumPy 等支持稀疏数组的库，却能轻松处理这类数据。

矩阵只能包含数字，因此需要用各种技术把非数值数据转换为矩阵中的数字。例如：

• 日期（图 3-9 的示例矩阵中省略了日期）可以按比例缩放为某个合适范围内的浮点数。
• 对于只能从一小组固定值中取值的列（例如电影数据库中的电影类型），通常采用 独热编码（one-hot encoding）：为每个可能的值建立一列（“喜剧”一列、“剧情”一列、“恐怖”一列，依此类推）；对于代表某部电影的每一行，在对应其类型的列中填 1，其余列填 0。这种表示也很容易推广到同时属于多种类型的电影。

数据一旦变成数值矩阵，就适合进行线性代数运算，而线性代数正是许多机器学习算法的基础。例如，图 3-9 中的数据可以用在向用户推荐其可能喜欢的电影的系统中。数据框十分灵活，可以让数据从关系形式逐步演变为矩阵表示，同时让数据科学家自行掌控哪种表示最适合达成数据分析或模型训练的目标。

还有一些数据库专门存储大型多维数值数组，例如 TileDB ⁶⁶。这类系统称为 数组数据库（array database），最常用于科学数据集，例如地理空间测量数据（规则间隔网格上的栅格数据）、医学影像或天文望远镜的观测结果 ⁶⁷。金融行业也用数据框表示 时间序列数据（time-series data），例如资产价格以及按时间记录的交易 ⁶⁸。

总结

数据模型是一个巨大的课题，本章只是快速浏览了各种不同的模型。我们没有足够的篇幅详述每个模型，但希望这份概览足以引起你的兴趣，促使你进一步了解最适合应用需求的模型。

关系模型 尽管已有半个多世纪的历史，但对许多应用来说仍然是一种重要的数据模型——尤其是在数据仓库和商业分析领域，关系型星型或雪花型模式与 SQL 查询无处不在。不过，关系数据的几种替代方案也在其他领域流行起来：

• 文档模型 主要关注自包含的 JSON 数据文档，而且文档之间的关系非常稀少。
• 图数据模型 用于相反的场景：任意事物都可能与其他一切事物相关，查询可能需要跨越多跳才能找到感兴趣的数据（这类查询可以用 Cypher、SPARQL 或 Datalog 中的递归查询来表达）。
• 数据框 把关系数据推广到拥有大量列的情形，在数据库与多维数组之间架起了桥梁；而多维数组正是许多机器学习、统计分析和科学计算的基础。

一个模型可以用另一个模型来模拟——例如，图数据可以在关系数据库中表示——但结果往往很别扭，正如 SQL 对递归查询的支持所表明的那样。

因此，人们为每种数据模型开发了各式各样的专用数据库，提供针对该模型优化的查询语言和存储引擎。另一方面，数据库也在不断加入对其他数据模型的支持，向相邻领域扩展：例如，关系数据库通过 JSON 列支持文档数据，文档数据库加入类似关系模型的连接，而 SQL 对图数据的支持也在逐步改善。

我们还讨论了 事件溯源：它把数据表示为不可变事件的仅追加日志，这种形式可能很适合为复杂业务领域中的活动建模。仅追加日志有利于数据写入（正如我们将在 第 4 章 中看到的）；为了支持高效查询，CQRS 会把事件日志转换为针对读取优化的物化视图。

非关系数据模型的一个共同点是，它们通常不会将存储的数据强制约束为特定模式，这可以使应用更容易适应不断变化的需求。但是应用很可能仍会假定数据具有一定的结构；区别仅在于模式是 明确的（写入时强制）还是 隐含的（读取时假定）。

虽然我们已经覆盖了很多层面，但仍有一些数据模型没有提到。举几个简单的例子：

• 研究基因组数据的研究人员通常需要执行 序列相似性搜索，这意味着取一个很长的字符串（代表一个 DNA 分子），在一个包含大量相似但不完全相同的字符串的数据库中寻找匹配。这里描述的数据库都不能处理这种用法，这就是研究人员编写了 GenBank ⁶⁹ 等专用基因组数据库软件的原因。
• 许多金融系统以采用复式记账法的 账本 作为数据模型。这类数据可以用关系数据库表示，但也有 TigerBeetle 这样专攻此类数据模型的数据库。加密货币和区块链通常基于分布式账本，并把价值转移也内置在数据模型之中。
• 全文检索 可以说是一种经常与数据库配合使用的数据模型。信息检索是一个很大的专业课题，本书不会深入介绍，但我们将在 “全文检索” 中谈到搜索索引与向量搜索。

我们暂且说到这里。在下一章中，我们将讨论在 实现 本章描述的数据模型时会遇到的一些权衡。

参考文献

4 存储与检索

人生的苦恼之一，就是每个人给事物起的名字总有那么一点不对。于是，世上的一切都变得比换个名字时更难理解。计算机最主要的用途，并不是通常所谓做算术的“计算”。[……] 它们主要是档案系统。

理查德・费曼， 特立独行的思考 研讨会（1985 年）

一个数据库在最基础的层次上需要完成两件事情：当你把数据交给数据库时，它应当把数据存储起来；而后当你向数据库要数据时，它应当把数据返回给你。

在 第 3 章 中，我们讨论了数据模型和查询语言，即你将数据交给数据库时采用的格式，以及日后向数据库取回数据时使用的接口。在本章中，我们会从数据库的视角来讨论同样的问题：数据库如何存储我们提供的数据，以及如何在我们需要时重新找到数据。

作为应用开发者，为什么要关心数据库内部存储与检索的机理？你可能不会从头开始实现自己的 存储引擎（storage engine），但是你 确实 需要从许多可用的存储引擎中选择一个适合应用的。为了让存储引擎能在你的工作负载上运行良好，你也需要大致了解它在底层究竟做了什么。

尤其需要注意，针对事务型工作负载（OLTP）优化的存储引擎，与针对分析型工作负载优化的存储引擎之间存在巨大差异（这种区别已在 “分析型与事务型系统” 中介绍）。本章首先考察 OLTP 存储引擎的两大类：写出不可变数据文件的 日志结构（log-structured）存储引擎，以及像 B 树 这样就地更新数据的存储引擎。键值存储（key-value store）和 二级索引（secondary index）都可以采用这两类结构。

稍后在 “分析型数据存储” 中，我们会讨论一类针对分析优化的存储引擎；在 “多维索引与全文索引” 中，还会简要介绍用于文本检索等复杂查询的索引。

OLTP 系统的存储与索引

世界上最简单的数据库可以用两个 Bash 函数实现：

#!/bin/bash

db_set () {
  echo "$1,$2" >> database
}

db_get () {
  grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}

这两个函数实现了键值存储。调用 db_set key value，会将 key 和 value 存入数据库。键和值（几乎）可以是任意内容，例如值可以是一个 JSON 文档。随后调用 db_get key，就会查找与这个键关联的最新值并将其返回。

麻雀虽小，五脏俱全：

$ db_set 12 '{"name":"London","attractions":["Big Ben","London Eye"]}'

$ db_set 42 '{"name":"San Francisco","attractions":["Golden Gate Bridge"]}'

$ db_get 42
{"name":"San Francisco","attractions":["Golden Gate Bridge"]}

底层存储格式非常简单：一个文本文件，每行包含一条以逗号分隔的键值对（忽略转义问题的话，大致与 CSV 文件类似）。每次调用 db_set 都会向文件末尾追加记录。多次更新一个键时，旧版本的值不会被覆盖——因而要找到最新值，就必须查看这个键在文件中最后一次出现的位置（所以 db_get 中使用了 tail -n 1）：

$ db_set 42 '{"name":"San Francisco","attractions":["Exploratorium"]}'

$ db_get 42
{"name":"San Francisco","attractions":["Exploratorium"]}

$ cat database
12,{"name":"London","attractions":["Big Ben","London Eye"]}
42,{"name":"San Francisco","attractions":["Golden Gate Bridge"]}
42,{"name":"San Francisco","attractions":["Exploratorium"]}

db_set 函数对于如此简单的实现其实有着相当不错的性能，因为在文件末尾追加写入通常非常高效。与 db_set 所做的事情类似，许多数据库在内部使用 日志（log），也就是仅追加的数据文件。真正的数据库还要处理更多问题（例如并发写入、回收磁盘空间以免日志无限增长，以及崩溃恢复时处理只写了一部分的记录），但基本原理是一样的。日志极其有用，我们还会在本书中多次遇到它。

另一方面，如果数据库中有大量记录，db_get 函数的性能就会非常糟糕。每次查找一个键，db_get 都必须从头到尾扫描整个数据库文件，寻找这个键。用算法的语言来说，查找开销是 O(n)：如果数据库中的记录数 n 翻了一倍，查找时间也要翻一倍。这就不好了。

为了高效查找数据库中特定键的值，我们需要一种数据结构：索引（index）。本章将介绍一系列索引结构，并比较它们之间的差异。索引背后的大致思想，是以某种特定方式组织数据（例如按某个键排序），从而更快地定位想要的数据。如果想以几种不同的方式搜索同一份数据，那么也许需要在数据的不同部分建立多个索引。

索引是从主数据衍生出的 额外 结构。许多数据库允许添加和删除索引，这不会影响数据库的内容，只会影响查询性能。维护额外结构会产生开销，特别是在写入时。写入性能很难超过简单地向文件末尾追加，因为追加是最简单的写入操作。任何类型的索引通常都会拖慢写入速度，因为每次写入数据时还必须更新索引。

这是存储系统中一项重要的权衡：精心选择的索引能加快读查询，但每个索引都会占用额外的磁盘空间，并拖慢写入速度，有时影响还相当显著 ¹。因此，数据库通常不会默认索引所有内容，而是要求编写应用程序或管理数据库的人，根据自己对典型查询模式的了解手动选择索引。这样便可以选出给应用带来最大收益的索引，同时避免不必要的写入开销。

日志结构存储

首先假设你仍想把数据保存在 db_set 写入的仅追加文件中，只是希望加快读取速度。最简单的索引策略是保留一个内存中的哈希映射，其中每个键都映射到数据文件里的一个字节偏移量，指明该键最新的值位于何处，如 图 4-1 所示。

每当向文件追加新的键值对时，还要更新哈希映射，使它指向刚刚写入的数据。查找一个值时，先用哈希映射找到日志文件中的偏移量，再寻道至该位置读取即可。如果数据文件的这一部分已经在文件系统缓存中，读取甚至完全不需要磁盘 I/O。

这种方法快得多，但仍有几个问题：

• 被新值覆盖的旧日志条目仍占着磁盘空间，始终得不到释放；只要继续写入数据库，磁盘空间迟早会耗尽。
• 哈希映射没有持久化，数据库重启时必须重建。例如，可以扫描整个日志文件，找出每个键最新的字节偏移量。如果数据量很大，重启就会十分缓慢。
• 哈希表必须能放进内存。原则上可以在磁盘上维护哈希表，可惜磁盘哈希表很难有良好的性能：它需要大量随机访问 I/O，装满后的扩容代价很高，而且解决哈希冲突需要烦琐的逻辑 ²。
• 范围查询效率不高。例如，无法轻松扫描 10000 到 19999 之间的所有键，只能在哈希映射中逐个查找。

SSTable 文件格式

实践中，数据库索引很少采用哈希表，更常见的做法是把数据保存在 按键排序 的结构中 ³。排序字符串表（Sorted String Table，简称 SSTable）便是一例，如 图 4-2 所示。这种文件格式同样存储键值对，但保证键值对按键排序，而且每个键在文件中只出现一次。

这样便不必在内存中保留所有键。可以把 SSTable 中的键值对分成若干个几千字节大小的 块（block），索引只存储每个块的第一个键。这种只收录部分键的索引称为 稀疏索引（sparse index）。索引保存在 SSTable 的一个独立区域中，可以采用不可变 B 树、字典树或其他能快速查找特定键的数据结构 ⁴。

以 图 4-2 为例，一个块的第一个键是 handbag，下一个块的第一个键是 handsome。假设要查找没有出现在稀疏索引中的 handiwork。根据排序关系可知，handiwork 必定在 handbag 与 handsome 之间。因此，可以寻道至 handbag 的偏移量，再从那里开始扫描文件，直到找到 handiwork；如果一直扫到下一个块仍未找到，就说明文件中没有这个键。几千字节的数据块很快就能扫描完。

此外，每个记录块都可以压缩（图 4-2 中的阴影区域）。除了节省磁盘空间，压缩还能减少 I/O 带宽的使用，代价只是多耗费一点 CPU 时间。

构建和合并 SSTable

SSTable 文件格式比仅追加日志更利于读取，却让写入变得困难。不能直接向文件末尾追加，否则文件就不再有序（除非键碰巧按升序写入）。如果每次在文件中间插入一个键都要重写整个 SSTable，写入成本又会高得无法接受。

解决办法是采用 日志结构 方法，将仅追加日志与排序文件结合起来：

1. 收到写入时，将其加入内存中的有序映射数据结构，例如红黑树、跳表 ⁵ 或字典树 ⁶。这类数据结构可以按任意顺序插入键、高效查找键，并按排序顺序读出键。这个内存数据结构称为 内存表（memtable）。
2. 当内存表超过某个阈值（通常为几兆字节）时，按排序顺序将它写成磁盘上的 SSTable 文件。这个新的 SSTable 文件称为数据库最新的 段（segment），它与较旧的段分别存放在独立文件中，每个段都有自己的索引。向磁盘写出新段期间，数据库可以继续向新的内存表实例写入；SSTable 写完后，旧内存表占用的内存即可释放。
3. 读取某个键的值时，先在内存表和磁盘上最新的段中查找。如果没有找到，就依次查看更旧的段，直到找到这个键或查完最旧的段。如果任何段中都没有这个键，它就不存在于数据库中。
4. 后台不时运行合并与压实过程，将段文件合并起来，并丢弃已经覆盖或删除的值。

段的合并类似于 归并排序 算法 ⁵，如 图 4-3 所示。并行读取各个输入文件，比较每个文件当前的第一个键，把排序最靠前的键复制到输出文件，然后不断重复。如果同一个键出现在多个输入文件中，只保留较新的值。这样生成的新段仍按键排序，每个键只保留一个值；由于可以逐键遍历 SSTable，整个过程只需要很少的内存。

为了避免数据库崩溃时丢失内存表中的数据，存储引擎还会在磁盘上保存一个单独的日志，每次写入都会立即追加到这个日志。日志不按键排序，但这并不重要，因为它的唯一用途是在崩溃后恢复内存表。每当内存表写成 SSTable 后，日志中相应的部分便可丢弃。

如果要删除一个键及其关联的值，必须向数据文件追加一种称为 墓碑（tombstone）的特殊删除记录。日志段合并时，墓碑会指示合并过程丢弃这个键此前的所有值。墓碑一旦合并进最旧的段，自身也就可以删除。

这里描述的算法，本质上就是 RocksDB ⁷、Cassandra、ScyllaDB 和 HBase ⁸ 所采用的算法。这些系统都受 Google Bigtable 论文 ⁹ 的启发；SSTable 和 memtable 两个术语正是由该论文提出的。

这一算法最初发表于 1996 年，名为 日志结构合并树（Log-Structured Merge-Tree，简称 LSM 树）¹⁰，它建立在更早的日志结构文件系统研究之上 ¹¹。因此，凡是以合并、压实有序文件为基本原理的存储引擎，通常都称为 LSM 存储引擎。

在 LSM 存储引擎中，段文件会一次写完（或者由内存表写出，或者由若干现有段合并而成），此后便不可变。段的合并与压实可以由后台线程完成；在此期间，旧段文件仍可继续处理读取请求。合并完成后，读取请求切换到新的合并段，旧段文件即可删除。

段文件不一定要保存在本地磁盘上；它们也非常适合写入对象存储。例如，SlateDB 和 Delta Lake 就采用这种方法 ¹²。

段文件不可变，也让崩溃恢复变得更简单：如果写出内存表或合并段时发生崩溃，数据库只需删除未完成的 SSTable，再重新开始即可。用于持久化内存表写入的日志，可能因写到一半时崩溃或磁盘已满而留下不完整记录；通常可以借助日志中的校验和检测这些记录，并丢弃损坏或不完整的条目。我们将在 第 8 章 进一步讨论持久性与崩溃恢复。

布隆过滤器

在 LSM 存储中，读取很久以前才更新过的键，或读取根本不存在的键，可能十分缓慢，因为存储引擎必须检查多个段文件。为了加快这类读取，LSM 存储引擎通常会为每个段配备一个 布隆过滤器（Bloom filter）¹³，用来快速、近似地判断某个键是否出现在某个 SSTable 中。

图 4-4 展示了一个包含两个键、长度为 16 位的布隆过滤器（实际的键和位都会多得多）。对 SSTable 中的每个键计算哈希函数，会得到一组数字，再将这些数字解释为位数组中的下标 ¹⁴。把这些位置上的位设为 1，其余位保持为 0。例如，键 handbag 的哈希结果是 (2, 9, 4)，于是将第 2、9、4 位设为 1。得到的位图会与稀疏键索引一起存入 SSTable。它会占用一点额外空间，不过布隆过滤器通常远小于 SSTable 的其余部分。

要判断某个键是否出现在 SSTable 中，只需对它计算同样的哈希，再检查对应下标处的位。例如，图 4-4 查询的是键 handheld，其哈希结果为 (6, 11, 2)。其中第 2 位为 1，另外两位为 0。所有 CPU 都支持的位运算可以极快地完成这些检查。

只要其中至少一位为 0，就能确定 SSTable 中绝对没有这个键。如果查询对应的位全为 1，这个键很可能在 SSTable 中，但也可能只是其他键碰巧把这些位全都设成了 1。这种看似存在、实际却不存在的情况称为 假阳性（false positive）。

假阳性的概率取决于键的数量、每个键设置多少位，以及布隆过滤器的总位数。可以借助在线计算器为应用选择合适的参数 ¹⁵。粗略地说，SSTable 中每个键分配 10 位布隆过滤器空间，假阳性概率约为 1%；此后每个键再多分配 5 位，概率就会降低一个数量级。

对 LSM 存储引擎来说，假阳性不会造成正确性问题：

• 如果布隆过滤器判断键 不存在，就可以放心跳过这个 SSTable，因为其中一定没有该键。
• 如果布隆过滤器判断键 存在，还要查询稀疏索引、解码键值对块，确认键是否真的在其中。如果遇到假阳性，不过是多做了一点无用功，并无其他危害；继续搜索下一个更旧的段即可。

压实策略

LSM 存储的一项重要设计细节，是何时执行压实，以及每次压实应包含哪些 SSTable。许多基于 LSM 的存储系统都允许配置压实策略，常见选择包括 ^{16 17}：

按大小分层压实（size-tiered compaction）

将较新、较小的 SSTable 逐步合并到较旧、较大的 SSTable 中。保存旧数据的 SSTable 可能变得非常大，合并时需要大量临时磁盘空间。这种策略的优点是能应对很高的写入吞吐量。

分级压实（leveled compaction）

将键范围拆分到较小的 SSTable 中，并把较旧的数据移入不同的“层级”。这样可以更增量地进行压实，所需磁盘空间也少于按大小分层策略。分级压实的读取效率更高，因为存储引擎只需检查较少的 SSTable，就能判断其中是否含有所需的键。

根据经验，如果工作负载以写入为主、读取很少，按大小分层压实通常表现更好；如果读取占主导，分级压实通常更好。若少量键经常写入，而大量键很少写入，分级压实也可能更有优势 ¹⁸。

尽管其中有许多微妙之处，LSM 树的基本思想——保存一系列在后台合并的 SSTable——简单而有效。我们将在 “比较 B 树与 LSM 树” 中更详细地讨论其性能特征。

B 树

日志结构方法很流行，但它不是键值存储的唯一形式。按键读写数据库记录时，使用最广泛的结构是 B 树。

B 树自 1970 年问世 ²¹，不到 10 年就被称为“无处不在”²²，很好地经受住了时间的考验。时至今日，它仍然是几乎所有关系数据库中的标准索引实现，许多非关系数据库也使用 B 树。

与 SSTable 一样，B 树按键保存有序的键值对，因而能够高效地查找键值和执行范围查询。但相似之处也到此为止：B 树有着截然不同的设计理念。

前面看到的日志结构索引把数据库分成大小可变的 段（segment），通常每段为几兆字节或更大；段只写入一次，此后便不可变。相比之下，B 树把数据库分成大小固定的 块 或 页，并允许就地覆盖页。传统的页大小是 4 KiB，不过 PostgreSQL 目前默认使用 8 KiB，MySQL 默认使用 16 KiB。

每一页都有页号作为标识，因此一页可以引用另一页——类似于指针，只不过位于磁盘而非内存。如果所有页都保存在同一个文件中，页号乘以页大小，就是该页在文件中的字节偏移量。利用这些页引用可以构造一棵页组成的树，如 图 4-5 所示。

其中一页被指定为 B 树的 根（root）；在索引中查找键时，总是从这里开始。根页包含若干个键和对子页的引用。每个子页负责一段连续的键范围，引用之间的键标示出相邻范围的边界。（这种结构有时称为 B+ 树，不过这里不必把它与其他 B 树变体区分开来。）

在 图 4-5 的例子中，我们要寻找键 251，因此沿着边界 200 与 300 之间的页引用向下走。接下来的一页结构相似，只是把 200–300 进一步划分成更小的子范围。最终会到达包含各个键的 叶页（leaf page）；叶页或者直接保存每个键的值，或者保存指向值所在页的引用。

B 树一页中对子页的引用数称为 分支因子（branching factor）。例如，图 4-5 中的分支因子为 6。实践中的分支因子取决于页引用和范围边界所需的空间，不过通常可达几百。

如果要更新 B 树中已有键的值，就先找到包含该键的叶页，再用含有新值的版本覆盖磁盘上的这一页。如果要添加新键，则找到范围涵盖该键的页，并把键加入其中。如果页内没有足够的空闲空间容纳新键，就把它拆成两个半满的页，并更新父页，以反映键范围的新划分。

在 图 4-6 中，我们想插入键 334，但负责 333–345 范围的页已经装满。于是把它拆成两页：一页负责 333–337（并包含新键），另一页负责 337–344。父页也必须更新，增加对两个子页的引用，并以 337 作为二者的边界。如果父页容不下新的引用，它也要拆分；这种拆分可能一路向上传播到树根。根页拆分时，则在其上方创建一个新根。删除键还可能需要合并节点，处理起来更加复杂 ⁵。

这个算法可以确保树始终 平衡（balanced）：包含 n 个键的 B 树深度总是 O(log n)。大多数数据库只需要三四层深的 B 树，因此不必沿着很多页引用就能找到目标页。（一棵四层深、页大小为 4 KiB、分支因子为 500 的树，最多可以存储 250 TB 数据。）

使 B 树可靠

B 树最基本的底层写操作，是用新数据覆写磁盘上的页，并假定覆写不会改变页的位置：也就是说，页被覆写后，所有指向它的引用仍然有效。这与 LSM 树一类日志结构索引形成鲜明对比；后者只向文件追加写入（并最终删除过时文件），从不就地修改文件。

一次覆写多个页——例如拆分页时——是很危险的操作。如果数据库只写完其中一部分就崩溃，最终会留下损坏的树（例如出现不属于任何父页的 孤儿页，orphan page）。如果硬件不能原子地写入整页，还可能留下只写了一部分的页，这称为 页撕裂（torn page）²³。

为了让数据库能够从崩溃中恢复，B 树实现通常会在磁盘上维护一个额外的数据结构：预写日志（write-ahead log，WAL）。这是一个仅追加文件；对 B 树的每项修改，都必须先写入 WAL，才能应用到树本身的页上。数据库在崩溃后重新启动时，会用这个日志把 B 树恢复到一致状态 ^{2 24}。文件系统中的对应机制称为 日志机制（journaling）。

为了提高性能，B 树实现通常不会立刻把每个修改过的页写入磁盘，而是先把 B 树页在内存中缓冲一段时间。此时，预写日志还负责确保崩溃时不丢数据：只要数据已写入 WAL，并通过 fsync() 系统调用刷到磁盘，它就是持久的，因为数据库能够在崩溃后将它恢复出来 ²⁵。

B 树变体

由于 B 树已经存在很久，多年来发展出了许多变体。这里只举几例：

• 一些数据库（如 LMDB）不覆写页，也不靠 WAL 进行崩溃恢复，而是采用写时复制方案 ²⁶。修改过的页写入新的位置，并为树中的父页创建新版本，使其指向新位置。这种方法对并发控制也很有用，我们将在 “快照隔离与可重复读” 中看到。
• 可以不存储完整的键，而只存储其缩写，以节省页内空间。尤其在树的内部页中，键只需包含足够的信息，能够充当键范围之间的边界即可。一页容纳的键越多，树的分支因子就越大，层数也越少。
• 为了加快按排序顺序扫描键范围，有些 B 树实现会尽量安排树的布局，使叶页在磁盘上也按顺序出现，从而减少磁盘寻道。不过随着树不断增长，这种顺序很难维持。
• 还可以向树中加入额外的指针。例如，让每个叶页引用左右相邻的兄弟页，便能按顺序扫描键，而不必反复跳回父页。

比较 B 树与 LSM 树

根据经验，LSM 树更适合写入密集型应用，而 B 树的读取通常更快 ^{27 28}。不过，基准测试结果往往对工作负载的细节非常敏感。只有使用自己的实际工作负载测试系统，比较才有意义。此外，LSM 树与 B 树并非严格的二选一：存储引擎有时会融合两种方法的特点，例如维护多棵 B 树，再用 LSM 风格将它们合并。本节将简要讨论衡量存储引擎性能时值得考虑的几个方面。

读取性能

在 B 树中查找键，需要在树的每一层读取一页。由于层数通常很少，B 树读取一般很快，性能也比较容易预测。LSM 存储引擎往往需要检查处于不同压实阶段的多个 SSTable，不过布隆过滤器能减少实际需要执行的磁盘 I/O 次数。两种方法都可能有良好表现；究竟哪种更快，取决于存储引擎的具体实现和工作负载。

B 树本身有序，因此范围查询简单而快速。LSM 存储也能利用 SSTable 的排序，但必须并行扫描所有段，再把结果合并起来。布隆过滤器对范围查询无能为力，因为不可能计算范围内每个潜在键的哈希；所以在 LSM 存储中，范围查询的成本高于点查询 ²⁹。

在日志结构存储引擎中，高写入吞吐量可能在内存表填满时引发延迟尖峰。如果数据来不及写入磁盘——或许因为压实速度赶不上新增写入——就会出现这种情况。包括 RocksDB 在内的许多存储引擎会在此时施加 背压（backpressure）：暂停所有读写，直到内存表写入磁盘 ^{30 31}。

至于读取吞吐量，现代 SSD（尤其是 NVMe）可以并行处理许多相互独立的读取请求。LSM 树和 B 树都能提供很高的读取吞吐量，但存储引擎必须经过精心设计，才能利用这种并行能力 ³²。

顺序与随机写入

使用 B 树时，如果应用写入的键散布在整个键空间，产生的磁盘操作也会四处分散，因为存储引擎要覆写的页可能位于磁盘任何位置。日志结构存储引擎则一次写出整个段文件——无论是把内存表写出，还是压实现有段——其大小远远超过 B 树中的一页。

这种数量多、规模小而位置分散的写入模式（如 B 树）称为 随机写入（random write）；数量少、规模较大的写入模式（如 LSM 树）则称为 顺序写入（sequential write）。磁盘的顺序写入吞吐量通常高于随机写入，因此在相同硬件上，日志结构存储引擎一般能承受比 B 树更高的写入吞吐量。这种差异在机械硬盘（HDD）上尤其显著；如今多数数据库使用固态硬盘（SSD），差距有所缩小，但依然不可忽略（参见 “SSD 上的顺序与随机写入”）。

写放大

无论采用哪种存储引擎，应用发出的一次写请求都会转化为底层磁盘上的多次 I/O。对 LSM 树而言，一个值首先写入日志以确保持久性；内存表写入磁盘时又写一次；此后每次所在的键值对参与压实，还要再次写入。（如果值远大于键，可以把键和值分开存放，只压实包含键和值引用的 SSTable，以降低这项开销 ³⁷。）

B 树索引也必须把每份数据至少写两次：一次写入预写日志，一次写入树页本身。为了确保 B 树能在崩溃或断电后正确恢复，有时即使页内只有几个字节发生变化，也必须写出整页 ^{38 39}。

把某个工作负载实际写入磁盘的总字节数，除以不带索引、只写仅追加日志时所需的字节数，得到的比值就是 写放大（write amplification）。（写放大有时也按 I/O 操作次数而非字节数定义。）在写入密集型应用中，瓶颈可能是数据库向磁盘写入的速度。此时写放大越高，在有限磁盘带宽内每秒能处理的写入就越少。

LSM 树和 B 树都有写放大问题。孰优孰劣取决于许多因素，例如键和值的长度，以及覆盖现有键与插入新键各有多频繁。对典型工作负载而言，LSM 树往往具有更低的写放大，因为它不必写出整页，还可以压缩 SSTable 中的数据块 ⁴⁰。这也是 LSM 存储引擎适合写入密集型工作负载的原因之一。

写放大除了影响吞吐量，也关系到 SSD 的磨损：存储引擎的写放大越低，SSD 损耗得就越慢。

测量存储引擎的写入吞吐量时，实验必须运行足够长的时间，才能显现写放大的影响。刚开始向空 LSM 树写入时，压实尚未发生，全部磁盘带宽都可供新写入使用。随着数据库增长，新写入便不得不与压实共享磁盘带宽。

磁盘空间使用

B 树可能随着时间推移逐渐 碎片化。例如，删除大量键之后，数据库文件里可能留下许多 B 树不再使用的页。以后向 B 树添加数据时可以复用这些空闲页，但它们位于文件中间，很难归还给操作系统，所以仍会占用文件系统空间。因此，数据库需要后台进程搬移并重新整理这些页，例如 PostgreSQL 的清理（vacuum）进程 ²⁵。

碎片化对 LSM 树来说问题较小，因为压实过程本来就会定期重写数据文件，而且 SSTable 中不存在留有空闲空间的页。此外，SSTable 中的键值对块更便于压缩，所以生成的磁盘文件通常小于 B 树。已经覆盖的键和值会继续占用空间，直到在压实中移除；不过采用分级压实时，这项开销相当低 ^{40 41}。按大小分层压实（参见 “压实策略”）会占用更多磁盘空间，尤其是在压实过程中临时占用的空间。

如果需要删除某些数据并确信它们确实已经消失——例如为了遵守数据保护法规——磁盘上并存的多份副本也会带来麻烦。在大多数 LSM 存储引擎中，已删除的记录仍可能留在较高层级，直到代表删除操作的墓碑传遍所有压实层级；这一过程可能持续很久。有些专门的存储引擎设计可以更快地传播删除操作 ⁴²。

另一方面，SSTable 段文件的不可变性很适合为数据库创建时间点快照（例如用于备份，或复制一份数据库进行测试）：只需写出内存表，再记下当时存在哪些段文件。只要不删除属于快照的文件，就完全不必实际复制它们。B 树会覆写页，因此很难如此高效地创建快照。

多列索引与二级索引

到目前为止，我们只讨论了键值索引，它们类似于关系模型中的 主键 索引。主键唯一标识关系表中的一行、文档数据库中的一个文档，或图数据库中的一个顶点。数据库里的其他记录可以通过主键（或 ID）引用这一行、文档或顶点，而索引负责解析这种引用。

二级索引 也很常见。在关系数据库中，可以用 CREATE INDEX 命令在同一张表上创建多个二级索引，从而按主键以外的列进行搜索。例如，图 3-1（见 第 3 章）中的各张表很可能都要在 user_id 列上建立二级索引，以便找出属于同一用户的所有行。

二级索引很容易用键值索引构建。主要区别在于，二级索引中的被索引值不一定唯一，也就是说，同一个索引条目下可能对应许多行（或文档、顶点）。有两种解决办法：把索引中的值做成匹配行标识符的列表（类似全文索引的倒排列表）；或者在每个索引项后附加行标识符，使它成为唯一项。B 树一类就地更新的存储引擎和日志结构存储都可以实现二级索引。

在索引中存储值

索引中的键是查询要搜索的内容，而值可以采用以下几种形式：

• 如果实际数据（行、文档或顶点）直接存储在索引结构中，这就是 聚簇索引。例如，MySQL 的 InnoDB 存储引擎总是把表的主键作为聚簇索引；SQL Server 则允许每张表指定一个聚簇索引 ⁴³。
• 另一种选择是让值引用实际数据：它可以是相应行的主键（InnoDB 的二级索引便是如此），也可以直接引用磁盘上的位置。后一种情况下，存放行的地方称为 堆文件（heap file）；堆文件中的数据没有特定顺序，可以是仅追加的，也可以记录已删除的行，以便日后用新数据覆写。例如，Postgres 就使用堆文件 ⁴⁴。
• 两者之间的折中称为 覆盖索引（covering index）或 包含列的索引（index with included columns）：完整的行仍保存在堆文件或主键聚簇索引中，但索引也会保存表的 部分 列 ⁴⁵。这样，一些查询只用索引就能得到答案，不必再解析主键或访问堆文件；此时称该索引 覆盖 了查询。覆盖索引可以加快某些查询，但重复数据会占用更多磁盘空间，也会拖慢写入。

到目前为止讨论的索引，都只是把单个键映射到值。如果需要同时查询表中的多个列（或文档中的多个字段），请参见 “多维索引与全文索引”。

更新值但不改变键时，只要新值不大于旧值，堆文件就能就地覆写记录。如果新值更大，情况会复杂一些：记录可能必须移到堆内空间足够的新位置。此时，要么更新所有索引，使其指向记录在堆中的新位置；要么在旧位置留下一个转发指针 ²。

全内存存储

本章到目前为止讨论的数据结构，都是对磁盘局限的应对。与主内存相比，磁盘处理起来很麻烦。无论是磁性硬盘还是 SSD，要想获得良好的读写性能，都必须仔细安排数据在磁盘上的布局。不过我们能容忍这种麻烦，是因为磁盘有两项显著优势：它是持久的（断电后内容不会丢失），而且每 GB 的成本低于 RAM。

随着 RAM 越来越便宜，磁盘的每 GB 成本优势正在减弱。许多数据集本来就没有那么大，因此完全可以把它们全部放进内存，必要时还可以分布到多台机器上。于是，内存数据库 发展了起来。

有些内存键值存储（如 Memcached）仅用于缓存，机器重启时丢失数据也无妨。但另一些内存数据库以持久性为目标，可以借助特殊硬件（如电池供电的 RAM）、把变更日志写入磁盘、定期把快照写入磁盘，或把内存状态复制到其他机器来实现。

内存数据库重启时，需要从磁盘或通过网络从副本重新加载状态（使用特殊硬件时除外）。它虽然写磁盘，却仍然属于内存数据库，因为磁盘只是用作确保持久性的仅追加日志，所有读取都由内存处理。写入磁盘还有运维上的好处：外部工具可以轻松备份、检查和分析磁盘上的文件。

VoltDB、SingleStore 和 Oracle TimesTen 等产品是采用关系模型的内存数据库。供应商宣称，省去管理磁盘数据结构的全部开销后，它们可以大幅提高性能 ^{46 47}。RAMCloud 则是一个具备持久性的开源内存键值存储，对内存和磁盘中的数据都采用日志结构方法 ⁴⁸。

Redis 和 Couchbase 通过异步写入磁盘提供弱持久性。

反直觉的是，内存数据库的性能优势并不来自省去了磁盘读取。如果内存足够，即便基于磁盘的存储引擎也可能从不真正读取磁盘，因为操作系统本来就会把最近使用的磁盘块缓存在内存中。内存数据库之所以更快，是因为它省去了把内存数据结构编码成可写入磁盘的形式这一开销 ⁴⁹。

除了性能之外，内存数据库还有一个有趣之处：它可以提供很难用磁盘索引实现的数据模型。例如，Redis 为优先队列、集合等各种数据结构提供了类似数据库的接口。由于所有数据都放在内存中，实现起来相对简单。

分析型数据存储

数据仓库最常采用关系数据模型，因为 SQL 通常很适合分析查询。许多图形化数据分析工具可以生成 SQL 查询、可视化查询结果，并让分析师通过 下钻、切片与切块 等操作探索数据。

表面上，数据仓库与关系型 OLTP 数据库十分相似，因为二者都有 SQL 查询接口。然而，它们的内部实现可能大相径庭，因为两者针对的查询模式完全不同。如今，许多数据库供应商只专注于事务处理或分析工作负载中的一种，而非两者兼顾。

Microsoft SQL Server、SAP HANA 和 SingleStore 等数据库在同一产品中同时支持事务处理和数据仓库。不过，这些混合事务/分析处理（HTAP）数据库（已在 “数据仓库” 中介绍）正日益演变成两套彼此独立的存储与查询引擎，只是恰好通过同一个 SQL 接口访问 ^{50 51 52 53}。

云数据仓库

Teradata、Vertica 和 SAP HANA 等数据仓库供应商，既以商业许可证销售本地部署的数据仓库，也提供云端解决方案。随着越来越多的客户迁往云端，Google Cloud BigQuery、Amazon Redshift 和 Snowflake 等新一代云数据仓库也得到广泛采用。与传统数据仓库不同，云数据仓库会利用对象存储、无服务器计算平台等可伸缩的云基础设施。

云数据仓库通常能更好地集成其他云服务，也更具弹性。例如，许多云数据仓库支持自动摄取日志，并且可以轻松接入 Google Cloud Dataflow、Amazon Web Services Kinesis 等数据处理框架。它们把查询计算与存储层解耦，因此也更具弹性 ⁵⁴。数据持久保存在对象存储而非本地磁盘上，于是存储容量和查询计算资源可以分别调整，正如 “云原生系统架构” 所介绍的那样。

Apache Hive、Trino 和 Apache Spark 等开源数据仓库也随着云计算共同演进。分析数据存储迁入对象存储上的数据湖之后，开源数据仓库开始拆分、解耦 ⁵⁵。过去集成在 Apache Hive 这类单一系统中的功能，如今往往由以下独立组件实现：

查询引擎

Trino、Apache DataFusion 和 Presto 等查询引擎负责解析 SQL 查询，将其优化成执行计划，再针对数据执行。查询通常需要由分布式任务并行处理。有些查询引擎内置了任务执行能力，另一些则借助 Apache Spark 或 Apache Flink 等第三方执行框架。

存储格式

存储格式规定如何把表中的行编码成文件里的字节；文件通常保存在对象存储或分布式文件系统中 ¹²。查询引擎可以访问这些数据，使用同一数据湖的其他应用也可以。Parquet、ORC、Lance 和 Nimble 都属于这类格式，下一节还会进一步介绍。

表格式

以 Apache Parquet 等存储格式写出的文件通常不可变。为了支持插入和删除行，还要使用 Apache Iceberg 或 Databricks Delta 等表格式。表格式用一种文件格式来定义哪些文件构成一张表，以及这张表采用什么模式。它还可以提供时间旅行（查询表在过去某个时刻的状态）、垃圾回收乃至事务等高级功能。

数据目录

正如表格式定义哪些文件组成一张表，数据目录定义哪些表组成一个数据库。目录用于创建、重命名和删除表。与存储格式和表格式不同，Snowflake Polaris、Databricks Unity Catalog 等数据目录通常作为独立服务运行，并通过 REST 接口接受查询。Apache Iceberg 也提供目录，既可以嵌入客户端运行，也可以作为独立进程运行。查询引擎读写表时会使用目录信息。传统上，目录与查询引擎集成在一起；将二者解耦之后，数据发现和数据治理系统（见 “数据系统、法律与社会”）也可以访问目录中的元数据。

列式存储

正如 “星型与雪花型：分析模式” 所述，数据仓库通常采用关系模式：一张巨大的事实表通过外键引用各张维度表。如果事实表有数万亿行、数 PB 数据，如何高效存储和查询就成了严峻挑战。维度表通常小得多（只有数百万行），所以本节将重点讨论事实表的存储。

尽管事实表通常有 100 多列，但典型的数据仓库查询一次只访问其中 4、5 列（分析查询很少需要 "SELECT *"）⁵²。以 示例 4-1 为例：它会访问大量行（2024 年中每一笔水果或糖果销售记录），却只需要 fact_sales 表中的三列：date_key、product_sk 和 quantity。其他所有列都被查询忽略了。

SELECT
    dim_date.weekday, dim_product.category,
    SUM(fact_sales.quantity) AS quantity_sold
FROM fact_sales
    JOIN dim_date ON fact_sales.date_key = dim_date.date_key
    JOIN dim_product ON fact_sales.product_sk = dim_product.product_sk
WHERE
    dim_date.year = 2024 AND
    dim_product.category IN ('Fresh fruit', 'Candy')
GROUP BY
    dim_date.weekday, dim_product.category;

怎样才能高效执行这个查询？

大多数 OLTP 数据库都以 面向行（row-oriented）的方式布置存储：表中同一行的所有值相邻存放。文档数据库也很相似，通常把整个文档存成一段连续的字节序列。图 4-1 的 CSV 示例就是如此。

为了处理 示例 4-1 这样的查询，可以在 fact_sales.date_key 和（或）fact_sales.product_sk 上建立索引，告诉存储引擎去哪里寻找某一天或某种产品的所有销售记录。但面向行的存储引擎仍要把这些完整的行（每行有 100 多个属性）从磁盘载入内存，逐一解析，再过滤掉不满足条件的行。这个过程可能十分耗时。

面向列（column-oriented，或 列式，columnar）存储背后的想法很简单：不要把同一行中的所有值放在一起，而要把同一 列 中的所有值放在一起 ⁵⁶。每列分别存储后，查询只需读取和解析自己用到的列，能省下大量工作。图 4-7 用 图 3-5 中事实表的扩展版本展示了这一原理。

面向列的存储布局要求每一列都按相同的行顺序保存数据。因此，要重新拼出完整的一行，可以分别取出每列中的第 23 项，把它们组合成表的第 23 行。

实际上，列式存储引擎并不会把完整的一列（可能有数万亿行）一次存放在一起。它会把表切成若干个包含数千乃至数百万行的数据块，再在每个块内分别保存各列的值 ⁶⁰。许多查询只关注特定日期范围，因此常让每个块包含某个时间戳范围内的行。查询只需在与目标日期范围重叠的块中，加载自己需要的列。

如今，几乎所有分析数据库都采用列式存储 ⁶⁰：从 Snowflake ⁶¹ 这样的大型云数据仓库，到 DuckDB ⁶² 这样的单节点嵌入式数据库，再到 Pinot ⁶³、Druid ⁶⁴ 等产品分析系统。Parquet、ORC ^{65 66}、Lance ⁶⁷ 和 Nimble ⁶⁸ 等存储格式，以及 Apache Arrow ^{65 69}、pandas/NumPy ⁷⁰ 等内存分析格式，也都采用列式布局。InfluxDB IOx ⁷¹、TimescaleDB ⁷² 等时间序列数据库同样以列式存储为基础。

列压缩

除了只从磁盘加载查询需要的列，还可以压缩数据，进一步降低对磁盘吞吐量和网络带宽的需求。幸运的是，列式存储通常很适合压缩。

看看 图 4-7 中各列的值序列：它们往往相当重复，这是很适合压缩的信号。根据列中数据的不同，可以选用不同的压缩技术。其中对数据仓库特别有效的一种是 位图编码，如 图 4-8 所示。

通常，一列中不同值的数量远小于总行数（例如，零售商可能有数十亿笔销售交易，却只有 100,000 种产品）。可以把一个具有 n 个不同值的列转换成 n 张独立位图：每个不同值对应一张位图，每一行对应其中一位。如果该行取这个值，对应位就是 1，否则为 0。

一种选择是按每行一位直接存储这些位图。不过，位图中通常有大量的 0，也就是十分 稀疏。这时还可以使用游程编码：统计连续出现的 0 或 1 的数量，并存下这个数字，如 图 4-8 底部所示。Roaring 位图会在两种位图表示之间切换，总是选用更紧凑的一种 ⁷³。这样可以极其高效地编码一整列。

像这样的位图索引非常适合数据仓库中常见的查询类型。例如：

WHERE product_sk IN (31, 68, 69):

加载 product_sk = 31、product_sk = 68 和 product_sk = 69 对应的三张位图，再计算三者的按位 或，这个操作可以非常高效地完成。

WHERE product_sk = 30 AND store_sk = 3:

加载 product_sk = 30 和 store_sk = 3 对应的位图，再计算按位 与。之所以可行，是因为各列中的行顺序相同：一列位图中的第 k 位，与另一列位图中的第 k 位对应同一行。

位图也可以回答图查询，例如找出社交网络中所有“被用户 X 关注、同时又关注用户 Y”的用户 ⁷⁴。列式数据库还有许多其他压缩方案，参见参考文献 ⁷⁵。

列存储中的排序顺序

在列式存储中，行的存储顺序并不一定重要。最简单的方式是按插入顺序存放，因为插入新行时只需向每一列追加数据。不过，也可以像此前处理 SSTable 那样，为数据指定某种顺序，并把这种顺序用作索引机制。

注意，分别对每一列独立排序毫无意义，因为那样就再也不知道不同列中的哪些项属于同一行。我们之所以能够重建一行，正是因为一列中的第 k 项与另一列中的第 k 项属于同一行。

因此，即使数据按列存储，排序也必须以整行为单位。数据库管理员可以根据自己对常见查询的了解，选择表按哪些列排序。例如，如果查询经常针对“上个月”这样的日期范围，就可以把 date_key 作为第一个排序键。这样查询只需扫描上个月的行，比扫描所有行快得多。

对于第一排序列中取值相同的行，可以用第二列进一步决定顺序。例如，如果 图 4-7 以 date_key 为第一排序键，那么把 product_sk 作为第二排序键或许很有用：同一天、同一种产品的所有销售记录就会在存储中相邻。这有利于在特定日期范围内按产品分组或筛选销售记录的查询。

排序的另一个好处是有助于列压缩。如果主排序列没有太多不同的值，排序后会形成很长的连续序列，同一个值反复出现。使用简单的游程编码——就像 图 4-8 中的位图一样——即可把这一列压缩到几千字节，即使表中有数十亿行也不例外。

这种压缩效果在第一排序键上最强。第二、第三排序键会更加杂乱，不会出现那么长的重复值序列。排序优先级更低的列基本呈随机顺序，压缩效果可能不佳。不过，只要前几列经过排序，整体上依然受益。

写入列式存储

我们在 “事务处理与分析的特征” 中看到，数据仓库的读取通常要聚合大量行；列式存储、压缩和排序都能加快这类读查询。数据仓库的写入则往往是批量导入数据，通常通过 ETL 流程完成。

对列式存储而言，在有序表的中间插入单独一行非常低效，因为从插入位置开始，所有压缩列都必须重写。但一次批量写入很多行，可以分摊重写这些列的成本，因而效率很高。

批量写入通常采用日志结构方法。所有写入先进入一个面向行、有序的内存存储。积累足够多的写入后，再与磁盘上的列编码文件合并，并成批写入新文件。旧文件保持不可变，新文件一次写成，所以对象存储很适合保存这些文件。

查询必须同时检查磁盘上的列数据和内存中的近期写入，再把两部分结果合并起来。查询执行引擎会向用户隐藏这项区别。在分析师看来，插入、更新或删除的数据会立刻反映在后续查询中。Snowflake、Vertica、Apache Pinot、Apache Druid 等许多系统都是这样做的 ^{61 63 64 76}。

查询执行：编译与向量化

复杂的分析型 SQL 查询会被分解成一个 查询计划（query plan），其中包含多个称为 算子（operator）的执行阶段；这些算子可能分布到多台机器上并行执行。查询规划器可以决定选用哪些算子、以什么顺序执行，以及每个算子在哪里运行，从而完成大量优化。

在每个算子内部，查询引擎都要对列中的值执行各种操作，例如找出值属于某个集合的所有行（或许是连接的一部分），或者判断值是否大于 15。查询引擎还要同时查看同一行的多个列，例如找出产品是香蕉、门店又恰好是目标门店的所有销售记录。

数据仓库查询需要扫描数百万行，因此不仅要关注从磁盘读取的数据量，还要关注执行复杂算子所需的 CPU 时间。最简单的算子就像编程语言解释器：遍历每一行时，查看表示查询的数据结构，弄清要对哪些列做什么比较或计算。遗憾的是，这种方式对许多分析场景来说太慢。实践中出现了两种高效执行查询的方法 ⁷⁷：

查询编译（query compilation）

查询引擎根据 SQL 查询生成执行代码。代码逐行迭代，读取相关列中的值，完成所需的比较或计算；如果条件满足，就把必要的值复制到输出缓冲区。随后，查询引擎把生成的代码编译成机器码（往往借助 LLVM 等现有编译器），再对已经载入内存的列编码数据运行。这种代码生成方式类似 Java 虚拟机（JVM）等运行时采用的即时（JIT）编译。

向量化处理（vectorized processing）

查询仍然采用解释执行，而非编译执行；但它不再逐行迭代，而是成批处理一列中的许多值，从而提高速度。数据库内置一组固定的预定义算子，向算子传入参数，就会得到一批结果 ^{50 75}。

例如，把 product_sk 列和“香蕉”的 ID 传给相等比较算子，会得到一张位图：输入列的每个值对应一位，是香蕉则为 1。再把 store_sk 列和目标门店的 ID 传给同一个算子，得到另一张位图。最后把两张位图传给“按位与”算子，如 图 4-9 所示。结果位图中，特定门店售出的每一笔香蕉都对应一个 1。

这两种方法的实现大不相同，但都已投入实际使用 ⁷⁷。它们都能利用现代 CPU 的特点，获得优异性能：

• 优先顺序访问内存而非随机访问，减少缓存未命中 ⁷⁸；
• 把大部分工作放在紧凑的内层循环中（指令少且没有函数调用），使 CPU 指令流水线保持忙碌，并避免分支预测错误；
• 利用多线程和单指令多数据（SIMD）指令等并行机制 ^{79 80}；
• 直接处理压缩数据，不先解码成另一种内存表示，从而省去内存分配和复制的成本。

物化视图与多维数据集

我们曾在 “时间线的物化与更新” 中遇到 物化视图（materialized view）。在关系数据模型中，它是一种类似表的对象，内容是某个查询的结果。物化视图是实际写入磁盘的查询结果副本，而虚拟视图只是编写查询的快捷方式。从虚拟视图读取时，SQL 引擎会即时把它展开成底层查询，再处理展开后的查询。

底层数据变化时，物化视图也必须随之更新。有些数据库可以自动完成这项工作，Materialize 等系统则专门负责维护物化视图 ⁸¹。更新视图会增加写入工作量，但如果工作负载反复执行相同查询，物化视图可以改善读取性能。

物化聚合（materialized aggregate）是一类对数据仓库很有用的物化视图。如前所述，数据仓库查询经常使用 SQL 中的 COUNT、SUM、AVG、MIN 或 MAX 等聚合函数。如果许多查询都使用相同的聚合，每次重新处理原始数据就太浪费了，何不把最常用的计数或总和缓存起来？多维数据集（data cube，或 OLAP 多维数据集，OLAP cube）会创建一个按不同维度分组的聚合网格，正是为了实现这种缓存 ⁸²。图 4-10 展示了一个例子。

暂且假设每条事实记录只外键引用两张维度表——图 4-10 中是 date_key 和 product_sk。这样可以画出一张二维表，一条轴表示日期，另一条轴表示产品。每个单元格保存具有相应“日期—产品”组合的所有事实记录中，某项属性（如 net_price）的聚合值（如 SUM）。再沿每一行或每一列应用同样的聚合，就能得到减少一个维度的汇总结果：不考虑日期的产品销售额，或者不考虑产品的逐日销售额。

一般而言，事实往往不止两个维度。图 3-5 中就有日期、产品、门店、促销和客户五个维度。五维超立方体很难想象，但原理仍然一样：每个单元格保存特定“日期—产品—门店—促销—客户”组合的销售额，随后可以沿每个维度反复汇总这些值。

物化多维数据集的优点，是某些查询会变得非常快，因为结果实际上已经预先计算好了。例如，要知道昨天每家门店的总销售额，只需查看相应维度上的汇总值，不必扫描数百万行。

缺点是多维数据集不如直接查询原始数据灵活。例如，价格不是其中一个维度，就无法计算有多大比例的销售额来自售价超过 100 美元的商品。因此，大多数数据仓库会尽可能保留原始数据，只把多维数据集等聚合用作某些查询的性能优化手段。

多维索引与全文索引

本章前半部分介绍的 B 树和 LSM 树，可以对单个属性执行范围查询。例如，如果键是用户名，就能用它们建立索引，高效找出所有以 L 开头的名字。但有时，只按一个属性搜索并不够用。

最常见的多列索引称为 联合索引（concatenated index）。它把一列接在另一列之后，将多个字段组合成一个键；字段的连接顺序由索引定义指定。这就像老式纸质电话簿提供的索引：从（姓、名）映射到电话号码。由于索引按这个顺序排列，可以找出某个姓氏对应的所有人，也可以找出特定 姓—名 组合对应的所有人。但如果只想查找某个名字对应的所有人，这个索引就毫无用处。

多维索引（multidimensional index）则允许同时查询多个列，这对地理空间数据尤其重要。例如，餐厅搜索网站的数据库可能保存了每家餐厅的经纬度。用户查看地图时，网站需要找出当前矩形地图区域内的所有餐厅。这就需要下面这样的二维范围查询：

SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079
    AND longitude > -0.1162 AND longitude < -0.1004;

在纬度和经度列上建立联合索引，无法高效回答这个查询：它只能返回某一纬度范围内的所有餐厅（经度任意），或者某一经度范围内的所有餐厅（纬度可以是南北两极之间的任意位置），却无法同时约束两者。

一种办法是使用空间填充曲线把二维位置转换成单个数字，再建立普通的 B 树索引 ⁸³。更常见的做法是使用 R 树、Bkd 树 ⁸⁴ 等专门的空间索引；它们对空间进行划分，让邻近的数据点尽量落在同一棵子树中。例如，PostGIS 使用 PostgreSQL 的通用搜索树索引设施，以 R 树实现地理空间索引 ⁸⁵。另一种选择是使用规则排布的三角形、正方形或六边形网格 ⁸⁶。

多维索引并不只用于地理位置。例如，电子商务网站可以在（红、绿、蓝）三个维度上建立索引，以搜索特定颜色范围内的产品；天气观测数据库也可以在（日期、温度）上建立二维索引，高效找出 2013 年中温度介于 25～30℃ 的所有观测记录。使用一维索引，要么必须扫描 2013 年的所有记录（不考虑温度）再按温度筛选，要么反过来处理。二维索引则可以同时按时间戳和温度缩小结果范围 ⁸⁷。

全文检索

全文检索（full-text search）允许按关键词搜索一组文本文档（网页、产品描述等），关键词可以出现在文本中的任意位置 ⁸⁸。信息检索是一门庞大而专门的学科，往往还要针对具体语言进行处理。例如，一些亚洲语言书写时不会在词与词之间添加空格或标点，因此把文本切分成词需要借助模型，判断哪些字符序列构成一个词。全文检索还经常需要匹配相似但不完全相同的词（例如拼写错误或同一个词的不同语法形式），以及同义词。这些问题都超出了本书的范围。

不过从核心原理看，全文检索也可以视为一种多维查询：文本中可能出现的每个词（即一个 词项，term）都是一个维度。包含词项 x 的文档在维度 x 上取值为 1，不包含 x 则取值为 0。搜索提到“红苹果”的文档，就是同时寻找 红 维度和 苹果 维度都为 1 的文档。这样一来，维度数可能非常庞大。

许多搜索引擎使用 倒排索引（inverted index）回答这类查询。它是一种键值结构：键是词项，值是所有包含该词项的文档 ID 列表，即 倒排列表（postings list）。如果文档 ID 是连续数字，倒排列表也可以表示成 图 4-8 那样的稀疏位图：如果 ID 为 n 的文档包含词项 x，那么词项 x 的位图中第 n 位就是 1 ⁸⁹。

现在，查找同时包含词项 x 和 y 的所有文档，就类似于用向量化数据仓库查询寻找满足两个条件的行（图 4-9）：载入 x 和 y 对应的两张位图，再计算按位与。即使位图经过游程编码，这个操作也可以高效完成。

Elasticsearch 和 Solr 使用的全文索引引擎 Lucene 就采用这种方法 ⁹⁰。它把从词项到倒排列表的映射保存在类似 SSTable 的有序文件中，再使用本章前面介绍的日志结构方法，在后台合并这些文件 ⁹¹。PostgreSQL 的 GIN 索引也通过倒排列表支持全文检索，以及 JSON 文档内部的索引 ^{92 93}。

除了把文本切分成词，还可以找出所有长度为 n 的子串，称为 n-gram。例如，字符串 "hello" 的 3-gram（n = 3）是 "hel"、"ell" 和 "llo"。如果为所有 3-gram 建立倒排索引，就能搜索任意长度至少为三个字符的子串。这样的索引甚至支持在搜索查询中使用正则表达式，缺点是体积相当大 ⁹⁴。

为了应对文档或查询中的拼写错误，Lucene 可以搜索与目标词相差一定编辑距离的词（编辑距离为 1，表示增加、删除或替换了一个字母）⁹⁵。它把词项集合存储成一个以键中字符为边的有限状态自动机，结构类似 字典树（trie）⁹⁶；再将其转换成 莱文斯坦自动机（Levenshtein automaton），从而高效搜索给定编辑距离以内的词 ⁹⁷。

向量嵌入

语义搜索不只处理同义词和拼写错误，还试图理解文档表达的概念和用户的意图。例如，帮助中心有一页标题是“取消订阅”，那么用户搜索“如何关闭账户”或“终止合同”时也应当找到它：这些说法用词完全不同，意思却十分接近。

为了理解文档的语义，也就是它表达的含义，语义搜索索引会使用嵌入模型，把文档转换成由浮点数组成的向量，称为 向量嵌入（vector embedding）。这个向量表示多维空间中的一个点，每个浮点数表示文档在某一维坐标轴上的位置。如果输入文档的语义相似，嵌入模型就会生成在多维空间中彼此接近的向量。

例如，一篇介绍农业的维基百科页面，其三维向量嵌入可能是 [0.1, 0.22, 0.11]。介绍蔬菜的页面应该离它很近，向量或许是 [0.13, 0.19, 0.24]。介绍星型模式的页面则可能得到 [0.82, 0.39, -0.74]，距离相对很远。只看数字也能发现，前两个向量比第三个更接近。

实际的嵌入模型使用大得多的向量，往往包含 1,000 多个数字，但原理相同。我们不会试图理解每个数字各自代表什么；它们只是嵌入模型用来指向抽象多维空间中某个位置的方式。搜索引擎通过余弦相似度、欧几里得距离等距离函数衡量向量间的距离。余弦相似度计算两个向量夹角的余弦，判断它们有多接近；欧几里得距离则计算空间中两点间的直线距离。

Word2Vec ⁹⁸、BERT ⁹⁹ 和 GPT ¹⁰⁰ 等许多早期嵌入模型都处理文本数据，通常以神经网络实现。后来，研究者又为视频、音频和图像创建了嵌入模型。近来，模型架构进一步走向 多模态（multimodal）：同一个模型可以为文本、图像等多种模态生成向量嵌入。

用户输入查询时，语义搜索引擎会把查询及其相关上下文（例如用户位置）交给嵌入模型，生成查询的向量嵌入。随后，搜索引擎还必须通过向量索引，找出向量嵌入与查询相似的文档。

向量索引保存一组文档的向量嵌入。查询时传入查询本身的向量嵌入，索引会返回向量最接近查询向量的文档。前面介绍的 R 树不适合维度很高的向量，因此需要专门的向量索引，例如：

平面索引（Flat indexes）

向量原样保存在索引中。查询必须读取每个向量，并测量它与查询向量的距离。平面索引结果精确，但逐一计算查询与每个向量的距离很慢。

倒排文件（IVF）索引

把向量空间聚类成若干向量分区，以减少必须比较的向量数；这些分区称为 质心（centroid）。IVF 索引比平面索引更快，却只能给出近似结果：查询向量和某个文档向量可能十分接近，却恰好落入不同分区。查询 IVF 索引时，首先要指定 探测数（probes），也就是需要检查多少个分区。探测数越大，查询越准确，但也越慢，因为必须比较更多向量。

分层可导航小世界（HNSW）

HNSW 索引维护向量空间的多个层级，如 图 4-11 所示。每层都表示成一张图：节点代表向量，边表示向量彼此接近。查询先在节点很少的最顶层找到最近向量，再进入下一层的同一节点；下一层连接更密集，查询沿边寻找更接近查询向量的向量。这个过程不断重复，直至最底层。与 IVF 一样，HNSW 也是近似索引。

许多流行的向量数据库都实现了 IVF 和 HNSW 索引。Facebook 的 Faiss 库为两者提供了许多变体 ¹⁰¹，PostgreSQL 的 pgvector 也同时支持这两种索引 ¹⁰²。IVF 和 HNSW 算法的完整细节超出了本书范围，不过介绍它们的论文是很好的参考资料 ^{103 104}。

总结

在本章中，我们试图深入了解数据库是如何处理存储与检索的。把数据存入数据库时会发生什么？日后再次查询这些数据时，数据库又会做什么？

“分析型与事务型系统” 介绍了事务处理（OLTP）与分析（OLAP）的区别。本章进一步看到，针对 OLTP 优化的存储引擎，与针对分析优化的存储引擎大不相同：

• OLTP 系统针对大量请求优化；每个请求只读写少量记录，并且需要迅速响应。记录通常通过主键或二级索引访问，这些索引一般是从键到记录的有序映射，也支持范围查询。
• 数据仓库等分析型系统，针对需要扫描大量记录的复杂读查询优化。它们通常采用经过压缩的列式存储布局，尽可能减少查询要从磁盘读取的数据量；并通过查询的即时编译或向量化，尽可能减少处理数据所耗费的 CPU 时间。

在 OLTP 方面，我们看到了两个主要思想流派的存储引擎：

• 日志结构学派只允许向文件追加数据和删除过时文件，从不更新已经写出的文件。SSTable、LSM 树、RocksDB、Cassandra、HBase、ScyllaDB、Lucene 等都属于这一类。一般而言，日志结构存储引擎能提供很高的写入吞吐量。
• 就地更新学派把磁盘视为一组大小固定、可以覆写的页。B 树是这种理念最典型的代表，所有主流关系型 OLTP 数据库和许多非关系数据库都使用它。根据经验，B 树通常更适合读取，其读取吞吐量高于日志结构存储，响应时间也更短。

随后，我们考察了能够同时搜索多个条件的索引：R 树等多维索引可以同时按经度和纬度搜索地图上的点；全文检索索引则可以搜索同一段文本中出现的多个关键词。最后，向量数据库用于对文本文档及其他媒体进行语义搜索；它把数据表示成高维向量，再通过比较向量相似度找出相似文档。

作为应用开发者，如果掌握了这些有关存储引擎内部机制的知识，就能更好地判断哪种工具最适合自己的应用。需要调整数据库的调优参数时，这种理解也让你能够设想参数调高或调低会产生怎样的影响。

尽管本章无法让你成为某一种存储引擎的调优专家，但希望它已经提供了足够的概念和词汇，让你能够读懂自己所选数据库的文档。

参考文献

5 编码与演化

唯变所适。

以弗所的赫拉克利特，引自柏拉图《克拉提鲁斯》（公元前 360 年）

应用程序不可避免地会随时间而变化。随着新产品推出、对用户需求的理解日益深入，或者商业环境发生变化，应用程序总要增添或修改功能。在 第 2 章 中，我们介绍了 可演化性（evolvability）的概念：应该尽力构建能够灵活适应变化的系统（参见“可演化性：让变化更容易”）。

在大多数情况下，修改应用程序的功能也意味着需要更改其存储的数据：可能需要记录新的字段或记录类型，也可能需要以新的方式呈现现有数据。

我们在 第 3 章 中讨论的数据模型，采用不同的方法来应对这种变化。关系数据库通常假定数据库中的所有数据都遵循同一个模式：尽管可以通过模式迁移（即 ALTER 语句）来更改模式，但任何时刻都只有一个模式有效。相比之下，读时模式（即“无模式”）数据库不会强制使用某个模式，因此数据库中可以混合存放在不同时间写入的新旧数据格式（参见“文档模型中的模式灵活性”）。

当数据格式或模式发生变化时，通常也需要相应地修改应用程序代码（例如，为记录添加新字段，然后让应用程序开始读写该字段）。但在大型应用程序中，代码变更往往无法瞬间完成：

• 对于服务端应用程序，可能需要执行 滚动升级（rolling upgrade，也称为 逐步发布，staged rollout）：每次只把新版本部署到少数几个节点，确认运行正常后，再逐步部署到所有节点。这样无需中断服务即可上线新版本，有利于更频繁地发布，也让系统更容易演化。
• 对于客户端应用程序，是否升级只能任由用户决定，而用户可能很长时间都不安装更新。

这意味着，新旧版本的代码以及新旧数据格式，可能同时存在于系统中。系统要继续顺利运行，就需要保持双向兼容：

向后兼容（backward compatibility）

较新的代码可以读取由较旧代码写入的数据。

向前兼容（forward compatibility）

较旧的代码可以读取由较新代码写入的数据。

向后兼容通常不难实现：新代码的作者知道旧代码写入的数据格式，因此可以显式地处理它（必要时，只要保留读取旧数据的旧代码即可）。向前兼容则可能棘手得多，因为旧代码必须忽略新版本代码新增的部分。

向前兼容还有一个难点，如 图 5-1 所示。假设你在记录模式中添加了一个字段，新代码创建了一条包含这个字段的记录，并把它存入数据库。随后，尚不了解这个新字段的旧版代码读出记录，做了更新，又将其写回。在这种情况下，通常希望旧代码把新字段原样保留下来，即使它无法解释该字段。但如果记录被解码成一个不会显式保留未知字段的模型对象，数据就可能丢失，如 图 5-1 所示。

本章将介绍几种数据编码格式，包括 JSON、XML、Protocol Buffers 和 Avro。我们尤其关注这些格式如何应对模式变化，以及如何支持新旧数据与新旧代码共存。随后，我们会讨论这些格式如何用于存储和通信，包括数据库、Web 服务、REST API、远程过程调用（RPC）、工作流引擎，以及 actor 和消息队列等事件驱动系统。

编码数据的格式

程序通常（至少）使用两种形式的数据：

1. 在内存中，数据保存在对象、结构体、列表、数组、哈希表、树等数据结构中。这些结构通常使用指针，针对 CPU 的高效访问与操作进行了优化。
2. 如果要将数据写入文件或通过网络发送，就必须将其编码成某种自包含的字节序列（例如 JSON 文档）。由于指针对其他进程没有意义，这种字节序列表示通常与内存中的数据结构大不相同。

因此，需要在两种表示之间进行转换。从内存表示转换为字节序列，称为 编码（encoding，也称为 序列化，serialization，或 编组，marshalling）；反过来则称为 解码（decoding，也称为 解析，parsing，反序列化，deserialization，或 解组，unmarshalling）。

也有一些情况不需要编码和解码。例如，“查询执行：编译与向量化” 中介绍过，数据库可以直接操作从磁盘加载的压缩数据。还有一些 零拷贝（zero-copy）数据格式，例如 Cap’n Proto 和 FlatBuffers；它们既可用于运行时，也可直接用于磁盘或网络上的数据，无需显式的转换步骤。

不过，大多数系统仍需在内存对象与扁平的字节序列之间转换。这是个极其常见的问题，因而有数不清的库和编码格式可供选择。下面先来简要概览一下。

特定语言的格式

许多编程语言都内置了将内存对象编码成字节序列的功能。例如，Java 有 java.io.Serializable，Python 有 pickle，Ruby 有 Marshal，等等。此外还有许多第三方库，例如 Java 的 Kryo。

这些编码库非常方便，只需很少的额外代码就能保存和恢复内存对象。但是，它们也有一些深层次的问题：

• 这类编码通常与某种编程语言紧密绑定，其他语言很难读取。如果用这类编码存储或传输数据，就可能在很长一段时间内把自己锁定在当前语言上，也很难与其他组织的系统集成——它们使用的语言可能与你不同。
• 为了恢复出相同类型的对象，解码过程必须能够实例化任意类，这经常成为安全漏洞的来源 ¹。如果攻击者能让应用程序解码任意字节序列，就可能借此实例化任意类，进而实施远程执行任意代码之类的恶意操作 ^{2 3}。
• 这些库通常事后才考虑数据的版本管理。它们只求快速、方便地编码数据，往往忽略向前兼容和向后兼容这些棘手的问题 ⁴。
• 效率——包括编码或解码所耗的 CPU 时间，以及编码结果的大小——往往也是事后才考虑的。例如，Java 的内置序列化就因性能糟糕、编码臃肿而臭名昭著 ⁵。

因此，除非数据只作非常短暂的使用，否则采用语言内置的编码通常不是个好主意。

JSON、XML 及其二进制变体

说到可由多种编程语言读写的标准编码，JSON 和 XML 是最显眼的候选者。它们广为人知、广受支持，也几乎同样“广受憎恶”。XML 经常因为过于冗长和不必要的复杂而受到批评 ⁶。JSON 的流行，主要得益于 Web 浏览器的内置支持，以及它相对于 XML 的简单性。CSV 是另一种流行的语言无关格式，但它只能表示不含嵌套的表格数据。

JSON、XML 和 CSV 都是文本格式，因而具有一定的人类可读性（尽管它们的语法一直是热门争议话题）。除了表面的语法问题，它们还有一些不易察觉的麻烦：

• 数字 的编码有很多模糊之处。在 XML 和 CSV 中，无法区分数值和碰巧只由数字组成的字符串，除非借助外部模式。JSON 虽然区分字符串和数值，却不区分整数与浮点数，也没有规定精度。

  处理大数时，这会造成问题。例如，大于 2⁵³ 的整数无法用 IEEE 754 双精度浮点数精确表示；如果某种语言像 JavaScript 一样使用浮点数来解析数值，这些大整数就会失真 ⁷。X（原 Twitter）使用 64 位数字标识每条帖子，便是一个实际例子。为了绕过 JavaScript 应用程序无法正确解析这类数字的问题，其 API 返回的 JSON 会把帖子 ID 包含两次：一次作为 JSON 数值，另一次作为十进制字符串 ⁸。

• JSON 和 XML 对 Unicode 字符串（即人类可读的文本）支持得很好，却不支持二进制字符串（即不带字符编码的字节序列）。二进制字符串非常有用，人们通常把二进制数据用 Base64 编码成文本来绕过这一限制，再由模式说明该值应按 Base64 解读。这个办法虽然管用，却有些取巧，而且会让数据体积增加 33%。

• XML 模式和 JSON 模式功能强大，因而学习和实现起来都相当复杂。数字、二进制字符串等数据的正确解释依赖模式中的信息，所以不使用 XML/JSON 模式的应用程序可能不得不硬编码相应的编码与解码逻辑。

• CSV 没有任何模式，每行每列的含义完全由应用程序自行定义。如果应用程序变更增加了一行或一列，就必须手工处理这种变化。CSV 本身也相当含糊：如果值中包含逗号或换行符，该怎么办？尽管转义规则已有正式规范 ⁹，却不是所有解析器都正确实现了它。

尽管有这些缺陷，JSON、XML 和 CSV 对许多用途来说已经足够好。它们很可能会继续流行，尤其是作为数据交换格式——也就是把数据从一个组织发送给另一个组织。在这种情况下，只要大家能就格式达成一致，格式是否美观或高效往往并不重要。毕竟，让不同组织对 任何事情 达成一致，就已经压倒了大多数其他考量。

JSON 模式

当数据需要在系统间交换或写入存储时，JSON 模式已经成为广泛采用的数据建模方式。它出现在许多地方：作为 OpenAPI Web 服务规范的一部分用于 Web 服务（参见“Web 服务”）；用于 Confluent Schema Registry、Red Hat Apicurio Registry 等模式注册表；也用于数据库，例如 PostgreSQL 的 pg_jsonschema 验证扩展，以及 MongoDB 的 $jsonSchema 验证语法。

JSON 模式规范提供了许多功能。它包含字符串、数值、整数、对象、数组、布尔值和空值等标准基本类型，还另有一套验证规范，开发者可以用它给字段附加约束。例如，可以规定 port 字段的最小值为 1、最大值为 65535。

JSON 模式可以采用开放或封闭的内容模型。开放内容模型允许出现模式未定义的任意字段，而且这些字段可以是任意数据类型；封闭内容模型则只允许出现显式定义的字段。在 JSON 模式中，把 additionalProperties 设为 true 就会启用开放内容模型，而这恰好是默认值。因此，JSON 模式通常是在定义 不允许什么（也就是已定义字段上的无效值），而不是穷举模式中 允许什么。

开放内容模型功能强大，但也可能相当复杂。假设你想定义一个从整数（例如 ID）到字符串的映射。JSON 没有映射或字典类型，只有“对象”类型；对象的键必须是字符串，值则可以是任意类型。此时可以借助 JSON 模式，用 patternProperties 和 additionalProperties 约束对象，规定键只能由数字组成、值只能是字符串，如 示例 5-1 所示。

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "patternProperties": {
        "^[0-9]+$": {
        "type": "string"
    }
    },
    "additionalProperties": false
}

除了开放和封闭内容模型以及验证器，JSON 模式还支持条件式 if/else 模式逻辑、命名类型、远程模式引用等诸多功能。这些能力造就了一门十分强大的模式语言，却也让模式定义变得庞杂难用。解析远程模式、推断条件规则，或者以向前或向后兼容的方式演化模式，都可能很有挑战 ¹⁰。XML 模式也有类似的问题 ¹¹。

二进制编码

JSON 比 XML 简洁，但两者与二进制格式相比仍然很占空间。于是，人们开发出了大量 JSON 的二进制编码（例如 MessagePack、CBOR、BSON、BJSON、UBJSON、BISON、Hessian 和 Smile）以及 XML 的二进制编码（例如 WBXML 和 Fast Infoset）。这些格式更紧凑，有时解析也更快，因此在各自的细分领域得到应用；但没有一种像文本版 JSON 和 XML 那样普及 ¹²。

其中一些格式扩展了数据类型集合，例如区分整数和浮点数，或者支持二进制字符串；除此之外，它们仍然沿用 JSON/XML 的数据模型。尤其是，它们没有规定模式，所以必须把所有对象字段名都写进编码后的数据。也就是说，对 示例 5-2 中的 JSON 文档进行二进制编码时，某处仍须包含 userName、favoriteNumber 和 interests 这些字符串。

{
    "userName": "Martin",
    "favoriteNumber": 1337,
    "interests": ["daydreaming", "hacking"]
}

下面来看 MessagePack，它是 JSON 的一种二进制编码。图 5-2 展示了用 MessagePack 编码 示例 5-2 中的 JSON 文档后得到的字节序列。开头几个字节的含义如下：

1. 第一个字节 0x83 表示接下来是一个对象（高四位 = 0x80），其中有三个字段（低四位 = 0x03）。（如果对象超过 15 个字段，字段数无法装进四位，就会改用另一种类型标识符，并用两个或四个字节编码字段数。）
2. 第二个字节 0xa8 表示接下来是一个字符串（高四位 = 0xa0），长度为八个字节（低四位 = 0x08）。
3. 接下来的八个字节，是以 ASCII 编码的字段名 userName。由于前面已经给出长度，不需要再用标记或转义来指示字符串在哪里结束。
4. 再往后的七个字节，以前缀 0xa6 加六个字母的方式编码字符串值 Martin，后续内容依此类推。

二进制编码共 66 字节，只比去掉空白后的文本 JSON（81 字节）略小一点。各种 JSON 二进制编码在这方面都差不多。如此有限的空间节省（外加也许更快的解析速度），是否值得牺牲人类可读性，并不好说。

接下来我们会看到，同一条记录其实可以只用 32 字节编码，效果好得多。

Protocol Buffers

Protocol Buffers（protobuf）是 Google 开发的二进制编码库。它与最初由 Facebook 开发的 Apache Thrift 很相似 ¹³；本节关于 Protocol Buffers 的大部分内容也适用于 Thrift。

Protocol Buffers 要求任何待编码的数据都有模式。要用 Protocol Buffers 编码 示例 5-2 中的数据，可以用 Protocol Buffers 的接口定义语言（IDL）这样描述模式：

syntax = "proto3";

message Person {
    string user_name = 1;
    int64 favorite_number = 2;
    repeated string interests = 3;
}

Protocol Buffers 自带代码生成工具。它接收上述模式定义，生成用各种编程语言实现该模式的类，应用程序可以调用生成的代码来编码或解码符合模式的记录。与 JSON 模式相比，Protocol Buffers 的模式语言非常简单：它只定义记录的字段及其类型，不支持对字段取值施加其他约束。

使用 Protocol Buffers 编码器对 示例 5-2 进行编码，需要 33 字节，如 图 5-3 所示 ¹⁴。

与 图 5-2 类似，每个字段都有类型注解，用来说明它是字符串、整数还是其他类型；必要时还会给出长度，例如字符串长度。数据中的字符串（“Martin”“daydreaming”“hacking”）也和之前一样编码为 ASCII——准确地说，是 UTF-8。

与 图 5-2 相比，最大的区别在于这里没有字段名（userName、favoriteNumber、interests）。编码数据包含的是数字形式的 字段标签（field tag）（1、2 和 3），也就是模式定义中的那些数字。字段标签好比字段的别名：无需写出字段名，就能以紧凑的方式指出所说的是哪个字段。

Protocol Buffers 把字段类型和标签号塞进同一个字节，进一步节省了空间。它还使用变长整数：数字 1337 编码成两个字节，每个字节的最高位表示后面是否还有更多字节。这样，-64 到 63 之间的数字用一个字节编码，-8192 到 8191 之间的数字用两个字节编码，依此类推；数字越大，占用的字节就越多。

Protocol Buffers 没有显式的列表或数组数据类型。interests 字段上的 repeated 修饰符表示该字段包含一组值，而不是单个值。在二进制编码中，列表元素只是同一字段标签在同一条记录中重复出现。

字段标签与模式演化

前面说过，模式不可避免地会随时间改变，这称为 模式演化（schema evolution）。Protocol Buffers 如何在保持向后和向前兼容的同时处理模式变更？

从示例可以看出，一条编码后的记录，就是各个已编码字段的拼接。每个字段由标签号（示例模式中的 1、2、3）标识，并带有数据类型注解（例如字符串或整数）。如果某个字段没有值，就直接从编码记录中省略。由此可见，字段标签对编码数据的含义至关重要。模式中的字段名可以修改，因为编码数据从不引用字段名；但字段标签不能修改，否则现有的所有编码数据都会失效。

可以向模式中添加新字段，只要给它分配一个新的标签号。旧代码并不知道新增的标签号；当它读取新代码写入的数据、遇到无法识别的新字段时，只需忽略该字段即可。借助数据类型注解，解析器能够判断要跳过多少字节；同时还应保留未知字段，以免出现 图 5-1 所示的问题。这样就保持了向前兼容：旧代码仍能读取新代码写入的记录。

向后兼容又如何呢？只要每个字段的标签号唯一，新代码就总能读取旧数据，因为标签号的含义没有改变。如果新模式增加了一个字段，而读取的旧数据尚不包含它，就会填入默认值：例如，字符串字段填入空字符串，数值字段填入零。

删除字段与添加字段类似，只是向后兼容和向前兼容的考量正好相反。已经用过的标签号绝不能再次使用，因为某处可能仍有带着旧标签号的数据，而新代码必须忽略这个字段。可以在模式定义中把用过的标签号标记为保留，确保以后不会忘记。

字段的数据类型能否改变？某些类型可以，详情需查阅文档，但值有可能被截断。例如，假设把一个 32 位整数改成 64 位整数。新代码可以轻松读取旧代码写入的数据，因为解析器能用零补齐缺少的位。但如果旧代码读取新代码写入的数据，它仍会用 32 位变量保存这个值；一旦解码后的 64 位值装不进 32 位，就会被截断。

Avro

Apache Avro 是另一种二进制编码格式，与 Protocol Buffers 有着颇为有趣的差异。它于 2009 年作为 Hadoop 的子项目启动，起因是 Protocol Buffers 不适合 Hadoop 的使用场景 ¹⁵。

Avro 也使用模式来规定待编码数据的结构。它有两种模式语言：一种是供人编辑的 Avro IDL，另一种基于 JSON，更便于机器读取。与 Protocol Buffers 一样，Avro 的模式语言只规定字段及其类型，不支持 JSON 模式那样复杂的验证规则。

用 Avro IDL 编写的示例模式可能如下所示：

record Person {
    string                  userName;
    union { null, long }    favoriteNumber = null;
    array<string>           interests;
}

等价的 JSON 表示如下：

{
    "type": "record",
    "name": "Person",
    "fields": [
        {"name": "userName",        "type": "string"},
        {"name": "favoriteNumber",  "type": ["null", "long"], "default": null},
        {"name": "interests",       "type": {"type": "array", "items": "string"}}
    ]
}

首先请注意，模式中没有标签号。如果用这个模式编码示例记录（示例 5-2），Avro 的二进制编码只有 32 字节，是目前所见编码中最紧凑的。图 5-4 展示了这个字节序列的组成。

仔细查看这个字节序列，会发现其中没有任何内容标识字段或数据类型；编码仅仅是各个值的拼接。字符串就是长度前缀加上 UTF-8 字节，但编码数据本身并不说明它是字符串——它同样可能是整数或其他任何东西。整数则使用变长编码。

要解析二进制数据，必须按照字段在模式中出现的顺序逐一读取，并由模式告知每个字段的数据类型。这意味着，读取数据的代码只有使用与写入代码 完全相同的模式，才能正确解码二进制数据。读写双方的模式只要有任何不一致，解码结果就会出错。

那么，Avro 如何支持模式演化？

写入者模式与读取者模式

当应用程序要编码数据——例如写入文件或数据库，或者通过网络发送——它会使用自己所知版本的模式；这个模式可能已经编译进应用程序。这称为 写入者模式（writer’s schema）。

当应用程序要解码数据——例如从文件或数据库读取，或者从网络接收——它会使用两个模式：一个是与编码时完全相同的写入者模式，另一个是可能有所不同的 读取者模式（reader’s schema），如 图 5-5 所示。读取者模式定义了应用程序代码期望每条记录包含哪些字段，以及这些字段的类型。

如果读写双方的模式相同，解码很简单。如果不同，Avro 会并排比较写入者模式与读取者模式，把数据从前者转换成后者，从而协调其中的差异。Avro 规范 ^{16 17} 精确定义了这一解析过程，图 5-6 给出了示意。

例如，写入者模式和读取者模式中的字段顺序不同并不成问题，因为模式解析会按字段名配对。读取代码如果遇到只存在于写入者模式、却不在读取者模式中的字段，就将其忽略；如果读取代码需要某个字段，而写入者模式中没有同名字段，就填入读取者模式声明的默认值。

模式演化规则

对 Avro 而言，向前兼容意味着可以用新版模式写入、用旧版模式读取；反过来，向后兼容意味着可以用旧版模式写入、用新版模式读取。

为了保持兼容，只能添加或删除带默认值的字段（示例 Avro 模式中的 favoriteNumber 字段，默认值就是 null）。例如，假设新增了一个带默认值的字段，于是该字段存在于新模式、却不存在于旧模式。当采用新模式的读取者读取旧模式写入的记录时，就会为缺少的字段填入默认值。

如果新增的字段没有默认值，新读取者就无法读取旧写入者产生的数据，因而破坏向后兼容。如果删除的字段没有默认值，旧读取者就无法读取新写入者产生的数据，因而破坏向前兼容。

在某些编程语言中，任何变量都可以默认取 null，Avro 却并非如此：如果希望字段允许为 null，就必须使用 联合类型（union type）。例如，union { null, long, string } field; 表示 field 可以是数字、字符串或 null。而且，只有当 null 是联合类型的第一个分支时，才能把它用作默认值。这种写法比默认所有内容都可为 null 略显冗长，却明确说明了什么可以、什么不可以为 null，从而有助于避免错误 ¹⁸。

只要 Avro 能完成相应的类型转换，就可以更改字段的数据类型。字段名也能更改，不过稍微麻烦一些：读取者模式可以为字段名声明别名，从而让旧写入者模式中的字段名与别名匹配。因此，更改字段名向后兼容，却不向前兼容。同样，给联合类型增加一个分支向后兼容，却不向前兼容。

但什么是写入者模式？

到目前为止，我们一直略过一个重要问题：读取者如何知道某段数据是用哪个写入者模式编码的？不能把整个模式塞进每条记录，因为模式很可能比编码后的数据大得多，那样二进制编码省下的空间就全白费了。

答案取决于 Avro 的使用场景。举几个例子：

包含大量记录的大文件

Avro 的一种常见用途，是存储包含数百万条记录的大文件，所有记录都使用同一个模式编码（我们会在 第 11 章 讨论这种情况）。此时，文件的写入者只需在文件开头写入一次写入者模式。Avro 为此规定了一种文件格式，称为对象容器文件。

逐条写入记录的数据库

在数据库中，不同记录可能在不同时间用不同的写入者模式写入，不能假定所有记录都采用同一个模式。最简单的解决方案，是在每条编码记录的开头放一个版本号，并在数据库中维护模式版本列表。读取者取出记录后先提取版本号，再从数据库取得该版本对应的写入者模式，用它解码记录的其余部分。

例如，Apache Kafka 的 Confluent Schema Registry ¹⁹ 和 LinkedIn 的 Espresso ²⁰ 就采用这种做法。

通过网络连接发送记录

当两个进程通过双向网络连接通信时，可以在建立连接时协商模式版本，并在连接的整个生命周期中使用这个模式。Avro RPC 协议（参见“流经服务的数据流：REST 与 RPC”）就是这样工作的。

无论采用哪种方式，维护模式版本数据库都很有用：它既是文档，也让你有机会检查模式兼容性 ²¹。版本号可以是简单递增的整数，也可以是模式的哈希值。

动态生成的模式

与 Protocol Buffers 相比，Avro 的一个优点是模式中没有任何标签号。但这为什么重要？在模式中维护几个数字，能有什么问题？

区别在于，Avro 对 动态生成 的模式更友好。假设你想把关系数据库的内容转储到文件，并希望使用二进制格式，避开前面提到的 JSON、CSV、XML 等文本格式的问题。使用 Avro 时，可以很容易地从关系模式生成 Avro 模式（采用前面展示过的 JSON 表示），再用它编码数据库内容，把所有数据转储到 Avro 对象容器文件中 ²²。可以为每张数据库表生成一个记录模式，让表中的每一列对应记录中的一个字段，数据库列名则映射为 Avro 字段名。

如果数据库模式发生变化，例如表中增加一列、删除一列，只要根据更新后的数据库模式生成新的 Avro 模式，再用新模式导出数据即可。数据导出过程无需关注具体发生了什么模式变更，每次运行时照常完成模式转换就行。读取新数据文件的人会看到记录字段发生了变化，但由于字段按名称标识，更新后的写入者模式仍能与旧读取者模式匹配。

相比之下，如果用 Protocol Buffers 完成这项工作，字段标签很可能必须手工分配：数据库模式每次变化，管理员都得手工更新数据库列名到字段标签的映射。（这也许能够自动化，但模式生成器必须格外谨慎，不能再次分配以前用过的标签号。）动态生成模式从来就不是 Protocol Buffers 的设计目标，却是 Avro 的设计目标之一。

模式的优点

正如我们所见，Protocol Buffers 和 Avro 都用模式描述二进制编码格式。它们的模式语言比 XML 模式或 JSON 模式简单得多；后两者支持更细致的验证规则，例如“这个字段的字符串值必须匹配某个正则表达式”，或者“这个字段的整数值必须介于 0 和 100 之间”。Protocol Buffers 和 Avro 实现起来更简单，使用起来也更简单，因此已经支持相当广泛的编程语言。

这些编码背后的思想绝不新鲜。例如，它们与 ASN.1 有许多共同之处。ASN.1 是一门模式定义语言，早在 1984 年便首次标准化 ^{23 24}；它曾用于定义各种网络协议，其二进制编码 DER 至今仍用于编码 SSL 证书（X.509）²⁵。与 Protocol Buffers 类似，ASN.1 也用标签号支持模式演化 ²⁶。不过，ASN.1 非常复杂，文档也很糟糕，因此可能并不适合新的应用程序。

许多数据系统也为自身数据实现了某种专有二进制编码。例如，大多数关系数据库都有自己的网络协议，用于接收查询并返回响应。这些协议通常只适用于特定数据库，由数据库厂商提供驱动程序（例如采用 ODBC 或 JDBC API），把数据库网络协议中的响应解码成内存数据结构。

由此可见，尽管 JSON、XML 和 CSV 等文本格式非常普遍，基于模式的二进制编码同样是可行的选择，而且具备一些很好的性质：

• 它们可以比各种“二进制 JSON”变体紧凑得多，因为编码数据中不必包含字段名。
• 模式本身就是一种很有价值的文档。解码时必须使用模式，所以可以确信它与数据保持同步；而手工维护的文档很容易与实际情况脱节。
• 维护模式数据库，可以在部署任何变更之前检查它是否保持向前和向后兼容。
• 对于静态类型编程语言的用户，从模式生成代码很有用，因为这样可以在编译时进行类型检查。

总而言之，模式演化提供了与无模式/读时模式 JSON 数据库相同的灵活性（参见“文档模型中的模式灵活性”），同时还能为数据提供更强的保证和更好的工具。

数据流的模式

本章开头曾经说过，每当你想把数据发送给不共享内存的另一个进程——例如通过网络发送数据，或者将数据写入文件——都需要先把它编码成字节序列。随后，我们讨论了完成这项工作所用的各种编码。

我们还讨论了向前兼容与向后兼容。两者对可演化性都很重要：它们允许独立升级系统的不同部分，不必一次改动所有内容，从而让变更更容易。兼容性描述的是编码数据的进程与解码数据的进程之间的关系。

这个概念相当抽象，因为数据可以通过许多方式从一个进程流向另一个进程。究竟由谁编码，又由谁解码？本章余下部分将探讨几种最常见的进程间数据流：

• 通过数据库（参见“流经数据库的数据流”）
• 通过服务调用（参见“流经服务的数据流：REST 与 RPC”）
• 通过工作流引擎（参见“持久化执行与工作流”）
• 通过异步消息（参见“事件驱动的架构”）

流经数据库的数据流

在数据库中，写入数据库的进程负责编码数据，读取数据库的进程负责解码。也许始终只有一个进程访问数据库，此时读取者只不过是同一进程的后续版本——可以把向数据库存入数据看作 给未来的自己发送消息。

显然，这里必须保持向后兼容，否则未来的你就无法解码过去写下的数据。

一般来说，多个不同进程同时访问数据库很常见。这些进程可能属于不同的应用程序或服务，也可能只是同一服务的多个实例，为可伸缩性或容错而并行运行。无论哪种情况，只要应用程序还在变化，访问数据库的进程就很可能有些运行新版代码，有些仍在运行旧版代码。例如，滚动升级期间，一部分实例已经更新，其他实例还没有。

这意味着，数据库中的某个值可能由 较新 版本的代码写入，随后却被仍在运行的 较旧 版本读取。因此，数据库通常也需要向前兼容。

不同时间写入的不同值

数据库通常允许随时更新任何值。因此，同一个数据库里可能既有五毫秒前写入的值，也有五年前写入的值。

部署新版应用程序时——至少对服务端应用程序而言——可能只需几分钟就能用新版本完全替换旧版本。但数据库内容不是这样：除非显式重写，五年前的数据仍会以最初的编码留在那里。这种现象有时概括为：数据比代码更长寿。

当然，可以把数据重写（即 迁移）到新模式，但对大型数据集来说代价高昂，所以大多数数据库都会尽量避免。大多数关系数据库允许某些简单的模式变更，例如增加一个默认值为 null 的新列，而不必重写已有数据。读取旧行时，如果磁盘上的编码数据缺少某一列，数据库便为它填入 null。

因此，模式演化让整个数据库看上去仿佛都用同一个模式编码，尽管底层存储中可能混有按各个历史版本模式编码的记录。

更复杂的模式变更——例如把单值属性改成多值属性，或者把一部分数据移到另一张表中——仍然需要重写数据，而且通常要在应用程序层完成 ²⁷。如何在这类迁移中保持向前和向后兼容，至今仍是一个研究问题 ²⁸。

归档存储

也许你会不时为数据库制作快照，用于备份或者加载到数据仓库中（参见“数据仓库”）。这时，即使源数据库的原始编码混合了不同时期的多个模式版本，数据转储通常也会统一使用最新模式编码。反正数据总要复制一遍，不妨让副本采用一致的编码。

数据转储一次写成，此后不再修改，因此 Avro 对象容器文件之类的格式很适合。这里也是把数据编码成适合分析的列式格式（例如 Parquet）的好机会（参见“列压缩”）。

在 第 11 章 中，我们会进一步讨论归档存储中数据的用途。

流经服务的数据流：REST 与 RPC

当多个进程需要通过网络通信时，可以采用几种不同的组织方式。最常见的方式包含两个角色：客户端（client）和 服务器（server）。服务器通过网络公开 API，客户端连接服务器并向 API 发出请求。服务器公开的这个 API 称为 服务（service）。

Web 正是这样工作的：客户端（Web 浏览器）向 Web 服务器发出请求，用 GET 请求下载 HTML、CSS、JavaScript、图片等内容，用 POST 请求向服务器提交数据。这个 API 由一套标准化的协议和数据格式组成，包括 HTTP、URL、SSL/TLS、HTML 等。因为 Web 浏览器、Web 服务器和网站作者基本都遵循这些标准，所以理论上可以用任何 Web 浏览器访问任何网站。

Web 浏览器并不是唯一的客户端。例如，运行在移动设备或桌面计算机上的原生应用程序经常与服务器通信，浏览器中的客户端 JavaScript 应用程序也可以发出 HTTP 请求。这种情况下，服务器返回的通常不是供人阅读的 HTML，而是便于客户端代码进一步处理的编码数据，最常见的是 JSON。HTTP 虽然可以作为传输协议，但构建在它之上的 API 仍然由应用程序自行定义，客户端与服务器必须就 API 的细节达成一致。

在某些方面，服务很像数据库：它们通常允许客户端提交和查询数据。不过，数据库允许使用 第 3 章 讨论过的查询语言发起任意查询，服务公开的却是应用程序专用 API，只接受服务业务逻辑（应用程序代码）预先规定的输入，也只产生预先规定的输出 ²⁹。这种限制带来了一定程度的封装：服务可以细粒度地约束客户端能做什么、不能做什么。

面向服务架构或微服务架构的一项关键设计目标，是让服务可以独立部署和演化，从而使应用程序更容易修改和维护。一条常见原则是：每项服务由一个团队负责，这个团队应当能够频繁发布服务的新版本，而不必与其他团队协调。因此，服务器和客户端的新旧版本同时运行是意料之中的，双方使用的数据编码必须跨服务 API 版本保持兼容。

Web 服务

如果以 HTTP 作为与服务通信的底层协议，就称为 Web 服务（Web service）。Web 服务常用于构建面向服务或微服务架构（前文“微服务与无服务器”已经讨论过）。不过，“Web 服务”这个名字并不十分贴切，因为它不只用于 Web，还出现在其他几种场景中。例如：

1. 运行在用户设备上的客户端应用程序（例如移动设备上的原生应用，或者浏览器中的 JavaScript Web 应用）通过 HTTP 请求服务。这些请求通常经由公共互联网传输。
2. 作为面向服务或微服务架构的一部分，一项服务请求同一组织拥有的另一项服务；两者通常位于同一个数据中心。
3. 一项服务请求另一组织拥有的服务，通常经由互联网完成。这种方式用于不同组织的后端系统交换数据，包括在线服务提供的公共 API，例如信用卡支付系统，以及用来共享访问用户数据的 OAuth。

最流行的服务设计理念是 REST，它建立在 HTTP 的原则之上 ^{30 31}。REST 强调简单的数据格式，以 URL 标识资源，并利用 HTTP 的功能进行缓存控制、身份认证和内容类型协商。遵循 REST 原则设计的 API 称为 RESTful API。

调用 Web 服务 API 的代码必须知道应该请求哪个 HTTP 端点、应发送什么格式的数据，以及预期得到什么响应。即使服务遵循 RESTful 设计原则，客户端也得通过某种途径获知这些细节。服务开发者通常使用接口定义语言（IDL）来定义并记录 API 端点和数据模型，随后再逐步演化它们。其他开发者可以根据服务定义判断如何发起请求。最流行的两种服务 IDL 是 OpenAPI（也称为 Swagger ³²）和 gRPC。OpenAPI 用于收发 JSON 数据的 Web 服务，而 gRPC 服务收发 Protocol Buffers 数据。

开发者通常用 JSON 或 YAML 编写 OpenAPI 服务定义，参见 示例 5-3。服务定义可以描述端点、文档、版本、数据模型等许多内容。gRPC 的定义看起来与此相似，但采用 Protocol Buffers 的服务定义语法。

openapi: 3.0.0
info:
  title: Ping, Pong
  version: 1.0.0
servers:
  - url: http://localhost:8080
paths:
  /ping:
    get:
      summary: Given a ping, returns a pong message
      responses:
        '200':
          description: A pong
          content:
            application/json:
              schema:
                type: object
                properties:
                  message:
                    type: string
                    example: Pong!