当前位置: 首页 > news >正文

OceanBase DBA实战营2期--自动分区分裂学习笔记

OceanBase 分区的前置知识点
为什么分区能让查询变快?
分区除了可以让一张超级大表的数据比较均衡地负载在不同的数据库节点上,另外一个目的就是加速查询。因为查询时会利用过滤条件里面的分区键进行分区裁剪。例如下面这两个例子:
·如果过滤条件里有分区键,计划中可以看到 partitions(p0),说明只扫描了 p0 这一个分区的数据。

如果过滤条件里没有分区键,计划中可以看到 partitions(p[0-1]),说明扫描了 p0 和 p1 全部所有分区的数据。其中 PX PARTITIONITERATOR 算子就是用来循环扫描所有分区的迭代器。

为什么主键必须包含全部分区键?
很多社区用户会问:“有一张订单流水表,数据很大,想考虑按年份对数据进行分区。现在只有 ID 列是主键。尝试了一下好像无法按日期进行分区。是必须要把日期做成和 ID 的联合主键才可以分区么?答案是对的,主键必须包含所有分区键。
因为主键的唯一性检查是在各个分区内部进行的,如果主键不包含全部分区键,这个检查就会失效。所以 MySQL 及其他数据库,一般情况下,也都会有这个要求。
说明:
对于这个限制,前一阵儿还有一位数据库界的 KOL 老师认为上面的写法过于绝对了,尝试举出反例最后终于找到一个叫 pg_pathman 的第三方 pg 插件。
这类第三方插件为了提升设置分区的灵活性,不要求分区键是主键或者唯一键的子集,但往往也会导致数据库中的主键和唯一键都不再保证唯一性,进而可能引入比较严重的正确性问题。不过终究也算是打破了这个限制。
最后在上面那段话中,又加入了“一般情况下”这几个字。
下面举个例子解释下原因:
创建了一张表,主键是 c1 和 c2,分区键是 c2,小于 3 的值在 p0 分区,大于等于 3 且小于6 的值在 p1 分区。然后插入了两个行,第一行在 p0 分区,第二行在 p1 分区。

如果主键只有 c1而没有 c2,那么在 p0 和 p1 分区内对 c1 列的唯一性检测都会成功,因为在各个分区内 c1列的值都不重复(每个分区都只有一行数据,在分区内自然不会重复),然后就会判定插入的数据符合主键约束。

但实际上在分区间会有重复值 c1=1,数据并不符合主键约束(主键只有c1列),所以所有数据库
在分区时,都要求主键包含全部分区键。
分区表应该优先考虑哪种分区方式?
分布式数据库的优势在于对于空间问题和请求访问问题分而治之。针对每个分区的访问,由该分区所在的节点响应即可。 即使该 SQL 并发很高,由于访问的是不同的分区,分别由不同的节点提供服务。每个节点自身也有一定能力满足一定的 QPS,所有节点集中在一起就能提供更大的 QPS。这个时候如果扩容节点数量,该 SQL 总的 QPS 也能获得相应的提升,这是分布式数据库里最好的情形。分区的目标是将大量数据和访问请求均匀分布在多个节点上,一是想充分利用资源进行并行计算,消除查询热点问题;二是想利用分区裁剪来提升查询效率。如果每个节点均匀承担数据和请求,那么理论上10 个节点就应该能承担 10 倍于单节点的数据量和访问量。然而如果分区是不均匀的,一些分区的数据量或者请求量会相对比较高,出现数据偏斜skew),这个可能导致节点资源利用率和负载也不均衡。偏斜集中的数据我们又称为热点数据。避免热点数据的直接方法就是数据存储时随机分配(没有规则)给节点,缺点是读取的时候不知道去哪个分区找该记录,只有扫描所有分区了,所以这个方法意义不大。实际常用的分区策略都是有一定的规则。用户必须在业务查询条件明确的情况下,根据真实业务场景进行分区规划,不要在场景不明确的情况下随意进行分区规则。 在规划分区时,建议尽量保证各个分区的数据量相对均衡。最常用的三种分区方式如下:
● HASH 分区:一般适用于分区列 NDV(不同值的种类)较大,且难以划分出明确范围的情况。优点是容易让没有特定规则的数据也能够在不同的分区内均匀分布,缺点是在范围查询时难以进行分区裁剪。
● RANGE 分区:一般适用于分区键容易划分出明确的范围的情况,例如可以把记录流水信息的大表根据表示信息时间的列做 RANGE 分区。
● LIST分区:一般适用于需要显式控制各行数据如何映射到具体的某一个分区时,优点是可以对无序或无关的数据集进行精准分区,缺点是在范围查询时难以进行分区裁剪。
为了更好地支持并行计算和分区裁剪,0ceanBase 还支持二级分区。OceanBase 数据库 MySQL 模式目前支持HASH、RANGE、LIST、KEY、RANGECOLUMNS 和LIST COLUMNS 六种分区类型,二级分区为任意两种分区类型的组合。例如在用户账单领域,数据库往往需要按照 user_id 做 HASH 一级分区,然后再在各个一级分区内部,继续按照账单创建时间做 RANGE 二级分区。

