OBCE 第三章实验 内存管理手动实践 深入了解Queuing(buffer)表

本文主要是介绍OBCE 第三章实验 内存管理手动实践 深入了解Queuing(buffer)表,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

实验环境:oceanbase 企业版V3 1-1-1 架构。

1.查看当前资源情况

select unit_config_id,name,max_cpu,min_cpu,round(max_memory/1024/1024/1024) max_mem_gb, round(min_memory/1024/1024/1024) min_mem_gb, round(max_disk_size/1024/1024/1024) max_disk_size_gb  from __all_unit_config  order by unit_config_id;

2.黑屏创建oracle租户

(1)创建unit

CREATE RESOURCE UNIT unit1 MAX_CPU 3, MAX_MEMORY '6G', MAX_IOPS 10000,MAX_DISK_SIZE '500G', MAX_SESSION_NUM 1000, MIN_CPU=3, MIN_MEMORY='6G',MIN_IOPS=1000;

(2)创建资源池

create resource pool ora_pool_test unit = 'unit1',unit_num = 1;

(3)创建oracle租户

create tenant ob_ora resource_pool_list=('ora_pool_test'), primary_zone='RANDOM',comment 'oracle tenant/instance', charset='utf8' set ob_tcp_invited_nodes='%', ob_compatibility_mode='oracle';

这样我们就有了租户资源规格大小为 3C6G 的oracle类型租户。

开始实验:
 

步骤 1 登录 Oracle 租户的 sys 用户(注意不是 sys 租户),查看修改前参数值;修改隐含参数 _ob_queuing_fast_freeze_min_count 的默认值,此参数限制 delete 语句到达这个阈值 后, 触发对 queuing 表执行转储的操作;

show parameters like '_ob_queuing_fast_freeze_min_count';
alter system set "_ob_queuing_fast_freeze_min_count"=20000;

上面这个参数查不到值 ,应该类似于oracle 的隐含参数,目前还没搞清楚ob中oracle租户的隐含参数怎么查询,但可以直接修改。

步骤 2 创建并登录 tpcc 用户,授予 dba 权限,创建 2 张表,一张表为普通表,另外一个为 queuing 表

create user tpcc identified by obce_test;
grant dba to tpcc;
drop table tab_no_queue purge; 
drop table tab_queue purge; 
create table tab_no_queue (id int primary key, name varchar(10), contact 
varchar(20), addr varchar(100)); 
create table tab_queue(id int primary key, name varchar(10), contact varchar(20), 
addr varchar(100)) table_mode='queuing';

步骤3 查看两个表的主副本位置

SELECTtenant.tenant_name,meta.table_id,tab.table_name,partition_id,ZONE,svr_ip,svr_port,CASEWHEN ROLE = 1 THEN 'leader'WHEN ROLE = 2
THEN 'follower'ELSE NULLEND AS ROLE,tab.primary_zone
FROM__all_virtual_meta_table meta
INNER JOIN __all_tenant tenant ONmeta.tenant_id = tenant.tenant_id
INNER JOIN __all_virtual_table tab ONmeta.tenant_id = tab.tenant_idAND meta.table_id = tab.table_id
WHEREtenant.tenant_id = 1004
ORDER BYtenant.tenant_name,table_name,partition_id,ZONE;

步骤4 向表 tab_no_queue 添加测试数据

insert into tab_no_queue select level, 
case mod(level,5) 
when 0 then '张一'
when 1 then '李一'
when 2 then '王一'
when 3 then '赵一'
when 4 then '钱一'
else null
end
, '1234567890','Asia-China-Sichuan-Chengdu' 
from dual where mod(level,5)=3 connect by level <=200000;
commit;

我这里把50w变成了20w 执行了两次,不然很容易报

步骤5 执行一次表和租户级别的转储, 避免以上插入操作对本实验的影响

ALTER SYSTEM MINOR FREEZE TENANT=(ob_ora);

步骤6 确认转储成功

SELECT * FROM __all_zone WHERE name='merge_status';

查看 gv$merge_info,确认转储发生时间

select * from gv$merge_info where table_id =1103909674337105 order by start_time  desc limit 6;

步骤 7 执行批量 insert 语句,模拟此表被应用插入新数据的场景

