Shirakami: A Hybrid Concurrency Control Protocol for Tsurugi Relational Database System

本文提出了一种名为 Shirakami 的混合并发控制协议，该协议专为 Tsurugi 关系数据库系统设计，通过结合基于多版本视图可串行化的长事务处理机制（Shirakami-LTX）和基于 Silo 的短事务处理机制（Shirakami-OCC），在无需动态切换协议的情况下实现了稳定的高性能，实验表明其延迟比 PostgreSQL 低 19.7 倍，且长事务吞吐量比短事务高出 680 倍。

要点

这篇论文介绍了一种名为**“白神”（Shirakami）**的新技术，它是为了解决现代数据库在处理“大杂烩”式工作负载时遇到的难题而设计的。

为了让你轻松理解，我们可以把数据库想象成一个繁忙的超级厨房，而数据库里的“事务”（Transaction）就是厨房里正在进行的“烹饪任务”。

1. 厨房里的难题：大锅炖 vs. 小炒肉

在这个厨房里，通常有两种截然不同的任务：

• 小炒肉（短事务）： 就像顾客点了一份“宫保鸡丁”。厨师（数据库）需要在几秒钟内快速切菜、下锅、装盘。这种任务要求快，而且经常发生。
• 大锅炖（长事务）： 就像餐厅老板需要计算整个月所有食材的成本，或者统计所有电话账单。这需要厨师把成千上万种食材（数据）都翻一遍，慢慢计算，最后写出一份厚厚的报告。这种任务很慢，但必须保证数据绝对准确。

以前的厨房（传统数据库）出了什么问题？
以前的厨房管理规则（并发控制协议）通常只擅长处理“小炒肉”。

• 如果老板开始做“大锅炖”，他需要占用很多锅和食材。
• 这时候，如果有顾客来点“小炒肉”，厨师可能会因为食材被老板占用了而排队等待，或者因为老板正在计算，小炒肉的数据看起来是“乱”的，导致小炒肉做废了（回滚/失败）。
• 反过来，如果小炒肉太多，老板的“大锅炖”可能永远没法开始，或者因为不断被打断而永远做不完。

这就导致了要么顾客等太久，要么老板的账永远算不清。

2. “白神”协议：聪明的双轨制厨房

这篇论文提出的“白神”协议，就像给厨房设计了一套智能的双轨管理系统，让“大锅炖”和“小炒肉”互不干扰，还能和平共处。

它把任务分成了两类，并给它们制定了不同的规则：

A. 针对“大锅炖”的规则（Shirakami-LTX）

• 核心策略：提前占位（Write Preservation）。
  想象老板开始做“大锅炖”前，会先在厨房门口贴一张纸条：“接下来我要用这 100 个锅和 500 斤肉，请大家暂时别动这些特定的食材。”
• 效果： 当顾客来点“小炒肉”时，厨师一看纸条，发现需要的食材被老板“预占”了，就会立刻知道：“哦，这块肉老板要用，我不能抢，我换个别的做，或者等老板做完再说。”
• 好处： 避免了“小炒肉”做到一半发现食材被抢了而被迫重做（失败），也避免了老板的“大锅炖”被无数个小任务打断。

B. 针对“小炒肉”的规则（Shirakami-OCC）

• 核心策略：乐观快速（基于 Silo 协议）。
  对于普通的“小炒肉”，厨师依然保持**“先做再说，最后检查”**的乐观态度。只要没人明确贴条说“这块肉被老板预占了”，厨师就大胆地切菜下锅。
• 好处： 保持了处理普通订单的极速，不会因为老板在算账就让整个厨房停摆。

C. 神奇的“时间胶囊”（Epoch-based Synchronization）

• 厨房被划分成一个个**“时间胶囊”（Epoch）**。
• 大锅炖的任务通常在一个时间胶囊开始时“入场”，并锁定未来的某些资源。
• 小炒肉的任务在时间胶囊结束时“结账”。
• 这种机制就像给任务排了队，确保老板的“大锅炖”永远排在前面，不会被插队，但也不会因为老板在算账而让所有小任务都停下来等。

3. 一个生动的比喻：高速公路与施工队

如果把数据库比作一条高速公路：

• 普通车辆（短事务）： 像日常通勤的小轿车，需要快速通过。
• 工程车（长事务）： 像正在铺设路面的大型工程队，需要占用很长的路段，速度很慢。

