左边是 BE 进程的内存总占用，右边是索引的内存总占用

最新推荐文章于 2024-04-27 11:22:38 发布

原创最新推荐文章于 2024-04-27 11:22:38 发布 · 662 阅读

CC 4.0 BY-SA版权

文章标签：

内存占用方面，相比原来的全内存，内存占用只有约原来的 1/10。下图是我们导入测试时的内存对比，左边是 BE 进程的内存总占用，右边是索引的内存总占用。在全内存索引模式下，可以看到随着数据的持续导入，总内存最高可以达到 120GB，索引内存最高达到 60GB。在开启持久化索引之后，随着数据的持续导入，总内存最高约 70-80GB，索引内存最高到 3-4GB，内存的使用下降是非常可观的。

2、部分列更新

原来的主键模型表导入时只支持整行的 upsert 和 delete 操作，upsert 的操作需要提供所有列的值。有了部分列更新的功能之后，就可以仅仅提供需要更新的列，其他没有更新列就不再需要提供。常见的使用场景是我们在 StarRocks 中创建一张大宽表，逻辑上来说它是由多个表 join 而成，上游的每个模块仅负责大宽表中的一部分列，对于其他不负责的列，是无法知道当前值的。

另外一种数据流建模方式是在 StarRocks 中按照模块去创建多个表，然后查询时对这多个表进行 join。虽然 StarRocks 在多表查询方面，性能优化已经非常好了，但是在一些极端场景下，用户还是期望使用大宽表方式来做查询，带来极速查询性能。

目前如果想要实现效果，有几个不太优雅的妥协方案。方案一是在上游的数据流中插入 join 模块或者 join 算子，通常用 Flink 做流失的 join。当多个模块的数据流实时做 join 拼成整行后，再导入到 StarRocks 中。缺点是需要提供一个额外的流计算模块和配套的状态存储。方案二是使用 TP 系统构造一个大宽表，上游模块一部分以列更新的方式写入 TP 系统，再通过 TP 系统同步给 AP 系统，这样的话就需要额外搭建一套 TP 模块和 CDC 同步模块。方案三是分模块导入 AP 系统，在 AP 系统中通过 DML 定期地去做 join，刷新到大宽表中，但会牺牲一部分实时性。这三种模式都需要引入新的模块，增加了系统的复杂度，不是一个完美的方案。如果 StarRocks 能够支持部分列更新，就可以很好地解决问题，极大的简化和构建实时交易数据流的难度。为了实现简单和已有设计的兼容和传承，目前 2.3 版本已经实现了部分类更新的功能，以现有的 Delete + Insert 模式为基础。基本流程可以参考下图。