【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】4.x
【问题描述】对于OB现在的磁盘存储模型有一些疑问，OB现在将磁盘上的基线数据通过一个大文件block_file管理，内部划分为2M的宏块去进行分配使用，这样由于宏块可能不连续导致SSTable变成了一个逻辑上的概念，请问这样的设计带来了什么好处，和SSTable单文件管理相比是否会对Range Scan的性能产生影响，影响多大，是否大文件宏块设计是读性能和合并速度的一种trade off？此外4.x的ob_admin工具dumpsst需要指定宏块ID，这个是从哪里获得的，自己的工具一直报错
【复现路径】
【问题现象及影响】
【附件】
存储这块的设计理念可以看下文档
https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001698938
dumpsst中宏块ID可以参考
https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001698819
文档写的有点官方，
且并没有解决我的问题
具体执行的语句可以提供一下吗？
ob_admin dumpsst -d macro_block -f ./store
好的谢谢您，已经可以正确显示了，在我连续发起两次转储后，发现第一次生成了minor sstable，第二次生成了mini sstable，在您提到的系统表中这两个sstable的宏块ID是相同的，所以一个宏块是可以被多个SSTable共用的吗
4.1有小sstable的优化，可以允许不同的sstable数据存在同一个宏块里
好的谢谢，那请问不连续的SSTable读取性能不会有影响吗
目前有中间层索引来索引定位sstable和宏块的位置，可以理解为使用了B+Tree来加速元数据的查找
您好 我看4.1里面 没有这个表了？
show tables看不到，但是直接查询有这个表的
