核心大表7亿数据，查询性能快40倍！科大讯飞HTAP探索实践

科大讯飞在 2021 年关注原生分布式数据库，并于 2023 年 7 月在核心业务落地 OceanBase，实现了业务稳定运行、灵活扩缩容，以及一套系统处理 TP 和 AP 业务且互不影响。并带来了意外收获，即存储成本下降 50%、运维复杂度极大简化。科大讯飞数据库团队负责人李梦嘉分享了此次数据库方案升级的经验。

科大讯飞是亚太地区知名的智能语音和人工智能上市企业。自成立以来，一直从事智能语音、自然语言理解、计算机视觉等核心技术研究并保持了国际前沿技术水平。2023 年 4 月，科大讯飞上线了一个非常重要的业务，在初上线时整体业务量很小，经历 5 月份的服务对外发布和 9 月份的推广后，业务量呈现爆发式增长。

该业务的数据存储于 MySQL 中，随着业务量的增长，数据量和磁盘占用几乎直线攀升：

• 该业务数据量极大，且每一次用户交互都会生成一条记录，仅半年，最核心的大表已有 7 亿条数据；

• 业务数据增长速度极快。日增量千万级，预估年增量 5TB 左右。

由于业务数据海量且增速飞快，同时该业务的报表有多维度、实时性的分析需求，以供业务决策，因此，我们团队很快就发现 MySQL 已经无法满足业务需求，亟需转向关注已久的原生分布式数据库方案。

当然，推动数据库方案替换的因素还包括一些已知痛点。众所周知 MySQL 分库分表方案具备横向扩展能力，能够提升整体集群的读写负载。科大讯飞使用 MySQL 的业务较多，运维架构也非常成熟，然而，MySQL 对业务有侵入，需要改造业务，分库分表也给整体运维增加了工作量。由于新业务更新迭代快速，频繁有大表上线和更新操作，以及业务处于关键阶段，希望尽可能减少改造代价。如果继续使用分库分表方案，需要去做相应适配改造工作，增加了许多额外的工作量，无奈当下没有时间和精力改造。

综合考虑下，我们选择原生分布式数据库方案，并希望新方案能够解决三方面的问题：

• 可扩展性。高度可扩展的数据存储及处理能力能够适应大规模数据增长和高并发访问需求。

• 可维护性。完善的生态工具帮助我们简化数据库管理与维护任务，降低数据库的维护成本和复杂度。

• HTAP 能力。即混合负载与读写分离，在一套系统中实现 TP 与 AP 业务需求。

那么，为什么会选择 OceanBase，以及 OceanBase 能帮助科大讯飞解决哪些问题呢？

我们从 2021 年就关注 OceanBase，经过两年的调研与了解，我们分析其特性满足科大讯飞新业务的数据库需求，

（一）扩展性

OceanBase 是一个基于分布式的可扩展架构，内部有很多节点，且节点之间是对等的，通过把集群部署在多个可用区，可以实现故障的隔离和快速恢复。

OceanBase 可扩展性主要体现在两个方面。一方面是 Zone 内扩展，当业务量快速增长，集群资源无法满足性能要求时，可以选择在 Zone 内进行扩节点，通过在每个可用区增加节点来提升整个集群的对外服务能力。另一方面是水平扩展 Zone，因为 OceanBase 内部数据都是有多副本的，这些副本分布在每个可用区，比如少数可用区有故障，剩余副本可以保证集群仍然提供服务。通过增加可用区的数量，可以提升整体集群的容灾能力。

无论是 Zone 内扩展，还是水平扩展 Zone，都可以在线动态完成，对业务完全透明。

（二）可维护性

OceanBase 提供了丰富的工具生态（400+），其中自研的 OCP 运维管理工具提供了如下能力。

• IaaS 资源管理：地域管理、机房管理、主机管理等。

• 租户管理：数据库管理、会话管理、参数管理、租户创建和删除，以及租户扩容、缩容、Zone 优先级。

• 软件包管理：上传、下载、存储。

• Proxy 管理：集群新建、接管、删除、升级、扩容、缩容、参数管理。

• 备份恢复：数据备份、日志备份、备份清理、二次备份、恢复/抽检。

