作业帮：探索多云架构下的数据库集群解决方案

导语：面对业务多元、数据海量、数据库种类多样、多云架构复杂等痛点，该如何制定既能解决问题又能降本增效的数据库升级方案？作业帮作为实践者，从四方面分享其数据库选型过程与思考。以下为作业帮DBA刘强在DTCC大会中的讲述。

嘉宾介绍：刘强，作业帮高级DBA。多年数据库运维经验，要负责MySQL、Redis、TiDB和 OceanBase 等不同数据库的使用与探索，数据库管理平台的开发工作。重点工作方向是分布式数据库在公司内部的推广和使用；配合业务部门进行需求测试以及方案落地。

作业帮数据库生态痛点及选型诉求

今天主要和大家分享作业帮在升级数据库方案时的选型思考，以及对 OceanBase 的尝试初体验。

大家都知道，作业帮作为在线教育的领军品牌之一，旗下有多款教育软件产品与硬件产品，而且每个产品背后的业务都有不同的特性和诉求。在这个背景下，我们的数据库状态呈现出五个特点。

数据库种类多样

为了更好地承接各类业务需求，作业帮使用不同的数据库产品来支撑不同的业务。目前使用的数据库主要有MySQL+Orch、Redis-Cluster、MongoDB、Elasticsearch、TiDB和 OceanBase。

业务需求多元

经过几年的沉淀，目前我们公司的在线教育相关软硬件业务线较多, 数据库的使用场景也越来越细分化，对数据处理的灵活性和高效性都提出了更多的要求。比如 MongoDB的Schema Design特性，对第三方信息的获取、Json格式文档存储提供了非常灵活高效的存取方式，再比如Elasticsearch在业务日志的存储分析、在大数据的快速聚合分析、基础运维指标的采集监控等场景都有明显优势。

多云架构复杂

作业帮是一个多云架构，在云原生的大背景下，作业帮使用阿里云、腾讯云、百度云三云架构。业务流量主要分布在腾讯云上，其次是阿里云和百度云。

我们选择多云的主要原因是保证业务的连续性，避免因云厂商的设施故障导致在线业务的中断；另外一个比较重要的原因是可以结合每个云厂商特有的优势，更好的为业务赋能。

同时这种多云环境对数据库的高可用架构提出了更高要求。

海量数据存储

相信很多MySQL用户都会遇到单机存储瓶颈带来的困扰，通常，解决办法要么是定期清理数据，要么分库分表，这都会给业务人员和DBA人员增加额外的工作。作业帮也不例外，解决单机存储问题是我们使用分布式数据库最基本的需求。

运维管理智能

很多公司会针对不同数据库来开发自己的运维管理平台，以提升对数据库管理的敏捷性和可靠性。而完善的运维管理平台对DBA人员来说，意味着一项复杂且周期较长的工作。

总结来说，业务场景的技术需求和企业降本增效的诉求驱动我们进行数据库方案的替换和升级，我们把目标瞄准在分布式数据库领域。

业务场景的技术需求：

作业帮有很多业务不需要分库分表的设计模式，这样可以减少对业务代码的侵入，也可以减轻DBA的压力。
承接复杂的查询操作，有时业务会查询一些扫描量较大的数据，也会经常去执行轻量级的OLAP类型的 SQL，而使用MySQL时总会出现响应不及时、跑不出数据的情况。
探索多云架构下数据库集群的解决方案。
对历史数据的归档。

降本增效的诉求：从数据存储的角度进行压缩，或对主机的CPU和内存进行更高效的利用。

OceanBase与TiDB的测试对比

在很早之前，我们就对 OceanBase 有所耳闻，但仅停留在“一款完全自主研发的优秀的数据库”这样的印象中。在 OceanBase 开源后，我们开始关注它并对它进行深入了解。

就在11月3日，OceanBase 社区版 4.0 发布，我们立即对 OceanBase 4.0做了进一步的调研和测试。结果，我们发现 OceanBase 主要有以下几个特点：

弹性扩缩容：能够很好地解决作业帮最基本的单机存储瓶颈问题。
数据压缩比、多租户模式：这两个特性能够帮助作业帮真正做到降本增效，尤其是OceanBase 4.0支持对CPU进行超卖分配，可以使我们更充分地利用硬件资源。
OLTP 性能高：我们只进行了最基本的sysbench压测，性能超出了我们的意料，在高并发情况下，SQL的响应耗时依然维持较低的水平。

业务兼容性：如果想从MySQL切换至 OceanBase，与 MySQL 5.7.24兼容性的对比是很重要的一点，我们测试了 OceanBase 4.0后，发现兼容性很高。
管理易用性：我们使用的数据库如MySQL、Redis等，都需要自己开发管理平台。OceanBase 的 OCP管理平台由于其功能完善，且使用方便，对我们DBA人员来说能解放很大一部分生产力，因此有较大的吸引力。

由于我们的部分业务使用TiDB作支撑，因此，在测试 OceanBase 的过程中，我们也对二者进行了横向对比，数据如下。

我们在数据写入后对比发现：

OceanBase 在存储效率方面相较于TiDB节省了35%以上的磁盘空间。
在兼容性上，TiDB与 OceanBase 的表现都很好，相较而言，TiDB涉及的业务改造较少，但主键操作受限，OceanBase 则可能涉及将表改成分区表的成本投入。
在运维管理方面，TiDB的监控比较完善，OceanBase 的优势在于其运维管理平台（OCP）易于使用，可以极大地减少DBA的开发管理工作。
关于数据同步组件，TiDB的DM相对来说比较完善，在我们的业务中使用较多，OceanBase的OMS在我们的测试中表现也比较亮眼，但对于我们的业务场景来说，还有一些功能需要进一步完善。
我们也关注到TiDB不支持多租户模式和多副本类型，而 OceanBase 对多租户模式的支持可以帮助我们高效利用资源，而且，OceanBase 还支持只读副本和日志副本。
另外，我们也很看重DDL的响应，OceanBase 和TiDB在加字段方面都是秒级响应，在加索引或修改一些字段类型的情况下，可能会涉及数据的拷贝，但并不阻塞读写。

OceanBase 方案实现资源隔离与快速响应

基于以上的调研和测试结果，我们选择使用 OceanBase 承接一些离线数据查询需求。

作业帮的业务人员经常需要连接MySQL来查询线上数据，时常会有一些慢SQL导致线上存库所在的主机性能抖动，影响线上业务。我们将MySQL通过工具同步到 OceanBase 后，将业务查询平台的入口数据源改成 OceanBase，同时对同步工具进行监控。如果发现了中断，或者有比较大的延迟，我们也会将这个查询的入口切换回 MySQL。

下图是使用 OceanBase 后的架构，该架构实现了资源隔离，极大地减少了对线上数据库不必要的影响。同时，在使用MySQL时一些耗时较长或对线上影响较大的SQL，在 OceanBase 中都能快速响应。后续，我们会将作业帮内部对统计分析类业务逐渐迁移到 OceanBase 中。

期待 OceanBase 解决作业帮多云环境的四个问题

我在文章开头提到，作业帮采用的是多云环境，如下图所示，三个机房之间有机房专线，业务流量分布不均匀，主要的业务流量都在腾讯云，阿里云和百度云会分布层级节点。作业帮的业务部署流量是实现单元闭环，每个机房都部署业务，这个业务只访问本机房内部的数据库入口节点（业务访问路径是App -> Proxy->MySQL）。