导语：面对业务多元、数据海量、数据库品种多样、多云架构简单等痛点，该如何制订既能解决问题又能降本增效的数据库降级计划？作业帮作为实践者，从四方面分享其数据库选型过程与思考。以下为作业帮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 企业版的一些优良个性如通明加密，咱们也会继续关注并在适当的机会推动商业化服务的单干。