insert into tab_no_queue select level, 
case mod(level,5) 
when 0 then '张一'
when 1 then '李一'
when 2 then '王一'
when 3 then '赵一'
when 4 then '钱一'
else null
end, '1234567890','Asia-China-Sichuan-Chengdu' from dual where mod(level,5) in (2) 
connect by level <=150000;
commit; 

步骤 8 登陆 sys 租户,查看 tab_no_queue 表在 memstore 的内存消耗情况, 关注 used_mb 字段值

select ip,table_id,partition_id,round(used/1024/1024,1) as used_mb,hash_items,btree_items,is_active from gv$memstore_info 
where table_id =1103909674337105;

步骤 9 模拟修改表的操作,了解多版本数据对 memstore 内存的使用

update tab_no_queue set name = '王二' where mod(id,5) in (2);
commit;

步骤 10 删除记录, 观察是否触发系统转储,理解隐含参数 ob_queuing_fast_freeze_min_count 的含义, 得出结果此参数对非 queuing 表无效

delete from tab_no_queue where mod(id,5) in (2);
commit;

步骤 11 查看表 tab_no_queue 的转储情况,确认没有转储

select * from gv$merge_info where table_id =1103909674337105 order by start_time 
desc limit 6;

再次执行 insert 和 delete 操作, 观察 tab_no_queue 表的转储情况, 确认没有转储发生
insert into tab_no_queue
select level, 
case mod(level,5) 
when 0 then '张一'
when 1 then '李一'
when 2 then '王一'
when 3 then '赵一'
when 4 then '钱一'
else null
end
, '1234567890','Asia-China-Sichuan-Chengdu' 
from dual 
where mod(level,5) in (4) 
connect by level <=150000;
delete from tab_no_queue where mod(id,5) in (4);
commit;

步骤 12 对 tab_no_queue 执行全表扫描, 查看 gv$sql_audit 的执行信息 , 注意 execute_time 时间(86744),记录与后面的 queuing 表对比。

select 
svr_ip,query_sql,trace_id,sql_id,plan_id,is_hit_plan,plan_type,elapsed_time, 
execute_time,get_plan_time,table_scan,memstore_read_row_count, 
ssstore_read_row_count from gv$sql_audit where tenant_id=1004 and query_sql like 
'select%, count(*) from tab_no_queue%';

步骤 13 对 tab_queue 表(queuing 表)执行以上相同的步骤,查询表 tab_queue 的 table_id 和 leader 副本所在的 Observer IP 地址; 注意 tenant_id 根据实际 tenant_id(我这里是1004), 记录 table_id(1103909674337106)和 IP(127.0.0.1)

select tenant.tenant_name,meta.table_id, tab.table_name, 
partition_id,zone,svr_ip,svr_port, case when role=1 then 'leader' when role=2 
then 'follower' else null end as role, tab.primary_zone from 
__all_virtual_meta_table meta inner join __all_tenant tenant on 
meta.tenant_id=tenant.tenant_id inner join __all_virtual_table tab on 
meta.tenant_id=tab.tenant_id and meta.table_id=tab.table_id where 
tenant.tenant_id=1004 and tab.table_name='TAB_QUEUE' order by 
tenant.tenant_name,table_name,partition_id,zone;

步骤 14 向 queuing 表(tab_queue)添加测试数据

insert into tab_queue select level, 
case mod(level,5) 
when 0 then '张一'
when 1 then '李一'
when 2 then '王一'
when 3 then '赵一'
when 4 then '钱一'
else null
end
, '1234567890','Asia-China-Sichuan-Chengdu' 
from dual where mod(level,5)=3 connect by level <=200000;
commit; 

这里level这个测试参数还是改为200000。

步骤 15 执行一次表和租户级别的转储, 避免以上插入操作对本实验的影响

ALTER SYSTEM MINOR FREEZE TENANT=(ob_ora);

步骤 16 确认转储结束

SELECT * FROM __all_zone WHERE name='merge_status';

 查看 gv$merge_info,确认转储发生时间
select * from gv$merge_info where table_id =1103909674337106 order by start_time 
desc limit 6;

 步骤 17 执行批量 insert 语句,模拟此表被应用插入新数据的场景

