Oceanbase一个节点中，所有落地数据都存储在同一个sstable文件块中，那如果在全表扫描的场景下，在读取数据这块是否需要消耗更多的时间（相比于mysql之类的数据库）
1 个赞
这方面感觉还是要看具体的场景，不过OB对于慢SQL调优的方法要比MySQL强很多(create outline等)
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001573891
就一个基本场景，3台机器的ob集群，存储几张大表；这时针对某张大表的分页展示这个使用场景下，由于被查询的大表没有做分区操作，这种情况下，该操作的耗时会不会比单纯使用mysql要高？
PS：ob上的几张大表是分布于3个mysql实例上的数据
同一分区的数据是否一定在同一个observer上?
如果表特别大，单个分区也很大， 也不拆分还是放在同一个observer上吗？
前置条件就是不做分区的大表； 这个先不考虑优化方面的事。
把租户的 primary zone 设置一下，测试一下与mysql的效果呢
是否有完整的测试方案+脚本提供？
Table Store内部，数据按照热、温、冷的顺序，依次分布在MemTable、Mini/Minor SSTable、Major SSTable中。最新数据写入Active MemTable，当MemTable达到一定大小后，会冻结不再写入，创建新的写入MemTable。为了节省内存，冻结MemTable会转储写到磁盘文件上，生成Mini SSTable。当Mini SSTable个数增多时，各个SSTable间主键交叉的概率会增大，影响查询效率，这时会触发Mini/Minor SSTable之间的合并，将多个多版本SSTable合并成Minor SSTable。
OceanBase采用LSM Tree的数据组织形式，数据只能以追加的方式写入。每次插入、更新、删除都是一条写入记录，MemTable和Mini/Minor SSTable保留了数据的多版本信息，包含比较多的冗余信息。而现实业务中，一般比较少更新历史数据，并且只需要读取数据的最新版本，这样对于历史冷数据存储，有比较多的优化方案。OceanBase系统运行时，在满足一定条件时，会选取某个历史快照点，读取数据最新版本，写入Major SSTable中。Major SSTable只保留主键在快照中的最新完整行，采用了行列混存的模式，对数据进行分段编码和压缩，减少数据存储成本的同时极大地提高了查询性能。
1 个赞
学习了
要具体分析的