这是Pat Helland 的论文：Pat Helland 的 CIDR22 论文，Pat的论文总是非凡的、与众不同的。他们有很多智慧。
问题和范围
抖动是指最大延迟与最小延迟的时间差，如最大延迟是20毫秒，最小延迟为5毫秒，那么网络抖动就是15毫秒，它主要标识一个网络的稳定性。
Jittery抖动指的是网络中的概率响应时间、消息延迟。在大数据处理系统中，很容易通过重试等零碎方式来解决抖动问题，事实上这在MapReduce的论文中已经提出。
但同样的方法并不适用于数据库，我们无法实现同样的幂等性要求，数据库本质应该是事务性的。
这篇论文提出了一个假设性的设计（意味着这并没有实现）。该设计探讨了在运行于云数据中心的数据库系统中抑制应用程序可见抖动的技术，在该数据中心中，大多数服务器都是响应式的。本文的目标不是定义一个超级可扩展的SQL系统，而是在一个基本不可预测的环境中运行时，以可预测的响应时间扩展到几十台服务器。
该设计将问题进一步限制为使用快照隔离的事务。只要没有冲突的更新，并且每个事务只看到快照读取，快照隔离的事务就可以对数据库做独立的修改。那么问题就来了，这两件事能不能在不耽误抖动的服务器的情况下完成？
在分布式系统中，quorums仲裁已经提供了答案。如果除了最近的数据外，所有的数据都保存在云端的共享存储中，并且我们可以在没有抖动的情况下读取这些数据（多亏了quorums），而这已经解决了快照隔离的无抖动快照读取方面的问题。
解决方案 
在此架构中，五种不同类型的服务器执行不同的工作。（这对我来说太过分了，我将在介绍这些之后讨论这个问题。）工作是通过生成新的记录版本和读取正确的记录版本来进行快照读取的。
- 工作服务器WorkerServer是数据库服务器。SQL 请求中的传入 DB 连接馈送。执行、读取和更新发生在工作服务器中。工作Worker在共享存储中记录自己的日志。
- 协调器服务器Coordinator有助于避免在事务提交时发生冲突更新，并帮助定位快照读取的最新更改。
- 数据存储服务器Shared Data Storage保存带有数据库数据的数据文件的副本。
- 日志存储服务器Shared Log Storage保存用于附加到日志的日志副本。
- Storage Catalog随着数据的老化，它会迁移到共享存储中的键值存储，该存储是作为 LSM（日志结构化合并系统）实现的。目录将键范围映射到存储的数据及其在共享存储中的位置。目录服务器跟踪工作人员worker、日志存储和数据存储的元数据。他们管理工作人员worker的日志范围和副本。
在这种分离的事务数据库架构中，每个记录更新都会创建一个新的记录版本，该记录版本位于较早的记录版本之上，并且对具有较晚快照时间的事务可见。早于几分钟左右的记录版本位于共享存储中，并且对数据库中的所有数据库服务器可见。在执行创建它们的事务的工作人员中可以找到最近的记录版本。快照读取语义是通过读取在读取器快照时间之前提交的最新记录版本来提供的。
在每笔事务开始时从协调员那里获得最近更新的行踪。每个行踪条目都描述了工作服务器最近可能进行的更新。协调员提供指导以在工作服务器中定位最近的记录版本。
表是通过连接表的 Table-ID 为每行创建具有唯一主键的记录版本来实现的，并且 SQL 定义的唯一主键包括一组有序的表列。描述了为快照查找记录版本，但我无法清楚地了解这是如何工作的，因为第 2.3 节到第 2.7 节并不容易理解。
该论文确定了该架构中的许多抖动风险。
- 风险 #1：worker到协调员
- 风险#2：worker追加到他们的日志
- 风险#3：worker阅读数据文件
- 风险#4：worker到Catalog
- 风险 #5：向其他worker询问最近的记录版本
- 风险 #6：阅读慢的worker的日志以避开它。如果worker无法响应其最近的更新，我们会查看其日志。这也有我们必须避免的抖动风险。
解决方案？
仲裁每个组件的。
点击标题原文中有更新的图表。请注意，协调器、目录和日志存储子系统都是仲裁的。
关于架构的讨论
worker是水平扩展计算的好主意。协调者（coordinator quorum）是管理交易纠纷的好主意。
我不喜欢拥有单独的数据存储服务器、日志存储服务器和目录服务器？
最近数据与旧数据的双重性质使设计不必要地复杂化。最近的数据是在worker中，worker从协调员那里learn，并在需要时与其他worker交谈以获得这些数据？这种worker对worker的通信是瓶颈的来源，也是由于worker不可用而导致的大抖动风险。（本文试图解决这个问题，但我不相信这些论点，并将在最后讨论原因。）
为什么不直接使用作为分布式键值存储实现的learn服务器，我们可以对它进行分区（通过分布式哈希表）以进行水平扩展。这将显着简化架构。只需放置一个持久的分布式日志。（Delos 工作只是一个例子。请注意，它也是通过 loglet 级别的 quorums 实现的。）
日志方法的另一个优点是它在阅读方面更具可扩展性。法定人数读取不会扩展。从节点的多数（如果您将仲裁定义为大多数工作中的多数）读取节点会保持每个节点上的负载。
您可以通过将分片划分得更小来克服这个限制，但这也很麻烦并且有成本。
相反，日志方法在这里有所帮助，您可以从一个节点读取并更好地扩展读取,许多系统使用这种方法。
.....