OceanBase 4.0社区版真的好用吗？

时间：2023-04-21 01:12:02 | 来源：网站运营

时间：2023-04-21 01:12:02 来源：网站运营

OceanBase 4.0社区版真的好用吗？：

本文由行业KOL白鳝（徐戟）老师分享，欢迎大家评论区探讨交流！

几个月前OceanBase 4.0 发布的时候，一个做数据库研发的朋友和我聊起这个，说现在国产数据库太卷了，OceanBase4.0单机版对于我们来说有点降维打击的意思啊。

我当时说，还得等 11 月份OceanBase4.0正式发布了，看看单机版能达到普通集中式数据库的水平的几成，如果能达到八成以上，那么这一招确实有降维打击的意思了。

转眼来到 11 月份，我们可以使用 OceanBase 4.0 社区版的正式版本来测试一下了。11 月 1 号我就收到了该版本的下载链接。也用了几天时间，对我一直十分感兴趣的 OceanBase 4.0 单机版做一个全面的测试，并把自己测试的感受写出来，与大家分享。

说实在的，国产数据库大多数文档写得都不太行，但是文档是用户使用数据库产品时十分重要的参考资料，缺乏高质量的文档是国产数据库的一个十分重要的缺陷。因此我们体验 OceanBase 4.0 社区版，还是从文档开始。

虽然 OceanBase 的文档种类丰富度相对于国外部分数据库还有差距，但相对来说，也算是国产数据库中进展的比较好的。在 OceanBase 的文档中，产品说明、部署手册、参考手册、管理员手册、开发手册等一应俱全，特别是在系统架构和参考信息等方面也比较齐全。

OceanBase 在手册中还提供了一个《文档概览》手册，让用户可以全面了解 OceanBase 的文档体系，还是挺有用的。

作为一个第一次使用 OceanBase 4.0的用户，我们从学习 OceanBase 的安装手册开始。在这个版本中，OceanBase 提供了一个 50 多页的安装部署手册--《OceanBase 4.0—部署数据库》。

从手册的部署环境要求看，OceanBase 4.0 支持 RHEL 7/8 的操作系统，以及龙蜥、德班、乌邦图和 SUSE 等 LINUX 发行版的系统。不过并没有直接列出针对麒麟、统信、中科方德等信创环境的支持，不知道在这些信创环境中支持程度如何。openEuler 和 CENTER OS 7 内核兼容性极高，估计支持起来问题不大。

OceanBase 4.0 的安装手册总体来说还是不错的，因为要针对不同种类的部署模式，部署不同种类的集群（单机，带 PROXY 的分布式集群，不带 PROXY 的分布式集群等），因此其复杂度还是挺高的，目前 50 多页的部署手册还略显简单。

如果针对以前玩过 OceanBase 的人来说，安装部署并不复杂，一些概念也没有太大变化。但是对于第一次玩 OceanBase 的人来说，OceanBase 4.0 的安装部署文档写的还是略显简单了一点，对于一些常见的部署模式，并没有针对性的描述，需要从字里行间去挑出自己所需要的内容。希望后续能够继续优化文档，最好把每种部署模式都单独来写。让想用某种部署模式的人能够在一个地方看到完整的步骤，而不是要在不同的地方挑着看。

在部署方式上，OceanBase 4.0 支持 docker 镜像的快速体验，也支持使用 OBD 进行离线部署，还支持通过 ob-operator 部署 K8S 环境。在部署方面还是考虑得比较周到的。作为一款分布式数据库产品，部署简便是十分关键的。

OceanBase 4.0 的安装部署手册上建议离线方式使用OBD工具来部署。说实在的虽然以前用过 OceanBase，也在为 OceanBase 开发智能运维工具，不过以前部署 OceanBase 都是同事做的，我自己也是第一次用 OBD 部署 OceanBase 数据库。总体来说，只要你规划好了部署方式，按照提前准备要求准备好了安装目录与 admin 用户。然后找一个 yaml 文件配置一下，就十分顺利的完成了部署。

