StarRocks 1.19 新版本特性介绍数据库数据分析

StarRocks 近期发布了1.19 版本，下面介绍一下新版本的核心功能：

Global Runtime Filter
关系型数据库中，表的关联查询是十分常见的操作。StarRocks 在1.19版本中实现了 Global Runtime Filter，通过动态过滤那些不会命中 join 的输入数据来大幅减少数据的传输和计算，从而提升 join 的执行性能。
在使用过程中，规划器会根据右表的数据量自动选择是否构建 Global Runtime Filter，不需要用户进行额外的参数调整。下面以 TPCH 100G Query 17为例，其中 lineitem 表数量是 600M，orders 表数量是 150M。运行并行度设置为8。

# TPCH Query 17select sum(l_extendedprice) / 7.0 as avg_yearly from lineitem, part where p_partkey = l_partkey and p_brand = 'Brand#23' and p_container = 'MED BOX' and l_quantity < ( select0.2 * avg(l_quantity) fromlineitemwhere l_partkey = p_partkey );

测试结果如下，通过开启 Global Runtime Filter，性能提升了6倍。

文章图片

BE节点内的磁盘均衡
随着数据量逐渐增大，当用户有加盘需求时，需要 StarRocks 自动进行数据均衡。StarRocks 在1.19版本中优化了磁盘均衡算法，在保证数据在各个BE之间均衡的基础上，新增了单个BE内部磁盘之间的 tablet 均衡，从而更好地利用新加的盘。
均衡步骤如下：

进行所有BE之间的磁盘均衡。
当集群达到均衡之后，进行每个 BE 内部磁盘之间的均衡。包括每个 BE 内部磁盘之间磁盘使用率的均衡和磁盘之间 tablet 分布的均衡。

[实验功能]Primary Key
为更好地支持实时/频繁更新功能，StarRocks 在1.19版本中新增了一种表的类型: 主键模型（Primary Key）。相较 Unique Key，该类型的表更好地解决了行级别的更新和删除操作，同时也极大地支撑了MySQL或其他数据库同步到 StarRocks 的场景。
原有的表类型整体上采用了读时合并（Merge-On-Read）的策略，写入时处理简单高效，但是读取(查询)时需要在线合并多版本，严重影响了查询性能。Primary Key 使用内存索引消除了这一问题，获得读性能的提升，其性能基本可以和 Duplicate Key 相近，是 Unique Key 的3-15倍（取决于版本的数量）。测试数据效果如下：

文章图片

另外，在 TPCH 测试中，有导入的查询相较没有导入的查询，性能下降仅在10%左右。
当前，Primary Key 支持 Stream Load、Broker Load 和 Routine Load。同时配合Flink-connector 可以实现 MySQL 数据的秒级同步。

文章图片

StarRocks-migrate-tools 可以根据 MySQL 和 StarRocks 的集群信息和表结构自动生成 source table 和 sink table 的建表语句。通过 Flink-cdc-connector 消费 MySQL 的 binlog，然后通过 Flink-connector-starrocks 写入 StarRocks。
参考文档：https://docs.starrocks.com/zh...主键模型
[实验功能]StarRocks外表写入
StarRocks 支持以外部表的形式接入其他数据源，当前支持的数据源类型有 MySQL、HDFS、ElasticSearch、Hive 以及 StarRocks。
StarRocks 在1.19版本中支持了将数据通过外表的方式写入另一个 StarRocks 集群的表中，以解决用户的读写分离需求，提供更好的资源隔离。仅需三步用户即可完成外表的周期性写入。