最佳实践|意出望外的一次相遇｜利楚初探 OceanBase OceanBase|分布式|数据库

武汉利楚商务服务有限公司（简称“利楚”）成立于 2011 年，是国内最早从事聚合支付技术研发和应用的高新技术企业之一，也是国内领先的商户数字化经营运营商。旗下拥有聚合支付中台“扫呗”、商户轻 SaaS“赋佳”、全域营销中台“有域”3 大产品体系，此外，利楚还有多项专业资质，30 多项软件著作权，拥有强大的系统研发和运营保证能力，是国内商户服务领域的创新者和引领者。

本期，我们特别邀请了利楚商服 CTO、副总裁、支付行业资深系统架构师林喆，从分布式数据库发展历史谈起，为大家讲述利楚与 OceanBase 相遇、相知的故事。

文章图片

为什么选择分布式数据库在互联网时代，数据成为一家企业经营的命脉，利楚作为聚合支付的领军企业之一，2021 年受理交易金额 3500 亿，覆盖全国 600+ 城市，服务线下商户 110 万+家，日交易笔数 2300 万+，合作伙伴 1000+。如此海量交易和支付场景下，数据对于利楚意味着服务质量，意味着企业经营的未来与生机。因此，对于数据的根基底座，数据库的稳定性高于一切，7*24*365 稳定运行是基本需求，服务连续性是服务质量底线，高可用的数据库，避免单点故障、快速容灾切换、数据无损是数据库技术大势所趋。

数据库技术发展
从数据库技术发展历史来看，经历了单体数据库、分库分表数据库、分布式数据库的发展。同比我们的业务应用和服务，很早就开始了微服务化、单元化架构升级，其本质也是服务分布式化，通过分布式一致性协议来协调各个应用和组件，从而达到服务高可用、高吞吐的能力。虽然姗姗来迟的分布式数据库技术，跟应用服务的技术架构差了半步，但从最终发展趋势来看，分布式数据库一定会成为主流数据库。

单机数据库
自 1970 年 IBM 的研究员 E.F.Codd 博士提出关系模型以来，关系模型经过几十年得到了充分的发展，并成为数据库的主流模型。这几十年也造就了 Oracle、DB2、MySQL、PG 等知名单机数据库产品。

单机数据库使用方便，单个节点维护成本较低，保证 ACID 特性（ACID 是Atomic 原子性，Consistency 一致性，Isolation 隔离性，Durability 持久性），但随着业务量增长，面对高并发读写、海量数据高效率处理显得力不从心，不断提升单个节点的规格终究会遇到天花板，摩尔定律无法赶上和业务增长规模。

文章图片

对于计算机时代的史前产品，放一张黑白图片示例

分库分表
单机数据库无法承载高并发和海量读写等任务时，分库分表方案开始斩露头角，到目前为止依然方兴未艾，分库分表的方案解决了快速业务增长所带来的高并发访问问题，同时对于海量读写也通过分而治之的手段得以满足。典型代表中间件包括 TDDL、Sharding-JDBC、MyCat 等。

通过对目前主流的一些云数据库产品调研，我们发现目前大多云上的分布式数据库，基本都是 MySQL、PG 为内核的二次开发的分库产品，搭配 ZooKeeper、etcd 等分布式组件，将多个数据库实例管理起来，达到形似分布式的数据库产品。本质上来讲，跟应用连接多个数据库类似，只是下移元数据管理到单独组件，实际使用上就会发现 ACID 无法保证，快速业务发展需要拆分实例数据迁移等高投入运维工作。

分布式数据库
到了 21 世纪，分布式数据库的概念开始提出，相比较传统数据库和非关系型数据库 NoSQL，新一代数据库成为 NewSQL 数据库，这类数据库承载了传统数据库和 NoSQL 数据库的功能和优点，将两者完美结合，既能保证 ACID 特性，又能解决分布式扩展能力，保证海量存储的同时也能达到高可用高效率的目标。

