有关OceanBase的转储和合并，有下列疑问：
1、我们知道memTable中，数据有btree和hash table两种结构，都指向rowkey，那这那种结构是每张表都有一个还是整个集群的一个memtable中只有一个呢，如果是集群共用的，那不同的table就有可能有相同的rowkey（主键），那在memtable中，schema和table的元数据是如何组织的以快速的定位到相同rowkey的不同表的数据呢？
2、memtable转储到mini sstable，mini sstable下压成minor sstable，如果磁盘上的sstable也是集群级别的，那么微块中数据也可能包含不同表的相同rowkey，并且这些rowkey的列个数也不同，那在ssstable中schema和table的元数据又是如何组织的从来能够直接定位到微块中的不同表的相同rowkey呢？
问题已收到，有信息会回复你的。
可以理解为每个tablet一个memtable/mini/ninor/major这样的结构吧，相当于每个tablet都是一棵lsm-tree这样的结构，这个系列的文章和您之前写的https://open.oceanbase.com/blog/5176614912这个都拜读过，个人比较愚钝不是理解不是很透彻，感谢答疑。
另外minor_compact_trigger （默认值为2）用于控制分层转储触发向下一层下压的阈值，这个应该是一个全局操作，也就是只要有tablet的的mini sstable数量到了2，所有tablet的mini sstable都会下压？如果某个租户的所有memtable的总大小到了freeze_trigger_percentage的阈值，那所有tablet的memtable都会转储成mini sstable？是这样理解的吗？
感谢支持。
1.这个过程目前还是个轮询调度的过程，对于达到minor_compact_trigger阈值的分区才会去调度merge的任务，所以并不是说一个tablet达到阈值了所有tablet都会受影响
2.是的，转储目前是个租户级的操作。
从手动命令上其实也可以看到，转储合并是有手动命令的，但minor是没有的，换句话说minor主要是为了减少sstable数量，对于不需要执行的分区是可以不做的
我看有些有些lsmtree的db（比如leveldb）是把tableid写入行头，和主键一起组成rowkey，所以ob的实现其实是和它们有差异的。另外 GV$OB_COMPACTION_PROGRESS视图可以看到需要合并的tablet数和已经完成的tablet数，其实其实需要合并的sstable结构和已经完成合并的sstable的数量？
是的，我理解ob设计之初就考虑了扩展性的问题。
你这里是说tablet数量就是lsm-tree结构的数量吧？
是的，是指的lsm-tree结构的数量
GV$OB_COMPACTION_PROGRESS这个视图中，就有用tablet的完成量来代表合并进度的，所以其实就是lsm-tree结构合并的完成量来代表进度？
对，这个进度是整个租户的，因此我们以每个分区为粒度进行进度的一个估算