智慧油客：从初识、再识OceanBase，到全栈上线

今天，我们邀请了智慧油客的研发总监黄普友，为我们讲述智慧油客与 OceanBase 初识、熟悉和结缘的故事。

---

智慧油客自2016年诞生以来，秉持新零售的思维，成功从过去二十年间以“以销售产品为中心”的传统思维模式，转向“以运营客户为中心”，并且依托智能大数据，驱动业务精准运营，致力于推动能源零售行业实现全面的产业升级。智慧油客全栈 SaaS 服务体系目前已帮助数万加油站完成产业升级，为加油站提供了全新一代的自动化智慧油站运营服务，集进销存业务运营、会员客户管理、自属移动互联网平台营销、聚合支付、财务管控、大数据和人工智能分析等技术为一体。目前已覆盖全国 30 个省级行政区，服务 1 万多座油站、3000 多万车主，每天订单量超过 100 万单。

初识 OceanBase

2021 年中旬，机缘巧合之下，智慧油客接触到国产分布式数据库产品 OceanBase，经过那次沟通交流，我对 OceanBase 有了简单的了解和认识，原来当年阿里的去 IOE、每次双十一大促的数据库功臣叫 OceanBase，其经历了 11 年的自主研发，是蚂蚁全栈都在使用的一款企业级原生分布式数据库。

这次交流后，我对 OceanBase 一些特性比较感兴趣，如高可用、高性能、可扩展、低成本、云原生、高度兼容 SQL 标准和主流关系型数据库生态等特点，对于企业比较吸引人，同时它也是全球首家通过 TPC-C 和 TPC-H 测试的分布式数据库。

随后我去查看了 TPC 的官方网站：TPC-C 连续两年蝉联第一，超越 Oracle 性能 20 多倍，这个结果对于一款纯国产数据库来说，颇有一些扬眉吐气的感觉，霸榜多年的 Oracle 被中国的产品完胜超越。

在当时的时间点，智慧油客正处于业务快速发展阶段，全线业务快速迭代，同时数据是智慧油客的立命之本，切换数据库对于我们还是需要谨慎和评估，因此当时未投入成本去验证产品。

后话：如果当时选择 OceanBase，可能就没有后面的一些小插曲。

再识 OceanBase

2022 年，刚刚过完忙碌的春节，OceanBase 团队再次约见。

调研分布式数据库

在这次交流前，针对之前介绍的分布式数据库专门去做了一些调研。毕竟分布式数据库的出现和发展没有几年，技术是否成熟，产品是否过硬，有多少客户案例，客户实际体验如何，这些都是问号。带着这些问题，我们对分布式数据库市场进行了一些技术预研。

首个分布式关系型数据库诞生于 2012 年，Google 发布 Spanner，打造的全球分布式数据库，承载 Google 自身的全球业务，代码闭源，近发布论文说明其架构原理，Shared Nothing 无共享模式是纯粹分布式的体现、ACID 是关系型数据库的基础，MVCC 是并发访问的保障。自此开创了分布式关系型数据库的元年，这样算来分布式关系数据库的发展也近十年的历史。

再看 OceanBase，Shared Nothing、ACID、MVCC 等等，分布式一致性协议为 Paxos，不由得想起 Google 的 Chubby 作者 Mike Burrows 的那句话：“There is only one consensus protocol, and that's Paxos”（世界上只有一种一致性算法，那就是 Paxos）。从数据库架构上来看，满足了关系型数据库的各类特性，同时也具有分布式的扩展性、一致性的特点。

OceanBase 官网也有很多产品资料和手册，颇有 Oracle 官方手册的规范性，面向 DBA 的、面向开发的等资料一应俱全。案例介绍、解决方案、培训中心等各个板块也都有清晰的分类，之前的疑问基本打消了一半。

小插曲：智慧油客经过多年的快速发展，数据量级已经达到了单实例 MySQL 的上限，因此去年 10 月份，我们对 MySQL 云实例进行了升级，采用计算存储分离的 MySQL，对数据库存储扩容，同时采用一主三从架构，以应对数据的爆发式增长。

春节的返乡潮，连续多日出现加油高峰，瞬时流量突发性增长，此时数据库却成为我们的拖累，执行计划未走索引，SQL 命中低，硬解析升高，负载急剧上升，延迟飙高，甚至出现了数据库宕机罢工，严重影响了客户加油体验，我们的研发团队，在这个春节加班加点保障服务 SLA，在大年初一终于扛过这一波业务高峰。

后来，通过 OceanBase 解决方案架构师对产品的详细介绍，同时结合我们业务规划和之前遇到的痛点为我们的数据库摸脉问诊，让我们对 OceanBase 有了一些信心，当时我们比较坚持的即使切换数据库也不会选择 MySQL 内核数据库，而 OceanBase 完全自主研发，不基于任何数据库内核，内核引擎同时支持 MySQL 和 Oracle，这在数据库产品中也是独一无二。

最终，我们决定详细测试和验证 OceanBase 数据库，看是否能够给我们带来额外惊喜。

全业务验证 OceanBase

我们组织了专项团队进行 OceanBase 验证测试，包括全链路、全业务的功能验证，性能压测。

首先，通过 OceanBase 生态产品 OMS 进行数据迁移，将我们的真实生产数据迁移到 OceanBase，OMS 产品支持结构迁移、全量迁移、增量迁移、全量校验等功能，一站式解决了数据库迁移和验证等问题。我们迁移了线上 5TB 的数据，到了 OceanBase 整个存储仅 1.1TB，近 20% 的压缩率确实给我们一个不小的惊喜，直接存储成本下降 80%，对于一个重数据成本的公司，成本下降显著。

OMS数据迁移产品

• 兼容性

