1. 数据模型

StarRocks提供四种数据模型： Duplicate Key, Aggregate Key, Unique Key, Primary Key

1.1 Duplicate Key

适用场景：

• 分析原始数据，如原始日志和原始操作记录。
• 可以使用多种方法查询数据，不受预聚合方法的限制。
• 加载日志数据或时序数据。新数据以追加模式写入，现有数据不更新。
  注意：
• 默认情况下，如果没有指定排序键列，StarRocks将使用前三列作为排序键【sort key】列
• 可以在表创建时创建索引，如BITMAP索引和Bloomfilter索引。
• 如果加载了两条相同的记录，将它们保留为两条记录，而不是一条
• 只能向表中追加数据。不能修改表中的现有数据。

1.2 Aggregate Key

此模型有助于减少查询需要处理的数据量，从而加快查询速度。
适用场景：

• 数据统计和分析场景
  使用时有如下特点：
• 大多数查询是聚合查询，例如SUM、COUNT和MAX。
• 不需要检索原始的详细数据。
• 历史数据不经常更新。只追加新数据。
  聚合时机：
• ingestion 阶段： 当数据批量加载到表中时，每个批量包含一个数据版本。生成数据版本后，StarRocks将在数据版本中具有相同排序键的数据进行聚合。
• compaction 阶段：将数据摄取时生成的多个数据版本的文件定期压缩成一个大文件时，StarRocks会在大文件中聚合具有相同排序键的数据。
• query 阶段：在返回查询结果之前聚合所有数据版本中具有相同排序键的数据。
  注意：
• 如果AGGREGATE KEY关键字不包括所有维度列，则无法创建表。
• 如果没有使用AGGREGATE key关键字显式地定义排序键列，将选择除度量列之外的所有列作为排序键列
• 在运行查询时，排序键列在多个数据版本聚合之前被过滤，而度量列在多个数据版本聚合之后被过滤。
• 创建表时，不能在表的度量列上创建BITMAP索引或Bloom Filter索引
• 将数据加载到使用聚合键模型的表中时，只能更新表的所有列

1.3 Unique Key

使用场景：

• 需要频繁实时更新数据的业务场景，如在电子商务场景中，每天可以下数亿个订单，订单状态经常变化
  注意:
• 主键必须创建在执行唯一约束且不能更改名称的列上
  • 在运行查询时，主键列在多个数据版本聚合之前被过滤，而度量列在多个数据版本聚合之后被过滤
  • 在聚合过程中，StarRocks比较所有主键列。这很耗时，而且可能会降低查询性能。因此，不要定义大量的主键列
• 创建表时，不能在表的指标列上创建BITMAP索引或Bloom Filter索引。
• 不支持实体化视图。
• 将数据加载到使用唯一键模型的表中时，只能更新表的所有列

1.4 Primary Key

与Unique Key模型不同，Primary Key模型在查询期间不需要聚合操作，并支持谓词和索引的下推。因此，Primary Key模型可以提供较高的查询性能，尽管实时和频繁的数据更新。
Duplicate Key模型采用MoR策略。MoR简化了数据写入，但需要在线聚合多个数据版本。此外，Merge操作符不支持下推谓词和索引。结果，查询性能下降。
Primary Key模型采用删除+插入策略，确保每条记录都有唯一的主键。这样，主键模型就不需要合并操作。详情如下:

• 对记录进行更新操作时，它通过搜索主键索引来定位该记录，将该记录标记为已删除，并插入一条新记录。换句话说，StarRocks将更新操作转换为删除操作加上插入操作。
• 对记录进行删除操作时，它通过搜索主键索引来定位记录，并将记录标记为已删除
  适用场景：
• 数据需要经常实时更新
  • 实时流数据从交易处理系统到StarRocks，这简化了数据同步，并提供比使用唯一键模型的MoR (Merge on Read)表高3到10倍的查询性能
  • 通过对单个列执行更新操作来连接多个流：这些场景中的上游数据可能来自各种应用程序，如购物app、物流app和银行app，或者来自机器学习系统。主键模型非常适合这些场景，因为它支持对单个列的更新。每个应用程序或系统只能更新在自己的服务范围内保存数据的列
