共计 3828 个字符，预计需要花费 10 分钟才能阅读完成。
欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/
本文来自 OceanBase 社区分享，仅限交换探讨。作者介绍：刘强，就任于作业帮基础架构 DBA 团队，负责分布式数据库的摸索和应用，协同研发团队在公司外部推动分布式数据库在业务上的落地。
在作业帮刚上线 OceanBase 4.0 时，我分享过作业帮的业务架构痛点。目前，作业帮是多云架构（阿里云、百度云、腾讯云），并同时应用 MySQL、Redis-Cluster、MongoDB、Elastisearch、TiDB、OceanBase 这几款数据库。出于高可用和降本需要，咱们决定将更多 MySQL 业务场景用 OceanBase 代替，本文将和大家分享具体起因，以及 OceanBase 4.0 与 MySQL5.7 的比照数据。
高可用双活架构计划降级需要
因为作业帮业务的多样性和复杂性，咱们对于分布式数据库的应用需要次要基于以下几个方面。
第一，在海量数据的状况下心愿缩小分库分表的复杂度，并解决单机存储瓶颈。
第二，对 I/O 密集型的 SQL 及 CPU 密集型的 SQL 来说，咱们心愿可能进步响应速度，缩小它在 MySQL 中对线上业务的影响。
第三，每个业务外部都须要业务人员频繁查问、录取线上数据，并有相应的报表服务以供下级 Leader 查看，而且大数据部门也会有报表需要接入线上数据，这对于线上 MySQL 来说难以撑持，在数据归档及汇总的状况下，也不足良好计划。
第四，因为 MySQL 的个性限度，咱们须要基于一个内部的高可用组件来实现 MySQL 的高可用架构，在多云环境下，网络环境绝对简单，这对高可用的稳定性提出了更高要求。如果局部业务的申请链路长或简单，跨云拜访会使业务相应耗时减少，影响用户体验。
因而，咱们须要摸索良好的双活架构计划，初步计划是基于 MySQL，并引入 DTS 来实现双活架构。这种架构的复杂性及引入过程中 DTS 的异样或中断，对于数据的一致性有很大的挑战。同时在应用私有云的状况下，也心愿可能最大水平升高硬件的应用老本。
出于高可用和降本需要，咱们决定将更多 MySQL 的业务场景替换为 OceanBase，并对 OceanBase 和 MySQL5.7 进行了多方面的比照。
OceanBase 4.0 比照 MySQL5.7
1、性能比照
咱们应用 32C64GB 的硬件规格别离对 OceanBase 和 MySQL 进行性能、CPU 使用率、磁盘空间占用的测试。
首先，从图 1 可见，OceanBase 性能显著超过 MySQL。
图 1 OceanBase 和 MySQL 的性能比照
其次，从图 2 得悉，在雷同的并发环境下，OceanBase 的 CPU 使用率比 MySQL 低至多一倍以上。
图 2 OceanBase 和 MySQL 的 CPU 使用率比照
另外，因为 OceanBase 数据压缩及编码的技术相较于 MySQL，可能节约 2/3 以上的磁盘空间，因而，综合上述三方面的比照后果，咱们认为 OceanBase 能为作业帮的降本增效提供极大帮忙。
在性能方面，咱们还测试了 DDL 的执行速度。对于耗时较长的 DDL，MySQL 会有补充延时问题，须要咱们援用额定的审核工具来管制它的提早，而 OceanBase 不存在延时问题。对于执行速度，MySQL 和 OceanBase 相差不大，这让咱们更加期待 OceanBase 4.1 的数据旁路导入性能，能够将 DDL 的执行速度大幅晋升。不过，咱们也发现了一些语法兼容性的问题，例如，OceanBase 对主键的操作语法不反对多个 DDL 合并执行，只能各自独自执行。
2、架构比照
除了降本增效的需要，高可用也是咱们在摸索双活架构中最看重的一方面。相较于 MySQL，OceanBase 的高可用是有延长的，不须要额定的高可用组件，这有利于解决数据不统一的问题。再加上 OceanBase 的日志具备多正本个性，可能反对在多机房或多城市灵便部署。OceanBase 还便于作业帮实现一些单元化的需要，咱们能够将业务单元内的 Leader 数据调度在某一个机房内，实现业务拜访的流量闭环，缩小跨域读写。
3、字符集比照
最初，咱们测试了字符集的反对水平。作业帮成立十年，咱们应用 MySQL 的场景和字符集品种都比拟多。OceanBase 4.0 以后反对图 3 中显示的几种字符集，在 4.1 版本中减少了对拉丁字符的反对。后续咱们也心愿 OceanBase 可能扩大字符集及校验集的反对品种。
图 3 OceanBase 4.0 反对的字符集
以上就是作业帮对 OceanBase 和 MySQL 的次要比照数据。在将更多业务场景切换至 OceanBase 的过程中，咱们发现，在高可用双活架构计划之外，OceanBase 4.0 的 HTAP 和资源隔离能力也为咱们带来许多意外之喜。
低成本与低延时，更好地降本增效
OceanBase 是一个具备 HTAP 能力的原生分布式数据库，如何了解 HTAP？援用 OceanBase CTO 的一句话：HTAP 就是在高性能 OLTP 数据库的根底上扩大 OLAP 的能力，能很好反对实时剖析。
在作业帮的业务场景中，咱们 感触到 HTAP 的两大显著劣势：低成本和低延时。
• 低成本：咱们心愿一套零碎能同时反对 OLTP 场景和 OLAP 场景，相比两套零碎领有更高的性价比。
• 低延时：省去了繁琐费时的 ETL 过程，升高延时，更好反对实时剖析。
咱们晓得，在一套零碎同时实现 OLTP 和 OLAP 的能力，其中一项挑战是资源隔离，使业务之间互不影响。这便是 OceanBase 带给咱们惊喜的中央。
对于外围业务来说，咱们心愿可能应用物理资源管理，比方行存正本服务 OLTP，列存正本服务 OLAP，这两种业务是不共享物理资源的，能够 做到相对的隔离 。OceanBase 能够减少额定的只读正本，再通过配置 OBProxy 的 proxy_idc_name 实现读写拆散。
图 4 为 OceanBase 的物理资源隔离计划，基于只读正本，再减少逻辑机房的状况下，在 OBProxy 中配置逻辑机房的地位。所有 OLAP 的 只读流量都会录入只读正本中，防止与 OLTP 副争抢资源。
图 4 OceanBase 的物理资源隔离计划
对于老本敏感的逻辑资源隔离，OceanBase 在同一租户内就可能实现 OLAP 和 OLTP 的物理资源共享，进而实现资源隔离。
对于逻辑隔离来说，首先 OceanBase 定义了一个大查问，默认将执行工夫超过 5 秒的申请断定为大查问，当大查问和短查问同时争抢 CPU 时，大查问会被升高优先级，待 CPU 资源短缺时再被挂起，咱们能够设置 Large_query_worker_percentage 在同一租户内，大查问最多能够占用 30% 的用户线程数。在这种状况下，咱们能够无效隔离大查问对 OLTP 业务的影响，优先保障了 OLTP 业务的执行。
咱们应用了一些线上业务数据和 SQL 来比照 MySQL 和 OceanBase。在作业帮的业务场景中，一个大业务部门的报表须要多级 Leader 甚至上百人频繁查看，因而，即便是 OLAP 类型的业务，QPS 也能够达到几十甚至上百。咱们应用了 60 个并发去压测较简单的 SQL，通过图 5 能够看出，OceanBase 比 MySQL 最起码快了一倍以上。OceanBase 的 CPU 使用率也根本管制在 25% 以下。
图 5 OceanBase 与 MySQL 执行 SQL 耗时
在 60 个并发执行 OLAP 业务的同时，咱们也用 256 个并发去运行 Sysbench 工作，在 OLAP SQL 扫描量较大的状况下，咱们能够看到它的耗时呈现了一些抖动（见图 6）。
图 6 并发量 256 运行 Sysbench 工作
以上就是作业帮对 OceanBase 4.0 的摸索过程，目前，咱们曾经应用 OceanBase 半年了，总结出一些心得及倡议，供大家参考。
应用 OceanBase 的心得和倡议
首先，对于 OceanBase OCP 治理平台有如下几点倡议。
• 倡议减少 DDL 工作列表显示，须要在每一个租户下，能够看到有多少工作正在执行。
• 倡议减少 SQL 审核的性能，如果有业务正在从 MySQL 迁徙，能够尽快保障业务上线，缩小 DBA 工作，聚焦于对业务的落地。
• 在应用过程中咱们发现，每个租户下磁盘的使用量、数据库的大小及表的大小，这一部分数据的监控是缺失的，须要欠缺。
• 在集群中测试时，须要实时监控性能数据，比方 QPS 响应工夫、CPU 的使用率等，倡议在现有能力上再缩短提早。
其次，对 OceanBase 集群的一些问题，咱们也给出反馈，心愿得以晋升。
• DDL 无奈实时查看工作的进度百分比，心愿后续能够减少该性能。
• 当初集群降级时须要确保每个租户的 leader 都汇集在单个 Zone 下，这样对于每个集群有上百个租户来说，操作会比拟繁琐，心愿能够优化。
• 对于大家在应用过程中须要留神大小写敏感的参数设置，一旦创立后业务上线不合理则无奈通过 SQL 语句进行批改，心愿优化。
• 倡议留神 redo log 磁盘跟内存大小的配比，防止出现当磁盘空间还有富裕的时候，创立 redo log，显示磁盘空间不够的问题。
最初，还有一些对于 OMS 数据迁徙平台的小倡议：目前存在的问题有三个，一是在数据迁徙过程中不反对新增 DB 的同步，对于数据归档或汇总的需要不敌对；二是 OpenAPI 凋谢的太少，不利于咱们外部平台的革新；三是 ghc 的长期表疏忽写法过于繁琐，须要每一个 DB 都写一个配。因为 OMS 数据迁徙是测试中罕用的性能，咱们心愿后续能有对立的配置，能够将 ghc 长期表对立过滤掉。
欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/
