TPC-C基准测试之链路层优化
作者:易鸿伟 闫建良 王光树
在 TPC-C 标准定义中,测试系统分为 RTE(Remote Terminal Emulator)和 SUT 两部分。在实际的 TPC-C 测试流程中,不只是对 DB 端能力的考验,对链路 中的所有组件都存在极大的资源消耗和压力。以这次 6088 万 tpmC 测试结果看,我 们一共在 64 台 64C128G 的云服务器上运行了 960 个 RTE 客户端,来模拟总计 47942400 个用户 Terminal,最后还需要基于这么多 RTE 统计结果进行一致性 和持久化审计验证。而 SUT 又拆分为三部分:WAS(Web Application Server)、 OceanBase Proxy(OBProxy) 和 OceanBase Server(OBServer)。RTE 的 请 求 到 WAS,然后 WAS 通过 OceanBase 客户端来访问 OBProxy,OBProxy 会将请求 转发到后端 OceanBase 集群中最佳的 ObServer 去执行请求。WAS 和 OBProxy 是 RTE 和 OBServer 之间的桥梁,这个桥梁对于承载压力起着至关重要的作用。本 次 TPC-C 基准测试中,OceanBase 访问链路上主要涉及两个组件:
- ODBC 接口及驱动:TPC-C 测试中,WAS 请求 OceanBase 采用了 ODBC 接口。ODBC(Open Database Connectivity) 是 Microsoft 提出的 数据访问规范,ODBC 在大多数 DBMS 上都可以使用,OceanBase 也提供 了 ODBC 接口访问能力。感兴趣的用户可以查阅 ODBC API 说明 快速上手 使用,使用 ODBC 的用户可以直接使用该接口无缝迁移的访问 OceanBase。 ODBC 接口及驱动集成到 WAS 内部,作为请求 OceanBase 的客户端。
- OBProxy 代理:OceanBase 实现了 OBProxy 代理服务器来解决数据库链 路上的路由及容灾问题。OBProxy 会感知数据副本地址和分区规则,不参 与 SQL 引擎参与执行计划的生成调度,主要负责 SQL 路由和转发。这种架 构设计中,OBProxy 承担了基础的路由和容灾功能,而数据库的功能全部交
由 OBServer 实现。这样更加简单明确的分工可以各组件性能做的更加极致, OBProxy 也做到了完全无状态,只需要添加节点即可实现代理能力的水平扩 容,OceanBase 整体也能做到数据库的最高性能。
![](http://www.itpub.net/wp-content/uploads/2019/10/2019101411134580.png)
TPC-C 基准 OceanBase 链路访问图
TPC-C 是一个非常严苛的基准测试模型,考验的是一个完备的关系数据库系统 全链路的能力,任何一个环节有瓶颈均无法发挥数据库的最大性能,接下来本文会 分别在性能、成本及服务持续三个方面来说明下是如何优化 OceanBase 链路上的 组件。
链路性能优化
在 TPC-C 基准测试之 SQL 优化已经提到,从整个链路的角度来看,SQL 所 需要的执行时间是非常短暂的,大量时间花费在与客户端的交互过程中,造成资 源的浪费和耗时的增加,为此 OBServer 提供 Prepared Statement、存储过程和 ARRAY BINDING 能力。客户端和 OBProxy 针对该能力进行支持以使其真正发 挥作用。同时客户端本身也进行一些优化提升链路性能,接下来主要介绍链路性能部 分的优化点:
- 提供异步接口能力:通常使用数据库访问都是同步接口,同步接口开发方便, 但客户端受网络交互耗时影响大,并发能力受到限制。使用多线程的方式可以 帮助提升并发能力,但机器的线程资源是宝贵的,过多的线程会增加机器线 程切换的开销,限制了并发能力。为使 WAS 可以达到更高的吞吐能力,我 们基于事件驱动机制在 ODBC 接口内增加异步接口的支持。使用异步接口, WAS 单个线程内可以在发送请求后无需等待执行结果继续在其他 Session 上 发送请求,通过充分使用线程资源从而大幅提升吞吐能力。异步接口本身参 考 ODBC 接口规范,用户调用异步接口会立即返回,如果尚未执行完成则返 回 SQL_STILL_EXECUTING,用户可以轮询接口直到执行完成返回成功 (SQL_SUCCESS)或者失败(SQL_ERROR),也可以基于网络事件驱动, 在有结果返回时再次调用接口获取结果。使用异步接口,可以在少量线程资源 下轻松支持大量的并发连接,极大的提升了 WAS 的并发能力,机器资源的利 用率也得到提升,大幅降低压测成本。
- 提 供 Prepared Statement 能 力:Prepared Statement 是 一 种 二 进 制 的 请 求交互协议,一次 PS SQL 文本传输,多次执行,OBProxy SQL 引擎会缓 存 PS SQL 文本以及解析结果,每条 PS SQL 只需要执行一次 Prepare 操 作,后续所有 Session 上的每次执行只需要传入对应的 Statement Id,就可 以从缓存中找到对应的 SQL 解析结果,结合传入的参数,可以很快的计算出 OBServer 的路由信息,转发性能更为高效。同时,作为代理层的 OBProxy 也很好的支持了 OBServer 的分布式特性,当 Client Session 需要切换 Server Session 时,无需再次发送 PS SQL 和 Execute 阶段时的类型数据, OBProxy 可以自行判断并决定是否需要同步 PS SQL 或加上类型数据。通 过 Prepared Statement 能力,可以有效减低系统间的交互成本,提升性能,相比普通 SQL 文本的交互方式,省去了大量 SQL 文本的传输以及请求文本 解析的 CPU 开销。
- 存储过程:对于存储过程,OBProxy 做了大量优化,存储过程通常包含多条 SQL,不同 SQL 通常需要路由到不同 OBServer 上执行,产生大量远程执 行。远程执行不仅会增加 RT,也会占用更多的 CPU 资源,因此,OBProxy 的 SQL 引擎会解析存储过程中的 SQL,计算最优策略,将存储过程调用发往 最合适的 OBServer 上执行,尽可能的减少远程执行次数。OBProxy 也会缓 存存储过程的解析结果和路由信息,用以省去每次硬解析带来的 CPU 开销。
- 复杂类型:我们在 OceanBase 原有传输协议上重新做了扩展,使得整个链 路支持复杂类型的传输。同时,OBProxy 新增了复杂数据类型的解析,能够 根据复杂类型数据来计算路由和分区裁剪。通过支持复杂类型,可以提高每次 传输携带的数据信息,有效减少交互次数,也能够根据复杂类型的数据计算最 佳路由策略,尽可能的路由到分区更多的 OBServer 上,减少远程执行次数。 正是有了 OBProxy 对于数组等复杂类型的支持,才使得客户端可以更好的使 用存储过程和 ARRAY BINDING 的能力。
代理资源占用
OBProxy 代理采用多线程异步框架和透明流式转发的设计,保证了数据的高性 能转发(单核 5 万 QPS、转发 RT 30~50 us),以及自身对机器资源的最小消耗。 在 TPC-C 基准测试中,我们也采用了本地的形式部署到 WAS 端,这样可以最大程 度的的减少客户端到代理层的网络开销。在本次测试中,OBProxy 代理层部署到 64 台客户端机器上,每台机器上使用到了 10 个 Core,一共占用 640 Cores,仅占整 体 CPU 测试成本的 7% 左右,几乎没有使用存储资源,资源占用比例小且支持水平扩容。
持续服务能力
OceanBase 提供了高可用的数据库服务,在出现机器不可用的场景下,不需要 有任何人工干预数据库依然能够持续提供服务,在本次 TPC-C 做 Durability 测试强 制断电操作中,OceanBase 就表现出无人工干预下的数据库持续服务的能力,大大 超出审计员的期望。
OceanBase 针对强制断电这种单机故障场景,OBProxy 有包含黑名单和灰 名单两种机制,用于处理 OBServer 错峰合并、升级、宕机、启动 / 停止,网络分 区等状态。黑名单采取定期刷新维护,由 OBServer 反馈哪些服务器节点不能提供 服务。灰名单则采取主动触发维护,当 OBProxy 转发请求给 OBServer,如果发 现 OBServer 返回特定的系统错误,或者 OBServer 在一段时间内有多次连续不 可用,则将该 OBServer 加入灰名单。黑名单中的 OBServer 不会被访问,灰名 单中的 OBServer 每隔一段时间会重试一次,检查是否需要洗白,以避免长时间将 OBServer 降级。通过 OceanBase 这样的机制,能够保障 TPC-C Durability 测 试过程中的数据库持续服务能力。
总结
OceanBase 链路层为客户提供了端到端的完整解决方案,其自研的传输协议 能够非常灵活的支持 SQL 特性和交互协议,实现了标准的数据库访问接口并支持 Oracle 兼容模式,可以达到数据库的易用性、高性能、服务持续的最大平衡。后续 会持续优化传输协议以达到最高的传输及交互效率,完善数据库访问标准接口,为用 户提供一个更为成熟的数据库服务。