以前的做法：
工程车一上路，就封路。所有小轿车都得排队，或者因为路被占了而绕路（失败）。如果工程车很长，小轿车就堵死了。

“白神”的做法：

1. 工程车（LTX）： 在出发前，先发布“施工预告”（写保护），告诉后面的车：“我接下来要修 A 段和 B 段路。”
2. 小轿车（OCC）： 看到预告后，如果发现自己要走的路段正好被工程车占了，就立刻变道（选择其他数据或重试），而不是傻乎乎地冲上去撞车然后翻车。
3. 结果： 工程车可以安心修路，不用担心被小轿车撞；小轿车也能灵活变道，尽量不被堵死。

4. 实际效果有多好？

论文中的实验数据非常惊人：

• 速度对比： 在模拟“电话账单计算”（典型的长事务 + 短事务混合场景）时，使用“白神”系统的数据库（Tsurugi），比目前主流的 PostgreSQL 数据库快了 19.7 倍。
• 吞吐量对比： 专门处理“大锅炖”（长事务）的模式，比专门处理“小炒肉”（短事务）的模式，在混合场景下的效率高了680 倍。

总结

这篇论文的核心思想就是：不要试图用一套规则去管所有事。

通过**“白神”协议**，数据库学会了**“看人下菜碟”**：

• 对慢吞吞的大任务，给它特权和提前预警，防止被小任务打断。
• 对快节奏的小任务，保持灵活和快速，只要不冲突就让它飞。

这套系统让数据库既能处理复杂的后台计算（如账单、成本核算），又能保证前台用户的快速响应，就像一家既能做满汉全席，又能快速出餐的顶级餐厅。

技术摘要

Shirakami：Tsurugi 关系数据库系统的混合并发控制协议技术总结

1. 研究背景与问题 (Problem)

现代企业级应用（如物料清单 BoM 计算、电信计费系统）面临着一种新兴的混合工作负载挑战：需要同时处理短事务（Short Transactions，如在线订单更新）和长读写事务（Long Read-Write Transactions，如批量成本核算、计费聚合）。

现有的通用并发控制协议无法有效解决这一矛盾：

• 传统乐观并发控制 (OCC) 及其变体（如 Silo, ERMIA, TicToc）：基于冲突可串行化 (CSR) 或较窄的多版本空间。它们对短事务性能优异，但在处理长事务时，由于扫描大量数据导致冲突概率极高，极易发生频繁的中止 (Abort) 和重试，导致吞吐量急剧下降。
• 确定性协议：虽然能处理长事务，但要求预先知道事务的所有读写集，难以支持包含子查询的通用 SQL 执行，且灵活性不足。
• 现有混合方案：如 Oze 协议虽然利用了多版本视图可串行化 (MVSR) 的宽调度空间，但缺乏在生产系统中的实现，且对短事务效率低下；图数据库方案（如 Tuskflow, DDI）仅适用于特定图数据场景，不适用于通用关系型数据库。

核心问题：如何在生产级通用关系数据库系统中，实现长读写事务与短事务的高效共存，同时保持数据一致性且不牺牲短事务的性能？

2. 方法论 (Methodology)

作者提出了 Shirakami，一种专为 Tsurugi 关系数据库系统设计的混合并发控制协议。Shirakami 并非动态切换协议，而是通过一种集成架构，将两种子协议自然融合：

2.1 双协议架构

1. Shirakami-OCC (S-OCC)：
   • 目标：处理短事务（如 YCSB, TPC-C 负载）。
   • 基础：基于 Silo 协议的改进版。
   • 机制：采用乐观并发控制，包含读取阶段和提交阶段（加锁、验证、写入）。通过调整锁顺序避免死锁，并采用不可见读取 (Invisible Reads) 和并行提交来缩短临界区。
2. Shirakami-LTX (S-LTX)：
   • 目标：处理长读写事务（如 BoM 计算、批量计费）。
   • 基础：基于多版本视图可串行化 (MVSR) 的宽调度空间，优于传统的多版本时间戳排序 (MVTO)。
   • 核心机制：
     • 写保留 (Write Preservation, WP)：长事务在开始前声明其将写入的数据范围（表级粒度）。短事务在读取时若发现冲突的 WP 信息，可提前感知并中止，避免死锁或无效等待。
     • 顺序转发 (Order Forwarding)：当低优先级的长事务读取了高优先级长事务写入的数据时，系统动态调整序列化顺序，允许低优先级事务“向前转发”到高优先级事务的 Epoch 中提交。这打破了传统 CSR 的限制，消除了大量误报 (False Positives)，显著提高了长事务的提交率。
     • 优先级管理：S-LTX 事务拥有比 S-OCC 更高的优先级。在冲突时，S-LTX 优先提交，S-OCC 若冲突则中止。