尽管 OceanBase 数据库在组合分区上支持 RANGE+HASH 和 HASH+RANGE 两种组合,但是对于RANGE 分区的分区操作 add/drop,必须是 RANGE 分区做为一级分区的方式。所以针对例如数据量较大的流水表,为了维护方便(新增和删除分区),建议使用 RANGE+HASH 组合方式(时间列range -级分区+业务列 hash 二级分区)。
总结一下:
● 分区优先考虑用时间列 range -级分区+业务 hash 二级分区。
● 否则要根据数据聚集维度和常用查询语句来设计分区。
如何进行手动分区分裂?
这期课程主要是讲自动分区分裂,这里顺带也提一下手动分区分裂。
OceanBase 数据库支持在分区表中手动进行分区分裂(REORGANIZE)操作,即将一个已有的分区拆分为多个分区。这个功能可以指定需要分裂的分区和新分区的分裂位点进行手动执行分区分裂命令,根据需求和数据增长情况对分区进行调整。
OceanBase 当前(4.4.0及以下版本)仅支持对 Range/Range Columns 分区的一级分区表进行手动分区分裂操作。
示例:
创建 Range 分区的一级分区表 test_tbl1。

把test tbl1表的分区 p分裂成三个新的分区,分裂的位置是在30和60这两个值所对应的行上。分裂后,原来的分区p0被分成三个新的分区p01、p02和p0。

把 test_tbl1 表的分区 p_max分裂成三个新的分区,分裂的位置是在400和500这两个值所对应的行上。分裂后,原来的分区pmax被分成三个新的分区pmax1、p max2和p max_3。

查看表 test tbl1的结构和定义。

输出结果如下:

