几个月前 OceanBase 4.0发布的时候，一个做数据库研发的朋友和我聊起这个，说现在国产数据库太卷了，OceanBase 4.0单机版对于我们来说有点降维打击的意思啊。
我当时说，还得等11月份 OceanBase 4.0正式发布了，看看单机版能达到普通集中式数据库的水平的几成，如果能达到八成以上，那么这一招确实有降维打击的意思了。
转眼来到11月份，我们可以使用 OceanBase 4.0社区版的正式版本来测试一下了。11月1号我就收到了该版本的下载链接。也用了几天时间，对我一直十分感兴趣的 OceanBase 4.0单机版做一个全面的测试，并把自己测试的感受写出来，与大家分享。
文档
说实在的，国产数据库大多数文档写的都不太行，但是文档是用户使用数据库产品时十分重要的参考资料，缺乏高质量的文档是国产数据库的一个十分重要的缺陷。因此我们体验 OceanBase 4.0社区版，还是从文档开始。
不过总的来说，产品说明，部署手册，参考手册，管理员手册，开发手册等也算一应俱全。特别是对系统架构和参考信息等方面还算比较齐全。
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支持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在部署时严格检查空闲内存的目的是什么，按照一般情况来说，只要可用内存达到参数要求就不会有啥问题了。
配置TPCC租户
十分令人高兴的是单机版的 OceanBase 与分布式环境一样，支持租户。这样就可以把 OceanBase 拆分为多个小租户，分别给一些微服务使用。因为我的服务器上有好几个数据库，因此内存比较紧张。而 OceanBase 4.0在创建资源池时好像把内存减半了（具体原因后面再慢慢研究，是不是我的配置存在一些问题）。因此配置租户的时候，设置的内存只有12GB。
BENCHMARK测试
目前我创建了一个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 在性能上来看，还是令人满意的。
特殊情况下的HASH JOIN测试
优化器是数据库的灵魂，也是最难做的一个核心组件。优化器的设计与研发需要十分优秀的数据库专业研发队伍，并且需要长时间的积累和打磨，在各种应用场景中不断发现问题，解决问题才能有所成。
在一些常见的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 的主从复制，基于OBPROXY的高可用自动切换等功能的日益完善，我想 OceanBase 4.0的竞争力是相当可观的。因为目前我的实验环境限制，这个测试还比较简单，后续我们的D-SMART在为 OceanBase 4.0做适配的时候，我们将会进行更多的测试。
唯一觉得有点不爽的是，好像 OceanBase 4.0的很多监控视图都做了调整，并且放弃了和3.X版本的兼容，支持 OceanBase 3.1的D-SMART目前还无法直接纳管监控 OceanBase 4.0，因此我们无法通过D-SMART来观察压测期间 OceanBase 单机版的健康状态。
一个数据库产品升级后，核心监控视图最好能够与老版本保持一定的兼容性，否则对于第三方工具来说就不够友好了。也给现有用户升级数据库带来一些不必要的工作量。不过从初步体验上来看，OceanBase 4.0的各种系统视图更加规范了，比3.1提升不小。这应该也是一个数据库产品在成熟过程中都会遇到的问题吧。
PS：本文来自数据库行业KOL的白鳝（徐戟）老师的体验分享，欢迎更多开发者朋友前来体验。
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群（33254054），或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