2.2 时间片 (Epoch) 同步机制

• 系统维护全局 Epoch（时间片）用于序列化排序。
• S-OCC 使用“关闭 Epoch"作为序列化点。
• S-LTX 使用“开启 Epoch"作为序列化点，并优先于同 Epoch 内的 S-OCC 事务。
• 通过多版本数据结构提供每个 Epoch 的快照，确保长事务读取一致的历史版本。

2.3 幻读避免 (Phantom Avoidance)

• 针对 S-LTX 的顺序转发可能导致的幻读问题，设计了专门的验证机制。S-OCC 在提交时检查其读取集是否被 S-LTX 的 WP 或已提交版本影响，确保谓词读取的一致性。

3. 关键贡献 (Key Contributions)

1. 首个生产级混合协议实现：Shirakami 是首个在生产级关系数据库（Tsurugi）中实现的混合并发控制协议，成功解决了长/短事务共存的难题。
2. 创新的顺序转发机制：提出了基于优先级的动态序列化顺序调整（Order Forwarding），利用 MVSR 的宽调度空间，在保持高并发性的同时，大幅减少了长事务的误报中止。
3. 写保留 (WP) 与表级粒度优化：通过表级写保留声明，平衡了冲突检测的开销与准确性，使短事务能提前感知长事务的写入意图，避免了死锁和无效等待。
4. 无需动态切换：系统无需根据负载动态切换协议，而是通过统一的调度框架自然处理混合负载，保证了性能的稳定性。
5. 完整的系统实现：基于 Tsurugi 数据库系统，包含自定义索引 (Yakushima)、SQL 引擎 (Jogasaki) 和日志存储 (Limestone)，验证了协议在实际生产环境中的可行性。

4. 实验结果 (Results)

作者在 Tsurugi 系统上进行了广泛的基准测试，并与 PostgreSQL 进行了对比：

• 电信计费基准 (Telecommunication Billing Benchmark)：
  • 模拟了长事务（批量计费）与短事务（实时话单更新）混合场景。
  • 结果：在高并发（16 线程短事务）下，Tsurugi 的长事务延迟比 PostgreSQL 低 19.7 倍。PostgreSQL 在 64 线程下甚至无法在 1800 秒内完成测试，而 Tsurugi 成功完成。
• 物料清单基准 (Bill of Materials Benchmark)：
  • 模拟了复杂的成本计算长事务。
  • 结果：Tsurugi 的延迟比 PostgreSQL 低 5.6 倍。
• Shirakami 内部协议对比 (S-LTX vs S-OCC)：
  • 在包含长事务的 YCSB-E 混合负载下，专门针对长事务优化的 S-LTX 协议的吞吐量是 S-OCC 的 680 倍。
  • 随着长事务操作数的增加，S-OCC 的提交率迅速降至零，而 S-LTX 保持了稳定的高吞吐量。
• TPC-C 基准：
  • Tsurugi 在 128 线程下仍能线性扩展吞吐量，而 PostgreSQL 在 16 线程后性能饱和甚至下降。

5. 意义与影响 (Significance)

• 打破性能瓶颈：Shirakami 证明了在通用关系型数据库中，无需牺牲短事务性能即可高效处理长事务，解决了传统数据库必须将长事务（批处理）移至夜间执行的痛点。
• 生产级验证：不同于许多仅停留在理论或原型阶段的并发控制研究，Shirakami 已集成到 Tsurugi 这一生产级系统中，具备实际商业应用价值。
• 架构启示：该研究为设计支持 HTAP（混合事务/分析处理）的数据库提供了新的思路，即通过混合协议和宽调度空间来适应多样化的现代工作负载，而非单一依赖确定性或纯乐观控制。
• 开源与生态：Tsurugi 系统及其核心协议已开源，为学术界和工业界研究高并发、混合负载数据库提供了宝贵的参考实现。

总结：Shirakami 通过创新的“写保留”和“顺序转发”机制，成功融合了针对短事务的高效 OCC 和针对长事务的宽调度空间协议，在 Tsurugi 系统中实现了卓越的性能，显著降低了长事务的延迟并提升了吞吐量，为现代混合工作负载数据库设计树立了新的标杆。