数据库系列读物，第五版
Peter Bailis, Joseph M. Hellerstein, Michael Stonebraker, editors
[TOC]
前言
自上一版《Readings in database system》以来的十年中，数据管理领域出现了爆炸式增长。今天的数据库和数据密集型系统运行在前所未有的数据量上，这在很大程度上是由于大数据的兴起以及存储和计算成本的大幅下降。云计算和微服务的发展使得分布式和平行计算无处不在。数据是从越来越多的异构数据源中收集的，数量越来越多，并用于越来越多的任务。因此，商业数据库系统已经在多个维度上有了巨大的发展，从使用新的存储介质和处理器设计，到查询处理架构、编程接口、事务处理和分析需求同时满足的应用数据库系统设计。这个时代令人激动，市场上出现了很大的波动和新的研究成果和思想。
在这样一个快速变化的时代，我们对传统的《Red Book》进行更新，旨在提供数据库领域核心概念的基础，同时也对一些发展趋势进行分析。一些新技术和过去几十年的研究都非常相似，我们认为读者了解历史根源十分重要。同时，技术的发展趋势要求对数据库系统的几乎所有维度进行重新评估，许多经典的设计需要修改。我们整理这个论文集合的目标是在强调长期学习和基础设计的同时，重点指出最新颖和重要的观点。
因此，我们选择了早期数据库文献中的经典、传统论文以及在最近的发展中最具影响力的论文，包括事务处理、查询处理、高级分析、Web 数据和语言设计。 在每一章中，我们都包含了一个简短的评论，介绍了这些论文并描述了我们选择每一篇论文的原因。 每条评论均由其中一位编辑撰写，但所有编辑都提供了意见； 我们希望评论中不要缺乏自己的想法。
在选择阅读材料时，我们会寻找符合我们标准的主题和论文。首先，每个选择的材料都代表了数据管理的一个主要发展趋势，研究兴趣和市场需求都证明了这一点。 其次，每个选择的材料都是规范的或接近规范的； 我们为每个主题寻找最具代表性的论文。 第三，每个选择的材料都是主要来源。 对本集中的许多主题都有很好的调查，我们在评论中引用了这些调查。 然而，阅读原始资料提供了历史背景，让读者接触到形成有影响力的解决方案的思想，并有助于确保我们的读者在该领域有良好的基础。 最后，这个系列代表了我们目前对“最重要”的品味； 我们希望我们的读者以批判的眼光看待这个集合。
和Red Book上一个版本最大的不同是我们对于最后两节管理分析和数据集成的方式。很明显，这是目前无论学术还是市场面临的最大的数据管理问题。同时他们也在研究和实践中快速进化。由于这种快速变化，我们很难在这些主题上对权威论文达成一致。在这种情况下，我们决定忽略官方材料而提供注解。这样自然会对这个领域所发生的事情有一个更高的视野。所以我们不建议这些章节为Red Book 传统中的“必读”章节。反之，我们作为可选项来对待：片面分析。建议读者对这两部分酌情阅读和采纳（比如本书的其他部分更慎重）。
我们将免费发布此版本的红皮书，并在我们的文本上获得许可，允许以多种格式进行无限制的非商业再分发。 我们没有保护推荐论文的权利，只是提供了 Google Scholar 搜索的链接，可以帮助读者找到相关论文。 我们希望这种电子格式允许更频繁地版本“书”。 我们计划酌情改进该系列。
最后一点：这个系列自 1988 年以来一直存在，我们预计它会有很长的未来。 相应地，我们为编辑们添加了一点“年轻的血液”。 在适当的情况下，这个读物的编辑可能会随着时间的推移而进一步发展。
Peter Bailis
Joseph M. Hellerstein
Michael Stonebraker
第一章 背景
作者：Michael Stonebraker
论文:
我很惊讶这两篇论文仅仅写于十年前！在剖析论文的过程中，我又感到很惊讶，因为许多细节在论文发布的仅仅几年之后就发生了很大的变化。对数据模型的惊讶是好像没有人从历史上学到东西。让我们先来讨论数据模型论文。
十年前，流行的全是 XML。 供应商打算将 XML 添加到他们的关系引擎中。 行业分析师（以及不少研究人员）将 XML 吹捧为“下一件大事”。 十年后，它成为了一个不错的产品，而且这个领域也在向前发展。 在我看来，（如论文中预测的那样）它屈服于以下因素的组合：
- 过于复杂（没人能理解）
- 关系引擎的复杂扩展，它似乎并没有那么好，
- 没有被广泛接受的令人信服的用例
有点讽刺的是，论文的作者预测将会有人因为成功简化 XML而 获得图灵奖。 结果证明这个预测完全错误！事实是关系赢了，XML 输了。
当然，这并没有阻止“新手”重新发明轮子。 现在是 JSON，可以从下面三个方面来看：
- 一种通用的分层数据格式。任何认为这是个好主意的人都应该阅读有关 IMS 的数据模型论文部分。
- 稀疏数据的表示。比如有关员工的属性，并假设我们希望记录员工爱好的数据。对于每个爱好，我们记录的数据都会不同，而且爱好从根本上是稀疏的。这在关系 DBMS 中很容易建模，但它会导致非常宽、非常稀疏的表。这对于基于磁盘的行存储来说是灾难性的，但在列存储中工作正常。在前一种情况下，JSON 是“爱好”列的合理编码格式，并且几个 RDBMS（关系数据库管理系统;）最近添加了对 JSON 数据类型的支持。
- 作为“读取模式”的机制。实际上，该模式非常广泛且非常稀疏，基本上所有用户都希望对该模式进行一些投影。当从广泛的、稀疏的模式中读取时，用户可以说出他想在运行时看到的内容。从概念上讲，这只不过是一个投影操作。因此，“读取模式”只是对 JSON 编码数据的关系操作。
毫无疑问，下一个版本的红皮书将抛弃那些站在前辈脚尖而不是肩膀上的人发明的一些新的等级制度。
另一个在过去十年引起广泛关注的数据模型是 MapReduce，它是由谷歌专门构建的，用于支持他们的网络爬虫数据库。 几年后，Google 停止在该应用程序中使用 MapReduce，转而使用 Big Table。 现在，世界其他地方正在看到谷歌早先发现的东西； MapReduce 不是一种具有任何广泛适用性的架构。 相反，MapReduce 市场已经演变成 HDFS 市场，并且似乎准备成为关系 SQL 市场。 例如，Cloudera 最近推出了 Impala，它是一个 SQL 引擎，构建在 HDFS 之上，不使用 MapReduce。
最近，HDFS 领域出现了另一个值得讨论的重点，即“数据湖”。 HDFS 集群（目前大多数企业已经投资并希望找到对他们有用的东西）的合理使用是作为已摄取的数据文件队列。 随着时间的推移，企业将找出哪些值得花精力清理（数据管理；本书第 12 章介绍）。 因此，数据湖同时只是文件的“垃圾抽屉”。 此外，我们将在第 5 章中更多地介绍 HDFS、Spark 和 Hadoop。
总之，在过去的十年里，似乎没有人注意到“comes around（轮回）”的教训。 新的数据库模型创造出来，仅变成了表上面的SQL。和预言一样，层次结构被再次创造，并以失败告终。在未来的十年里看到这样更多的情况，我并不会感到奇怪。人们似乎热衷于重复造轮子。
总体来说：仅仅十年后，我们就可以注意到 DBMS 的构建方式发生了重大变化。 因此，细节发生了很大变化，但论文中描述的整体架构仍然非常真实。 该论文描述了大多数遗留 DBMS（例如 Oracle、DB2）的工作方式，十年前，这是普遍的实现。 现在，这些系统是历史文物； 什么都不擅长。 例如，在数据仓库市场中，列存储已经取代了本文所述的行存储，因为它们快了 1-2 个数量级。 在 OLTP 世界中，具有非常轻量级事务管理的主内存 SQL 引擎正在迅速成为常态。 这些新的发展记录在本书的第 4 章中。 现在很难找到传统行商店具有竞争力的应用领域。 因此，他们理应被送到“退休软件之家”。
很难想象“一刀切”将再次成为主导架构。 因此，“大象”有一个糟糕的“创新者困境”问题。 在 Clayton Christiansen 的经典著作中，他认为传统技术的供应商很难在不失去客户群的情况下转变为新结构。 然而，大象将如何尝试已经很明显了。 例如，SQLServer 14 至少是两个引擎（Hekaton - 一个主内存 OLTP 系统和传统的 SQLServer - 一个遗留的行存储）联合在一个公共解析器下。 因此，Microsoft 的策略显然是在其传统解析器下添加新引擎，然后支持将数据从疲惫的引擎移动到更现代的引擎，而不会干扰应用程序。 这将如何成功还有待观察。
然而，这些新系统的基本架构继续遵循论文中描述的解析器/优化器/执行器结构。 此外，线程模型和进程结构在今天与十年前一样重要。 因此，读者应该注意到并发控制、崩溃恢复、优化、数据结构和索引的细节处于快速变化的状态，但 DBMS 的基本架构保持不变。
此外，随着计算架构的发展，本文的各个方面可能会在未来变得更加相关。 例如，即将到来的 NVRAM 可能为新架构概念或旧架构概念的重新出现提供机会。
第二章 传统 RDBMS 系统
作者：Michael Stonebraker
论文：
Michael Stonebraker and Lawrence A. Rowe. The design of POSTGRES. SIGMOD, 1986.
本节是关于三个最重要的实际的 DBMS 系统的论文。 我们将在本介绍中按时间顺序讨论它们。
System R 项目是在 IBM Research 的 Frank King 的指导下开始的——大概是在 1972 年左右。那时 Ted Codd 的开创性论文(Codd提出了一个新的解决方案，于1970年发表了具有创新性的技术论文–”A Relational Model of Data for Large Shared Data Banks”（大型共享数据库的关系数据模型）。在论文中，Codd建议将数据独立于硬件来存储，程序员使用一个非过程语言来访问数据。)已经有 18 个月的历史了，很多人很明显应该构建一个原型来测试他的想法 . 不幸的是，Ted 没有被允许领导这项工作，他开始考虑 DBMS 的自然语言接口。 System R 很快决定实现 SQL，它从 1972 年的干净块结构语言 [2] 演变为本文 [1] 中描述的更复杂的结构。 有关 SQL 语言设计的评论，请参阅 [3]，该评论是在十年后编写的。
System R在架构上分为两层，底层和上层。当然也不是完全同步的，因为底层实现了上层并不支持的链接功能。作为底层团队的防守性决定，很明显他们在和有这个类型结构的IMS竞争，所以很自然要保护这个功能。上层也没有让优化器做这一块的工作。
事务管理器可能是该项目最大的遗产，显然是已故的 Jim Gray 的工作。 他的大部分设计至今仍在商业系统中使用。 第二名是 System R 优化器。 基于成本的动态规划方法仍然是优化器技术的黄金标准。
我对 System R 的最大抱怨是团队从未停止清理 SQL。 因此，当“上半部分”被简单地粘在 VSAM 上以形成 DB2 时，语言级别保持不变。 该语言所有烦人的特性一直持续到今天。 SQL 将成为 2020 年的 COBOL，这是一种我们坚持使用但每个人都会抱怨的语言。
我的第二大抱怨是 System R 使用子存储过程的调用接口（现在叫 ODBC）将客户端应用程序耦合到 DBMS。 我认为 ODBC 是地球上最糟糕的接口之一。 要发出单个查询，必须打开一个数据库，打开一个游标，将其绑定到一个查询，然后发出单独的数据记录提取。 仅仅运行一个查询就需要一页相当难以理解的代码。 Ingres [11] 和 Chris Date [4] 都有更清晰的语言嵌入。 此外，Pascal-R [9] 和 Rigel [7] 也是在编程语言中包含 DBMS 功能的优雅方式。 直到最近随着 Linq [6] 和 Ruby on Rails [8] 的出现，我们才看到更清晰的特定于语言的嵌入的复苏。
在 System R 之后，Jim Gray 去 Tandem 从事 Non-stop SQL 的工作，而 Kapali Eswaren 做了一个关系型初创公司。 团队的其余大部分人留在 IBM 并继续从事各种其他项目，包括 R*。
第二篇论文是关于 Postgres 的。 这个项目始于 1984 年，当时很明显，继续使用学术 Ingres 代码库进行原型设计毫无意义。 Postgres 的历史回顾出现在 [10] 中，读者被引导到那里对开发过程中的起起落落进行全面的回顾。
然而，在我看来，Postgres 的重要遗产是它的抽象数据类型 (ADT) 系统。 使用 Postgres 模型，用户定义的类型和函数已添加到大多数主流关系 DBMS 中。 因此，这种设计特征一直延续到今天。 该项目还尝试了时间旅行，但效果不佳。 我认为，随着更快的存储技术改变数据管理的经济性，无覆盖存储将大放异彩。
还应该指出的是，Postgres 的大部分重要性应该归功于强大且高性能的开源代码行的可用性。 这是最好的开源社区开发和维护模型的一个例子。 一个由志愿者组成的团队在 1990 年代中期采用了 Berkeley 的代码，并从那时起一直在指导其开发。 Postgres 和 4BSD Unix [5] 都有助于使开源代码成为代码开发的首选机制。
在1992，商业公司Illustra 开始支持Postgres的商业版本，之前一直由berkeley中持续进行。有关 Illustra 在市场上经历的起起落落的描述，请参见 [10]。
除了 ADT 系统和开源分发模型之外，Postgres 项目的一个关键遗产是一代训练有素的 DBMS 实施者，他们在构建其他几个商业系统方面发挥了重要作用
本节中的第三个系统是 Gamma，它于 1984 年至 1990 年在威斯康星州建立。在我看来，Gamma 将无共享分区表方法推广到多节点数据管理。 尽管 Teradata 也有相同的想法，但让这些概念普及的却是 Gamma。 此外，在 Gamma 之前，没有人谈论过hash-join，因此 Gamma 应该被认为（与 Kitsuregawa Masaru 一起）提出了这类算法。
基本上所有数据仓库系统都使用 Gamma 风格的架构。 任何使用共享磁盘或共享内存系统的想法几乎都消失了。 除非网络延迟和带宽能够与磁盘带宽相媲美，否则我预计当前的无共享架构将继续下去。
第三章 每个人都应该知道的技术
作者：Peter Bailis
论文：
在本章中，我们介绍了数据库系统设计中几个最重要的核心概念的主要和近主要来源：查询计划、并发控制、数据库恢复和分布。 本章中的思想对现代数据库系统非常重要，几乎每个成熟的数据库系统实现都包含它们。 本章中的三篇论文是各自主题的经典参考文献。 此外，与前一章相比，本章侧重于广泛适用的技术和算法，而不是整个系统。
查询优化
查询优化在关系数据库架构中很重要，因为它是启用独立于数据的查询处理的核心。 Selinger 等人关于 System R 的基础论文通过将问题分解为三个不同的子问题来实现实际的查询优化：成本估计、定义搜索空间的关系等价和基于成本的搜索。
优化器提供执行查询的每个组件的成本估计，以 I/O 和 CPU 成本衡量。 为此，优化器既依赖于关于每个关系内容的预先计算的统计信息（存储在系统目录中），也依赖于一组用于确定查询输出基数（大小）的启发式方法（例如，基于估计的 谓词选择性）。 作为练习，请详细考虑这些启发式方法：它们什么时候有意义，它们会在哪些输入上失败？ 如何改进？
使用这些成本估计，优化器使用动态编程的算法来构建查询计划。 优化器定义了一组实现给定逻辑运算符的物理运算符（例如，使用完整的“段”扫描与索引查找元组）。 使用这个集合，优化器迭代地构建一个左深算子树，反过来使用成本启发式来最小化运行算子所需的估计工作总量，考虑上游消费者所需的“有趣订单”。 这避免了必须考虑运算符的所有可能顺序，但计划大小仍然是指数级的； 正如我们在第 7 章所讨论的，现代查询优化器仍然在处理大型计划（例如，多路连接）。 此外，虽然 Selinger 采取了优化器提前执行编译的方案，但是其他早期系统，如 Ingres [25] 实际上是在逐个元组的基础上解释查询计划。
像几乎所有的查询优化器一样，Selinger等优化器实际上并不是“最优的”——不能保证优化器选择的计划是最快或最低成本的。 关系优化器在精神上更接近现代语言编译器中的代码优化例程（即将执行尽力而为搜索）而不是数学优化例程（即将找到最佳解决方案）。然而，当前很多关系引擎都采用了论文中的基础方法，包括二进制操作器和成本估算。
并发控制
第一篇关于事务的论文来自Gray等人，介绍了两个经典观点：多粒度锁和多种锁模式。事实上论文也可分为两块来阅读。
首先，本文提出了多粒度锁定的概念。 这里的问题很简单：给定一个层次结构的数据库，我们应该如何进行互斥？ 我们什么时候应该以粗粒度（例如，整个数据库）和更细粒度（例如，单个记录）锁定，我们如何同时支持对层次结构不同部分的并发访问？ 虽然 Gray 等人的分层布局（由数据库、区域、文件、索引和记录组成）与现代数据库系统的分层布局略有不同，但除了最基本的数据库锁定系统之外，今天的所有系统都采用了他们的建议。
其次，论文也开发出了多种隔离级别的概念。如Gray等人提醒我们，全局的并发控制是为了保证数据在满足一定的逻辑要求下的一致性。传统上，数据库使用串行事务来保证强一致：如果每个事务离开数据库的时候保持一致性，则一系列的操作（等同于一些事务的顺序执行）将确保所有的事务处于一个一致的数据库状态[5]。Gray 等人的“Degree 3”协议描述了经典的（严格的）“两阶段锁定”（2PL），它保证了可序列化的执行，是事务处理中的一个主要概念。
然而，强制序列化执行代价常常很高。为了提升性能，数据库系统使用非串行化隔离级别来执行事务。在论文中，维持锁代价是很昂贵的：出现冲突时的等待时间，也会出现死锁，或一直存在（或者导致错误）。于是，在1973，像IMS和system R等数据开始尝试非序列号规则。在一个基于锁的并发控制系统中，规则通过短暂的持有锁来实现。这样可以达到更好的并发，可能导致更少的死锁和系统主动放弃，另外在分布式配置中，可以实现更好的运行可用性。
在本文的后半部分，Gray 等人。 提供这些基于锁的策略行为的基本形式化。 今天，它们很普遍。 正如我们在第 6 章中讨论的那样，不可序列化隔离是大多数商业和开源 RDBMS 的默认设置，并且一些 RDBMS 根本不提供可序列化性。 2 级现在通常称为可重复读隔离，1 级现在称为已提交读隔离，而 0 级很少使用 [1]。 本文还讨论了可恢复性的重要概念：在不影响其他交易的情况下，可以中止（或“撤销”）交易的策略。 除 0 级事务外，所有事务都满足此属性。
Gray 等人在基于锁的可串行化方面的开创性工作之后，出现了广泛的替代并发控制机制。 随着硬件、应用程序需求和访问模式的变化，并发控制子系统也发生了变化。 然而，并发控制的一个特性仍然几乎可以肯定：并发控制中没有单边的“最佳”机制。 最佳策略取决于工作负载。 为了说明这一点，我们纳入了 Agrawal、Carey 和 Livny 的一项研究。 尽管已经过时，但本文的方法论和广泛的结论仍然符合目标。 这是经过深思熟虑的、与实施无关的性能分析工作的一个很好的例子，随着时间的推移可以提供宝贵的经验教训。
在方法论上，执行所谓”back of the envelope “计算能力是一个有价值的技能：对感兴趣的指标进行快速的估算，以正确值的数据量级内得到正确答案，可以节省数小时甚至数年的系统实现和性能分析。这也是数据库系统中一个长期和优良传统，从”Five Minute Rule“[12] 到谷歌的”Numbers Everyone Should Know“[4]。这些估算的出来的教训有一些是短暂的[8,10]，但是其结论却是长期的。
然而，在对像并发控制这样的复杂系统进行分析时，模拟是估算和全面的系统基准测试之间的一个重要的中间步骤。Agrawal 的研究是一个很好的例子：作者使用一个仔细设计的系统和用户模型来模拟锁，重启和乐观并发控制。
评价的几个方面特别有价值。首先，几乎每个图中都有一个“交叉”点：没有明显的赢家，因为性能最佳的机制取决于工作负载和系统配置。相比之下，几乎所有没有交叉点的性能研究都可能是无趣的。如果一个计划“总是成功”，那么研究应该包含分析分析，或者理想情况下，证明为什么会这样。其次，作者考虑了广泛的系统配置；他们调查和讨论了他们模型的几乎所有参数。第三，许多图表现出非单调性（即，并不总是向上和向右）；这是颠簸和资源限制的产物。正如作者所说明的，无限资源的假设会导致截然不同的结论。使这种假设隐含的较不谨慎的模型将不太有用。
最后，该研究的结论是合理的。 基于重启的方法的主要成本是在发生冲突时“浪费”的工作。 当资源充足时，投机是有道理的：浪费的工作成本更低，而且在资源无限的情况下，它是免费的。 但是，在资源更有限的情况下，阻塞策略将消耗更少的资源并提供更好的整体性能。 同样，没有单方面的最优选择。 然而，论文的结论已被证明是有先见之明的：计算资源仍然稀缺，事实上，当今很少有商品系统采用完全基于重启的方法。 然而，随着技术比率——磁盘、网络、CPU 速度——不断变化，重新审视这种权衡是很有价值的。
数据库恢复
事务处理中的另一个主要问题是保持持久性：事务处理的效果应该在系统故障后继续存在。 一种几乎无处不在的维护持久性的技术是执行日志记录：在事务执行期间，事务操作存储在日志中的容错介质（例如，硬盘驱动器或 SSD）中。 在数据系统中工作的每个人都应该了解预写日志的工作原理，最好是了解一些细节。
实现“No Force, Steal”基于 WAL 的恢复管理器的规范算法是 IBM 的 ARIES 算法，我们下一篇论文的主题。 （高级数据库研究人员可能会告诉你，非常相似的想法是在像 Tandem 和 Oracle 这样的地方同时发明的。）在 ARIES 中，数据库不需要在提交时将脏页写入磁盘（“无强制”），并且数据库可以随时将脏页刷新到磁盘（“窃取”）[15]；这些策略实现了高性能，并且几乎存在于每个商业 RDBMS 产品中，但反过来又增加了数据库的复杂性。 ARIES 的基本思想是分三个阶段执行崩溃恢复。首先，ARIES 通过重放日志转发来执行分析阶段，以确定崩溃时哪些事务正在进行中。其次，ARIES 通过（再次）重放日志和（这次）执行崩溃时正在进行的任何事务的影响来执行重做阶段。第三，ARIES 通过向后播放日志并撤消未提交事务的影响来执行撤消阶段。因此，ARIES 的核心思想是“重复历史”进行恢复；事实上，撤消阶段可以执行在正常操作期间用于中止事务的相同逻辑。
ARIES 应该是一篇相当简单的论文，但它可能是本系列中最复杂的论文。在研究生数据库课程中，这篇论文是一个成人礼。但是，该材料是基础材料，因此了解这一点很重要。幸运的是，Ramakrishnan 和 Gehrke 的本科教科书 [22] 和 Michael Franklin 的调查论文 [7] 都提供了温和的处理。我们在此处包含的完整 ARIES 论文因其对替代设计决策缺点的分散讨论而显着复杂化。在第一遍时，我们鼓励读者忽略这些材料而只关注 ARIES 方法。替代方案的缺点很重要，但应保留以供更仔细的第二次或第三次阅读。除了其组织之外，ARIES 协议的讨论因管理内部状态（如索引）（即嵌套顶部操作和逻辑撤消日志记录 - 后者也用于像 Escrow 交易 [21] 等奇异方案中）的讨论而进一步复杂化。技术来最大限度地减少恢复期间的停机时间。在实践中，恢复时间尽可能短很重要；这是很难实现的。
分布式
本章的最后一篇论文涉及分布式环境中的事务执行。 这个主题在今天尤其重要，因为越来越多的数据库是分布式的——要么是复制的，在不同的服务器上有多个数据副本，要么是分区的，数据项存储在不相交的服务器（或两者）上。 尽管提供了容量、持久性和可用性方面的好处，但分发引入了一系列新的问题。 服务器可能出现故障，网络链接可能不可靠。 在没有故障的情况下，网络通信的成本可能很高。
我们专注于分布式事务处理中的一项核心技术：原子承诺（AC）。非常非正式地，给定一个在多个服务器上执行的事务（无论是多个副本、多个分区还是两者），AC 确保事务在所有服务器上提交或中止。实现 AC 的经典算法可以追溯到 1970 年代中期，称为两阶段提交（2PC；不要与上面的 2PL 混淆！）[9, 18]。除了对 2PC 以及提交协议和 WAL 之间的交互进行很好的概述之外，本文还包含两个 AC 变体，以提高其性能。 Presumed Abort 变体允许进程避免强制对磁盘做出中止决定或确认中止，从而降低磁盘利用率和网络流量。 Presumed Commit 优化与此类似，在提交更多事务时优化空间和网络流量。注意 2PC 协议、本地存储和本地事务管理器之间交互的复杂性；细节很重要，正确实施这些协议可能具有挑战性。
失败的可能性大大增加了 AC（以及分布式计算中的大多数问题）的复杂性。 例如，在 2PC 中，如果协调器和参与者在所有参与者都发送了他们的投票之后但在协调器收到失败参与者的消息之前都失败了，会发生什么？ 其余的参与者将不知道是否提交或中止交易：失败的参与者是投了 YES 还是投了 NO？ 参与者不能安全地继续。 事实上，当在不可靠的网络上运行时，AC 的任何实现都可能会阻塞或无法取得进展 [2]。 再加上可序列化的并发控制机制，阻塞 AC 意味着吞吐量可能会停滞。 因此，一组相关的 AC 算法在关于网络（例如，通过假设同步网络）[24] 和服务器可用信息（例如，通过使用“故障检测器”）的宽松假设下检查了 AC 确定节点何时失败）[14]。
最后，许多读者可能熟悉与共识密切相关的问题，或者可能听说过 Paxos 算法等共识实现。在协商一致的情况下，可以选择任何提案，只要所有流程最终都同意。 （相比之下，在 AC 中，任何个人参与者都可以投票 NO，之后所有参与者都必须中止。）这使得共识成为比 AC [13] 更“容易”的问题，但是，与 AC 一样，任何共识的实现也可能在某些情况下被阻止场景 [6]。在现代分布式数据库中，共识通常被用作复制的基础，以确保副本以相同的顺序应用更新，这是状态机复制的一个实例（参见 Schneider 的教程 [23]）。 AC 通常用于执行跨越多个分区的事务。 Lamport [17] 的 Paxos 是最早的（也是最著名的，部分原因是其在复杂性上与 ARIES 相媲美）的共识实现之一。然而，Viewstamped Replication [19] 和 Raft [20]、ZAB [16] 和 Multi-Paxos [3] 算法在实践中可能更有帮助。这是因为这些算法实现了分布式日志抽象（而不是原始 Paxos 论文中的“共识对象”）。
不幸的是，数据库和分布式计算社区有些不同。 尽管对复制数据有共同的兴趣，但多年来两者之间的思想交流受到限制。 在云和互联网规模的数据管理时代，这一差距已经缩小。 例如，Gray 和 Lamport 在 2006 年合作开发了 Paxos Commit [11]，这是一种结合 AC 和 Lamport 的 Paxos 的有趣算法。 在这个交叉点还有很多事情要做，这个领域的“每个人都应该知道的技术”的数量已经增长。