kai_ding的专栏

当大家提到存算分离时，尤其是考虑后端使用 AWS S3 为代表的对象存储作为数据存储时，直觉就是性能拉胯，只能用作批量数据处理场景，至少这是我在跟很多用户交流时获得的第一感受。而 StarRocks 作为一个具备强实时性数据分析引擎，在引入了存算分离架构后，又能否能胜任实时场景呢，无数用户心理可能会打个问号。我们内部也考虑到了用户的心声，在新版本中引入了一键性能飞升能力，当然，多说无益，我们拿实际测试来说话。

StarRocks存算分离表中，垃圾回收是为了删除那些无用的历史版本数据，从而节约存储空间。考虑到对象存储按照存储容量收费，因此，节约存储空间对于降本增效尤为必要。用户手动执行了删除库、表、分区等命令，如执行了 drop table、drop database 以及 drop partition 等命令随着系统内 Compaction 任务不断进行，合并之前的数据文件可以被安全回收目前在 StarRocks 的存算分离表存储在对象存储上的文件类型包含如下几种：Segment 文件。

StarRocks 中每次数据摄入都会生成一个新的数据版本，而查询时需要将所有版本数据进行合并才能获得一个正确的结果，如果历史数据版本太多，那么查询时需要读取的文件数也会很多，造成查询效率低下。因而 StarRocks 存在内部任务定期将历史数据版本进行整合，消除重复数据记录，我们称之为 Compaction。Compaction 是为了将不同版本的数据文件进行整合，合并成大文件的动作，减少系统中小文件数量，进而提升查询效率。Compaction 调度由 FE 发起，BE执行。

StarRocks 中 Compaction 是为了将不同版本的数据文件进行整合，合并成大文件的动作，减少系统中小文件数量，进而提升查询效率。随着导入任务的执行，系统内部也在不断地调度执行 Compaction 任务，这些任务会被发往计算节点 CN 执行，系统也提供了一系列命令可以查看当前 Compaction 任务执行情况。因为 Compaction 对于查询性能的影响至关重要，因此，我们建议用户时刻关注系统中表与分区的后台数据合并情况，在这里我们给用户提供几点最佳实践的建议和指导。