阳泉软件定制网站建设,微信小程序开发编辑器,郑州网站网络推广公司,麦田 网站建设问题描述
某保险行业客户的核心系统#xff0c;从Oracle 迁移到OceanBase之后#xff0c;发现数据存储空间出现膨胀问题#xff0c;数据空间 datasize9857715.48M#xff0c;实际存储占用空间17790702.00M。根据 required_mb - data_mb 值判断#xff0c;数据空洞较为严重…问题描述
某保险行业客户的核心系统从Oracle 迁移到OceanBase之后发现数据存储空间出现膨胀问题数据空间 datasize9857715.48M实际存储占用空间17790702.00M。根据 required_mb - data_mb 值判断数据空洞较为严重。因此客户提出需求要降低存储空间。 上图查询sql参考空洞情况检查方法
原因分析
OceanBase 存储出现空洞的原因OceanBase的数据文件SSTABLE按照主键顺序进行存储如果业务数据插入比较离散期间有合并时2M宏块出现分裂会导致数据空洞率提升进而导致存储空间大于数据数据空间 这种现象多见于业务主键非递增插入的场景。
解决方法
对空洞较大的表强制执行全量合并
强制执行全量合并不执行渐进合并。
对于新建表set default_progressive_merge_num1。对于现存表ALTER TABLE $table SET progressive_merge_num1; 这样把需要的表设置上再进行合并。
注意全量合并会消耗大量资源需要设置完之后再设置回0。
progressive_merge_num值说明
0 表示执行渐进合并且渐进合并的次数为 100。1表示强制执行全量合并不执行渐进合并。大于 1 表示发生 Schema 变更时按照指定轮次做渐进合并。
空洞情况检查方法
select avd.database_name,
avt.tenant_id,
Case avt.table_type
When 3 Then
TABLE
When 5 Then
INDEX
ElseEnd As segment_type,
Case avt.table_type
When 3 Then
Sum(avmt.row_count)
ElseEnd As row_count,
round(Sum(avmt.data_size) / 1024 / 1024, 2) As data_mb,
round(Sum(avmt.required_size) / 1024 / 1024, 2) As required_mb
From __all_virtual_table avt
Inner Join __all_virtual_partition_table avmt
On avt.tenant_id avmt.tenant_id
And avt.table_id avmt.table_id
Inner Join __all_virtual_database avd
On avt.database_id avd.database_id
And avt.tenant_id avd.tenant_id
Where avmt.role 1
And table_type In (3, 5)
Group By avd.database_name, table_type, avt.tenant_id
Order By database_name, table_type;/*
select table_type, index_status, index_type, part_level from __all_virtual
_table;
table_type: 系统表(0),系统视图(1),虚拟表(2),用户表(3)用户视图(4)索引表(5)
index_status: 不可用(1)可用(2)
index_type: 局部普通索引(1),局部唯一索引(2),全局普通索引(3),全局唯一索引(4),主键索
引(5)
part_level: 不分区(0)一级分区(1)二级分区(2)
__all_virtual_meta_table 是基线数据
__all_virtual_storage_stat 是基线加转储数据
*/
合并管理概述
合并操作Major Compaction是将动静态数据做归并会比较费时。当转储产生的增量数据积累到一定程度时通过 Major Freeze 实现大版本的合并。合并与转储的最大区别在于合并是集群上所有的分区在一个统一的快照点和全局静态数据进行合并的行为是一个全局的操作最终形成一个全局快照。
合并分类
按照合并数据量合并可以分为
全量合并将静态数据全部读出并和动态数据合并为最终的静态数据。合并时间长耗费 IO 和 CPU。增量合并仅仅合并被修改过的宏块没有改变的宏块进行复用。增量合并极大地减少了合并的工作量是 OceanBase 数据库目前默认的合并算法。渐进合并每次全量合并一部分若干轮次后整体数据被重写一遍。并行合并将数据划分到不同线程中并行做合并。
全量合并与渐进合并
渐近合并是什么
OceanBase在设计之初就考虑到了Online DDL的需求目前在OceanBase中加列、减列、建索引等DDL操作都是不阻塞读写的也不会影响到多副本间的paxos同步。加减列的DDL变更是实时生效的OB将对存储数据的变更延后到每日合并的时候来做。和Mysql一样对于某些DDL操作如加减列等OB是需要将所有数据重写一遍的如果在一次每日合并过程中完成对所有数据的重写那么对存储空间和合并时间都会是一个比较大的考验。为了解决这个问题OB引入了渐进合并既然一次合并做代价太大那就搞多次。OB会将DDL变更造成的数据重写分散到多次每日合并中去做假设把渐进轮次设置为60那么一次合并就只会重写60分之一的数据在60轮合并过后数据就被整体重写了一遍。渐进合并减轻了DBA做DDL操作的负担同时也使得DDL变更更加平滑。
渐近合并的参数
schema中的progressive_merge_num属性来决定渐近的轮次假设progressive_merge_num5表示5轮合并重写完major sstable。 schema中的progressive_merge_round表示本次合并所处的渐近合并轮次
如何指定全量合并
当progressive_merge_num0或1时如果发生了DDL对于存储层的变更会在一轮合并中重写掉major sstable
全量合并与非全量合并
全量合并所有宏块不重用全部打开重写 非全量合并宏块会重用只打开有数据变更的宏块 当执行渐近合并时只有本次渐近轮次相关的宏块会做全量合并其他部分做非全量合并