oceanbase-ce: servers: # Please don't use hostname, only IP can be supported - 60.60.60.123 global: home_path: /u01/admin/observer data_dir: /u01/admin/data redo_dir: /u01/admin/redo devname: enp26s0f1 mysql_port: 2881 rpc_port: 2882 zone: zone1 memory_limit: 40G memory_limit_percentage: 80 system_memory: 12G datafile_size: 10G log_disk_size: 11G syslog_level: INFO enable_syslog_wf: false enable_syslog_recycle: true max_syslog_file_count: 4 appname: obcluster root_password: admin123 proxyro_password: proxy123我选择了一个最简单的单机部署模式，实际上 data_dir 和 redo_dir 我都是放在 /u01/admin 下的，因为这台服务器上只挂了一块数据盘，我试了一下使用软连接，是可以完成部署的。实际上在这里也可以直接设置为 /u01/admin/data。

在这里我遇到了一个小问题，刚开始的时候，参数文件里的一些参数我没有设置，因此一部署就报错了。而在部署手册里也没有明确哪些参数必须设置，哪些可以忽略。

这时候执行 deploy 会报错。而如果只留下 home_path 参数，其他参数全部注释掉是能够执行 deploy 的，但是在 deploy 过程中会报错。在这里，OBD 的报错信息显得不够准确。

看到上面的错误信息，一般用户还是会有点蒙圈的。OBD 工具的报错信息还可以再做些优化。解决掉这些小问题后，部署就十分顺利了。整个部署过程也很快。

安装好后，就可以试试用 obclient 连接一下数据库了。

在这里要注意的是，OBD 在部署集群的时候，对内存的限制是十分严格的，不管系统中的物理内存可用是多少，必须有足够的 free 才能完成部署。

当系统的物理内存被 CACHE 占用而不足时，部署会失败。而实际上，在 LINUX 上，经常会出现有些 BUFFER/CACHE 无法清除的问题，这也会限制我们完成部署工作。不知道 OceanBase 4.0 在部署时严格检查空闲内存的目的是什么，按照一般情况来说，只要可用内存达到参数要求就不会有啥问题了。

十分令人高兴的是单机版的 OceanBase 与分布式环境一样，支持租户。这样就可以把 OceanBase 拆分为多个小租户，分别给一些微服务使用。因为我的服务器上有好几个数据库，因此内存比较紧张。而 OceanBase 4.0 在创建资源池时好像把内存减半了（具体原因后面再慢慢研究，是不是我的配置存在一些问题）。因此配置租户的时候，设置的内存只有 12GB。

目前，我创建了一个 12G 内存的资源池，并在上面创建了一个 MySQL 租户“test”。接下来就可以用 benchmark 5.0 做一次 TPCC 测试了。因为测试环境是一个装了一些其他数据库的混合环境，因此我只是做了一个十分简单的测试。测试前完全使用 autodeploy 的默认参数，没有做任何的 OceanBase 参数调整。配置一个OceanBase 4.0 的压测 props 文件。因为租户的 CPU MAX 设置为 60，因此我只开启 70 客户端进行。

从 CPU 使用率上看，基本上把服务器的 CPU 资源都用上了。整个压测过程中，CPU 始终有 25% 左右的空闲，这是因为我对资源做了限制，并没有 100% 给 OceanBase 使用。

IO 上看，读写 IO 都达到了 200M+，总的 IO 吞吐量超过 500M /秒，IOPS 达到 1.7 万左右。因为服务器使用的是 ruler ssd，IO 延时还是比较好的，低于 1 毫秒。

整个测试过程还比较平稳，最终总的 TPMC 二十万出头，NewOrder 接近 10 万。对于一般的管理和业务类系统而言，二十万总 TPM 基本上能够承担了。测试环境是一台 2017 年出厂的 INTEL E8 6150 系列的 2 路白牌机，配置了 64GB 内存，而用于 TPCC 测试的租户内存仅仅配置了 12GB。基于 LSM-TREE 的数据库产品十分吃内存，如果内存配置大一点，达到 256GB 以上，硬盘也配置大一点，WH 数量达到 100 个，并发数提高一些，估计 TPMC 再翻几番是问题不大的。通过对 OceanBase 参数的优化，还可以继续提升 TPMC 的指标。不过对于一般性的应用来说，已经足够了。从这也可以看出，单机版的 OceanBase 在性能上来看，还是令人满意的。

