Oceanbase4云上版本的初步体验

白鳝的洞穴 2023-08-16

419

Oceanbase要加大在公有云的投入这件事很早就听说了，之前OB在云上不温不火，连阿里都在主页上减少了对OB的推荐，重点推荐自己的Polardb了。不过OB的云化动作很快，甚至线下的4.2稳定版还没正式推出的时候，公有云的4.1.0.1就正式推出了。6月底我受邀体验OB4的云上版本。于是7月初我在阿里云开通了一个试用实例。因为7月份事情太多，仅仅做了一些体验，没有做比较深的测试。昨天下午有点时间，我把以前的测试完成了，同时写了一篇文章，算是交作业吧。

我的试用版是4核/16G内存/200G存储空间的，不过存储是SSD盘，因此不仅仅可以用来进行功能测试，还可以稍微做一点小的性能测试。这个规模的云数据库月租金是3000多块钱，因为我参加了试用活动，这三千多大洋算是免了。云上的数据库都不便宜，在云上租这样一个小实例来做研发和软件功能测试应该是够用了。

首先我选择了单可用区的模式，只有北京H区承载写业务，其他两个区都是备用的。先创建一个Oracle租户，将全部资源分配给Oracle租户，然后进行一些简单的测试。

云上的租户创建还是挺方便的，填写表格后点击创建就开始后台的租户创建了。租户创建还是挺耗时的，大概4分钟后，租户创建完成。接下来可以进行体验了。

从集群控制台上，我们可以可以进行简单的监控，也可以进行集群的管理与调整。性能监控界面可以分别查看数据库和服务器的性能与负载情况。

我曾经尝试使用Windows上安装的OB DEVELOPER CENTER连接云上版本的ob4，不过没有成功，云上版本的Oracle租户的连接串有些不同。个人测试的结果觉得可能因为在Oracle租户的连接时不能使用租户参数，而Oceanbase开发者中心连接数据库时租户是必选项，因此可能二者存在一些冲突。

我的OB开发者中心能连接我自己部署在线下的ob 4.2beta，但是无法连接云上的OB4.1.0.1。不过在使用obclient连接云上的Oracle租户的时候，连接参数有些不同。

obclient -htxxxxxxx.oceanbase.aliyuncs.com -u-P1521 -p -c -A

用上面的连接方式可以正确的连接云上的OB，而带上租户，集群名则会失败。不过我可以先跳过这步，先测试一下Benchmark。为了测试线上的OB，我使用了我的笔记本电脑上的wsl子系统中的openEuler。在上面部署了benchmark工具，我准备直接通过互联网去压测一下公有云上的OB数据库。

为了能在互联网上访问OB，首先要申请一个公网地址。提交申请后，我就会得了一个tXXXXXX.oceanbase.aliyuncs.com:1521的访问地址。Oracle租户的端口号居然是1521。

在wsl里，我通过obclient连接了OB数据库。接下来我们先压测一下。

首先Build一下Warehouse。因为申请的内存不大，所以我只创建了一个20 个仓库的测试集，使用了一个50并发的测试用例。

监控界面上可以比较清晰的看到各种监控数据。如果需要也可以设置一些告警规则。不过从整体上来看，OB的性能监控台采集的指标数量并不多，被划分为性能与SQL、事务和存储与缓冲三个类别。加在一起有二十多个指标。

装载完毕数据，在正式测试前，我们先做一个合并。使用LSM-TREE存储引擎的数据库都存在基线版本和增量版本的问题。OB的增量数据存储在MEMSTORE和SST中，对于某一行的修改来说，在增量中只存储了变更的字段，不包含完整的行数据。因此要读取完整的UPDATE行的时候，需要使用基线数据加上增量数据生成一个一直性读的块才能够完成。因此对于性能是有一定影响的。

可以看出这次合并执行了47秒。数据库的基线版本也升级为一个新的版本。

由于是一个很小的测试环境，具体的TPMC指标也没有太大的意义。不过Benchmark压测的TPM指标还是挺稳定的。

从系统资源上看，主副本的资源消耗高一些，不过CPU的使用率还不算太高。我们来看看到底是什么原因导致了数据库的负载压不上去。

从等待事件上看，主要等待的是row callback lock wait，这个等待事件是DML产生的，DML涉及的每一行都会加一个锁。

跑了一段时间后，主节点的CPU使用率稳定在50%+， TPMC也增加到了3950左右。

我们尝试一下，在跑负载的时候做一个合并操作，看看会发生什么。

合并启动后，数据库的等待事件发生了一些变化。多了一些和IO与内存管理相关的等待。

这次合并执行了1分17秒，合并操作结束，TPMC已经略超过4000了，等待事件也发生了一些变化，db file data read等待多了一些，latch row callback lock wait等待少了一些。

从租户的QPS指标上看，在合并期间略微有一点点波动，不过波动不大。

完成这个测试之后，我修改了一下可用区的配置，把三个区都升级为主可用区。然后重新创建Warehouse，再进行一次压测。因为本系统是跨机房部署的，并且在代理上只能连接H区，所以把可用区升级为对等模式后，TPMC和QPS都反而有了一定的下降。TPMC最终稳定在3000+，比刚才少了将近1000。将可用区切换回H区单主后，TPMC也恢复了。如何优化这种多可用区下的性能，后续我会继续进行测试，昨天下午已经没有时间做这方面的测试了。

下面我们进行一次切换住可用区的操作。将主可用区从H区切换到J区，模拟一次H区机房的故障。

因为当前我测试的数据量不大，所以切主操作十分顺利，不到10秒控制台就显示完成了切换。Benchmark测试的客户端没有发生任何报错。平稳快速的做故障切换是关键业务系统十分关注的数据库能力，这方面的测试结果还是令人满意的。不过如果在大数据量和更大并发下测试才更有意义，我这个测试仅仅完成了一个功能测试，无法模拟生产场景。

其他功能方面，OB云平台提供的SQL工作台的功能基本上够用，可以大大提高数据库的易用性。用来管理数据库对象、会话、执行SQL，都还不错。这个工具的功能和Oracle的SQL DEVELOPER功能相近，易用性方面也不差。

在这个简单的测试中，唯一没有找到的是OCP中的TOP SQL/慢SQL优化工具。未免感到有些遗憾，也许是我没有找到工具的入口吧。还有一点有些遗憾的是，因为云上OB在登录参数上与云下版本的差异，我们的D-SMART没法接入，这方面我们后续会和OB的同学一起来分析一下原因，争取尽快让D-SMART也能接入云上的OB数据库实例。

云数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Oceanbase4云上版本的初步体验

评论