VOLTDB如何做到锁 定和读取一致性的？

1 .技术论文 VOLTDB如何做到锁 定和读取一致性的？ 

2 .背景介绍 传统的 RDBMS 系统在三件事上值得注意： 1. 锁定：即锁定记录的功能，以便其他人无法更改它们。 2. 阅读一致性：您（仅您自己）可以看到您所做的更改，直到您进行提交为止， 这时其他所有人才可以看到它们。 3. 遗憾的是其较差的可伸缩性：在线事务处理（OLTP）工作负载无法很好地扩 展。 在现实情况下，将CPU内核数量加倍不会使您的容量翻倍。 这种失败导致许多人尝试使用NoSQL解决方案，但是随着时间的流逝， 越来越明显的是，如果没有这些解决方案，锁定和读取一致性将很难实现。 • VOLTDB是唯一的数据平台，可让企业按比例进行锁定和读取一致性。 • 本文解释了为什么很难做到这一点，以及我们是如何做到这一点的。 2 HOW VOLTDB DOES LOCKING AND READ CONSISTENCY 

3 .为什么缩放OLTP很难 为了解释为什么很难扩展OLTP，让我们看一下简单的白板 交易的典型生命周期： 1. 在表格“ a”中插入一行 4. 做外部活动 2. 更新表“ b”中的行 5. 更新表“ a”中的行 3. 更新表“ c”中的行 6. 犯罪 乍一看，可能很难看出这是如何扩展的。 但是，让我们看一下使用旧 版RDBMS的实际实现： 3 HOW VOLTDB DOES LOCKING AND READ CONSISTENCY 

4 . 在此图中，几件事变得显而易见： 1.此操作不会立即完成 您需要12次网络旅行，每次旅行都需要花费可观的时间。 在任意一段 时间内，“现实世界的设备”都会关闭，并会做任何需要做的事情。 简而言之： 即使一切工作正常，此事务的耗时也将是几毫秒。 2.长时间运行的数据交换将是数据库服务器的挑战 每次更改数据库服务器中的内容时，您都需要做更多工作，因为所有其 他正在进行的数据交换都需要查看表的“旧”版本，直到提交为止。 出于实际目的的考量，每个不完整的交易都需要自己的数据库版本，该 数据库由现有数据及其未提交的更改组成。这意味着，如果您每秒运行一千笔交 易，并且每笔交易的端到端需要 10 毫秒（即每次网络行程少于 1 毫秒），则随 时将至少有 100 种不同版本的数据库存在，并且必须仔细检查任何新交易，以确 保它不会与其他人的更改冲突。 无论您使用SELECT FOR UPDATE，MVCC还是任何其他机制，此开销仍然 存在。 3.当您增加CPU芯数时，递减收益法则就会生效 随着工作量的增加，常规解决方法是添加更多的CPU内核并将工作分 散在它们之间。 虽然这在短期内会有所帮助，但它会带来另一个问题：当您只有一 个CPU内核时，可以肯定的是，当尝试处理会话请求时，数据库的其他100个 实时版本不会改变。这正是我们正在做的。 但是，添加第二个CPU内核后，数据库需要协调它们的活动。这引入 了一个全新的层的开销，每当您在“帮助”中添加另一个CPU内核时，问题就 会以几何级的速度变得更糟。 最终的结果是形成了一个恶性循环，在其中添加CPU内核以提高TPS， 但是每个新内核都需要关联消耗所有其他核心，最终将消耗您通过添加额外 核心获得的CPU容量。 如果额外的CPU容量来自群集中的另一个节点，那么事情将会出错。 因CPU内核之间相互争论的问题现在变成了到另一个数据库节点的网络访问。 4 HOW VOLTDB DOES LOCKING AND READ CONSISTENCY 