• 集群管理：集群新建、删除、升级、扩缩容、监控和告警，以及合并管理、参数管理、 Unit 管理。

OCP 运维管理工具几乎涵盖了所有的运维任务，其中，将黑屏的运维操作转变为白屏的运维操作，极大地简化了运维的整体工作量。

此外，OceanBase 的在线 DDL 增强功能出乎意料。众所周知，大表 DDL 操作是 MySQL 运维的痛点，虽然 MySQL 在 5.6 版本后做了优化，但仍无法覆盖很多使用场景。因此，在线上做 MySQL 大表 DDL 操作，一般需要三个工具，特别是上亿级大表在夜间执行时，耗时很长。OceanBase 实现了基于业务请求优先的分布式在线 DDL，使得在 MySQL 中执行时间超长的操作，在 OceanBase 中秒级完成。

（三）HTAP 能力

绝大多数的数据库，AP 能力和 TP 能力是完全分开的，通常部署在两套系统中，即线上有一套 TP 系统，需要把数据抽取到 AP 系统进行分析。OceanBase 实现了一套引擎同时支持 TP 能力和 AP 能力，且数据插入立即可见，其资源隔离能力可使 TP 处理与 AP 请求互不干扰，避免业务间产生影响。

此外，OceanBase 在 OLTP 方面的能力已经在连续 11 年的“双 11”和支付宝业务中得到验证，在 OLAP 方面具备复杂查询优化、秒级低时延响应、水平线性扩展（千/亿级数据关联查询）的能力。

为了确保 OceanBase 集群能够满足我们的业务需求，在调研之外，我们也对OceanBase进行了性能测试。

（四）性能测试

我们采用业界通用的 tpmC 性能压测工具，在生产环境分别对 OceanBase 三节点集群、MySQL 单实例、MySQL 分库分表进行压测（压测配置：硬盘SSD/96C/384G）。结果显示：在并发数小于 64 时，OceanBase 性能略低于  MySQL 方案 ；超过 128 并发后，OceanBase 性能优势显著。且随着并发的不断增长，OceanBase集群性能可以持续提升，而 MySQL 性能在 256 并发时达到顶峰，随后出现拐点，无法继续提升。

除 OLTP 性能压测外，我们也将系统中查询最耗时的一些统计抓取出来，分别在 MySQL 和 OceanBase 测试对比。结果表示，根据业务 SQL 的复杂程度不同，OceanBase 较 MySQL 的性能提升 7~40 倍。

在压测过程中，我们也验证了 OceanBase 相较于 MySQL 的数据压缩能力，经过生产环境实测，OceanBase 三副本压缩后的数据大概是 MySQL 的 50% 左右，极大地节省存储成本。

（五）协议兼容性与数据迁移

除了上述业务需求点的验证，我们还关心两个核心问题。第一个问题是和 MySQL 的协议兼容性，我们希望平滑的从 MySQL 迁移至 OceanBase，不需要过多改造。我们发现 OceanBase 完全兼容 MySQL 协议，上层业务无需代码改造即可完全切换。

第二个问题是数据迁移，因为业务系统非常重要，对外提供 7×24 小时服务，所以给我们的迁移切换窗口时间比较短。据我们了解，通过 OceanBase 提供的 OMS 数据同步工具可以完成 MySQL 到 OceanBase 的准实时同步，再结合中间层的流量切换可以迅速将业务从 MySQL 切到 OceanBase，缩短了我们预期的停机迁移时间。

（六）小结

总的来说，在调研和验证阶段，OceanBase 完全满足我们的需求。

• 可扩展性：OceanBase 可以根据业务增量进行动态垂直水平扩缩容。

• 可维护性：OceanBase 的 OCP 运维管理工具可将黑屏运维变为白屏运维，简化运维工作，降低运维工作量，在线 DDL 秒级完成。

• HTAP 能力：一套系统同时支持 TP 和 AP 业务，解决二者不能拆分的问题，且资源隔离，互不影响。

• 其他能力：完全兼容 MySQL 协议，业务方无需改造代码，迁移平滑；OMS 工具异构同步，可解决数据迁移问题；OceanBase 存储成本为 MySQL 的一半。

