我们知道，传统单机数据库不论是Oracle、MySql、PostgreSql还是SqlServer，它们的存储引擎都是基于Btree的，在Btree中IO的基本单位是Page，Page的长度可以配置，但一般都是定长的，比如说8KB、16KB这样的大小，一旦配置好就不是太好做调整了。定长的最大好处是方便做磁盘管理，不需要处理碎片的问题，但缺点是数据不好做压缩，这也很好理解，就算数据之前是定长的，一压也就成变长的了。
而一些基于LSM Tree的存储引擎，比如OceanBase和Rocksdb，把数据分为SSTable和MemTable，SSTable是静态只读的，非常适合压缩，所以这也是为什么和Oracle/MySql相比，存储相同的数据量OceanBase要消耗的磁盘空间要少得多。
压缩为用户节省了存储成本，但也带来了磁盘空间管理的问题，OceanBase为了在空间管理和数据压缩之间做平衡，才有了宏块-微块的两层管理结构，宏块大小是定长的，长度为2MB，方便做磁盘管理，是数据写的基本单位；宏块内部包含若干个微块，微块大小是变长的，大小可以4KB-512KB不等，方便做压缩，是数据读的最小单位。一般来说微块大小越大，压缩率越高，但相应一次读IO的代价也越大；微块大小越小，压缩率越低，但相应一次读IO的代价也越小。OceanBase默认的微块大小是16KB（当然实际压缩后是变长的，16KB是个大概建议值），基本上能适用大多数的场景了。