5 .4.随着容量的增加，性能变得越来越不稳定 实际经验告诉我们，即使您在各方面都做到最佳，您仍然会在实际环境 中遇到锁定问题，因为实际数据使用模式可能与测试场景大不相同。 一个典型的例子是网站访问者在添加购物车或购物篮并按下“重新加载” 时会不耐烦，这可能会导致以下情况：旧请求已锁定记录，而新请求则通知用户 “其他人”已锁定它。物联网（IoT）和电信应用程序尤其容易出现这种情况，因 为许多API的默认行为是在未收到即时响应时自动重试。 这可能会导致完全违背直觉的情况，即减少请求数量将大大增加成功完 成的交易数量，因为交易妨碍对方的机会较少。现实生活中发生的是，任何阻止 其他更多交易完成的单个交易都可能导致活动量激增，尤其是当应用程序开始盲 目重试时。 5.应用服务器或微服务器成为系统中的薄弱环节 市场上几乎每台数据库服务器都具有某种形式的高可用性，但是应用程 序服务器和微服务器通常被视为“无状态”，因为数据库服务器负责管理状态。 但是，如果您所有的客户都被路由到单个组件，并且该组件有大约100笔未完成的 交易，那么如果死机了该怎么办？ 数据库服务器从已连接的会话的角度看待世界，其中一些会话已锁定。 在已结束组件的会话持有数百个行级锁的世界中，您可以期望数据库服务器在几 分钟内遵守该锁定，直到最终弄清该组件已结束并关闭所涉及的会话，释放他们 的锁定状态。 这意味着，即使您已经准备好另一个应用服务器或容器立即承担其已结 束前任的工作量，否则它将无法对锁定了几分钟的任何记录进行任何更改，这意 味着“有效”多组数据将冻结几分钟，在此期间它将无法进行修改。 6.没有任何明显的方法可以解决此问题 尝试扩展OLTP的最简单方法是切换到NoSQL存储，该存储要求客户端在 进行更改之前发送证明已读取特定版本的记录的证据。 这将为您带来更快的性能-直到人们开始争用数据为止。最常见的实现 是将值 5 HOW VOLTDB DOES LOCKING AND READ CONSISTENCY 

6 .的哈希值与值本身一起发送回客户端。然后，将该哈希作为一种密码通过网络发 送，以证明该更改是对先前状态的合法修改。如果哈希错误，则意味着其他人同 时更改了该值，您需要重新开始。 这是一个不能令人满意的解决方案，因为当多个人开始同时更改同一条 记录时，它会导致与传统系统相同的负载下不稳定的性能。这也意味着，在上述 情况下，您可能需要操纵两个或什至三个键值对。实际上，您要做的就是将事务 复杂性降低到客户端层。 显然，您需要另一种解决方案。 VOLTDB是如何做到这一点的？ VoltDB的创建者，包括图灵奖获得者Michael Stonebraker，都考虑到了这一特定问题，开发了VoltDB数据平 台，并有效地解决了该问题。 VoltDB数据平台在做三件事上有不同之处： 1.IT分区将工作负载分配给每个分区，而这是控制CPU核心的单一物理线程的专有 责任 是的-许多现代数据平台都在划分工作负载。 但是，我们仅需将分区与 在单个CPU内核上运行的单线程对齐即可，这意味着该内核无需担心另一个内核在 做什么，因此，VoltDB立即消除了上述几何可伸缩性问题。 2.它允许任意数量的SQL语句和每个TRIP的逻辑关联到VOLTDB 尽管您可以愉快地将JDBC与VoltDB一起使用，但是当您将尝试将事例名 称和您使用的参数传递到 VoltDB 上的服务器侧逻辑时，您可以减少网络访问次 数和VoltDB必须跟踪的中间状态数量。 3.它表明每次访问都以提交结束 这似乎有些剧烈，但对性能有重大影响。 在任何时候，VoltDB分区都仅仅处理一个事务，因为它只有单个线程 “拥有”其中的所有数据。 通过坚持所有事务都是“提交”或“返回”状态， VoltDB不必从客户的角度跟踪存储状态数据库的任何额外“副本”。因此，在上 面的实例中， 6 HOW VOLTDB DOES LOCKING AND READ CONSISTENCY 

7 . VoltDB实现无需跟踪数据库的100个版本， 每个分区仅使用一个活动副本。 综上，这些更改既为您提供了传统RDBMS的功能，并且具有出色的可伸缩性，其性 能是同一个硬件的大约9倍。 现在，让我们看一下同一笔交易在VoltDB中是如何进展的。 Real-World Device 这可以通过两次调用VoltDB来完成。 第一次调用执行前三个更改，并 将会话ID /到期日期添加到另外两个软锁列中。 这允许其他交互查看正在进行的 交易，并自行决定要做什么。 当外部任务完成时，第二个调用触发，并清除软锁 列。 METHOD NETWORK TRIPS CLIENT API CALLS CAN SURVIVE L O S S CAN SURVIVE LOSS O F DB NODE O F APP SERVER NODE JDBC 12 5 Yes No VoltDB 6 2 Yes Yes 7 HOW VOLTDB DOES LOCKING AND READ CONSISTENCY 

