OB的不同编码格式压缩率如何

原创张瑞远 2024-10-29

239

引言：

一直以来我只是理解OB的存储高压缩率与LSM的架构以及编码格式有关，但是具体不同的编码格式存储率如何不是很清楚，最近我们遇到一个历史库迁移到ob的场景，有大表的索引创建失败，迁移完数据之后存储使用率70%左右，创建索引的时候，会占用临时空间导致磁盘使用率膨胀，剩余磁盘空间不足导致失败。尝试过先建索引后导数，但是效率不能接受。虽然直接扩容资源是最快的解决方式，我就想看看有没有更高压缩率的编码格式可以解决这个问题。

其实索引创建时占用空间评估官网也有资料， https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000568556?back=kb ，包括obdiag工具现在2.4版本也做了响应功能 https://open.oceanbase.com/blog/14027556898?_gl=1*us51pf*_ga*MjA4NzUwNzIzMy4xNjYxOTI3NjYz*_ga_T35KTM57DZ*MTcyODYzOTQ0Ni40NzYuMS4xNzI4NjQwMTU2LjM3LjAuMA.. 如果有类似的隐患可以创建索引前先检查下。当然我这次重点不是分析索引创建使用空间的问题，而是测试不同编码的不同数据压缩率。

结论：

为了节约大家时间我先放结论（我是在oracel模式下的租户测试的测试表是int，varchar2，date混合的数据类型），可以看出默认的格式压缩率就是最高的。

1728640684

其实还有个问题，跟林春老师也聊过，在一些场景，能不能调整编码格式，压缩率更低，能不能减少一些解压缩的消耗，提升一些sql效率，这个问题以后有机会测试下。

测试过程：

测试版本是4.2.1的把呢不能

测试过程相对不复杂，造了一张0.58g的测试表。

统计该表存储大小的语句用的如下sql。

select  a.table_id,a.table_name,b.database_name,e.svr_ip,e.role,  
case when d.table_type=0 then 'DATA_MEMTABLE' 
when d.table_type=1 then 'TX_DATA_MEMTABLE'  
when d.table_type=2 then 'TX_CTX_DATA_MEMTABLE' 
when d.table_type=3 then 'LOCK_MEMTABLE'  
when d.table_type=10 then 'MAJOR_SSTABLE'
when d.table_type=11 then 'MINOR_SSTABLE' 
when d.table_type=12 then 'MINI_SSTABLE' 
when d.table_type=13 then 'META_MAJOR_SSTABLE'  
when d.table_type=14 then 'DDL_DUMP_SSTABLE' 
when d.table_type=15 then 'REMOTE_LOGICAL_MINOR_SSTABLE'  
when d.table_type=16 then 'DDL_MEM_SSTABLE' ELSE 'UNKNOW' end as table_type ,round(d.size/1024/1024/1024,4) as size_g, round(d.data_block_count*2/1024,4) as block_size_g  
from  __all_virtual_table a  
inner join __all_virtual_database b   
on a.database_id=b.database_id  and a.tenant_id=b.tenant_id  
inner join  __all_virtual_tablet_to_ls c 
on  a.table_id=c.table_id   
inner join  __all_virtual_table_mgr  d 
on  c.tablet_id=d.tablet_id  
inner join  CDB_OB_TABLE_LOCATIONS e 
on e.table_name=a.table_name 
and    e.database_name=b.database_name and e.svr_ip=d.svr_ip and a.TABLE_ID=e.TABLE_ID  and e.tablet_id=d.tablet_id  
where a.table_name='t_tg_dict'  and b.database_name='sys'   and a.tenant_id=1002 order by  svr_ip,svr_ip;

首先修改了表的渐进合并到一次

   alter table t_tg_dict set progressive_merge_num=1;

合并之后再观察可以看到只有一个MAJOR_SSTABLE，当然如果短时间内多次合并，也可能会存在多份MAJOR_SSTABLE。

+----------+------------+---------------+--------------+----------+---------------+--------+--------------+
| table_id | table_name | database_name | svr_ip       | role     | table_type    | size_g | block_size_g |
+----------+------------+---------------+--------------+----------+---------------+--------+--------------+
|   500007 | T_TG_DICT  | SYS           | 111.11.111.2 | FOLLOWER | MAJOR_SSTABLE | 0.5810 |       0.5918 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.4 | LEADER   | MAJOR_SSTABLE | 0.5810 |       0.5918 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.6 | FOLLOWER | MAJOR_SSTABLE | 0.5810 |       0.5918 |
+----------+------------+---------------+--------------+----------+---------------+--------+--------------+

然后修改表的编码格式。

alter table t_tg_dict COMPRESS FOR QUERY;

再次合并后再次查询

+----------+------------+---------------+--------------+----------+---------------+--------+--------------+
| table_id | table_name | database_name | svr_ip       | role     | table_type    | size_g | block_size_g |
+----------+------------+---------------+--------------+----------+---------------+--------+--------------+
|   500007 | T_TG_DICT  | SYS           | 111.11.111.2 | FOLLOWER | MAJOR_SSTABLE | 2.1797 |       2.2148 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.4 | LEADER   | MAJOR_SSTABLE | 2.1797 |       2.2148 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.6 | FOLLOWER | MAJOR_SSTABLE | 2.1797 |       2.2148 |
+----------+------------+---------------+--------------+----------+---------------+--------+--------------+

下面看个合并的比较频繁的例子，出现了不同大小的major_sstable。

alter table t_tg_dict NOCOMPRESS; 修改了一次编码格式之后合并，之后再查询
+----------+------------+---------------+--------------+----------+---------------+---------+--------------+
| table_id | table_name | database_name | svr_ip       | role     | table_type    | size_g  | block_size_g |
+----------+------------+---------------+--------------+----------+---------------+---------+--------------+
|   500007 | T_TG_DICT  | SYS           | 111.11.111.2 | FOLLOWER | MAJOR_SSTABLE |  2.1797 |       2.2148 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.2 | FOLLOWER | MAJOR_SSTABLE |  2.1797 |       2.2148 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.2 | FOLLOWER | MAJOR_SSTABLE | 40.3586 |      40.8516 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.4 | LEADER   | MAJOR_SSTABLE |  2.1797 |       2.2148 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.4 | LEADER   | MAJOR_SSTABLE |  2.1797 |       2.2148 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.4 | LEADER   | MAJOR_SSTABLE | 40.3586 |      40.8516 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.6 | FOLLOWER | MAJOR_SSTABLE |  2.1797 |       2.2148 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.6 | FOLLOWER | MAJOR_SSTABLE |  2.1797 |       2.2148 |
|   500007 | T_TG_DICT  | SYS           | 111.11.111.6 | FOLLOWER | MAJOR_SSTABLE | 40.3586 |      40.8516 |
+----------+------------+---------------+--------------+----------+---------------+---------+--------------+

总结：

从这次简单的测试结果来看，默认的编码方式已经是压缩率最优的情况了，那我们只能通过扩容的方式解决该问题了，别的朋友遇到类似风险的时候，也可以按照最上面的两个链接里的方式评估下。

行之所向，莫问远方。

墨力计划 oceanbase

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

OB的不同编码格式压缩率如何

引言：

结论：

测试过程：

总结：

评论