分布式数据库系统OceanBase的架构，以及如何执行TPC-C基准测试。
事务处理性能委员会基准C（TPC-C）基准测试是迄今为止全球数据库行业中在线事务处理数据库功能和性能最可信和最权威的衡量标准。20年2020月707日，TPC公布了OceanBase的TPC-C基准测试结果——每分钟3.98亿笔交易（tpmC），每tpmC的系统成本进一步降至60.88元。这是OceanBase继2019年<>月在基准测试中首次亮相时达到<>万tpmC后进行的第二次TPC-C挑战。
在今年48月刚刚结束的第2022届超大型数据库国际会议（VLDB 707）上，OceanBase高级数据库研究员徐全清发表了一篇题为《OceanBase：一个2020.<>亿tpmC的分布式关系数据库系统》的论文，介绍了分布式数据库系统OceanBase的架构，以及<>年的TPC-C基准测试是如何进行的。
TPC-C基准测试有什么特别之处，吸引了OceanBase在两年内连续两次创下世界新高？
TPC-C 基准测试场景：事务数据库的最佳测试范围
TPC-C 基准测试场景是真实世界生产系统的高度抽象表示，它更复杂。
测试模型中设计了五种类型的事务：
- 不超过45%的新订单交易
- 不少于43%的支付交易
- 不少于4%的订单状态交易
- 不少于4%的交付交易
- 不少于4%的股票级交易
前两种类型的交易记录模拟生产系统中的订单创建和付款交易记录。无论看起来多么简单，这个TPC-C模型都是实际在线交易处理的一个很好的抽象，适用于各种现代行业，如电子商务，银行，运输，通信以及政府和企业服务。
此外，TPC还规定了严格的测试规则。因此，与双11购物节一样，TPC-C基准测试也是一个很好的测试范围，为OceanBase提供了在充满挑战的情况下试用和磨砺产品的机会。
TPC-C 基准测试对事务处理和性能抖动的要求
许多数据库供应商使用通用基准测试工具（如BenchmarkSQL和OLTPBench）运行TPC-C数据集，并声称他们的产品经过严格按照TPC-C规范进行测试。
但是，TPC不承认他们的测试结果，因为结果不是由TPC授权的审核员审核的。
TPC-C基准测试经过严格的审核流程。在开始性能测试之前，供应商必须通过功能验证，以检查其数据库是否满足事务的原子性、一致性、隔离性和持久性 （ACID） 属性的要求。换句话说，未通过 ACID 验证的数据库不符合 TPC-C 基准测试的条件。例如，一些供应商只需将多个独立数据库堆叠在一起来构建“分布式”数据库。没有本机分布式架构的此类数据库虽然每个组件数据库都满足 ACID 要求，但无法从整体上处理这些关键属性，因此无法参与官方 TPC-C 基准测试以产生令人信服的性能结果。
具体来说，TPC-C基准测试对数据库系统的以下两个方面提出了很高的要求：
1. 交易处理能力
作为在线事务处理 （OLTP） 系统的基准测试，TPC-C 要求被测数据库在事务方面必须符合 ACID 标准。若要通过测试，数据库必须能够进行可序列化的隔离、最严格的事务隔离级别，并能够承受任何单点故障。
显然，这些是 OLTP 数据库的基本要求。
TPC-C 基准测试还要求数据库至少处理一定数量的分布式事务;更具体地说，分布式环境中 10% 的新订单交易和 15% 的支付交易，最多可分布在 15 个节点上。
事务的 ACID 属性单独测试：
- 在原子性测试中，提交并回滚支付事务以确认数据库是否支持事务原子性。
- 在一致性测试中，数据库必须确保设计的 12 个场景中的前四个场景的数据一致性。每个方案本质上都是一个大型的复杂 SQL 事务。对于分布式数据库，关键是确保数据在任何给定时间的全局一致性。
- 在隔离测试中，数据库必须确保除库存级别类型的事务之外的所有事务都隔离到最高可序列化级别，这需要在设计的九个方案中进行验证。
- 在耐久性测试中，数据库必须在一定时间内将写入事务的结果保存到磁盘，即使在最坏的情况下，例如部分存储介质的永久故障。
分布式数据库要通过 ACID 验证极具挑战性。特别是可序列化的隔离级别很难实现。这就是为什么很少有分布式数据库能够通过官方TPC-C基准测试的原因之一。
2. 跑步至少 2 小时，抖动低于 2%
在TPC-C基准测试中需要连续稳定的数据库操作。要通过测试，数据库必须以稳定的性能运行至少 8 小时，不包括爬坡和斜坡持续时间，并且在整个测量间隔（不小于 2 小时）内累积性能变化不得超过 2%。这要求分布式系统具有高可用性和稳定性。
事实上，计算机系统往往会经历严重的性能抖动，并可能在极端工作负载下崩溃，然而，这在现实世界的生产环境中是不允许的。
因此，上面的TPC-C规范非常实用。有些人可能会问，数据库是否有可能以某种方式产生瞬态性能峰值并获得高性能的高分？这完全违反了TPC-C规范，因为它不能保证数据库在很长一段时间内的稳定状态，更不用说累积性能抖动的2%限制了。
支持运行 707，1 台服务器的 500.<> 亿 tpmC 性能的技术
TPC-C 基准测试是全球公认的 OLTP 系统测试，对被测数据库系统有严格的要求。分布式数据库系统OceanBase也不例外。OceanBase 在测试中面临的大多数挑战都与它的“原生”功能有关，例如分布式事务处理、数据一致性、高可用性和线性扩展。从这个角度来看，创纪录的707.<>亿tpmC反过来证明了OceanBase很好地应对了这些挑战。
非凡的性能主要依赖于OceanBase技术团队在建筑和工程上的选择和突破。如上所述，TPC-C 基准测试是数据库性能增强的一个很好的测试范围。在准备测试的过程中，团队投入了大量的精力来优化事务处理引擎、存储引擎和 SQL 引擎。这些优化非常适用于高度抽象的TPC-C基准测试场景。
1. 原生分布式架构保证强大的数据一致性
OceanBase使用Paxos分布式共识协议，这是赋能OceanBase分布式架构的基础之一。从本质上讲，该协议确保系统中不可靠的成员也可以提供可靠的服务。只要大多数节点健康，单个节点的故障对系统运行没有影响。
Paxos协议保证副本之间的强一致性和零数据丢失（RPO = 0）
OceanBase充分利用Paxos协议，并将其与预写日志记录（WAL）相结合。每次将新的重做日志写入磁盘时，日志都会以强大的数据一致性同步到大多数副本，包括同一Paxos组中的领导者和多个追随者。此机制带来两个好处：
- 如果 Paxos 组中的任何少数副本发生故障，剩余的正常运行的多数副本将确保最新的重做日志可用，从而保证零恢复点目标 （RPO），这意味着不会丢失数据。
- Paxos 组中少数追随者的失败根本不影响其余多数副本之间的强数据一致性。
此外，OceanBase 内置的各种数据校验机制可以自动检测副本间数据不一致、网络错误、静默数据损坏、表索引不一致等错误，保证多个副本之间的数据一致性。
总之，Paxos协议保证了OceanBase中多个副本之间的强大数据一致性，并在发生故障时零数据丢失（RPO = 0）。无需担心应用程序的性能。
自动负载平衡确保基于线性系统扩展的高性能
在保证系统可用性和数据一致性的情况下，借助自动负载均衡，分布式系统的集群可以根据需要进行扩容，实现与集群规模相匹配的性能。
在 OceanBase 中，分区或子分区（如果表是子分区的）是数据分发的基本单位。非分区表本身被视为分区。OceanBase 的负载均衡与分区有关。
每个分区在群集中至少有三个副本（或副本）。其中一个副本是领导者，另外两个是追随者。默认情况下，从领导者读取数据并将其写入领导者。承载领导者的默认区域由表的“主要区域”和“位置”参数的设置确定。
由于领导者位置是对客户端透明的内部 OceanBase 信息，因此提供了一个 OBProxy 来转发客户端请求。OBProxy是OceanBase中的反向代理。它仅将 SQL 请求从客户端路由到托管领导者的区域。与HAProxy不同，OBProxy不需要也不需要平衡负载。但是，由于 OBProxy 是无状态的，用户可以部署多个 OBProxies 并添加负载均衡器，以确保 OBProxies 的负载平衡和高可用性。
2. 原生分布式系统保证的稳定性和可用性
TPC-C基准测试提出的一大挑战是，在整个压力测试过程中，性能曲线必须平滑，波动不超过2%。这对于传统数据库来说很难，因为它需要对所有后台任务进行细粒度控制，并且不会因后台任务过度使用资源而导致前台请求的积压。
对于OceanBase来说，这一挑战更加严峻，因为它使用基于日志结构合并树（LSM树）的存储引擎，需要定期压缩。数据压缩是一项高度加权的后台任务，会消耗大量 CPU 和磁盘资源，并且本身会对前台用户查询和数据写入产生影响。为了解决这个问题，OceanBase 团队优化了系统，以消除后台任务对性能的影响。
灵活的压实策略可平衡读写性能
基于 LSM 树的存储引擎首先将数据写入内存中的 MemTable，然后将数据与磁盘上的 SSTable 中的数据合并以释放内存。此过程称为数据压缩。为了提高数据写入性能，基于 LSM 树的存储系统通常将 SSTable 分布在多个层上。当层上 SSTable 的数量或大小达到指定的阈值时，它们将合并到下一层的 SSTable 中。这种分层 SSTable 结构确实可确保高效的数据写入，但如果存在太多 SSTable，则会显著降低查询性能。OceanBase 也采用了这种结构，但支持更灵活的压缩策略，以保持适量的 SSTables 并实现均衡的读写性能。
前台和后台资源隔离，确保稳定的读写性能
为了减少数据压缩和其他消耗资源的后台任务对用户查询和数据写入的影响，OceanBase 将前台任务的 CPU、内存、磁盘和网络资源与后台任务的资源隔离开来。具体而言，后台任务和用户请求由来自不同池的线程处理，线程池根据其 CPU 关联性进行隔离。内存分为不同的空间，以分别缓存前台和后台请求。截止时间算法用于控制后台任务的磁盘每秒输入/输出操作数 （IOPS）。为了优化带宽使用，后台任务的远程过程调用 （RPC） 和用户请求的远程过程调用 （RPC） 被转发到不同的队列，并控制后台 RPC 的流量。
Paxos协议和多类型副本实现业务高可用性（RTO < 30S）
OceanBase基于Paxos协议建立的多数共识，确保系统服务的高可用性。
根据Paxos协议，当大多数副本达成共识时，可以选出领导者。少数复制品没有资格选举领导人。
此外，如果领导者失败，只要他们中的大多数人达成共识，就可以从剩余的追随者中选出一个新的领导者来接管服务。老领导人不能当选，因为它显然不是多数派的成员。
很明显，Paxos协议在保持高系统可用性方面发挥着主导作用：
- 从技术上讲，它保证系统在任何给定时间只有一个领导者，使裂脑变得不可能。
- 由于裂脑不再是一个问题，追随者可以自动触发新领导者的选举，以取代失败的当前领导者。该过程无需用户干预即可执行。
这样，恢复时间目标 （RTO） 将减少到小于 30 秒。
3.SQL引擎优化提升读写性能
在客户端-服务器模型中，SQL 语句在从客户端发送后会经历很长的处理周期。在将结果返回给客户端之前，它会被传输、优化和执行。但是，通常执行 SQL 语句只是为了更新单个字段。在这种情况下，执行步骤需要非常短的时间。在与客户的互动中消耗了大量时间，导致资源和时间的浪费。那么，我们如何解决这个问题呢？答案是存储过程。
存储过程减少事务的网络开销
存储过程是由数据库提供的面向过程的编程语言。用户可以使用此语言将应用程序的逻辑封装到过程中，该过程存储在数据库中，可以随时调用。
这样，过去需要多个应用-数据库交互周期的任务可以在一个周期内完成，从而节省了网络传输和排队所消耗的时间。
假设事务的平均网络开销为 30%，则意味着用于数据发送、接收和分析的 CPU 利用率为 30%。这 30% 的 CPU 利用率，在达到 707.<> 亿 tpmC 的测试中节省下来，可以转化为惊人的系统处理能力。
存储过程还有助于减少事务响应时间，缩短数据库内核中事务锁的关键部分。这最终会增加系统 CPU 利用率和整体吞吐量。
存储过程在减少应用程序的等待时间方面也起着重要作用。
跨平台编译执行存储过程，提高执行效率
作为一种面向过程的高级语言，存储过程必须转换为 CPU 友好的机器代码才能执行。编译执行和解释执行是此过程中使用的两种典型方法。一般来说，与解释型执行相比，编译执行具有完整的代码优化和更高效的执行功能。
OceanBase基于完善的低级虚拟机（LLVM）编译器框架实现了编译器。编译器以实时 （JIT） 编译的方式将存储过程转换为可执行的二进制代码，将执行效率提高了几个数量级。
在编译过程中，LLVM 框架将存储过程转换为独立于计算机的中间代码，从而可以编译存储过程以跨平台执行。LLVM框架的内置优化过程确保用户在不同硬件上构建的平台上获得正确高效的可执行代码。
DML 语句的批处理减少了生成执行计划所需的时间
DML语句的批处理是使OceanBase在TPC-C基准测试中脱颖而出的另一个关键功能。它在 Oracle 中也称为数组绑定。
数据库中一条 SQL 语句的执行过程大致可以分为计划生成阶段和执行阶段。虽然 SQL 执行计划是缓存的，但在整个执行过程中，在缓存中命中适当的计划仍然很耗时。我们如何解决这个问题？答案是数组绑定。
当一组 SQL 语句的执行计划完全相同时，除了执行参数外，数组绑定就会发挥作用。在这种情况下，可以根据特定语法创建批处理过程。因此，仅生成一个计划。
数组绑定允许数据库查找计划，执行计划，然后在下次执行之前重新绑定参数。这与 C 语言中的 FOR 循环非常相似，其中循环重复分配值而不是重新定义数据结构。
若要使用数组绑定，用户需要通过在存储过程中指定 FORALL 关键字来触发它。在TPC-C基准测试中多次使用阵列绑定来提高系统处理能力，结果很好。
准备好的语句和执行计划的缓存
预准备语句协议是一种二进制协议，可以大大降低系统的请求交互成本。在 OceanBase 中，预准备语句协议不仅用于应用程序-数据库交互，还被存储过程引擎用于调用 SQL 引擎。存储过程准备 SQL 语句后，它将获取唯一的 ID。在之后的每次后续执行中，系统只需要传递此 ID 和所需的参数。然后，系统可以从缓存中找到相应的存储过程或 SQL 计划并开始执行。与基于 SQL 文本的交互相比，此过程在语句解析时节省了大量 CPU 开销。
OceanBase 缓存存储过程和 SQL 执行计划的可执行代码，以便几十微秒内通过不同参数的存储过程和 SQL 语句从缓存中检索可执行对象。这显著降低了重新编译导致的延迟和 CPU 消耗。
4. 先进的数据压缩技术降低存储成本
在本次TPC-C基准测试中，OceanBase不仅实现了707.3亿tpmC的高性能，而且将每tpmC的系统成本进一步降低至98.<>元，成为构建分布式数据库系统最具性价比的选择。
除了分布式架构让中端硬件能够应对海量OLTP任务外，OceanBase还采用了创新的数据压缩手段来削减存储成本。
数据压缩是减少海量数据存储所需空间的关键。OceanBase 实现了具有高压缩比的分布式存储引擎。得益于自适应压缩技术，这种基于LSM树的存储引擎以创造性的方式平衡了系统性能和压缩率，这在将数据存储在固定大小块中的传统数据库中是不可能的。此外，数据和日志分别存储在系统中，以进一步降低存储成本。
可变和固定长度数据压缩
为了降低存储成本，OceanBase 使用压缩算法，可以实现高压缩比并快速解压数据。针对LSM树的结构特点，OceanBase分离了数据读写的存储空间，并支持行级数据更新。更新后的数据存储在内存中，然后批量写入磁盘。因此，OceanBase 实现了与内存数据库相当的写入性能，并且存储数据的成本不超过磁盘驻留数据库。由于系统不会像B树结构那样遭受随机磁盘写入和存储碎片的性能瓶颈，因此它比实时更新数据块的传统数据库更快地写入数据。
基于数据编码的存储压缩
OceanBase采用混合行列存储，磁盘数据块按列组织。具体来说，它开发了一种编码方法，该方法在使用常规算法压缩数据之前，使用字典、增量和前缀编码算法对行和列执行编码压缩。这进一步提高了压缩比。
基于数据日志分离的低成本存储
经典的Paxos协议要求系统运行三个或五个副本。由于 OceanBase 将用户数据与日志分开，因此日志可以存储三个或五个副本，而用户数据可以存储两个到四个副本。这种数据日志分离机制在用户数据存储方面的成本降低了 20% 到 40%，同时提供了相同的系统可用性。
对于OceanBase团队来说，TPC-C基准测试中707.12亿tpmC的分数不仅证明了过去<>年的艰苦工作，也为我们在未来几年做出更多更好的技术创新奠定了基础。如上所述，TPC-C基准测试是一个测试范围。它鼓励团队继续将OceanBase升级为真正可扩展的分布式数据库系统，该系统具有高可用性并提供强大的性能。