8 .让我们比较两种方法的统计信息： 如您所见，VoltDB的真实事务是通过更少的网络行程，更少的客户端 API调用以及通过避免应用服务器节点丢失的明确方法来完成的。 但这并不意味 着没有其他可考虑的情况。 让我们看看有关VoltDB如何进行锁定和读取一致性的 常见问题。 Q&A 如果数据库服务器出故障了怎么办？ 我们在序列图中未显示的是，分区每次收到请求时，都 会立即同步将该请求转发到位于另一台物理服务器上的一个或多个 “备份”分区。然后，所有分区将同时开始处理同一任务。这意味 着，如果一个节点死亡，则在群集中的其他节点上会存在该分区的 可行且最新副本，数据库将以最小的时间损失和机上交易损失，重 新启动。 如果应用程序服务器出现故障，该怎么办？ 只要客户可以使用正确的锁标识符找我们，我们的处理将照常进行。在 传统的RDBMS中，当涉及到锁定时，状态将有效地保留在客户端和服务器上，因为 服务器已使用客户端会话唯一的标识符标记行。 但是，如果客户端销户，则该会话将无效。这意味着您需要等待服务器 将数据库连接标识为过去状态并结束它，然后其他人才能修改该记录。 在VoltDB的系统里，我们通过允许多个SQL语句和关联的逻辑在服务器 上运行，来“设计”大多数应用场景。如果逻辑交易在关联的交易事件完成之前 依然无法完成，您可以使用简单的 SQL 自行锁定逻辑，从而重新控制情况并满足 您的 SLAs 。 VoltDB是否会自动执行此操作？ 不会，但是它在数据库表中多了两列，并增加了大约十二行代码。与处 理传统 RDBMS 或 NoSQL 交易和锁定行为所需的开发人员时间相比，这是完全合 理的。 8 HOW VOLTDB DOES LOCKING AND READ CONSISTENCY 

9 .我们仍然可以使用JDBC吗？ 是的，我们的许多应用程序代码是基于JDBC的。在大多数应用程序中， 20% 的开发人员时间用于编写 80% 的 SQL，这些 SQL 是友好的或直接的。其他 20% 涉及复杂的交易，正是这种方法使其变得非常有价值。 “每个内核一个分区一个线程”为何比共享工作负载的多线程和多内核更快？ 乍一看，似乎任何核心能够处理任何问题看起来是最佳选择。但是，正 如我们上面讨论的那样，随着您线性地添加多个内核，协调多个内核活动所需的 努力会以几何方式升级。而将事务强制进入虚拟队列并让每个队列进行单个线程。 这个过程要高效得多。 结论 锁定和读取一致性是当今世纪的两个重要领域，RDBMS和较新的NoSQL系 统都无法满足其需求，提供合理答。 在VoltDB，我们的使命是专注于可预测的、 符合严苛标准的大规模交易。虽然我们理解我们的一些设计决策可能看起来非常 规，但这些决策却是由多年的实际经验决定的。 如果您还有其他疑问，或者想了解更多有关VoltDB如何在保持低延迟的 情况下支持现代应用程序的信息，请联系我们洽谈吧！ ABOUT VoltDB VoltDB支持强ACID和实时智能决策的应用程序，以实现互联世界。没有其它数据库产品可以像VoltDB这样，可以同时需要低延时、大规模、高并发数 和准确性相结合的应用程序加油。 VoltDB由2014年图灵奖获得者Mike Stonebraker博士创建，他对关系数据库进行了重新设计，以应对当今不断增长的实时操作和机器学习挑战。 Stonebraker博士对数据库技术研究已有40多年，在快速数据，流数据和内存数据库方面带来了众多创新理念。 在VoltDB的研发过程中，他意识到了利用内存事务数据库技术挖掘流数据的全部潜力，不但可以满足处理数据的延迟和并发需求，还能提供实时分析 和决策。VoltDB是业界可信赖的名称，在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。 1 April 2021 © VoltDB, Inc. 209 Burlington Road, Suite 203, Bedford, MA 01730 • VOLTDB.COM 9 HOW VOLTDB DOES LOCKING AND READ CONSISTENCY