insert into tab_queue select level, 
case mod(level,5) 
when 0 then '张一'
when 1 then '李一'
when 2 then '王一'
when 3 then '赵一'
when 4 then '钱一'
else null
end, '1234567890','Asia-China-Sichuan-Chengdu' from dual where mod(level,5) in (2) 
connect by level <=150000;
commit;

步骤 18 登陆 sys 租户,查看 tab_queue 表在 memstore 的内存消耗情况, 关注 used_mb 字段值

select ip,table_id,partition_id,round(used/1024/1024,1) as 
used_mb,hash_items,btree_items,is_active from gv$memstore_info where table_id = 1103909674337106;

步骤 19 模拟修改表的操作 ,了解多版本数据对 memstore 内存的使用 

update tab_queue set name = '王二' where mod(id,5) in (2);
commit;

 

步骤 20 再次查看此步骤的内存消耗,可以看到 update 语句消耗更多内存

select ip,table_id,partition_id,round(used/1024/1024,1) as 
used_mb,hash_items,btree_items,is_active from gv$memstore_info where table_id = 1103909674337106;

 

步骤 21 删除记录,观察是否触发系统转储,理解隐含参数 ob_queuing_fast_freeze_min_count 的含义

delete from tab_queue where mod(id,5) in (2);
commit;

 

步骤 22 查看表 tab_queue 的转储情况, 确认发生转储的信息(若没有立即发现转储发生,可以等 待 30 秒左右,多次执行此命令)

select * from gv$merge_info where table_id =1103909674337106 order by start_time 
desc limit 6;

步骤 23 再次执行 insert 和 delete 操作,观察 tab_queue 表的转储情况, 确认发生一次新的转储

insert into tab_queue
select level, 
case mod(level,5) 
when 0 then '张一'
when 1 then '李一'
when 2 then '王一'
when 3 then '赵一'
when 4 then '钱一'
else null
end
, '1234567890','Asia-China-Sichuan-Chengdu' 
from dual 
where mod(level,5) in (4) 
connect by level <=150000;
delete from tab_queue where mod(id,5) in (4);
commit; 

(思考:比较和非 queuing 表 tab_no_queue 的转储情况,可以看到 tab_queue 在 delete 语句满足隐含参数(_ob_queuing_fast_freeze_min_count)设定的阈值时,立刻发生自 动转储,随即执行了 queuing 表独有的 buf minor merge,把刚刚转储生成的 mini sstable 与 major sstable 合并成一个 minor sstable,这个操作有利于对 queuing 表的全表扫描效率)

步骤 24 对 tab_queue 执行全表扫描, 查看 gv$sql_audit 的执行信息 , 注意 execution_time 时 间, 对比与非 queuing 表的执行时间, queuing 表明显缩短。

select 
svr_ip,query_sql,trace_id,sql_id,plan_id,is_hit_plan,plan_type,elapsed_time, 
execute_time,get_plan_time,table_scan,memstore_read_row_count, 
ssstore_read_row_count from gv$sql_audit where tenant_id=1004 and query_sql like 
'select%, count(*) from tab_queue%';

 

官网结论:从 queuing 表和 no queuing 表的执行时间对比结果得出,queue 表在用户多次执 行 DML 语句后造成内存数据增加,但是对批量 delete 语句自动转储对查询链路增加的问题 进行了优化, queuing 表的全表扫描总耗时大大减少

个人结论: 在oceanbase 的LSM-tree 架构中,对表进行DML操作,因为oceanbase是准内存性数据库,所以中间的记录都会在内存中记录,有点像PG中update方式(PG中update操作会先insert 再给原数据打上delete,但数据并没有真正删除)。所以当表中比较频繁的执行DML操作的时候,就会占用大量的内存,并且在做查询的时候也会扫描已经打上delete的数据块。PG中有autovacuum来清理数据块,oceanbase中也有buffer(Queuing表)来解决这个问题,对于table_mode='queuing' 的表,

当删除的数据量达到 _ob_queuing_fast_freeze_min_count

或删除的比例达到_ob_queuing_fast_freeze_min_threshold 则直接开始转储。

官网中有很明确的buffer(Queuing表)转储策略图:

 

我们在做实验的时候也可以看到明确的buf minor merge 标记,也可以看到 非buffer表的execute时间 38361 明显 大于buffer表的execute时间 13967。并且非buffer表没有自适应的转储策略。