自动分区分裂
背景
随着数字化的发展,当今数据库的业务数据量很大,单表往往也能达到非常大的数据量规模。此时,使用单机数据库往往无法容纳过大体量的业务,需要使用分布式数据库的可扩展能力,将数据打散在多个节点进行承载,达到负载均衡的效果。
在 OceanBase 中,我们将表进行分区,按照分区粒度将数据划分到集群的不同节点上,来实现负载均衡的目标。但这依赖用户能设计比较好的分区规则才能更好地使用水平扩展能力,这不仅要求用户具备对各种分区方式有充分的理解,并且还要求用户对业务使用数据库的方式有深入的了解,甚至在有些场景中,采用手动分区很难达到各方面都比较优的效果。自动分区分裂特性能自动地根据用户设定的分区阈值大小自动进行分区分裂,使得用户在对分区规划关注较少的前提下,也能用好 OceanBase 数据库的分布式能力。本篇文章将首先介绍手动分区存在的痛点问题,接着描述自动分区是如何解决手动分区这些问题的,最后我们将围绕自动分区功能,展开介绍它的特点,使用场景,使用方式以及限制等。
使用手动分区的痛点
分布式数据库负载均衡的目标是让各个节点的资源使用尽量达到均衡,要达到这个目标,就需要设计出合理的分区,使得分区间的资源占用比较适中,无论是分区多大或者分区过小都可能存在问题。分区过大可能存在负载不均衡,后台操作空间放大等问题,分区过小可能会导致元数据过多,性能不优等问题。
在自动分区发布之前,我们通常是手动设计分区规则,这个过程通常是比较困难的,我以一个抽象的业务场景为例来说明手动分区的痛点问题。
假设有一个系统,里面有一张表,它的主键是(公司 ID,员工 ID),现在将这个系统部署在OceanBase 上,它上面当前有一条 SQL 查询,按照公司 ID,员工 ID 进行点查,客户对数据库的期望
1.希望能充分利用 OceanBase 的分布式的能力,将表的负载均衡
2.希望尽量让 SQL 的性能比较优
为了满足点查的 SQL 性能比较优的需求,很自然地想到基于(公司 ID,员工 ID)进行 Key 分区,Key分区基本上能保证数据量均衡,并且,也能够高效地按照公司 ID,员工 ID 进行查询。
目前,业务的需求都得到了满足,我们来看看如果业务发生一些变化后,会出现什么情况?业务变化有两种,一种是业务的请求发生变化,另一种是业务的数据发生变化。我们先来看业务的SQL发生变化的场景。
业务请求发生变化
业务系统新增一个新的功能需求,它希望对每个公司的员工,进行按批处理,对应的 SQL 请求是一个范围扫描。如果在原来的 Key 分区上做范围扫描,会导致每个分区都参与范围扫描查询,特别是按批处理的场景如果每个批次数据量不大时,会带来比较多的 IO 放大和网络放大,SQL 的性能是不优的。
为了解决这个问题,一个解决办法就是按照range(公司 ID,员工 ID)进行分区,但比较难以设置划分的分区的边界,因为运维人员或者开发人员很难知道每个公司的员工数量,也就比较难以进行均衡的划分。即使这个是老的业务,我们提前知道数据,我们可以手工统计目前数据的分布,划分出一些边界但这也会有新的问题。随着业务的发展,每个公司可能在员工信息上会有变化,也就是业务数据变化那么就可能存在新的问题。
业务数据发生变化
假如某些公司因业务发展需要,招聘并入职了大量员工,如果不做任何的处理,新入职的员工可能会分布在某个分区上,使得该分区的数据量远超其他分区,集群会重新变得不均衡。为了避免该问题,可能运维人员需要规划好新的机器,并提前创建好新的分区,以便新的分区能够负责新的数据,防止已有分区的数据量过大的问题,这给业务运维带来了复杂度。总结下来,通过手动分区的方式,存在如下痛点:
1.负载均衡与 SQL 性能在部分业务场景可能难以兼顾,使用 Key 分区能够将负载打散,但对范围查询不够友好,使用 Range 分区又存在无法手动操作的可能性
2.手动设计的分区规则只适用于当前的业务情况,如果业务发生变化,可能需要重新设计分区规则。
3.设计分区规则时,运维人员和开发人员需要做充分的沟通,确保业务中的 SQL 正确使用上了分区键,存在一定的沟通成本。
自动分区分裂如何解决问题
在讨论自动分区如何解决问题之前,我们先来简单的了解下 OceanBase 的自动分区的大致流程,在OceanBase 中,当一个分区的数据量达到数据量阈值后,会自动地将数据按照主键或者主键前缀的Range 进行一分为二,这里面有两个好处:
1.有了自动分区后,每个分区的数据量会维持在大小适中的状态,当每个分区的数据量都差不多时,对负载均衡比较友好。
2.自动分区是按照 Range 自动分区的,它既适合范围查询,也适合点查询。
如果使用自动分区,按照一定数据量阈值,进行自动拆分range分区,那么就能够解决上述需求。
● 业务的第一个需求是负载均衡,自动分区分裂能够按照数据量阈值大小进行分裂,有助于负载均衡模块达到更好的均衡效果;
● 业务的第二个需求是按照公司 ID,员工 ID 进行点查询,在 Range 分区下,进行一次分区裁剪就能定位到对应的分区,之后在对应的分区查询,效率是比较高的;
● 业务的第三个需求是对员工进行批处理查询,本质上主键的范围查询,在自动分区下通常只会查询其中某个分区,效率也是比较高的;
● 业务的第四个需求是已有分区的数据出现变化,此时达到数据量值后,会重新切分成大小适中的分区,达到动态均衡。
总体来看自动分区存在三个业务价值:
1.自动分区的能够满足不同工作模式下的负载的性能需求。自动分区采用主键或者主键前缀的 Range分区方式,它能够很好地满足数据库中的范围和点查询的需求,并且能够避免手动 Range 分区无法找到合适切分点的问题。
2.自动分区能够满足分布式数据库的负载均衡需求,它会自动地按照数据量对分区进行分裂,在用户无须关注分区键的数据分布规则的前提下,自动生成数据量适合且均衡的分区,使得数据库内部更容易在机器间进行负载均衡。
3.自动分区能够轻松应对变化,当业务的数据分布发生了变化后或业务的数据量发生变化后,可能导致不同分区的数据不均衡,此时自动分区能够按照阈值重新分裂不均衡的分区,使得分区间重新均衡;当业务访问量发生变化,新增了机器后,可能导致机器间的不均衡,此时,自动分区已经切分好了多个大小适合的分区,可以将已有机器上的分区 transfer 到新加的机器上,使得机器间能够更加均衡。
自动分区能够很好地解决手动分区存在的痛点问题,在用户准备用0ceanBase 自动分区之前,通常会关注自动分区对业务的影响以及使用的便捷性等,我将通过对 OceanBase 自动分区的特点介绍,来解答用户关注的问题。
自动分区分裂的特点
OceanBase 自动分区具备三个特点:
1.Online:不阻塞业务的普通 DML 和查询。
2.使用资源少:分裂过程中使用的资源量较少
3.使用简单:只需要打开两个租户级的配置项,就能使用上自动分区分裂功能。
为了避免分裂对正常业务的影响,我们主要做了两方面的工作,一方面,当表上存在业务的普通 DML 和查询时,如果此时做自动分裂,会将查询和 DML的流量自动转移到新分区继续处理,对正在执行的DML 和查询的性能影响比较小;另一方面,我们做了一些优化使得分裂操作本身占用的资源比较少,包括重用大部分的数据、网络只同步逻辑操作等,充分节省了磁盘空间、带宽、网络带宽、CPU 和内存资源等。
我们在系统中只有一个分区的情况下,对这个分区进行分裂,模拟分裂带来影响最显著的场景,观察分裂对性能的影响。在面向 OLTP 场景的 sysbench 场景的测试,我们测试了点查,范围查和写入,性能影响在 4%~8% 左右,参考下图。