在正式上线 OceanBase 前，我们做了很多准备工作。

首先，搭建了OceanBase 的测试环境，并和开发侧验证了适配性和兼容性，以及确保 OLAP 和 OLTP 性能可以满足线上业务需求。

其次，在数据迁移阶段，验证了 MySQL 到 OceanBase 的 OMS 同步方案，并完成 MySQL 到 OceanBase 的数据同步和校验。为了应对迁移后无法预知的风险，我们还制定了回滚方案，以防出现问题时可以切回 MySQL。同时，在运维侧验证了 OceanBase 管理、高可用方案、应急预案等。

最后，我们和业务侧一起完成了从 MySQL 到 OceanBase 的上线，过程较为顺利。上线后运维侧会做一些常规的服务保障工作，如性能优化、监控管理、备份恢复等，保障 OceanBase 集群能够持续、稳定地运行。

下图是 MySQL 到 OceanBase 的切换流程图。切换前 MySQL 架构是一个主从的高可用架构，前端通过 ProxySQL 作为入口；切换后的架构是三节点的 OceanBase 集群，通过 Haproxy 作为入口及前端的负载均衡。我们将 Haproxy 前端代理端口和 MySQL 集群的 Haproxy 端口设置保持一致，在正式迁移前，通过 OMS 的实时同步功能把 MySQL 的数据迁移到 OceanBase。同时，做两个集群间的数据验证，包括两个集群的用户信息同步。在正式切换时只需把业务连接的 VIP 地址从 MySQL 集群切换到 OceanBase 集群即可，上层业务基本无感知。

在 OceanBase 上线后（架构见下图），MySQL 和 OceanBase 并行运行了一段时间，我们也配置了生产 MySQL 到 OceanBase 集群的反向同步。目的是预防 OceanBase 集群和 MySQL 不兼容问题，到时可快速将业务切回 MySQL，不过这一问题并未出现。

为了进一步提升整体系统的可用性，我们搭建了 OceanBase 容灾集群。容灾集群起到备份作用，如果生产集群出现故障无法恢复，我们可以快速切换到容灾集群，保证系统高可用。

由于整个上线过程所用时间较短，以及我们对 OceanBase 实操经验的不足，因此，我们提前了解 OceanBase 的架构和原理，并做了一些管理和维护的技能储备和大量测试工作。为了应对生产环境中无法预知的风险，我们也设计了一套高可用容灾架构。

然而上线过程中还是碰到了问题，我们刚上线 OceanBase 4.1 版本时，开发人员反馈统计的结果集错误，和 OceanBase 官方取得联系后，通过临时加 hint 的方式解决了该问题。除了验证问题，在大表、DDL 同步时也出现了 OMS 数据同步异常的问题。目前，在系统升级到 4.2.1 版本后，问题已被完全解决。

从上线至今，OceanBase 已稳定运行半年时间，我们总结了本次数据库方案切换带来的收益。

第一，业务稳定运行。OceanBase 是基于 Paxos 的原生分布式架构，完全消除了单点风险，为上层业务提供了非常稳定的特性。

第二，灵活扩缩容，业务无感知。OceanBase 可以动态的垂直、水平扩展，且对上层业务完全透明。

第三，可维护性提升，运维工作简化。OceanBase 提供了 OCP 运维管理工具，所有运维工作可通过其进行操作，极大地降低了运维工作量。

第四，存储降本 50%。根据我们对 OceanBase 的实测数据，它的数据压缩率是 MySQL 的 50% 左右，能够帮助我们节省一半的存储成本，该数据非常可观。

第五，业务平滑迁移。OceanBase 完全兼容 MySQL 协议，业务方不需要过多改造代码，为我们节省了很多开发成本。同时，OMS 迁移工具帮助我们顺利地将数据从 MySQL 迁移到 OceanBase。

第六，便捷的 HTAP 能力。OceanBase 通过一套引擎同时支持在线事务和统计分析，帮助我们省去了建设 AP 的费用。

后续，科大讯飞将在业务内扩展 OceanBase 应用范围，并加深与 OceanBase 的合作。