彩票类网站开发,网站建设制作费用,wordpress jq,wordpress 搜索框 位置1. 数据模型
StarRocks提供四种数据模型#xff1a; Duplicate Key, Aggregate Key, Unique Key, Primary Key
1.1 Duplicate Key
适用场景#xff1a;
分析原始数据#xff0c;如原始日志和原始操作记录。可以使用多种方法查询数据#xff0c;不受预聚合方法的限制。加…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()语句来设置分桶用于分桶的列也被称之为分桶键。分桶键可以是一列或多列。分桶是将一个分区划分为多个更易于管理的部分即tablettablet是使用和分配的最小存储单元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.enablefalse);查看分区
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 分区分桶修改
在建表完成后我们也可以手动增加分区。
如果没有指定分桶方式则自动使用建表时的分桶方式。如果指定分桶方式则使用新的分桶方式创建这里当前只能修改分桶数不能修改分桶方式或分桶列。动态分区表的分区不能直接增删改若要操作需要先关闭其动态分区属性。