21 世纪早期，分布式数据库已经有了一些雏形，以 Shared Storage 为典型代表 Oracle 的 RAC，将计算节点分布式处理，可以看作是分布式数据库的一个尝试，毕竟高端存储硬件不是一般企业能负担的起，而且存储层依然无法横向扩展。

2012 年 Google 发布 Spanner，因其代码闭源，只能通过论文一窥究竟，Shared Nothing、Paxos、ACID、MVCC 等基本确立了分布式数据库的主流架构模型。

文章图片

在众多分布式数据库选型中，TPCC 榜单的 OceanBase 进入了我们视线，连续两年 TPCC 测试第一，超越 Oracle 性能 20 多倍着实亮眼。同时经过了解，OceanBase 数据库是完全自主研发的分布式数据库，不是基于其他内核产品的包装品，这一点也是我们准备测试 OceanBase 的重要原因。

文章图片

选型验证 OceanBase 基于数据库的发展趋势，利楚作为创新型互联网企业，始终紧跟技术发展步伐，不断迭代平台架构，才能不断提升服务质量，应对持续增长的业务发展。因此，基于对分布式数据库的研究，我们选择 OceanBase 进行测试验证，基于我们的业务进行测试，也是对分布式数据库产品的初探。

对于 OceanBase 其实并不陌生，在 2019 年已经与 OceanBase 团队进行过交流，当时经过初步了解后，发现对于我们的数据迁移和运维管理提出了一些挑战，成本和风险让我们暂时搁置。时隔两年，再次见到 OceanBase 团队感觉很亲切，同时也希望这两年的沉淀，可以为我们带来不一样的产品。

高兼容
应用切换数据库，不仅仅是换个数据库驱动这么简单，驱动只是解决应用与数据库的通信协议，数据库对于 SQL 的兼容程度，直接影响了我们业务迁移的改造成本，OceanBase 一套集群同时支持 Oracle 和 MySQL 两种模式，在我们调研中的众多数据库中也是唯一的一款。

文章图片

本次兼容性评估，OceanBase 提供了 OMA 迁移评估工具，能够在数据迁移前对数据库进行全面扫描，做到有的放矢。通过 OMA 评估工具，我们直接评估了测试库的结构和 SQL 的兼容度，同时还可以通过代码扫描来分析应用中的 SQL，对于不兼容项可以通过评估报告提供详细说明和改进建议。

文章图片

通过命令行模式的结构迁移评估，很快生成了评估报告，根据评估报告的非兼容项，我们还发现了两处非标语法，消除兼容性隐患。

文章图片

OMA 还支持代码扫描评估，直接本地通过 OMA 工具进行代码扫描，避免将核心代码泄漏，兼容度分析 100%，在实际应用接入测试中发现评估报告比较准确，当然前提是确保 perfomance_schema 中的 SQL 覆盖了我们业务的所有 SQL。

OMA 工具易用，评估准确，给 OceanBase 点个赞。

高压缩比
经过评估之后，我们通过 OMS 迁移工具梳理迁移了多份数据进行测试对比，不得不提一下 OMS，几步配置操作即可拉取迁移，整个操作流程非常简单易用。

文章图片

在迁移完成后，我们特意对比了数据库存储差异，对于一个数据为核心业务的公司，数据的存储成本日益高涨，OceanBase 存储压缩率确实让我们感到意外，超高的压缩比可以极大地节约存储成本。下图中是一个 300GB+ 的宽表的存储对比，而对于整库的存储压缩率更是达到了 70% 以上。

文章图片

业务库表的存储对比

OceanBase 的高压缩比不仅仅是传统的 zlib、lz4 等压缩算法，还有编码、差值算法等高级压缩，相比较传统压缩算法又提供了更极致的压缩比，如此高的压缩比着实令人出乎意料。

HTAP
OceanBase 数据库不仅仅是一个 TP 关系型数据库，其主打的 HTAP 也是我们比较看中的特性，对于利楚的支付场景，支付交易订单量巨大，且业务规模快速增长，在进行联机交易的同时，我们希望能够有一些实时的统计分析，比如合作商家统计查询近期的交易汇总信息，对于查询时效也是服务体验的重要一环。