优化器是数据库的灵魂，也是最难做的一个核心组件。优化器的设计与研发需要十分优秀的数据库专业研发队伍，并且需要长时间的积累和打磨，在各种应用场景中不断发现问题，解决问题才能有所成。

在一些常见的 SQL 的执行计划生成上，大部分数据库的能力都差不多，因此要考察一个数据库产品的优化器是否能够应对各种复杂的应用场景，必须使用一些特殊的测试用例。在这些年的应用中，我们也积累了一些应用场景。在这里我们找个和 HASH JOIN 相关的 SQL 来测试一下。

分布式数据库在解决复杂 SQL 的问题上，往往都是采用多打一的战略，单机性能往往不够好。因为分布式执行计划优化的难度是很大的。正是因为这个原因，分布式数据库单机部署中有一个令人感到怀疑的地方，就是复杂 SQL 的性能如何。

实际上复杂 SQL 的性能不仅仅取决于并行执行计划的好坏，更多的是优化器处理 HASH JOIN 等大表关联的能力。Oracle 作为单机数据库，在很多复杂表关联业务上性能并不落下风。对于一个数据库产品，我经常会用一个很多数据库不支持的 HASH JOIN 场景来测试。比如下面的一条 SQL。在 PG 12 上，两张表做关联，关联条件带有 OR，那么这条SQL就无法使用 HASH JOIN 的执行计划，而改走NESTED LOOP。

这种执行计划是十分糟糕的，如果表中有数十万条数据或者更多，那么这个执行计划可能跑上几个小时也无法执行完。在这两年数据库从 Oracle 迁移到 PG 兼容的数据库或者其他国产数据库的时候，经常遇到这样的问题。此时只能对 SQL 进行改写，将 OR 拆分成多条 SQL 的 UNION 形式。如果条件中存在多个 OR，那么麻烦就大了。我曾经见到过一条只有数行的 SQL 被拆成上千行的案例。

我们在一套 OpenGauss v3.0 的数据库上，也看到了类似的执行计划，这个执行计划返回三十万行数据，消耗了 13 秒，而如果去掉 OR 条件，执行计划就可以走 HASH JOIN，200 多毫秒就出结果了。

这个场景在 OceanBase 4.0 上试了一下，OceanBase 生成了一个自动 UNION 的执行计划，将 SQL 分解为 2 个走 HASH JOIN 的分支。这正好实现了自动改写 SQL 的功能。

上面的这个查询只用了 87 毫秒，执行效率还是令人满意的。

这几天简单体验了一把单机版的 OceanBase 4.0，总体还是让人满意的，支撑单一业务系统与普通单机数据库相比，也不太落下风。

随着 OceanBase 4.0 的不断完善，在单机版 OceanBase 的主从复制，基于 OceanBase Proxy 的高可用自动切换等功能的日益完善，我想OceanBase 4.0 的竞争力是相当可观的。因为目前我的实验环境限制，这个测试还比较简单，后续我们的 D-SMART 在为 OceanBase 4.0 做适配的时候，我们将会进行更多的测试。

唯一觉得有点不爽的是，好像OceanBase 4.0 的很多监控视图都做了调整，并且放弃了和 OceanBase 3.X 版本的兼容，支持 OceanBase 3.1 的 D-SMART 目前还无法直接纳管监控OceanBase 4.0，因此我们无法通过 D-SMART 来观察压测期间 OceanBase 单机版的健康状态。

一个数据库产品升级后，核心监控视图最好能够与老版本保持一定的兼容性，否则对于第三方工具来说就不够友好了。也给现有用户升级数据库带来一些不必要的工作量。不过从初步体验上来看，OceanBase 4.0 的各种系统视图更加规范了，比 OceanBase 3.1 版本提升不小。这应该也是一个数据库产品在成熟过程中都会遇到的问题吧！

大家有体验OceanBase社区版4.0的感受，也欢迎在评论区多多互动哦。