实际生产环境中,分区数有很多个,同时在分裂的分区数只有一少部分,此时,分裂的影响会更小。为了让用户方便的使用自动分区,我们对于一些场景,例如全局索引,HBase 等 KV 场景,默认放开了分裂,用户无须配置即可使用,对于其他场景,用户也只需要配置两个租户级的参数,即可使用上自动分裂。
使用场景
当前 OceanBase 在行存表模式下支持了自动分区分裂,所以,它适用于的业务场景主要是行存表所适用的业务场景,包括 KV 场景,例如 OB-HBase,以及 OLTP 场景。
KV 场景
在尚未支持的自动分区的 OceanBase 版本中,默认推荐的是按照 Key 方式进行预分区,分区数量一般设置数百到上千,这种使用方式通常能较好地将数据量进行打散,支持点查的负载,但对于范围扫描的负载不够友好,需要扫描所有的分区,同时 Key 分区的方式把新老数据打散了,不方便做分区级的数据管理。
由于 OceanBase 自动分区一期支持的自动 Range/Range Columns 分区,它继承了 Range 分区的优势之一,比较适合范围扫描的场景,同时它还有普通 Range 分区所不具有的自动按照数据量分裂的能力,将数据量打散。为了避免写热点,在自动分区下,尽量避免按照主键追加写入。如果业务上在读写没有明显的按照主键范围的热点,那么即使业务负载都是点查,也能够使用自动分区将业务的负载打散。
自动扩展的 OLTP
在尚未支持自动分区的 OceanBase 版本中,如果为了更好地利用分布式集群的能力,用户需要结合业务规则设计相关的相关的分区,以便将数据量,业务负载打散到各个节点上。而支持自动分区后,我们可以默认对所有的表都是自动分裂的,用户在业务开始阶段就创建普通的非分区表,当业务体量增长时,由数据库本身自动的进行分区分裂,达到自动的负载均衡。
使用方法
使用入门
要使用自动分区功能,只需要关注两个配置项:
● enable_auto_split:租户级别配置项,控制这个租户是否开启自动分区功能,默认关闭。
● auto_split_tablet_size:租户级别配置项,控制这个租户开启自动分区功能之后触发分裂的阈值,默认值 2GB。
如果用户需要开启自动分区,并且内存资源足够,我们使用ALTER SYSTEM SET enable_auto_split =true,来打开自动分区。由于租户内存资源一般有限制,而我们支持的 tablet 数量跟租户内存大小有关一般经验计算公式是 1GB 能分配 2W 个 tablet,所以,为了避免 tablet 数量过多,我们可以调整auto_split_tablet_size 来避免因数据量太大而分配太多的 tablet。
进阶使用
通过租户级的配置使得用户能够很容易地将自动分区使用起来,但这种使用方式是将租户内所有的业务全部打开自动分区模式。在实际场景中,有可能使用灰度的方式,将业务慢慢地使用上自动分区功能,
两个常见的场景:
1.用户的一个新集群或者新业务,打算上 OceanBase,先对部分表尝鲜自动分区功能,那么可以使用建表时是否开启自动分区来控制

