做php门户网站那个系统好,网站建设流程资料,河南网站建设服务,物流信息网站cms今天有同事问我#xff0c;列存大宽表场景下#xff0c;如果在多个列上有等值过滤条件#xff0c;OceanBase 的性能是不是无法满足要求#xff1f; Hi 晓楚#xff0c;帮评估个OTS替换场景 大概1亿大宽表#xff0c;查询姿势就是任意字段的组合#xff0c;进行等值查询g…今天有同事问我列存大宽表场景下如果在多个列上有等值过滤条件OceanBase 的性能是不是无法满足要求 Hi 晓楚帮评估个OTS替换场景 大概1亿大宽表查询姿势就是任意字段的组合进行等值查询group by/sum这些聚合操作业务模型大概是这样1亿表过滤性最强的字段会扫50万左右数据单SQL OTS现在不超过300毫秒这个场景能搞定不主要也要求OB几百毫秒我还有个疑问这种场景是不是没有索引合并的能力耗时很难满足业务要求呢 . 典型 SQL 如下 200字段的大宽表sql大概就是 select sum(xx),count(*) from tb where a ? and b ? and c ? group by d / order by d limit 20 类似这种 答案是OceanBase 可以轻松搞定这种场景
OceanBase 列存表是如何处理 a ? and b ? and c ? 这种多个等值条件的扫描呢
按照一般的思路我们会将这三个表达式下压到存储层。存储层需要先按照 a ? 扫描出所有结果行得到第一组rowid然后按照 b ? 扫描出所有结果行得到第二组rowid最后按照 c ? 扫描出所有结果行得到第三组rowid然后把这三组 rowid 求交集得到最终结果。
这个思路并没有什么问题在最坏的情况下我们就是这么做的。因为只需要扫描三列一般是可以做得非常快的。1亿行百毫秒级绰绰有余。
但实际上OceanBase 存储层做了更多优化。比如首先做 a ? 扫描的时候就可以快速知道哪些微块上根本没有满足条件的数据那么在处理 b ? 和 c ? 时就可以快速跳过这样的微块。
再比如在先计算哪个条件的选择上可以选择过滤性最好的条件先做这样就可以跳过更多的微块。
还比如过滤性不确定的情况下还可以动态地选择三个表达式中的一个来做做一段时间发现过滤性不好就换另一个表达式。这样动态切换可以让计算过程具备更好的自适应能力。
对于 OceanBase 来说 a ? and b ? and c ? 是最好处理的场景了实际场景可以比这个复杂得多比如还有 or 条件的时候应该怎么处理这些 OceanBase 都有相应的优化策略。
基于存储层的这些优化我们在 5000万行的数据集下做了一些简单测试结果如下 可以看到在两个过滤条件的场景下5000万行的表只需要 50 毫秒即可过滤出结果。由此推算1亿行的场景也一定可以满足客户对延迟的需求。
