共计 3786 个字符，预计需要花费 10 分钟才能阅读完成。
3 月 25 日，第一届 OceanBase 开发者大会在北京举办， 作业帮数据库架构师刘强为大家带来了《作业帮基于 OceanBase 的 HTAP 实际》的分享 ，为大家介绍了 OceanBase 上线作业帮半年来的体验与心得。
以下内容由大会演讲整顿而成：
在作业帮刚上线 OceanBase 4.0 时，我分享过作业帮的业务架构痛点（移步《作业帮：摸索多云架构下的数据库集群解决方案》可浏览）。目前，作业帮是多云架构（阿里云、百度云、腾讯云），并同时应用 MySQL、Redis-Cluster、MongoDB、Elastisearch、TiDB、OceanBase 这几款数据库。出于高可用和降本需要，咱们决定将更多的 MySQL 业务场景降级为 OceanBase，本文将和大家分享具体起因，以及 OceanBase 4.0 与 MySQL 5.7 的比照数据。
高可用双活架构计划降级需要
因为作业帮业务的多样性和复杂性，咱们对于分布式数据库的应用需要次要基于以下几个方面。
第一，在海量数据的状况下，心愿缩小分库分表的复杂度，并解决单机存储瓶颈。
第二，对 I/O 密集型的 SQL 及 CPU 密集型的 SQL 来说，咱们心愿可能进步响应速度，缩小它在 MySQL 中对线上业务的影响。
第三，每个业务外部都须要业务人员频繁查问、录取线上数据，并有相应的报表服务以供下级 Leader 查看，而且大数据部门也会有报表需要接入线上数据，这对于线上 MySQL 来说难以撑持，在数据归档及汇总的状况下，也不足良好计划。
第四，因为 MySQL 的个性限度，咱们须要基于一个内部的高可用组件来实现 MySQL 的高可用架构，在多云环境下，网络环境绝对简单，这对高可用的稳定性提出了更高要求。如果局部业务的申请链路长或简单，跨云拜访会使业务相应耗时减少，影响用户体验。
因而，咱们须要摸索良好的双活架构计划，初步计划是基于 MySQL，并引入 DTS 来实现双活架构。这种架构的复杂性及引入过程中 DTS 的异样或中断，对于数据的一致性有很大的挑战。同时，在应用私有云的状况下，也心愿可能最大水平升高硬件的应用老本。
OceanBase 4.0 比照 MySQL 5.7
出于高可用和降本需要，咱们决定将更多 MySQL 的业务场景降级为 OceanBase，并对 OceanBase 和 MySQL 5.7 进行了多方面的比照。
▋ 性能比照
咱们应用 32C64GB 的硬件规格别离对 OceanBase 和 MySQL 进行性能、CPU 使用率、磁盘空间占用的测试。
首先，从下图可见，OceanBase 性能显著超过 MySQL。
OceanBase 和 MySQL 的性能比照
其次从下图得悉，在雷同的并发环境下，OceanBase 的 CPU 使用率比 MySQL 低至多一倍以上。
OceanBase 和 MySQL 的 CPU 使用率比照
另外，因为 OceanBase 数据压缩及编码的技术相较于 MySQL，可能节约 2/3 以上的磁盘空间，因而，综合上述三方面的比照后果，咱们认为 OceanBase 能为作业帮的降本增效提供极大帮忙。
在性能方面，咱们还测试了 DDL 的执行速度。对于耗时较长的 DDL，MySQL 会有补充延时问题，须要咱们援用额定的审核工具来管制它的提早，而 OceanBase 不存在延时问题。对于执行速度，MySQL 和 OceanBase 相差不大，这让咱们更加期待 OceanBase 4.1 的数据旁路导入性能，能够将 DDL 的执行速度大幅晋升。不过，咱们也发现了一些语法兼容性的问题，例如，OceanBase 对主键的操作语法不反对多个 DDL 合并执行，只能各自独自执行。
▋ 架构比照
除了降本增效的需要，高可用也是咱们在摸索双活架构中最看重的一方面。相较于 MySQL，OceanBase 的高可用是有延长的，不须要额定的高可用组件，这有利于解决数据不统一的问题。再加上 OceanBase 的日志具备多正本个性，可能反对在多机房或多城市灵便部署。OceanBase 还帮忙作业帮实现了一些单元化的需要，咱们能够将业务单元内的 Leader 数据调度在某一个机房内，实现业务拜访的流量闭环，缩小跨域读写。
▋ 字符集比照
最初，咱们测试了字符集的反对水平。作业帮成立十年，咱们应用 MySQL 的场景和字符集品种都比拟多。OceanBase 4.0 以后反对图 3 中显示的几种字符集，在 4.1 版本中减少了对拉丁字符的反对。后续咱们也心愿 OceanBase 可能扩大字符集及校验集的反对品种。
以上是作业帮对 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 实现读写拆散。
下图为 OceanBase 的物理资源隔离计划，基于只读正本，再减少逻辑机房的状况下，在 OBProxy 中配置逻辑机房的地位。 所有 OLAP 的只读流量都会录入只读正本中，防止与 OLTP 副争抢资源。
OceanBase 的物理资源隔离计划
对于老本敏感的逻辑资源隔离，OceanBase 在同一租户内就可能实现 OLAP 和 OLTP 的物理资源共享，进而实现资源隔离。
对于逻辑隔离来说，首先 OceanBase 定义了一个大查问，默认将执行工夫超过 5 秒的申请断定为大查问，当大查问和短查问同时争抢 CPU 时，大查问会被升高优先级，待 CPU 资源短缺时再被挂起，咱们能够设置 Large_query_worker_percentage 在同一租户内，大查问最多能够占用 30% 的用户线程数。
在这种状况下，咱们能够无效隔离大查问对 OLTP 业务的影响，优先保障了 OLTP 业务的执行。
咱们应用了一些线上业务数据和 SQL 来比照 MySQL 和 OceanBase。在作业帮的业务场景中，一个大业务部门的报表须要多级 Leader 甚至上百人频繁查看，因而，即便是 OLAP 类型的业务，QPS 也能够达到几十甚至上百。
咱们应用了 60 个并发去压测较简单的 SQL，通过下图能够看出，OceanBase 比 MySQL 最起码快了一倍以上。OceanBase 的 CPU 使用率也根本管制在 25% 以下。
OceanBase 与 MySQL 执行 SQL 耗时
在 60 个并发执行 OLAP 业务的同时，咱们也用 256 个并发（如下图），去运行 Sysbench 工作，在 OLAP SQL 扫描量较大的状况下，咱们能够看到它的耗时呈现了一些抖动。
并发量 256 运行 Sysbench 工作
作业帮想对 OceanBase 说
以上就是作业帮对 OceanBase 4.0 的摸索过程。目前，咱们曾经应用 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 长期表对立过滤掉。
明天分享到这里就完结了，如果大家有什么想交换的，欢送评论区留言与我探讨。