用户的原有的OceanBase集群,升级到支持自动分区的OceanBase版本,并想部分表试用自动分区功能,那么可以使用修改自动分区属性来控制

限制点
当前OceanBase自动分区存在如下限制点
·不支持自动分裂 List、Hash 分区表。
·不支持自动分裂二级分区表。
·不支持被自动分裂的表的分区键与主键前缀不一样。
·不支持无主键表的自动分区分裂。
·不支持列存表的自动分区分裂。
·不支持列存副本的自动分区分裂。
·如果表所在的 TABLEGROUP(表组)里面包含了多张表时,不支持自动分区分裂;如果这个TABLEGROUP 中只有这张表,则支持自动分区分裂。
·不支持物化视图的自动分区分裂。
·不支持全文索引的自动分裂。
利用自动分裂特性,打散数据,提高 SQL 执行效率实验
OceanBase 数据库可以自动的根据分区数据量,对较大的分区进行切分,从而将数据分散到不同的节点。每个节点都可以独立地执行任务,并且可以通过高速的网络互相通信,实现数据的交互和同步,所以分区分裂可以使 SQL 利用更多的节点的资源从而带来更高的执行效率。
环境准备
● 以下示例是在 1-1-1 分布式下 4c 10g 规格的机器上进行的演示,并且为了确保结果的相对稳定,对 observer 的 CPU 使用率限制在了90%。导入数据时间可能过长,请耐心等待。
● 以下示例中的 sysbench 测试结果为非固定,具体已实际执行结果为准。
● 本篇教程以 MySQL 模式为例进行说明。
● test 数据库、temp_tenant 租户已预建完成,不需要手动创建,可直接使用。
● temp_tenant 租户拥有管理权限,已预授权。
● 此处 temp_tenant 租户未设置密码,只供体验使用,在实际环境中,请根据需要配置相关租户密码。
● 本教程已将相关脚本上传至服务器 /root 路径下,可以直接使用。
解压文件夹
tar -xzvf split_test_v9.tar.gz
执行环境准备的脚本
cd /root/split_test_collection/oceanbase/sysbench/lua/ && ./prepare_test_environment.sh
该脚本会创建一个 temp_tenant 租户,配置 4c 10g 的规格的资源,用于接下来的测试。看到 “初始化环境完成” 后可以进行后续实验步骤。
场景1:在不开自动分裂的环境中对单分区表进行数据导入和 sysbench 查询的测试
在不开自动分裂的环境, 对单分区表进行数据导入,以及 sysbench 查询的测试
登陆到目标租户机器
obclient -h0.0.0.0 -P2883 -uroot@temp_tenant -c -A -Dtest
创建一张单分区表
CREATE TABLE IF NOT EXISTS sbtest1(
id int AUTO_INCREMENT,
k INTEGER DEFAULT ‘0’ NOT NULL,
c CHAR(120) DEFAULT ‘’ NOT NULL,
pad CHAR(60) DEFAULT ‘’ NOT NULL,
primary key (id)
) partition by range(id) (
partition p0
values
less than (MAXVALUE)
);
返回终端执行数据插入脚本
cd /root/split_test_collection/oceanbase/sysbench/lua && ./insert_data.sh
利用脚本发起一个 sysbench 随机点查测试
cd /root/split_test_collection/oceanbase/sysbench/lua && ./start_sysbench_test.sh
sysbench 会把本次任务的 QPS 相关统计呈现在终端, 这里主要关注 queries 这一行统计数据 (2685.27 per sec),也就是单分区表,每秒平均执行了 2685.27 次 SQL。
SQL statistics:
queries performed:
read: 268732
write: 0
other: 0
total: 268732
transactions: 268732 (2685.27 per sec.)
queries: 268732 (2685.27 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)

