客户之声｜客如云上线 OceanBase 小记

当一家业务遍布全国各地的头部 SaaS 服务商未来要服务百万商家时，作为 IT 系统基石的数据库该如何考量和选择变得尤为重要。今天，我们特别邀请了资深 DBA 李国标来给大家讲述 客如云上线 OceanBase 的故事。
李国标：拥有多年金融及互联网数据库运维管理经验，近年来服务于餐饮及新零售，致力于满足百万商家数智化服务需求的资深 DBA。
客如云是餐饮、零售、美业等服务业商家的数字化系统 SaaS 服务商，服务全国几十万家商户，帮助商家实现数字化、智能化升级。对于 IT 系统来说，大量的商户意味着高并发和海量的数据生成，基于海量数据为客如云构建了多层级报表应用以充分挖掘数据价值为客户提供服务。
随着业务的进一步发展，客如云开启了数据库新方案的寻路之旅。
为什么需要新方案
我们就海量数据的存储实践上，主要有以下三点原因：
海量数据逼近单实例存储上限
客如云的报表一级库在去年年底已用 85TB 空间，虽说会定期清理两年前的数据，但随着业务量的逐步增长，在不久的将来，两年的业务数据超过现用数据库的单库存储上限是必然事件，需要提前规划处理。更换存储引擎使用压缩可明显减少所需存储空间，查询/写入性能的衰减却是业务不能接受的，寻求全新的解决方案被提上日程。
降本增效是要求也是趋势
多个报表类业务的数据库在存储空间上都已经超过20TB，数据量还在以每月TB级别不断增长，也就导致了在数据存储上的高昂花费，且需不断的提高投入。
报表查询性能有待提高
既有数据库整体上对查询/写请求的处理表现良好且稳定，不过对于少量的报表类聚合查询，平均响应时间达秒甚更，尤其是某些查询不返回数据本应快速结束时，反执了超预期的时间，这个瑕疵影响服务质量的进步提升。
对新方案的预期
对于待选的新数据库，如果为了降低成本而影响了应用的服务质量，从业务的角度考量这是不能接受的；如果在解决面临问题的同时导致成本进一步升高，那么方案也不完美，客如云需要一个“鱼和熊掌兼得”的方案：
写入性能稳定
订单库数据流式处理后实时写入报表库，业务高峰期流量很大，写入延迟会导致消息积压进而影响服务质量，因此要求新方案在写入性能上不能低于现有的表现。
查询性能提升
对于少量的报表慢查询（执行时间>1s），新方案的表现应优于现状，在业务不断发展流量进一步增加的情况下，每日的慢查询数量低于当前数字。
综合成本降低
在业务需求被满足的同时，新方案的综合成本应有明显降低(≥20%)，契合集团和公司的整体战略。
为什么选择 OceanBase
通过和 OceanBase 技术团队的深入沟通，了解到 OceanBase 微块级别编码+压缩的特点对于缓解存储压力会有明显帮助，同时在读写性能和数据压缩比之间做了很好的平衡，也能确保满足业务需求。
从实际场景出发，客如云进行了大量的验证工作，如下两项结果决定了最终选择：

单副本存储空间节省 80%
测试中客如云挑选了一级库中两张大表对比迁移前后的存储空间占用：
报表慢查询性能显著提高
抽取慢 SQL 报表中的常见查询对比执行情况：

*注：结果一致率低于100%是因为未排序列在不同数据库上输出顺序不一致
如何不停机迁移
流式业务在线实现数据库的切换，经过和 OceanBase 解决方案架构师以及内部相关研发同学讨论后，通过如下四步实现了“开着飞机换引擎”：
OMS数据迁移
OMS 是 OceanBase 提供的数据迁移工具，支持多种异构数据存储和 OceanBase 间的全量迁移/增量迁移/全量校验/数据同步，迁移过程对源端库没有影响。
客如云先将源端数据以全量+增量方式迁移到 OceanBase，全量校验通过后，持续应用新生增量来保持和源数据库的数据一致。

*注：OMS 架构如上图
应用侧双写/停止OMS增量
业务研发调整代码新增连接 OceanBase 的数据源，将每次写入都转化为对源端和目标端的双写，开启后停止 OMS 任务的增量应用。
数据清理校验
由于开启双写和 OMS 增量停止应用之间有一个时间窗口，这期间对于目标端 OceanBase 来说其实写入操作进行了两次：首先是业务程序的写入，其次是 OMS 抓取到源端 binlog 后解析成对应的 SQL 语句并执行。
OMS 在增量应用的幂等性方面做了充分的考虑，绝大部分情况即使写入操作先后逻辑上重复执行也保证了数据一致，这里有一个特例是自增主键的新进数据，在不同的数据库上自增主键 ID 难以完全匹配，因此业务团队也编写了脚本基于业务逻辑校验/删除窗口期的重复数据并持续校验每天的数据。
切流
双写持续一段时间确认没有问题后，修改应用侧数据源到仅有 OceanBase，应用重启后完成切流上线。
使用 OceanBase 的收益
情理之中
报表一级库 85 TB 数据在迁移到 OceanBase 后只用了 14 TB 存储空间，不仅使存量数据所需空间大幅度减少，后续增量数据对新购空间的需求/压力也将同时降低；慢查询数据量减半；数据库成本下降 40%。
意料之外
大表上在线 DDL (主要是列添加)秒级完成，OceanBase 基于 LSM Tree 的存储架构和多版本 schema 管理让此类操作不再令人抓狂；索引的创建更快速，使用更灵活，曾经客如云调整 item info 表上的一个索引用了近 3 周的时间，在 OceanBase 上索引的创建默认并行执行，大表上索引的调整一天内即可搞定，同时借鉴 Oracle 的 invisible index 等特性，也让不同索引间的对比和选择特别方便。
产品建议/期待
分区表+全局索引场景持续优化
通过本次迁移实践，发现当分区表上有多个全局索引时 DML 操作的 CPU 消耗相比单表的情况还是有明显升高，全局索引是分区（分片）概念上的重要功能，因为业务逻辑要求下很难在分区表上只使用本地索引，单表又需面对难扩展的现实，内核层面对全局索引关于分区表上写入性能上进一步优化很有必要。期待 OceanBase 4.0 对此类场景的优化。
云上配套产品能力进一步完善
OceanBase 内核对支撑业务所提供的功能以及表现出来的性能都不错，云上配套产品如果参考阿里云 DAS 在一键诊断/ SQL 洞察等方面进行增强，使用体验会更好。
在降本提效的大背景下，OceanBase 的技术优势在合适场景为客户创造了价值，客如云也在积极寻找其余合适项目进行迁移，希望 OceanBase 产品能力进一步扩展和增强，在未来更多场景，可以带来更多可能。
后记（架构师感悟）
OceanBase 解决方案架构师孙鹏：为了保障迁移的顺利和上线后的稳定，前期充分的沟通探讨必不可少，在综合系统流量规律、读写分布、数据清理及流转需求等方面后力求最优方案。
客如云流量和数据量双高的应用特点对于 OceanBase 公有云上的产品配套是一次很好的检验和历练，经此一役，相关产品的能力得到验证，成熟度得以提高，为后续同类场景的迁移做好了准备。
高并发、大存储的 TP 场景本就是 OceanBase 的强势所在，3.X 版本在 HTAP 方向重点优化后，对应场景的实际表现也值得期待。