• 主键占用的内存【memory occupied by the primary key 】是可控的
  • 当将数据加载到表中时，StarRocks将主键索引加载到内存中。因此Primary Key模型需要比其他三个数据模型更大的内存容量。StarRocks将组成主键的字段的总长度限制为编码后的127字节
  • 表包含快速变化的数据和缓慢变化的数据。快速变化的数据经常在最近几天更新，而缓慢变化的数据很少更新，如订单表，按天分区，在运行数据加载作业时，主键索引不会加载到内存中，只有最近更新的订单的索引项才会加载到内存中。
  • 表是一个由数百或数千列组成的平面表。主键只包含表数据的一小部分，并且只消耗少量内存。如user status or profile table，表的列太多，但只有几千万到几亿条
    注意：
• 必须在强制执行唯一约束的列上创建主键，并且不能更改主键列的名称。
• 主键列可以是以下任何数据类型:BOOLEAN、TINYINT、SMALLINT、INT、BIGINT、LARGEINT、STRING、VARCHAR、DATE和DATETIME。但是，主键列不能定义为NULL。
• 分区列和桶列必须参与主键。
• the memory occupied by the primary key index 的计算公式： (主键长度+9) x 记录数量 x 副本数 x 1.5 = 占用内存大小
  • 9是每行不可变的开销，1.5是每个哈希表的平均额外开销
• enable_persistent_index:主键索引可以持久化到磁盘并存储在内存中，以避免占用太多内存。
• 从2.3.0版本开始， indicator column现在支持BITMAP、HLL数据类型。
• 创建表时，不能在表的 metric columns 上创建BITMAP索引或Bloom Filter索引。
• 从2.4.0版本开始，可以基于主键表创建异步物化视图

2. 分区分桶

2.1 分区：

• StarRocks中的分区是在建表时通过PARTITION BY RANGE()语句设置，用于分区的列也被称之为分区键，当前分区键仅支持日期类型和整数类型（支持一列或多列）。
• 在分区时，可以设置分区的存储策略，包括副本数量、热数据或冷数据的存储策略、存储介质等。
• StarRocks允许在集群中使用多个存储介质。例如，将最新数据保存在SSD硬盘上，可以提高查询性能;将历史数据保存在SATA硬盘上，可以降低存储成本。
• StarRocks的分区粒度视数据量而定，单个分区原始数据量建议维持在100G以内。

2.2 分桶：

• 对每个分区的数据，StarRocks还会再进行Hash分桶。我们在建表时通过DISTRIBUTED BY HASH()语句来设置分桶，用于分桶的列也被称之为分桶键。分桶键可以是一列或多列。
• 分桶是将一个分区划分为多个更易于管理的部分即tablet，tablet是使用和分配的最小存储单元
• bucket列中具有相同哈希值的数据被分布到同一tablet中
• StarRocks为每个tablet创建多个副本(默认为三个)，以防止数据丢失。这些副本由单独的本地存储引擎管理。创建表时必须指定bucket列。
• 分桶数的设置通常也建议以数据量为参考，从经验来看，每个分桶的原始数据建议不要超过5个G，考虑到压缩比，也即每个分桶的大小建议在100M-1G之间。
• 分桶的目的我们一直在说是为了将数据打散，所以分桶键就需要选择高基数的列（去重后数据量最大的列）。分桶后的数据如果出现严重的数据倾斜，就可能导致系统局部的性能瓶颈，所以我们也可以视情况使用两个或三个列作为分桶键，尽量的将数据均匀分布。我们可以show语句查看表中的数据分布情况：

mysql> show tablet from tablename;

• 若不好估算数据量，我们也可以将分桶数设为：分桶数=“BE个数BE节点CPU核数”或者“BE个数BE节点CPU核数/2”，这样一般也不会有什么问题。这里需要注意的是，已创建分区的分桶数不能修改（有其他方式能实现，但比较麻烦），所以前期设定合适的分桶数非常重要。

2.3 动态分区

