查询延迟降10倍，冷查不担心

前言

在数据海量增长的今天，自从 AWS S3 服务于 2009 年推出以后，对象存储凭借其 API 简单、成本低、高可靠性和可用性、海量扩展性等优势已经逐步成为海量数据存储的事实标准，各大云厂商以及私有化存储服务供应商也纷纷推出类似服务。

随着 AWS S3 推出了15个年头，越来越多的服务开始基于对象存储来构建，由于构建在独立的存储之上，这些服务天然就是存储计算分离架构，节约成本的同时更带来了极致的弹性能力。用户的集群规模不再受限于数据容量的制约，所有数据存储在 S3 之上，计算资源可以随时被拉起或者释放而无需担心数据丢失。

对象存储浑身是宝，但它也不是银弹。尤其是在 IO 延迟上，典型的 1MB 读取延迟 P99 延迟甚至能达到数百 ms。StarRocks 存算分离基于对象存储构建，一旦出现 Cache Miss 就需要直接访问底层对象存储，在一些重度数据扫描场景会带来延迟的升高，影响业务体验。

针对这些问题，StarRocks 存算分离也在一直改进，在 3.3.0 版本中我们开始引入多项优化，尤其是 Tablet 内并行 Scan 能力，将原来大的串行 IO 拆解为多个小 IO，并利用线程池并行处理这些 IO 任务，显著提升 IO 效率。

本文章给大家展示新的机制带来的查询性能提升。

效果对比

测试场景

我们知道大家最关注的还是冷查优化前后的性能对比 是骡子是马，拉出来遛遛。为此，我们基于 SSB 1TB 数据集（具体建表见附录）设计了以下三种测试场景。所有的测试都是基于 StarRocks 存算分离最新版本测试。

1. 测试 Data Cache 禁用情况下开启 Tablet 内并行 Scan 前后的 SSB 1T 数据集的查询性能对比
2. 测试 Data Cache 打开情况下开启 Tablet 内并行 Scan 前后的 SSB 1T 数据集的查询性能对比
3. 测试 存算一体模式下开启 Tablet 内并行 Scan 前后的 SSB 1T 数据集的查询性能对比

测试中控制每个 Tablet 大小在 4-5G 左右。

测试资源

测试中使用 AWS EC2 1 FE + 5 BE ，计算节点规格如下：

测试结果

注：

1. Cache Disabled-优化前：关闭 StarRocks 存算分离的 Data Cache，并关闭 Tablet 并行 Scan
2. Cache Disabled-优化后：关闭 StarRocks 存算分离的 Data Cache，并打开 Tablet 并行 Scan
3. Cache Enabled-优化前：打开 StarRocks 存算分离的 Data Cache，并关闭 Tablet 并行 Scan
4. Cache Enabled-优化后：打开 StarRocks 存算分离的 Data Cache，并打开 Tablet 并行 Scan
5. 存算一体：存算一体模式下关闭并行 Scan 优化的查询性能
6. 存算一体-开启并行Scan 优化：存算一体模式下开启并行 Scan 优化的查询性能

测试结论

1. 对于 Cache Disabled 场景，开启了并行 Scan 等优化后，查询延迟显著下降 5 - 20 倍
2. 开启并行 Scan 等优化后，Cache Disabled 时性能已经与存算一体等差距没有那么大了（整体差距只有 2.X 倍）
3. 对于 Cache Enabled 场景，与存算一体都开启并行 Scan 等优化后的性能几乎一致
   

最后

上面的标准数据集测试虽然不是非常充分，但也验证了在对象存储作为存储介质条件下，通过技术手段降低 IO 延迟带来的副作用的可行性。而且，这种并行优化带来的一个极大的优势是可以让 Tablet 可管理的数据变大，例如以前为了提升并行度，我们一般推荐单个 Tablet 1GB 大小较为合适，而有了 Tablet 内并行 Scan 技术，用户可以不再受这个限制（例如本文的测试中单 Tablet 数据量就约为 5GB ），可以提升 Tablet 数据量，降低 Tablet 数量。更少的 Tablet 数量一方面可以降低 FE 上内存使用，另外也可以显著降低写入时访问对象存储的 IO 次数，带来性能提升和成本下降，一举多得。

最后，如果您对该能力感兴趣，可以下载 3.3.0 Release 版本( 可以访问www.mirrorship.cn），然后设置如下两个命令即可体验飞一般的感觉：

附录

测试中建表语句如下：