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 兼容模式，可以达到数据库的易用性、高性能、服务持续的最大平衡。后续 会持续优化传输协议以达到最高的传输及交互效率，完善数据库访问标准接口，为用 户提供一个更为成熟的数据库服务。