阿里巴巴网站的搜索引擎优化案例,类似携程网的网站,做网站现在还行吗,小程序游戏制作蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注#xff0c;为了更清楚的展示其中的技术细节#xff0c;我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读#xff0c;共包括五篇#xff1a;
1#xff09;TPC-C基准测试介绍 2#xff09;OceanBase…蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注为了更清楚的展示其中的技术细节我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读共包括五篇
1TPC-C基准测试介绍 2OceanBase如何做TPC-C测试 3TPC-C基准测试之SQL优化 4TPC-C基准测试之数据库事务引擎的挑战 5TPC-C基准测试之存储优化 OceanBase 这次 TPC-C 测试与榜单上 Oracle 和 DB2 等其他数据库在硬件使用上有非常大的不同OceanBase 的数据库服务器使用的是 2043 台型号是 ecs.i2.16xlarge 阿里云 ECS 服务器其中 204 台作为 data node还有 3 台作为 root node每位读者都可以在阿里云网站上轻松按需购买。如果读者翻看 Oracle 和 DB2 的 TPC-C 测试报告会发现这些数据库都会使用专用的存储设备例如前最高记录保持者 Oracle 在 2010 年的测试使用了 97 台 COMSTAR 专用的存储设备其中 28 台用来存储数据库的重做日志Redo Log。
硬件的差异给软件架构提出了完全不同的挑战专用的存储设备其内部通过硬件冗余实现了设备自身的可靠保证数据库软件在使用这样的存储设备时就天然的预设了数据不会丢失。但是这种方式带来了成本的极大消耗专用的存储设备的价格都是特别昂贵的。
OceanBase 使用通用的 ECS 服务器提供数据库服务并且只使用 ECS 机器自带的本地硬盘做数据存储这是最通用的硬件条件。但是这种方式对软件架构提出了很大的挑战因为单个 ECS 服务器的不如专用的存储设备可靠性高。这也对 OceanBase 的事务引擎提出了很大的挑战OceanBase 是在普通的 ECS 服务器上就可以实现 ACID 特性。
TPC-C 测试是对事务 ACID 特性有完整并且严格的要求。下面分别介绍 OceanBase 针对事务 ACID 的特性的解决方案。
Paxos 日志同步保证持久性(Durability)
OceanBase 数据库的事务持久性Durability保证是依赖事务重做日志Redo Log的持久性来达成的。所有的 Redo Log 会实时强同步到另外两台数据库服务机器上包含产生 Redo Log 的机器在内总共会有三台机器在硬盘中持久化 Redo Log。OceanBase 采用了 Paxos 一致性同步协议来协调这三台机器上 Redo Log 的持久化Paxos协议采用超过半数也叫“多数派”成功即算成功的算法三个副本时两个成功即超过半数当其中两台机器完成持久化后事务即可完成提交剩下的一台机器的 Redo Log 在通常情况下也是立即就持久化完成了。但如果这台机器碰巧出现异常也不会影响事务的提交系统会在其恢复后自动补齐所缺失的 Redo Log。如果机器永久故障系统会将故障机器所应负责同步的数据分散给集群内的其他机器这些机器会自动补齐所缺失内容并跟上最新的 Redo Log 写入。
使用 Paxos 一致性协议的最大优势是数据持久化和数据库服务可用性Availability的完美平衡。当使用三个副本时任何时候坏掉一个副本时至少还有另一个副本有数据并且写入还可以持续因为还剩下两个副本后续的写入也不受影响。所以OceanBase 在保证了事务持久性的同时也大大提升了数据库的连续服务能力。TPC 组织的审计员在现场审计 OceanBase 持久性能力时在客户端持续产生压力的情况下从 OceanBase 集群中随意挑选了一台机器做了强制断电操作发现数据库的数据不仅没丢数据库不需要任何人工干预还能持续的提供服务审计员们都很吃惊并且对 OceanBase 大为赞赏。
依靠自动两阶段提交原子性(Atomicity)
TPC-C 测试模型的五种事务中的“订单创建”和“订单支付”两个事务分别会对很多数据做修改是其中相对复杂的两个事务。TPC-C 标准对事务的原子性Atomicity是强制性的要求要求一个事务内部对仓库、订单、用户等表格的修改一定要原子的生效不允许出现只有一半成功的情况。
OceanBase 的数据是按照仓库 IDWarehouse_ID拆分到多台机器上的如果所有的事务都是发生在同一个仓库内部那么无论数据量有多大事务的修改都只会涉及一台机器的数据也就是在一台机器上完成事务提交这是一种完美的线形扩展的场景。但是这不符合实际的业务场景大多数的实际业务都会有很多不同维度之间的数据交互。TPC-C 测试标准也是对此认真考虑所以对于事务操作数据的随机性规则提出了要求最终要保证产生 10% 的“订单创建”事务和 15% 的“订单支付”事务要操作两个及以上的仓库。在 OceanBase 数据库内这样就产生了跨机器的事务操作而这必须使用两阶段提交协议来保证原子性。
OceanBase 会自动跟踪一个事务内所有 SQL 语句操作的数据根据实际数据修改的位置自动确定两阶段提交的参与者事务开始提交时OceanBase 自动选择第一个参与者作为协调者协调者会给所有参与者发送 Prepare 消息每个参与者都需要写各自的 Redo Log 和 Prepare Log也意味着每个参与者各自做自己的 Paxos 同步等协调者确认所有参与者的 Redo Log 和 Prepare Log 完成后然后再给所有参与者发送 Commit 消息再等所有参与者的 Commit 工作完成。整个协议是在事务提交过程中自动完成对用户完全透明。OceanBase 为每一个两阶段提交事务自动选择一个协调者整个系统任何机器都可以分担协调者工作所以 OceanBase 可以将事务处理能力进行线形扩展。
多版本并发控制保证事务的隔离性(Isolation)
TPC-C 标准里要求“订单创建”、“订单支付”、“订单配送”、“订单支付”事务之间都是串行化隔离级别Serializable。OceanBase 采用的方法是基于多版本的并发控制机制。事务提交时会申请一个事务的提交时间戳事务内的修改以新的版本写入存储引擎并且保证之前版本的数据不受影响。事务开始时会获取一个读取时间戳整个事务内数据的读取操作只会看到基于读取时间戳的已提交数据。所以事务的读取不会遇到脏数据、不可重复读数据以及幻读数据。同时事务的修改会在修改的数据行上持有行锁保证两个并发的修改相同行的事务会互斥。
OceanBase 的全局时间戳生成器也是由多副本组成可以独立部署在三台机器上也可以像这次 TPC-C 评测中一样部署在 root node 机器上与 root node 共享资源。全局时间戳的三副本是一种极高可用的架构任何一次时间戳的获取操作都至少在三台机器上的两台获得了确认所以任意一台机器出现故障获取时间戳的操作不会有一点影响。
按照 TPC-C 标准OceanBase 准备了 9 种不同的场景测试有读-读、读-写冲突时事务的隔离性最终都完美通过了审计员的审计。
一致性保证(Consistency)
在有了上述的事务能力后OceanBase 可以完美的保证各种数据的一致性的约束。TPC-C 标准里提出了 12 种不同的一致性测试场景在各种测试运行前后对数据库内的数据进行一致性校验。因为 OceanBase 此次测试数据规模庞大一致性校验的 SQL 需要核对大量的数据所以一致性校验的挑战在于校验的 SQL 本身运行的效率。基于 OceanBase 的并行查询能力发挥整个集群所有的计算资源校验 SQL 的运行时间均缩短了几个数量级很好的完成一致性功能的审计工作。
复制表
TPC-C 测试模型中有一张商品ITEM表这张表的内容是测试所模拟的销售公司所有售卖的商品信息包含了商品的名字、价格等信息。“订单创建”事务执行中需要请求这张表内的数据来确定订单的价格信息如果商品表的数据只存放在一台机器上那么所有机器上发生的“订单创建”事务都会请求包含商品表的机器这台机器就会成为瓶颈。OceanBase 支持复制表功能将商品表设置为复制表后商品表的数据会自动复制到集群中的每一台机器上。TPC-C 标准不限制数据的副本数但是不管数据的组织形式标准里要求事务的 ACID 一定要保证。OceanBase 使用特殊的广播协议保证复制表的所有副本的 ACID 特性当复制表发生修改时所有的副本会同时修改。并且当有机器出现故障时复制表的逻辑会自动剔除无效的副本保证数据修改过程中不会因为机器故障出现无谓的等待。复制表在很多业务场景中都有使用例如很多业务中存储关键信息的字典表还有金融业务中存储汇率信息的表。
总结
OceanBase 坚持在普通的PC服务器上实现高可靠、高可用、高性能、可扩展的数据库实现了用廉价硬件和云计算的部署环境提供最关键的数据库服务的能力。后续我们会持续优化事务处理的性能丰富事务的各种功能特性为用户提供更好用的数据库服务。
原文链接 本文为云栖社区原创内容未经允许不得转载。
相关文章：
