本文作者：贾万利，北京数维原动教育科技

业务背景

作为国内专注于高端教育评估的机构，北京数维原动教育科技有限公司，其核心业务聚焦于中小学学校的诊断、评估与提升工作。自2009年起，公司便踏上了自主研发之路。经过十余载的不懈努力，已成功构建了一套针对基础教育阶段的全面学校诊断体系，涵盖了从理论探索到实践应用，再到模型构建、流程优化以及结果反馈的完整闭环。同时，依托互联网技术，公司自主研发了独特的诊断工具、数据分析平台及报告生成系统，旨在为学校提供更为全面、个性化的支持。迄今为止，公司已为国内众多知名中小学提供了专业、精细化的学校诊断评估与管理咨询服务，在学校教学改进、学生个性发展以及学校部门工作优化等方面发挥了显著作用，并赢得了项目合作学校的高度认可与赞誉。

业务痛点

近两年，随着业务的发展，原有的底层数据库管理系统压力越来越大。最初在线业务平台和后台分析平台我们均使用的MySQL数据库，云端在线业务还好，但是后台分析平台和报告报表系统随着数据量越来越大性能下降严重，增加表分区之后相对好一些，但是系统扩展性及单机性能瓶颈和安全性始终让人担心，可能无法应付接下来快速发展的业务。所以开启了探索MySQL的替代方案。由于拥有大量的人工制作的报表，所以必须完美兼容MySQL语法，否则成百上千的报表重新制作将会是一场“灾难”。

调研和选型

选型之路，很长也很难。

尝试中间件

MyCat是一个支持多种类型数据库的分片中间件，它支持多种类型数据库的分片，易扩展。但MyCat也存在一些缺点：

• 在整个系统中，MyCat会成为一个单点，所有的SQL都会通过MyCat来路由，在数据库比较多的情况下，MyCat本身的CPU性能压力就会随之增大。
• 不够通用，数据库连接的处理复杂，对业务不够透明，处理复杂分库分表中间件MyCat模式通过中间代理层（MyCat）来统一管理所有的数据源，后端数据库集群对前端应用程序透明。

所以综合考虑后放弃了MyCat。

ShardingSphere 是一个开源的分布式数据库中间件，优点明显：

• 强大的分片和路由功能：支持多种分片算法和路由策略，能够灵活地将数据分布到多个数据库节点上。
• 丰富的数据库支持：支持多种类型的数据库，包括 MySQL、Oracle、SQL Server 等。
• 高可用性和可扩展性：支持主从复制和数据备份，提供了高可用性和数据可靠性。同时，它可以轻松地进行水平扩展，以适应不断增长的数据量和并发请求。
• 灵活的配置和管理：提供了丰富的配置选项和管理工具，可以方便地进行分片、路由、数据迁移等操作。

在没有尝试OceanBase之前我们决定准备使用ShardingSphere。但最终选择OceanBase数据库是由于其原生分布式架构，无需中间件。

尝试Greenplum

Greenplum我们之前有一些业务在使用，还是很稳定的，但是它的语法是基于PostgreSQL 的，和MySQL的语法差异很大，我们需要的是可以兼容MySQL的，所以放弃了Greenplum。

尝试Doris

Apache Doris 是一个基于 MPP 架构的高性能、实时的分析型数据库，以极速易用的特点被人们所熟知，仅需亚秒级响应时间即可返回海量数据下的查询结果，不仅可以支持高并发的点查询场景，也能支持高吞吐的复杂分析场景。看到官网介绍后，我们进行了测试，性能很能打，强悍，亿级的数据也可以秒回，可以满足我们即席查询的需求，其架构也简单，我们当时测试的1.x版本，发现还是有一些聚类分析以及其他不常用的MySQL函数不能兼容，BI系统一执行常规报表没问题，但是总有一些报表报异常信。如果我们是新项目或者报表重新制作也许会选择Doris。

尝试SequoiaDB

巨杉数据库，常用于金融领域，高性能与无限水平弹性扩展能力很好，官网也称完全兼容传统关系型数据，通过测试也还是不能完美兼容MySQL所以放弃。

尝试OceanBase