Throughput:
events/s (eps): 2685.2676
time elapsed: 100.0764s
total number of events: 268732

Latency (ms):
min: 2.42
avg: 55.82
max: 227.10
95th percentile: 102.97
sum: 15001277.12

Threads fairness:
events (avg/stddev): 1791.5467/45.19
execution time (avg/stddev): 100.0085/0.01
场景2:在开自动分裂的环境中对单分区表进行数据导入和 sysbench 查询的测试
在打开自动分裂的环境,对单分区表进行数据导入(系统自动分裂该单分区表),以及 sysbench 查询的测试。
登陆到目标租户机器
obclient -h0.0.0.0 -P2883 -uroot@temp_tenant -c -A -Dtest
打开自动分裂功能
打开租户级别自动分裂配置项, 这样后续测试的表, 都会打开自动分裂功能。
alter system set enable_auto_split = true;
新建一张单分区的表
DROP TABLE IF EXISTS sbtest1;

CREATE TABLE sbtest1(
id int AUTO_INCREMENT,
k INTEGER DEFAULT ‘0’ NOT NULL,
c CHAR(120) DEFAULT ‘’ NOT NULL,
pad CHAR(60) DEFAULT ‘’ NOT NULL,
primary key (id)
) partition by range(id) (
partition p0
values
less than (MAXVALUE)
);

quit

返回终端执行数据插入脚本
cd /root/split_test_collection/oceanbase/sysbench/lua && ./insert_data.sh
发起一次冻结
登陆到目标租户机器, 发起一次冻结, 用于加速分裂调度(实际生产环境中这一步并不是必要的)。
obclient -h0.0.0.0 -P2883 -uroot@temp_tenant -c -A -Dtest
alter system minor freeze;
quit
登陆到系统租户
返回终端,随后登陆到系统租户,查询等待系统完成自动分裂。
obclient -h0.0.0.0 -P2883 -uroot@sys -c -A -Doceanbase
执行下列 SQL 可查看测试表 sbtest1 各 tablet 主副本(leader)所在的节点信息。

  1. 如果查询结果中不同的 (svr_ip, svr_port) 组合数量 ≥ 3,说明该表的 tablet 已均匀分布在集群全部机器上,此时即可开始性能测试。
  2. 若不足 3 个,请再等待 4 – 5 分钟, 至到系统自动将该表的 tablet 分裂打散到集群不同机器。
    SELECT C.tablet_id,
    C.ls_id,
    D.svr_ip,
    D.svr_port
    FROM __all_virtual_ls_meta_table AS D
    JOIN
    ( SELECT tenant_id,
    A.tablet_id,
    ls_id
    FROM __all_virtual_tablet_to_ls AS A
    JOIN
    ( SELECT tablet_id,
    part_name
    FROM __all_virtual_part
    WHERE table_id =
    ( SELECT table_id
    FROM __all_virtual_table
    WHERE TABLE_NAME = ‘sbtest1’ ) ) AS B ON A.tablet_id = B.tablet_id ) AS C ON C.ls_id = D.ls_id
    WHERE D.role = 1
    AND D.tenant_id =
    ( SELECT tenant_id
    FROM __all_tenant
    WHERE tenant_name = ‘temp_tenant’ );

