系统架构

—

​

核心进程：FE（Frontend）、BE（Backend）。所有节点都是有状态的。

FE（Frontend）负责管理元数据，管理客户端连接，进行查询规划、查询调度等工作。

• Follower

• Leader：Follower 会通过类 Paxos 的 BDBJE 协议选主出一个 Leader，所有事务的提交都是由 Leader 发起并完成；

• Follower：提高查询并发，同时参与投票，参与选主操作。

• Observer：不参与选主操作，只会异步同步并且回放日志，主要用于扩展集群的查询并发能力。

BE（Backend）负责数据存储以及 SQL 执行等工作。

#03

存储架构

—

在 StarRocks 里，一张表的数据会被拆分成多个 Tablet，而每个 Tablet 都会以多副本的形式存储在 BE 节点中，如下图：

​

Table 数据划分 + Tablet 三副本的数据分布：

StarRocks 支持 Hash 分布、Range-Hash 的组合数据分布（推荐）。

为了等到更高的性能，强烈建议使用 Range-Hash 的组合数据分布，即先分区后分桶的方式。

• Range 分区可动态添加和删减；

• Hash 分桶一旦确定，不能再进行调整，只有未创建的分区才能设置新的分桶数。

分区和分桶的选择是非常关键的。在建表时选择好的分区分桶列，可以有效提高集群整体性能。

以下是针对特殊应用场景下，对分区和分桶选择的一些建议：

• 数据倾斜：业务方如果确定数据有很大程度的倾斜，那么建议采用多列组合的方式进行数据分桶，而不是只单独采用倾斜度大的列做分桶。

• 高并发：分区和分桶应该尽量覆盖查询语句所带的条件，这样可以有效减少扫描数据，提高并发。

• 高吞吐：尽量把数据打散，让集群以更高的并发扫描数据，完成相应计算。