基于此目的，我们详细对比了我们现有数据库和 OceanBase 的 TP 和 AP 能力，验证在保证支付业务稳定的场景下，是否能够提供实时的统计查询能力。我们通过一个 4.9 亿+条数据的宽表，通过不同场景的统计分析 SQL 进行对比，OceanBase 查询性能较为出众，TP 性能如 TPCC 榜首一样，高并发高性能的保障，同时 HTAP 混合引擎也提供了实时的数据分析能力。

文章图片

4.9 亿+表的会员统计汇总分析，执行时间对比

通过真实业务 SQL 的执行对比，OceanBase 的表现再次超出预期。

文章图片

业务初探 OceanBase
通过不同场景的测试验证，OceanBase 不仅满足我们对分布式数据库的要求，其性能和高存储压缩比也出乎意料。

我们首先选择了一个创新业务“来合伙”进行迁移割接。这个业务上线时间不长，但业务增长迅猛，高速增长的业务对数据库也是极大挑战，不知道哪一天出现突发增长，对于传统 MySQL 即使分库分表都来不及拆表迁移。

数据迁移过程中再次发挥了 OMS 的作用，不仅仅支持数据的全量迁移，同时支持结构迁移、全量校验、增量迁移、反向同步等功能。全量校验对于支付场景对我们非常有帮助，节省我们开发校验程序的工作，同时还保障了数据迁移的准确性。增量迁移能够与源库保持实时同步，为我们业务验证提供了一个窗口期进行充分验证，确保割接上线的稳定。

文章图片

通过数据全量数据迁移，其中一个逻辑库的存储压缩对比，“来合伙”业务基本压缩率在 26.4%，符合之前的测试预期。

文章图片

来合伙某个逻辑库迁移前后对比，从 11.06GB 存储降到 2.92GB

在迁移割接过程中，应用代码仅仅需要修改配置文件，切换数据源，OceanBase 对 MySQL 协议的兼容性完全不需要更换驱动等。同时基于之前的OMA 评估报告，对于应用的验证也非常顺利，OceanBase 对 MySQL 语法的兼容度也降低了数据库的切换门槛。

迁移后，通过 OceanBase 的云服务平台，监控 CPU、TPS、QPS 等性能，同时还可以设置告警，保障服务 SLA，实时诊断功能更是给 DBA 提供了一套“利器”，慢 SQL 查询、TopSQL 查询，甚至还可以在不改动业务代码的同时，对慢 SQL 进行索引绑定等操作，极大提高了数据库运维效率。

文章图片

在 OceanBase 生态工具的加持下，首个业务顺利完成迁移，同时对线上持续监控，目前业务平稳运行，后续利楚会逐步迁移其他业务线迁移割接到 OceanBase，拥抱分布式数据库时代，享受分布式数据库带来的技术红利！

后记（架构师感悟）
OceanBase解决方案架构师周贵卿（花名：曜松）：
再会利楚近两载，虽然当年没有能够让利楚倾心，但是两年的时间 OceanBase 各类生态产品取得了突破性进展，各类周边配套产品从客户实际问题出发，解决评估、迁移、运维等一系列问题，本次测试验证不论从数据库还是生态产品都得到了客户的认可，也是我们“把简单留给客户，把复杂留给自己”的践行。
针对利楚高流量高并发业务场景，在评估迁移过程中，结合蚂蚁最佳实践，对核心数据库表结构进行了部分优化，实现了业务代码零改造的同时，提供了数据库扩展能力和性能的提升。
【最佳实践|意出望外的一次相遇｜利楚初探 OceanBase】利楚首个业务落地 OceanBase 仅仅是一个开端，对于其他业务，尤其支付的海量数据，我们会与利楚一道共同努力，希望通过 OceanBase 为客户带来迁移一键式、运维一体化、HTAP 一套库的服务体验。