一次偶然的机会，看到OceanBase 4.1.0发布了，高度兼容 Oracle 和 MySQL，能够随着业务发展快速的扩容缩容。主要有以下优点。

高兼容，高度兼容 Oracle 和 MySQL，覆盖绝大多数常见功能，支持过程语言、触发器等高级特性，提供自动迁移工具，支持迁移评估和反向同步以保障数据迁移安全，可支撑金融、政府、运营商等关键行业核心场景替代。

水平扩展，实现透明水平扩展，支持业务快速的扩容缩容，同时通过准内存处理架构实现高性能。支持集群节点超过数千个，单集群最大数据量超过 3PB，最大单表行数达万亿级。

低成本，基于 LSM-Tree 的高压缩引擎，存储成本降低 70% - 90%；原生支持多租户架构，同集群可为多个独立业务提供服务，租户间数据隔离，降低部署和运维成本。

实时 HTAP，基于“同一份数据，同一个引擎”，同时支持在线实时交易及实时分析两种场景，“一份数据”的多个副本可以存储成多种形态，用于不同工作负载，从根本上保持数据一致性。

初步阅读文档后，感觉高可用没有问题，但是对于MySQL的兼容性还是没有太大信心。毕竟前面尝试很多方案都已折戟沉沙。

功能和兼容性测试

我们计划先部署 OceanBase 演示环境，看看效果。基于官网文档，简单几行命令很顺利的在本地虚拟机中安装好了测试环境，而且对机器配置要求也不高

项目	描述
系统	CentOS Linux 7.6 版本
CPU	4 核。
内存	8 GB
磁盘类型	使用 SSD 存储。
磁盘存储空间	100GB。
文件系统	XFS
all-in-one 安装包	all-in-one 安装包需选择 V4.1.0 及以上版本。

导入数据后，基于我们当时的报告系统，跑了一套报告，想不到在没有做任何修改的情况下完美生成了我们的报告文件，这说明我们使用的BI系统和其中几千个报表是可以完美兼容OceanBase的，很兴奋，因为在尝试很多方案后，终于找到一款应该可行的方案，能够兼容我们各种各样的复杂的统计语句。

于是，我们很快申请了较高配置的虚拟机，开始正式进行功能性和兼容性测试

当我们将MySQL中的数据全部迁移到OceanBase中，发现节省了很多的磁盘空间，MySQL中401.5G到OceanBase中也就44.7G，后来阅读官方文档才知道OceanBase 数据库的存储引擎是基于 LSM-Tree 架构，具有高压缩率，同时将数据分为静态基线数据（放在 SSTable 中）和动态增量数据（放在 MemTable 中）两部分保证性能。

在安装OceanBase，以及创建资源池，租户，数据库，用户等等对象时，操作简单，文档清晰，所以上手很容易，也很顺利。

随后，我们开始大量的测试，其中也遇到了一些问题，如部分SQL语句的性能问题，通过和社区人员以及钉钉群中的技术老师沟通都能很快得到解决，后来升级到4.2.1，稳定性也更好一些。

数据迁移

通过navicat、kettle、datax等工具可以实现快速迁移，性能，kettle测试1.2亿数据导入，8分钟完成，也可以使用mydumper和myloader。

迁移注意事项：

• 关闭自增主键属性，否则高并发导入时严重影响性能
• 索引和外键先关闭，导入数据后再建立
• 注意将字符集utf8替换为 utf8mb4
• 大表数据导入超时问题
  • 连接超时修改参数

show variables like '%ob_query_timeout%'; 修改为3600 000 000微秒

• • 写入超时修改参数

show variables like '%net_write_timeout%';  修改为600秒

总结

现在，我们分析平台的业务已经正式切到OceanBase上，经过一段时间的使用还是比较满意的，首先解决了MySQL中几亿数据的大表和多个表join关联分析卡死问题，其次对于单点故障的担忧也随之解决，对于数据库系统的安全性，高可用和扩展性有了保障，后期随着我们业务的快速发展，仅需要动态扩容就可以，对于我们数据库的运维人员压力骤减，最后也希望OceanBase发展越来越好！