导语：面对业务多元、数据海量、数据库种类多样、多云架构复杂等痛点，该如何制定既能解决问题又能降本增效的数据库升级方案？作业帮作为实践者，从四方面分享其数据库选型过程与思考。以下为作业帮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）。
这个多云架构存在四个问题。
第一个问题， 在专线抖动的情况下，当阿里云的业务节点需要向master进行写数据的时候，会出现写入失败的情况。我们的基本诉求是业务节点在阿里云内能够实现只读，这样可以尽可能地减少对业务的影响。
第二个问题， 专线故障。当腾讯云和阿里云之间出现了专线故障且长时间不可恢复，此时在保证高可用不会误切主的前提下，通知业务将阿里云的业务流量调度到腾讯云, 等专线恢复后再将架构复原。
第三个问题， 机房级别的故障。机房级别的故障分为主机房不可用和主机房可用两种情况，如果主机房可用，而主机房和其他两个机房都实现了网络隔离，我们会优先将业务流量切换到腾讯云，这样能保证绝大部分流量不用进行切换处理。
第四个问题， 基础机房不可用，导致腾讯云整个系统故障。此时我们会进行数据库层面的切换，将主节点切换到阿里云或百度云，再将腾讯云的业务流量切换到新的集群主节点中。
基于我们的业务流量分布特点和架构情况，当前高可用架构的主要痛点在于如何保证其稳定性并在极端网络情况下不发生脑裂。同时，基于MySQL的双活架构，实现难度也较大。
那么，OceanBase 是否能给我们带来更好的解决方案？
OceanBase 不需要额外的高可用管理组件，使用Paxos协议能更好地保证高可用架构的稳定性，且避免了脑裂的情况。
在我们同城三机房的背景下，我们使用三zone五副本的方式部署一套集群，能够满足绝大部分业务需求。同时，在单云化改造方面提供了较为完善的解决方案。
假如我们按照用户的某个维度进行数据分片，一个机房一个分片表，通过leader的调度功能将leader副本调度到本机房内，每个机房的业务单云在本机房实现流量闭环读写。
除此之外，据 OceanBase 的工程师透露，OceanBase 的主备集群的的功能将会在 OceanBase 开源4.1版本中发布，这让我们非常期待。因为该架构的主要优势在于可以进行异地机房的数据容灾，且备集群只需要单个副本，架构易于管理且成本低。
写在最后
基于 OceanBase 的种种优势，比如高效的资源利用、灵活地副本调度、稳定地高可用架构等，我们将陆续在公司内部进行推广，并连同业务尝试单元化方案的改造和落地。
另外，OceanBase 企业版的一些优秀特性如透明加密，我们也会持续关注并在适当的时机推进商业化服务的合作。