编者按：科大讯飞在2021年关注原生分布式数据库，并于2023年在核心业务落地OceanBase，实现了业务稳定运行、灵活扩缩容，以及一套系统处理TP和AP业务且互不影响。并带来了意外收获，即存储成本下降50%、运维复杂度极大简化。科大讯飞数据库团队负责人李梦嘉分享了此次数据库方案升级的经验。
探索原生分布式数据库
科大讯飞是亚太地区知名的智能语音和人工智能上市企业（股票代码：002230）。自成立以来，一直从事智能语音、自然语言理解、计算机视觉等核心技术研究并保持了国际前沿技术水平。2023年，我们上线了一个非常重要的业务。初上线时整体业务量很小，经历一段时间的服务对外发布和9月份的推广后，业务量呈现爆发式增长。
该业务的数据存储于MySQL中，随着业务量的增长，数据量和磁盘占用几乎直线攀升：
- 该业务数据量极大，且每一次用户交互都会生成一条记录，仅半年，最核心的大表已有7亿条数据。
- 业务数据增长速度极快。预估年增量5TB左右。
由于业务数据海量且增速飞快，同时该业务的报表有多维度、实时性的分析需求，以供业务决策，因此，我们很快就发现MySQL已经无法满足业务需求，亟需转向关注已久的原生分布式数据库方案。
当然，推动数据库方案替换的因素还包括一些已知痛点。众所周知MySQL分库分表方案具备横向扩展能力，能够提升整体集群的读写负载。我们使用MySQL的业务较多，运维架构也非常成熟，然而，MySQL对业务有侵入，需要改造业务，分库分表也给整体运维增加了工作量。由于新业务更新迭代快速，频繁有大表上线和更新操作，以及业务处于关键阶段，希望尽可能减少改造代价。如果继续使用分库分表方案，需要去做相应适配改造工作，增加了许多额外的工作量，无奈当下没有时间和精力改造。
综合考虑下，我们选择原生分布式数据库方案，并希望新方案能够解决三方面的问题：
1．可扩展性。高度可扩展的数据存储及处理能力能够适应大规模数据增长和高并发访问需求。
2．可维护性。完善的生态工具帮助我们简化数据库管理与维护任务，降低数据库的维护成本和复杂度。
3．HTAP能力。即混合负载与读写分离，在一套系统中实现TP与AP业务需求。
那么，为什么会选择OceanBase，以及OceanBase能帮助科大讯飞解决哪些问题呢？
方案探索，为何选择OceanBase
我们从2021年就关注OceanBase，经过两年的调研与了解，我们分析其特性满足科大讯飞新业务的数据库需求，
1.扩展性。
OceanBase是一个基于分布式的可扩展架构，内部有很多节点，且节点之间是对等的，通过把集群部署在多个可用区，可以实现故障的隔离和快速恢复。
OceanBase可扩展性主要体现在两个方面。一方面是Zone内扩展，当业务量快速增长，集群资源无法满足性能要求时，可以选择在Zone内进行扩节点，通过在每个可用区增加节点来提升整个集群的对外服务能力。另一方面是水平扩展Zone，因为OceanBase内部数据都是有多副本的，这些副本分布在每个可用区，比如少数可用区有故障，剩余副本可以保证集群仍然提供服务。通过增加可用区的数量，可以提升整体集群的容灾能力。
无论是Zone内扩展，还是水平扩展Zone，都可以在线动态完成，对业务完全透明。
2.可维护性。
OceanBase提供了丰富的工具生态（400+），其中自研的OCP管理平台提供了如下能力。
- IaaS资源管理：地域管理、机房管理、主机管理等。
- 租户管理：数据库管理、会话管理、参数管理、租户创建和删除，以及租户扩容、缩容、Zone 优先级。
- 软件包管理：上传、下载、存储。
- Proxy管理：集群新建、接管、删除、升级、扩容、缩容、参数管理。
- 备份恢复：数据备份、日志备份、备份清理、二次备份、恢复/抽检。
- 集群管理：集群新建、删除、升级、扩缩容、监控和告警，以及合并管理、参数管理、 Unit 管理。
OCP管理平台几乎涵盖了所有的运维任务，其中，将黑屏的运维操作转变为白屏的运维操作，极大地简化了运维的整体工作量。
此外，OceanBase的在线DDL增强功能出乎意料。众所周知，大表DDL操作是MySQL运维的痛点，虽然MySQL在5.6版本后做了优化，但仍无法覆盖很多使用场景。因此，在线上做MySQL大表DDL操作，一般需要三个工具，特别是上亿级大表在夜间执行时，耗时很长。OceanBase实现了基于业务请求优先的分布式在线DDL，使得在MySQL中执行时间超长的操作，在OceanBase中秒级完成。
3. HTAP能力。
绝大多数的数据库，AP能力和TP能力是完全分开的，通常部署在两套系统中，即线上有一套TP系统，需要把数据抽取到AP系统进行分析。OceanBase实现了一套引擎同时支持TP能力和AP能力，且数据插入立即可见，其资源隔离能力可使TP处理与AP请求互不干扰，避免业务间产生影响。
此外，OceanBase在OLTP方面的能力已经在连续10年的“双11”和支付宝业务中得到验证，在OLAP方面具备复杂查询优化、秒级低时延响应、水平线性扩展（千/亿级数据关联查询）的能力。
为了确保OceanBase集群能够满足我们的业务需求，在调研之外，我们也对OceanBase进行了性能测试。
4.性能测试。
我们采用业界通用的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%左右，极大地节省存储成本。
5.协议兼容性与数据迁移。
除了上述业务需求点的验证，我们还关心两个核心问题。第一个问题是和MySQL的协议兼容性，我们希望平滑的从MySQL迁移至OceanBase，不需要过多改造。我们发现OceanBase完全兼容MySQL协议，上层业务无需代码改造即可完全切换。第二个问题是数据迁移，因为业务系统非常重要，对外提供7×24小时服务，所以给我们的迁移切换窗口时间比较短。据我们了解，通过OceanBase提供的OMS数据同步工具可以完成MySQL到OceanBase的准实时同步，再结合中间层的流量切换可以迅速将业务从MySQL切到OceanBase，缩短了我们预期的停机迁移时间。
6.小结。
总的来说，在调研和验证阶段，OceanBase完全满足我们的需求。
- 可扩展性：OceanBase可以根据业务增量进行动态垂直水平扩缩容。
- 可维护性：OceanBase的OCP平台可将黑屏运维变为白屏运维，简化运维工作，降低运维工作量；在线DDL秒级完成。
- HTAP能力：一套系统同时支持TP和AP业务，解决二者不能拆分的问题，且资源隔离，互不影响。
- 其他能力：完全兼容MySQL协议，业务方无需改造代码，迁移平滑；OMS工具异构同步，可解决数据迁移问题；OceanBase存储成本为MySQL的一半。
从MySQL到OceanBase的切换流程
在正式上线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的架构和原理，并做了一些管理和维护的技能储备和大量测试工作。为了应对生产环境中无法预知的风险，我们也设计了一套高可用容灾架构。
然而上线过程中还是碰到了问题。我们刚上线OceanBase4.1版本时，开发人员反馈统计的结果集错误，和OceanBase官方取得联系后，通过临时加hint的方式解决了该问题。除了验证问题，在大表、DDL同步时也出现了OMS数据同步异常的问题，在系统升级到4.2.1版本后，问题已被完全解决。
OceanBase稳定运行半年，业务收益总结
从上线至今，OceanBase已稳定运行半年时间，我们总结了本次数据库方案切换带来的收益。
第一，业务稳定运行。OceanBase是基于Paxos的原生分布式架构，完全消除了单点风险，为上层业务提供了非常稳定的特性。
第二，灵活扩缩容，业务无感知。OceanBase可以动态的垂直、水平扩展，且对上层业务完全透明。
第三，可维护性提升，运维工作简化。OceanBase提供了OCP管理平台，所有运维工作可通过平台进行操作，极大地降低了运维工作量。
第四，存储降本50%。根据我们对OceanBase的实测数据，它的数据压缩率是MySQL的50%左右，能够帮助我们节省一半的存储成本，该数据非常可观。
第五，业务平滑迁移。OceanBase完全兼容MySQL协议，业务方不需要过多改造代码，为我们节省了很多开发成本。同时，OMS数据同步工具帮助我们顺利地将数据从MySQL迁移到OceanBase。
第六，便捷的HTAP能力。OceanBase通过一套引擎同时支持在线事务和统计分析，帮助我们省去了建设AP的费用。
后续，科大讯飞将在业务内扩展OceanBase应用范围，并加深与OceanBase的合作。