• 在StarRocks中，必须先有分区，才能将对应的数据导入进来，不然导入就会报错（提示there is a row couldn’t find a partition）。比如使用日期作为分区，那就需要先创建每天的分区，再进行数据导入。在日常业务中，除了每日会新增数据，我们还会对旧的历史数据进行清理。动态分区就是StarRocks用来实现新分区自动创建以及过期分区自动删除的方式。
• 动态分区由后台常驻进程调度，默认调度周期为10分钟一次，由FE配置文件中的dynamic_partition_check_interval_seconds参数控制（单位是秒，配置文件中默认没有该配置），所以并不是创建动态分区表后所有分区就立刻被创建，我们还需要等待不超过10分钟让后台调度生效。
• 动态分区参数在properties中配置：
  • dynamic_partition.enable：是否开启动态分区特性，可指定为TRUE或FALSE。如果该参数等号后不填写值，则默认代表TRUE。
  • dynamic_partition.time_unit：动态分区调度的粒度，可指定为DAY/WEEK/MONTH。不同分区粒度下动态分区自动创建分区的名称后缀不同，指定为DAY时，分区名后缀为yyyyMMdd，例如table07中的20211009。指定为WEEK时，分区名后缀为yyyy_ww，例如2021_40代表2021年第40周。指定为MONTH时，动态创建的分区名后缀格式为yyyyMM，例如202110。这里注意，我们创建静态分区时，分区命名也建议和动态分区自动创建的规则保持一致。
  • dynamic_partition.start：动态分区的开始时间。以当天为基准，根据该参数向过去推算数个粒度的时间，超过该时间范围的分区将会被删除。如果不填写，则默认为Integer.MIN_VALUE即-2147483648。
  • dynamic_partition.end：动态分区的结束时间。以当天为基准，会根据该参数提前创建数个粒度的分区范围。
  • dynamic_partition.prefix：动态分区自动创建的分区名前缀。
  • dynamic_partition.buckets：动态创建的分区所对应的分桶数量。
    以上属性在建表完成后也可以进行修改，例如关闭动态分区属性：

ALTER TABLE table07 SET("dynamic_partition.enable"="false");

• 查看分区

SHOW PARTITIONS FROM table07;

• 当分区键为日期类型的时候，需要指定INTERVAL关键字来表示日期间隔，目前日期仅支持day、week、month、year，分区的命名规则同动态分区一样。例如：

PARTITION BY RANGE (event_day) (
    START ("2019-01-01") END ("2021-01-01") EVERY (INTERVAL 1 YEAR),
    START ("2021-01-01") END ("2021-05-01") EVERY (INTERVAL 1 MONTH),
    START ("2021-05-01") END ("2021-05-04") EVERY (INTERVAL 1 DAY)
)

## 等价于
PARTITION p2019 VALUES [('2019-01-01'), ('2020-01-01')),
PARTITION p2020 VALUES [('2020-01-01'), ('2021-01-01')),
PARTITION p202101 VALUES [('2021-01-01'), ('2021-02-01')),
PARTITION p202102 VALUES [('2021-02-01'), ('2021-03-01')),
PARTITION p202103 VALUES [('2021-03-01'), ('2021-04-01')),
PARTITION p202104 VALUES [('2021-04-01'), ('2021-05-01')),
PARTITION p20210501 VALUES [('2021-05-01'), ('2021-05-02')),
PARTITION p20210502 VALUES [('2021-05-02'), ('2021-05-03')),
PARTITION p20210503 VALUES [('2021-05-03'), ('2021-05-04'))

• 当分区键为整数类型时，我们可以直接使用数字进行分区，这里注意分区值需要使用引号引用，而EVERY则不用引号，例如：

PARTITION BY RANGE (datekey) (
    START ("1") END ("5") EVERY (1)
)

## 等价于
PARTITION p1 VALUES [("1"), ("2")),
PARTITION p2 VALUES [("2"), ("3")),
PARTITION p3 VALUES [("3"), ("4")),
PARTITION p4 VALUES [("4"), ("5"))

2.4 分区分桶修改

在建表完成后，我们也可以手动增加分区。

• 如果没有指定分桶方式，则自动使用建表时的分桶方式。
• 如果指定分桶方式，则使用新的分桶方式创建（这里当前只能修改分桶数，不能修改分桶方式或分桶列）。
• 动态分区表的分区不能直接增删改，若要操作，需要先关闭其动态分区属性。