OceanBase 自主研发，未基于任何数据库内核，这一点反倒让我们担心其兼容性，因为语法兼容度越高，业务代码的改造成本越小，我们的业务快速迭代，如果因为切换数据库而投入过多人力，得不偿失。

根据 OceanBase 团队的介绍，OceanBase 支持 MySQL 5.7 绝大部分语法，同时官网也有详细的 MySQL 兼容项对比。我们的生产库采用 5.6 版本，对后续测试我们还是比较乐观。

经过我们测试团队全量的集成测试，发现了几个不兼容项，比如table的大小写问题，插入时间戳的默认值的问题，函数兼容性等问题，对于一个新的数据库产品，我们本着严格筛选的原则，将这些问题一一反馈 OceanBase 专家，没想到 OceanBase 做到了 MySQL语法兼容的同时，很多参数、变量也都沿用了 MySQL 的传统，对于学习成本和维护成本也都没有太多壁垒，最终仅通过参数和变量的调整均得到了解决。

• 性能压测

智慧油客的业务中，智慧支付是客户体感最强烈的环节，服务与赋能加油站企业，首先是能让车主顺畅加油快捷支付，其次才是为车主和油站提供附加服务和运营管理能力。因此针对订单、支付、油价查询等高频场景进行了针对性的压测，对高并发高流量场景进行验证。

测试集群采用 OceanBase 公有云 14C70G 规格，OceanBase支持多租户资源隔离，在该集群上开了三个租户，其中压测的租户规格仅 8C48G 资源。

首先开启 30 个并发小试牛刀，这个并发下对数据库完全没有压力，TPS、QPS 各项平稳，压测场景中测试数据集中，存在热点行，但此时依靠准内存数据库级的高性能写入，RT 延迟依然较低。

高并发压测，6000 并发访问验证突发峰值流量时的响应，对于突发访问数据依然采用较为集中的测试数据，因此也是考验对于热点行的高并发情况，对于一个 8C 的小资源租户，读写延迟增加也在意料之中，但数据库整体稳定，可以应对突发流量。

600 并发压测，TPS、QPS 平稳，SQL 硬解析后很快走 Plan Cache，整体 RT 平稳，写 RT 在 1ms 以下，读 RT 也在 1ms 左右，整体性能和稳定性都非常满意。

• 测试小结

整个测试历时两周，全面分析评测，在显著节约成本的同时，无论是兼容性还是性能均超出预期，同时分布式数据库的高可用能力也能为我们的服务保驾护航。

结缘 OceanBase

测试结果让我们对 OceanBase 充满信心，准备全面切换数据库服务。如何平稳切换数据库，如何在切换过程中保证服务的可用性成为我们的难题，OceanBase 的迁移平台为我们提供了迁移的保障。具体迁移步骤和数据清洗等细节，OceanBase 提供了数据库迁移规划和咨询服务，经过一周的讨论研究，同时结合 OceanBase 专家的建议，最终梳理并确定了全业务迁移方案。

一站式服务

智慧油客的近两年业务规模飞速发展，2020 年初服务 5000 家油站，2021 年初服务 8000 家油站，到 2021 年底已经超越 10000 家，年增长 40% 以上。

快速增长对我们的技术架构提出了挑战，持续扩容应用节点数量，最终压力都汇聚到了数据库，高并发、高流量对于传统数据库，终究会达到连接上限和性能极限，即便开了再多的从库，传统数据库的单节点写无法满足高并发写入场景。

分库分表解决方案可以解决多节点写入问题，但中间件的性能瓶颈，数据均衡等问题，以及业务改造成本、运维成本都是制约业务发展的因素。与其采用一个中间态的产品，不如直接进化到分布式内核的数据库产品，通过 OceanBase 公有云服务提供的一站式部署、扩容、监控运维管理、开发工具、数据迁移、备份恢复等端到端数据库服务化解决方案，同时兼顾了运维成本与服务保障。

OB Cloud 产品架构

大幅度降本

线上全业务迁移，包括我们的业务库、报表库等三个实例集群，经过分析清洗，通过 OMS 迁移工具，可以边界的选择 Schema 进行迁移，最终迁移原来三个实例共 5TB 数据，OceanBase 存储仅仅 869GB，比测试阶段的主库压缩率高出更多，直接节省存储 83%。

总存储压缩对比

租户存储监控

    

企业上云可以节省运维和资源成本，而云产品的选择也是一门学问，面对众多同类云服务，充分调研产品特性，与云产品的团队深入沟通，充分测试云产品是否适合企业架构，前期的投入最终均会回报到后续运营成本上。OceanBase 对 MySQL 的高兼容性降低改造成本，存储压缩特性大幅度降低存储成本，数据库的直接账单成本节约 40% 以上。

未来，智慧油客将持续进行服务升级改造，快速迭代打磨产品，OceanBase 数据库作为智慧油客的数据底座，通过多租户的资源动态调配、分布式的弹性扩容，上层业务架构更加灵活，面对突发流量、营销活动等场景也多了一份从容。

实践 Tips

在 MySQL 中通过参数 lower_case_table_names 来控制表名的存储和比较规则，即 Table 大小写敏感等规则，在 OceanBase 上的语义与 MySQL 完全一致。

MySQL 官方文档对 explicit_defaults_for_timestamp 的说明

时间戳默认值，explicit_defaults_for_timestamp 变量控制时间戳默认值，在MySQL 5.6、5.7，默认为关闭，而 MySQL 8.0 此参数默认开启，直接导致的是一个 not null 且有默认值的时间戳字段，如果显式插入该字段为 NULL，会直接报错。出于 SQL 的严谨性和规范性，建议企业未来开启此选项，OceanBase 默认开启，在关闭该变量后，完全兼容 MySQL 5.7。