实时更新存储引擎

1、主键模型

大概在一年前，我们在 1.9 版本中发布了新的存储引擎，支持实时更新，主要用来满足实时分析动态数据场景需求，在支持实时更新的同时保持查询的高性能。它是基于 Delete + Insert 方式或 merge-on-read 的方式来实现更新的。相比原来 merge-on-read 的 uniq 模型，在导入性能几乎不受影响的前提下，查询性能提升了 3-10 倍。

虽然仅支持整行的 upsert 和 delete，但它非常适合 TP 到 AP 实时同步数据并加速查询的场景。一般通过 Apache Flink（以下简称 Flink） CDC 工具将 TP 业务系统，比如 MySQL 的数据直接同步到 StarRocks 系统中加速查询，极大地简化实时分析的数据流。它非常简单易用，目前已有很多个用户在线上系统中采用，是目前实时数据分析的典型范式。

​

2、局限 

虽然使用广泛，在最初设计和实际使用的过程中，我们也注意到主键模型和使用范式的局限性。

首先，由于开发资源的问题，本着实现简单、性能高效的初衷，我们使用了基于全内存的主键索引，它的性能非常好，对写入性能影响非常小。但最大的问题是内存消耗非常高，这直接限制了使用场景：场景一是总行数相对可控的业务场景。比如用户状态表或用户画像表，总用户数量级不大（比较小的维度表）等。场景二是数据冷热特征业务。把数据按照时间，比如按天或者按月分区，这样需要保证最近的热数据会被修改，老的冷数据不会再被修改，整个数据仅有一小部分的热数据索引才会被加载，从而使得使用内存得到一定程度的控制。

​

另一个比较常见的问题是高频导入。StarRocks 是一个批量（微批）系统，从事务系统到存储引擎的设计都是以处理不太频繁的大事务为前提，这与传统的 TP 系统或近年出现的 HTAP 系统追求高并发大量小事务是非常不一样的，和按行准实时处理的流式系统也是非常不一样的。随着用户对 StarRocks 实时分析的需求越来越高，微批的规模就会越来越小，以满足越来越高的实时性的需求。带来的挑战是它的写入频率会非常高，事务数量非常大，事务也越来越小。特别是引入 Flink CDC 等流式 ETL 的数据流之后，为了提高性能，通常会开启多个并发导入事务，使得事务数量成倍增多，这对现有的设计是一个很大的挑战。我们有些客户经常会遇到 too many versions、too many pending versions 之类的问题，本质上就是我们系统最初的设计并不能很好地解决高频导入这一问题。

最后一个问题是功能性和易用性是待完善的。首先是对部分列更新和条件更新的支持。目前 ETL 数据流强依赖这种导入方式。然后是相关的 DML 需要补足，比如 delete、update、merge 语句的缺失，这些语句对从 ETL 到 ERT 的衍进是非常重要的。最后是主键模型和 uniq 模型类似，还不支持创建更通用的物化视图。由于数据会发生更新变化，无法及时维护，相比没有更新的 duplicate 和聚合表来说，实现它的资源消耗会多很多，困难也会多很多，当然这也是 StarRocks 实现不可能的一个机遇。

#02

近期工作

1、持久化主键索引 

持久化主键索引用来解决主键索引被吐槽最多的内存问题。我们原来的主键索引是基于全内存哈希表的，新的持久化索引同样使用了基于哈希的设计，并且使用了类似 LSM 的多层设计。为了保证性能，目前只有两层：第一层还是哈希为内存的哈希表，它是 mutable 可修改的，同时会写 WL 来保证持久化。第二层是基于磁盘的哈希表结构，immutable 不可修改。为了节约存储空间，我们同样使用了原来全内存索引表下的 balance 设计。测试结果显示它的索引更新性能相比全内存索引下降了一些，但对于一般的写入吞吐来说是够用的。另外由于索引本质上是一个大量的随机读的 IO 操作，我们推荐使用 SSD 或者 NVMe 磁盘来开启持久化索引。

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