本文是学习StarRocks的读书笔记，让你快速理解下一代高性能分析数据仓库的架构、数据存储及表设计。
StarRocks的架构相对简单。
StarRocks提供四种数据模型： Duplicate Key, Aggregate Key, Unique Key, and Primary Key
适用场景：
注意：
CREATE TABLE IF NOT EXISTS detail (
event_time DATETIME NOT NULL COMMENT "datetime of event",
event_type INT NOT NULL COMMENT "type of event",
user_id INT COMMENT "id of user",
device_code INT COMMENT "device code",
channel INT COMMENT ""
)
DUPLICATE KEY(event_time, event_type)
DISTRIBUTED BY HASH(user_id) BUCKETS 8;
此模型有助于减少查询需要处理的数据量，从而加快查询速度。
适用场景：数据统计和分析场景
使用时有如下特点：
聚合时机：
注意：
CREATE TABLE IF NOT EXISTS example_db.aggregate_tbl (
site_id LARGEINT NOT NULL COMMENT "id of site",
date DATE NOT NULL COMMENT "time of event",
city_code VARCHAR(20) COMMENT "city_code of user",
pv BIGINT SUM DEFAULT "0" COMMENT "total page views"
)
AGGREGATE KEY(site_id, date, city_code)
DISTRIBUTED BY HASH(site_id) BUCKETS 8
PROPERTIES ("replication_num" = "1");
适用场景:
注意:
CREATE TABLE IF NOT EXISTS orders (
create_time DATE NOT NULL COMMENT "create time of an order",
order_id BIGINT NOT NULL COMMENT "id of an order",
order_state INT COMMENT "state of an order",
total_price BIGINT COMMENT "price of an order"
)
UNIQUE KEY(create_time, order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8;
基于StarRocks提供的一个新的存储引擎设计的
与Unique Key模型不同，Primary Key模型在查询期间不需要聚合操作，并支持谓词和索引的下推。因此，Primary Key模型可以提供较高的查询性能，尽管实时和频繁的数据更新。
Duplicate Key模型采用MoR策略。MoR简化了数据写入，但需要在线聚合多个数据版本。此外，Merge操作符不支持下推谓词和索引。结果，查询性能下降。
Primary Key模型采用删除+插入策略，确保每条记录都有唯一的主键。这样，主键模型就不需要合并操作。详情如下:
适用场景：
当将数据加载到表中时，StarRocks将主键索引加载到内存中。因此Primary Key模型需要比其他三个数据模型更大的内存容量。StarRocks将组成主键的字段的总长度限制为编码后的127字节
表包含快速变化的数据和缓慢变化的数据。快速变化的数据经常在最近几天更新，而缓慢变化的数据很少更新，如订单表，按天分区，在运行数据加载作业时，主键索引不会加载到内存中，只有最近更新的订单的索引项才会加载到内存中。
表是一个由数百或数千列组成的平面表。主键只包含表数据的一小部分，并且只消耗少量内存。如user status or profile table，表的列太多，但只有几千万到几亿条
注意：
enable_persistent_index:主键索引可以持久化到磁盘并存储在内存中，以避免占用太多内存。create table orders (
dt date NOT NULL,
order_id bigint NOT NULL,
user_id int NOT NULL,
merchant_id int NOT NULL,
good_id int NOT NULL,
good_name string NOT NULL,
price int NOT NULL,
cnt int NOT NULL,
revenue int NOT NULL,
state tinyint NOT NULL
) PRIMARY KEY (dt, order_id)
PARTITION BY RANGE(`dt`) (
PARTITION p20210820 VALUES [('2021-08-20'), ('2021-08-21')),
PARTITION p20210821 VALUES [('2021-08-21'), ('2021-08-22')),
...
PARTITION p20210929 VALUES [('2021-09-29'), ('2021-09-30')),
PARTITION p20210930 VALUES [('2021-09-30'), ('2021-10-01'))
) DISTRIBUTED BY HASH(order_id) BUCKETS 4
PROPERTIES("replication_num" = "3",
"enable_persistent_index" = "true");
create table users (
user_id bigint NOT NULL,
name string NOT NULL,
email string NULL,
address string NULL,
age tinyint NULL,
sex tinyint NULL,
last_active datetime,
property0 tinyint NOT NULL,
property1 tinyint NOT NULL,
property2 tinyint NOT NULL,
property3 tinyint NOT NULL,
....
) PRIMARY KEY (user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 4
PROPERTIES("replication_num" = "3",
"enable_persistent_index" = "true");
# 整个表只有一个分区，并按site_id分桶
CREATE TABLE site_access(
site_id INT DEFAULT '10',
city_code SMALLINT,
user_name VARCHAR(32) DEFAULT '',
pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(site_id, city_code, user_name)
DISTRIBUTED BY HASH(site_id) BUCKETS 10;
# 先按日期分区，再按site_id分桶
CREATE TABLE site_access(
event_day DATE,
site_id INT DEFAULT '10',
city_code VARCHAR(100),
user_name VARCHAR(32) DEFAULT '',
pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY RANGE(event_day)
(
PARTITION p1 VALUES LESS THAN ("2020-01-31"),
PARTITION p2 VALUES LESS THAN ("2020-02-29"),
PARTITION p3 VALUES LESS THAN ("2020-03-31")
)
DISTRIBUTED BY HASH(site_id) BUCKETS 10;
GLOBAL enable_tablet_internal_parallel。CREATE TABLE site_access(
event_day DATE,
site_id INT DEFAULT '10',
city_code VARCHAR(100),
user_name VARCHAR(32) DEFAULT '',
pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY RANGE(event_day)
(
PARTITION p1 VALUES LESS THAN ("2020-01-31"),
PARTITION p2 VALUES LESS THAN ("2020-02-29"),
PARTITION p3 VALUES LESS THAN ("2020-03-31")
)
DISTRIBUTED BY HASH(site_id) BUCKETS 10;
CREATE TABLE site_access(
site_id INT DEFAULT '10',
city_code SMALLINT,
user_name VARCHAR(
32
) DEFAULT '',
pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(site_id, city_code, user_name)
DISTRIBUTED BY HASH(site_id,city_code); --do not need to set the number of buckets
CREATE TABLE site_access(
datekey DATE,
site_id INT,
city_code SMALLINT,
user_name VARCHAR(32),
pv BIGINT DEFAULT '0'
)
ENGINE=olap
DUPLICATE KEY(datekey, site_id, city_code, user_name)
PARTITION BY RANGE (datekey)
(
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)
)
DISTRIBUTED BY HASH(site_id) BUCKETS 10
PROPERTIES(
"replication_num" = "1"
);
ALTER TABLE site_access
ADD PARTITION p4 VALUES LESS THAN ("2020-04-30")
DISTRIBUTED BY HASH(site_id) BUCKETS 20;
ALTER TABLE site_access DROP PARTITION p1;
RECOVER PARTITION p1 FROM site_access;
SHOW PARTITIONS FROM site_access;
StarRocks支持四种数据压缩算法:LZ4、Zstandard(或zstd)、zlib和Snappy。
这些数据压缩算法在压缩比和压缩/解压缩性能上存在差异。
压缩比：zlib > Zstandard > LZ4 > Snappy.
特别是LZ4和Zstandard具有良好的压缩比和解压性能
如果对更小的存储空间没有特定的要求，建议使用LZ4或Zstandard。
只能在创建表时为表指定数据压缩算法，不能在创建后更改。
CREATE TABLE `data_compression` (
`id` INT(11) NOT NULL COMMENT "",
`name` CHAR(200) NULL COMMENT ""
)
ENGINE=OLAP
UNIQUE KEY(`id`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`id`) BUCKETS 7
PROPERTIES (
"compression" = "ZSTD"
);