文章有参考自官网OBCE 培训学习资料-官网内存管理学习资料

这篇关于OBCE 第三章实验 内存管理手动实践 深入了解Queuing(buffer)表的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1130597

相关文章

Spring Security简介、使用与最佳实践

《SpringSecurity简介、使用与最佳实践》SpringSecurity是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架,本文给大家介绍SpringSec... 目录一、如何理解 Spring Security?—— 核心思想二、如何在 Java 项目中使用?——

防止Linux rm命令误操作的多场景防护方案与实践

《防止Linuxrm命令误操作的多场景防护方案与实践》在Linux系统中,rm命令是删除文件和目录的高效工具,但一旦误操作,如执行rm-rf/或rm-rf/*,极易导致系统数据灾难,本文针对不同场景... 目录引言理解 rm 命令及误操作风险rm 命令基础常见误操作案例防护方案使用 rm编程 别名及安全删除

C++统计函数执行时间的最佳实践

《C++统计函数执行时间的最佳实践》在软件开发过程中,性能分析是优化程序的重要环节,了解函数的执行时间分布对于识别性能瓶颈至关重要,本文将分享一个C++函数执行时间统计工具,希望对大家有所帮助... 目录前言工具特性核心设计1. 数据结构设计2. 单例模式管理器3. RAII自动计时使用方法基本用法高级用法

PHP应用中处理限流和API节流的最佳实践

《PHP应用中处理限流和API节流的最佳实践》限流和API节流对于确保Web应用程序的可靠性、安全性和可扩展性至关重要,本文将详细介绍PHP应用中处理限流和API节流的最佳实践,下面就来和小编一起学习... 目录限流的重要性在 php 中实施限流的最佳实践使用集中式存储进行状态管理(如 Redis)采用滑动

SpringBoot 多环境开发实战(从配置、管理与控制)

《SpringBoot多环境开发实战(从配置、管理与控制)》本文详解SpringBoot多环境配置,涵盖单文件YAML、多文件模式、MavenProfile分组及激活策略,通过优先级控制灵活切换环境... 目录一、多环境开发基础(单文件 YAML 版)(一)配置原理与优势(二)实操示例二、多环境开发多文件版

ShardingProxy读写分离之原理、配置与实践过程

《ShardingProxy读写分离之原理、配置与实践过程》ShardingProxy是ApacheShardingSphere的数据库中间件,通过三层架构实现读写分离,解决高并发场景下数据库性能瓶... 目录一、ShardingProxy技术定位与读写分离核心价值1.1 技术定位1.2 读写分离核心价值二

深入浅出Spring中的@Autowired自动注入的工作原理及实践应用

《深入浅出Spring中的@Autowired自动注入的工作原理及实践应用》在Spring框架的学习旅程中,@Autowired无疑是一个高频出现却又让初学者头疼的注解,它看似简单,却蕴含着Sprin... 目录深入浅出Spring中的@Autowired:自动注入的奥秘什么是依赖注入?@Autowired

MySQL分库分表的实践示例

《MySQL分库分表的实践示例》MySQL分库分表适用于数据量大或并发压力高的场景,核心技术包括水平/垂直分片和分库,需应对分布式事务、跨库查询等挑战,通过中间件和解决方案实现,最佳实践为合理策略、备... 目录一、分库分表的触发条件1.1 数据量阈值1.2 并发压力二、分库分表的核心技术模块2.1 水平分

Redis实现高效内存管理的示例代码

《Redis实现高效内存管理的示例代码》Redis内存管理是其核心功能之一,为了高效地利用内存,Redis采用了多种技术和策略,如优化的数据结构、内存分配策略、内存回收、数据压缩等,下面就来详细的介绍... 目录1. 内存分配策略jemalloc 的使用2. 数据压缩和编码ziplist示例代码3. 优化的

SpringBoot集成XXL-JOB实现任务管理全流程

《SpringBoot集成XXL-JOB实现任务管理全流程》XXL-JOB是一款轻量级分布式任务调度平台,功能丰富、界面简洁、易于扩展,本文介绍如何通过SpringBoot项目,使用RestTempl... 目录一、前言二、项目结构简述三、Maven 依赖四、Controller 代码详解五、Service