OceanBase 应用实践：如那里理数据空洞，低沉存储空间

问题形貌

某保险行业客户的核心体系，从Oracle 迁徙到OceanBase之后，发现数据存储空间出现膨胀问题，数据空间 datasize=9857715.48M，实际存储占用空间17790702.00M。根据 required_mb - data_mb 值判定，数据空洞较为严重。因此客户提出需求，要低沉存储空间。

上图查询sql参考：空洞情况查抄方法
缘故起因分析

OceanBase 存储出现空洞的缘故起因：OceanBase的数据文件SSTABLE按照主键顺序进行存储，如果业务数据插入比力离散，期间有归并时，2M宏块出现分裂会导致数据空洞率提拔，进而导致存储空间大于数据数据空间， 这种现象多见于业务主键非递增插入的场景。
解决方法

对空洞较大的表强制实行全量归并
强制实行全量归并，不实行渐进归并。

• 对于新建表：set default_progressive_merge_num=1。
  
• 对于现存表：ALTER TABLE $table SET progressive_merge_num=1; 这样把需要的表设置上，再进行归并。
  

注意：全量归并会消耗大量资源，需要设置完之后再设置回0。
progressive_merge_num值说明：

• 0 ：表示实行渐进归并，且渐进归并的次数为 100。
  
• 1：表示强制实行全量归并，不实行渐进归并。
  
• 大于 1 ：表示发生 Schema 变动时按照指定轮次做渐进归并。
  

空洞情况查抄方法

1. select avd.database_name,
2. avt.tenant_id,
3. Case avt.table_type
4. When 3 Then
5. 'TABLE'
6. When 5 Then
7. 'INDEX'
8. Else
9. ''
10. End As segment_type,
11. Case avt.table_type
12. When 3 Then
13. Sum(avmt.row_count)
14. Else
15. ''
16. End As row_count,
17. round(Sum(avmt.data_size) / 1024 / 1024, 2) As data_mb,
18. round(Sum(avmt.required_size) / 1024 / 1024, 2) As required_mb
19. From __all_virtual_table avt
20. Inner Join __all_virtual_partition_table avmt
21. On avt.tenant_id = avmt.tenant_id
22. And avt.table_id = avmt.table_id
23. Inner Join __all_virtual_database avd
24. On avt.database_id = avd.database_id
25. And avt.tenant_id = avd.tenant_id
26. Where avmt.role = 1
27. And table_type In (3, 5)
28. Group By avd.database_name, table_type, avt.tenant_id
29. Order By database_name, table_type;
31. /*
32. select table_type, index_status, index_type, part_level from __all_virtual
33. _table;
34. table_type: 系统表(0),系统视图(1),虚拟表(2),用户表(3)，用户视图(4)，索引表(5)
35. index_status: 不可用(1)，可用(2)
36. index_type: 局部普通索引(1),局部唯一索引(2),全局普通索引(3),全局唯一索引(4),主键索
37. 引(5)
38. part_level: 不分区(0)，一级分区(1)，二级分区(2)
39. __all_virtual_meta_table 是基线数据
40. __all_virtual_storage_stat 是基线加转储数据
41. */

复制代码

归并管理概述

归并操纵（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_num=5，表示5轮归并重写完major sstable。 schema中的progressive_merge_round表示本次归并所处的渐近归并轮次
如何指定全量归并

当progressive_merge_num=0或1时，如果发生了DDL对于存储层的变动，会在一轮归并中重写掉major sstable
全量归并与非全量归并

全量归并：所有宏块不重用，全部打开重写
非全量归并：宏块会重用，只打开有数据变动的宏块
当实行渐近归并时，只有本次渐近轮次相干的宏块会做全量归并，其他部分做非全量归并

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。