quit
3. 输入 quit 返回终端, 并利用脚本发起一个 sysbench 随机点查测试。
cd /root/split_test_collection/oceanbase/sysbench/lua && ./start_sysbench_test.sh
4. 最终 sysbench 脚本将会把本次任务的 QPS 相关统计呈现在终端,这里我们主要关注 queries 这一行统计数据(4751.77 per sec)。也就是打开分区分裂后,每秒平均执行了4751.77 次 SQL。
SQL statistics:
queries performed:
read: 475730
write: 0
other: 0
total: 475730
transactions: 475730 (4751.77 per sec.)
queries: 475730 (4751.77 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)

Throughput:
events/s (eps): 4751.7732
time elapsed: 100.1163s
total number of events: 475730

Latency (ms):
min: 0.75
avg: 31.54
max: 1066.05
95th percentile: 99.33
sum: 15005723.95

Threads fairness:
events (avg/stddev): 3171.5333/89.71
execution time (avg/stddev): 100.0382/0.03
sysbench 测试结果总结
核心优势
OceanBase 的自动分裂特性通过将大数据分区自动切分并分散到不同节点,相比与单分区无分裂实现了以下提升:
性能提升显著
吞吐量提升:近 1.7 倍的增长, 从 2685.27 TPS 提升至 4751.77 TPS。
延迟表现优秀
● 平均延迟:降低 63%,从 41.62 ms 降至 15.31 ms。
● 95%分位延迟:降低 44%, 从 94.10 ms 降至 52.89 ms。
● 最小延迟:降低 71%, 从 1.46 ms 降至 0.43 ms。
负载均衡优化
● 资源利用率:多节点并行处理能力得到充分利用。
结论
这些数据充分证明了 OceanBase 自动分裂特性提高了 SQL 执行效率,是发挥分布式数据库优势的重要技术手段。

参考链接:https://open.oceanbase.com/course/detail/12749

http://www.lryc.cn/news/611900.html

相关文章:

  • 虚幻GAS底层原理解剖四 (TAG)
  • 《爬虫实战指南:轻松获取店铺详情,开启数据挖掘之旅》
  • Adobe Analytics 数据分析平台|全渠道客户行为分析与体验优化
  • 时隔六年!OpenAI 首发 GPT-OSS 120B / 20B 开源模型:性能、安全与授权细节全解
  • 【WAIC 2025】AI安全的攻防前线:合合信息AI鉴伪检测技术
  • 算法训练营DAY55 第十一章:图论part05
  • 支持向量机(SVM)算法依赖的数学知识详解
  • 非机动车识别mAP↑28%!陌讯多模态融合算法在智慧交通的实战解析
  • Unity里的对象旋转数值跳转问题的原理与解决方案
  • Linux《进程间通信(上)》
  • Android 之 Kotlin中的符号
  • Linux---第二天---基础指令
  • 基于Python的超声波OFDM数字通信链路设计与实现
  • 2024年测绘程序设计比赛--空间探索性分析(数据为2025年第三次模拟数据)
  • 基于MCP提示构建工作流程自动化的实践指南
  • ipv6学习
  • ESP32:2.搭建UDP服务器
  • Wireshark协助捕获信号波形
  • 强化应急通信生命线:遨游三防平板、卫星电话破局极端灾害救援
  • OpenWebUI通过pipeline对接dify的workflow
  • 5G随身WiFi怎么选?实测延迟/网速/续航,中兴V50适合商务,格行MT700适合短租、户外党~避坑指南+适用场景全解析
  • 5G毫米波射频前端测试:OTA暗室与波束成形性能验证
  • 中宇联5G云宽带+4G路由器:解锁企业办公高效协同与门店体验升级
  • GPU 优化-用 tensor core实现5G Massive MIMO 64x64
  • Solidity:接口与实现的“契约”关系研究,以Uniswap V3为例
  • Lesson 31 Success story
  • 【动态规划 | 01背包】动态规划经典:01背包问题详解
  • 虚拟机磁盘扩容
  • 深度解读丨利用 DeepSeek 开放权重模型推动悦数 Graph RAG AI 开发平台创新
  • WinXP配置一键还原的方法