VOLTDB技术分享之事务管理

1 .新⼀一代内存数据库和计算引擎 https://www.voltdb.com/try-voltdb https://github.com/VoltDB/voltdb 

2 . VoltDB 公司 USA, China, UK, Founded 2009 Mike Stonebraker TPC-C, YCSB NewSQL Database + Streaming Open Source + Enterprise 2 

3 . VOLTDB价值-关键特性 原⽣生 基于健全合理理的设计原则 安全 云⽀支 企业特性 数据 持 • 企业级 性能 • 实时性能 智能决策 • 节约成本 件处理理 • 将关键功能组合在⼀一个解决⽅方案中 ⾼高可 实时 ⽤用 复杂事 价值产出 引擎 • 传统关系型数据实时处理理 • 能够在持续⼤大量量的流数据上做出关键的决策⽽而不不会丢 失数据 • 结合复杂的机器器学习的模型同时满⾜足⾦金金融、电信级的 ⾼高性能要求 易易 迟 ⽤用 延 性 低 3 ⾼高吞吐 

4 .从2010年年以来，VoltDB已经发布了了9个主要版本 4 

5 . VOLTDB的设计思想和事务管理理 5 

6 . VoltDB可以提供什什么？ 单台服务器器每秒可执⾏行行10-50万符合ACID要求的事务（100%写操作） 单台服务器器每秒可执⾏行行百万条SQL语句句。 集群线性⽔水平扩展（30-50个节点，甚⾄至更更⾼高），可以动态扩、缩容。 ⾼高可⽤用，集群内⽀支持多副本，集群间⽀支持多活同步。 在⽀支持磁盘持久化的同时可达到低⾄至1ms的延时，99.999%的延时⼩小于50ms。 ⽀支持多个平台的导⼊入、导出。 

7 .VoltDB背后的学术研究 C-Store: A Column-oriented DBMS. VLDB 2005. OLTP Looking Through Glasses. SIGMOD 2008. H-Store: A High-Performance, Distributed Main Memory Transaction Processing System. VLDB Endowment 2008. 

8 . compression 8 

9 . 传统数据库⼤大多数CPU时间在等待 87.7% CPU Cycle Breakdown for Shore on TPC-C New Order Source: Harizopoulos, Abadi, Madden and Stonebraker, “OLTP Under the Looking Glass”, SIGMOD 2008 

10 . 如果把所有数据放⼊入内存呢? 内存的单位存储价格越来越低。 很多场景的数据集并不不⼤大（从⼏几百M到⼏几百G）。 可以分布式的存储数据。 10 

11 . OLTP事务⼤大多⽐比较短⼩小 以TPC-C举例例，⾥里里⾯面最复杂的事务： 平均读写200条记录， 平均执⾏行行时间1ms， 不不属于CPU密集型任务。 11 

12 . 换成单线程执⾏行行？ 降低数据结构的复杂度，减少开销。 线程独占数据，⽆无需在表、⾏行行级别加 锁。 12 

13 . 存储过程：⼀一等公⺠民 执⾏行行的查询已经提前规划好。 应⽤用程序⾥里里的外部控制流可以转换成存储过程⾥里里的条件判 断。 让逻辑向数据靠拢，⽽而不不是反过来。 减少与客户端的交互。 13 

14 . 对数据分⽚片 按照数据key的Hash分⽚片。 每个线程独占⼀一部分数据，不不共享内存。 充分利利⽤用多核的性能，减少CPU空闲。 通过多个线程同时执⾏行行事务来达到并发。 14 

15 .VoltDB设计上的权衡 数据全内存存储 单线程执⾏行行SQL引擎 分布式存储 ⽆无锁设计（lockless） ⽆无需等待（waitless） 

16 . 来点⼲干货吧！ 16 

17 . 在副本间同步数据的⽅方法 独⽴立同步 各个副本独⽴立地运⾏行行事务。 在事务结束后需要检查是否各个副本产⽣生的结果相同。 被动同步 由某个副本先执⾏行行事务，将执⾏行行后的结果传递给其他副本。 VoltDB采⽤用的是第⼀一种⽅方式。 

18 . ⽆无锁设计 没有锁的保护，如何在多个副本上保证执⾏行行结果的⼀一致性？ 在任何时刻，按照相同的顺序执⾏行行相同的事务，应该产⽣生相同的结果。 确定的事务 + 相同顺序 = 可重放的⽇日志。 事务的逻辑应当保证确定性。 A B C 副本1 结果相同！ A B C 副本2 时间 

19 . 不不确定的事务 Insert into foo values (rand(), now()); 

20 . 数据⾏行行的存储顺序 SELECT SUM( Balance) FROM account; id Balance id Balance 1 100.0 1 100 2 200.0 2 200 3 999.999 4 55.5 4 55.5 3 999.999 

21 . 依赖外部输⼊入 Begin Transaction Read environment variable en_var if en_var is set do some write else do something else Commit Transaction 

22 . 如何保证事务的确定性？ VoltDB的管理理操作都是确定性的，⽐比如更更改 Procedure foo (params1, param2, ...) DDL，加载类。 { logic VoltDB为存储过程提供满⾜足确定性的API来获取 read sql 1 时间、随机数 logic write sql 1 logic VoltDB保证存储过程内部语句句的执⾏行行顺序。 read sql 2 logic ⽤用户定义的存储过程，需要额外的检查。 write sql 2 return response } 

23 . 额外的哈希检查 事务请求 分区follower 事务请求 返回结果+hash 客户端 分区Leader 事务请求 返回结果 ⽐比较所有返回结果 分区follower 和对应的hash值 返回结果+hash 

24 .当不不幸发⽣生时...⼑刀下留留⼈人 

25 . 忍者的替身术 当Leader检测到某个事务的hash不不⼀一致时，主动抛弃该分区所有的follower。 如果之后系统奔溃，从磁盘重新恢复的状态保证和之前⼀一样。 以降低了了冗余度的代价保证了了系统的可⽤用性。 在纠正了了事务逻辑的不不确定性后，再将follower添加回来。 

26 . ⽆无需等待 因为事务是确定性的，所有分区按照相同的顺序执⾏行行，所以： 副本之间执⾏行行事务⽆无需互相等待； Redo⽇日志⽆无需等到事务提交，收到事务请求就可开始写⼊入磁盘； Redo⽇日志、副本间的同步⽇日志传输效率更更⾼高，因为只需传递事务的参数。 

27 . VoltDB分布式⼀一致性 -- 类Raft协议 通过Leader读写 成员掉线，不不影响正在执⾏行行的事务 Leader掉线，通过成员选举选出新的Leader，继续未完成的事务 成员之间⻆角⾊色的变更更（Leader主动迁移） 

28 . VoltDB通过了了Jepsen测试 https://aphyr.com/posts/331-jepsen-voltdb-6-3 Jepsen测试是业界公认的测试分布式数据库数据安全的测试框架，该框架模拟了了在 各种故障场景下的完整性和⼀一致性测试。 

29 .节点 #1 单分区事务（数据冗余，⾼高可⽤用） 分区 #1 SPI #1 分区 #2 PLAYER PLAYER_ID LAST_NAME FIRST_NAME CREDITS 节点 #2 分区 #1 SPI #2 分区 #2 29