starRocks

同类产品：ClickHouse

适用场景:OLAP多维分析；实时数据仓库；高并发查询；统一分析
特性:分布式执行:分区分桶存储；支持多种数据分析场景的极速分析；查询速度(尤其是多表关联查询)远超同类产品

明细模型:表中会存在主键重复的数据行
聚合模型:表中不存在主键重复的数据行，主键重复的数据行聚合为-行
主键模型和更新模型:表中不存在主键重复的数据行，最新导入的数据行，替换掉其他主键重复的数据行。

项目使用主键模型通过insert主键重复来达到更新的效果
官网建议一个桶在100MB~1G,starRocks本身会通过压缩算法对数据压缩
每个桶Sr会分布一个线程计算
insert分区范围外的记录会插入失败
StarRecks单表百亿级，mysq单表亿级

starRocks单表查询tps能到600，对写和关联查询不太友好

列式存储不适合场景:
1.数据需要频繁更新的交易场景。
2.表中列属性较少的小量数据库场景。
3.不适合做含有删除和更新的实时操作

StarRocks
- StarRocks是新一代极速全场景MPP（Massively Parallel Processing）数据库。
- MPP是分布式执行框架，将查询请求拆分成多个物理计算单元并在多机上并行执行。每个执行节点拥有独享的资源（CPU、内存）。通过MPP执行框架，单个查询可以充分利用所有执行节点的资源，从而提升单个查询的性能。
- StarRocks的核心理念是提供高性能、可扩展的分析型数据库解决方案，专注于解决大规模数据分析和实时查询的需求。它具有高速的数据加载和查询能力，可以处理海量数据并提供快速的查询结果。
- StarRocks支持多维分析、复杂查询和即席查询等功能，帮助用户更好地理解和分析数据，做出更明智的决策。

建表语句说明：
- 排序键：创建StarRocks表时，指定的列将被用于内部组织和存储数据，这些列被称为排序列（Sort Key）。示例中的recruit_date和region_num是排序列。
- 注意：排序列应该在其他列之前定义。
- 查询的条件字段应尽量使用排序列。

分区分桶：
- PARTITION关键字用于创建表的分区。示例中使用recruit_date进行范围分区，每天创建一个分区，从11日到15日。
- StarRocks支持动态生成分区。
- DISTRIBUTED关键字用于创建表的分桶，示例中使用recruit_date和region_num两个字段作为分桶列。
- 从2.5.7版本开始，StarRocks支持自动设置分桶数量。

数据模型：
- DUPLICATE关键字表示当前表为明细模型，KEY字段中列出了当前表的排序列。

索引：
- StarRocks默认为Key列创建稀疏索引以加速查询。
- 稠密索引：每条记录对应一个索引字段，访问速度快，但维护成本高。
- 稀疏索引：数据查询速度较慢，但存储空间小，维护成本低。

数据表模型：
- StarRocks支持四种数据模型：明细模型（Duplicate Key Model）、聚合模型（Aggregate Key Model）、更新模型（Unique Key Model）和主键模型（Primary Key Model）。
- 这四种数据模型适用于多种数据分析场景，如日志分析、数据汇总分析、实时分析等。

明细模型：
- 在明细模型中，数据按照排序键（DUPLICATE KEY）排序，排序键可以重复。
- 默认的建表模型，表中可能存在主键重复的数据行，与导入的数据完全对应。
- 适用于日志数据分析等场景，支持追加新数据，不支持修改历史数据。

聚合模型：
- 在聚合模型中，数据按照排序键（AGGREGATE KEY）聚合后排序，排序键需要满足唯一性约束。
- 建表时，可以定义排序键和指标列，并为指标列指定聚合函数。
- 当多条数据具有相同的排序键时，指标列会进行聚合。
- 适用于分析统计和汇总数据，能够减少查询时所需处理的数据量，提高查询效率。

更新模型：
- 在更新模型中，数据按照排序键（UNIQUE KEY）进行替换后排序，排序键需要满足唯一性约束。
- 建表时，可以定义主键和指标列，查询时返回主键相同的一组数据中的最新数据。
- 相对于明细模型，更新模型简化了数据导入流程，适用于实时和频繁更新的场景。

主键模型：
- 主键模型支持定义主键和排序键。
- 主键（PRIMARY KEY）需要满足唯一性约束和非空约束，相同主键的数据行将被替换。
- 排序键用于排序，并由ORDER BY指定。

**1. 主键模型和更新模型的区别**

更新模型采用了Merge-On-Read策略，写入操作简单高效，但查询时需要在线聚合多个版本的数据，无法进行谓词和索引下推，严重影响查询性能。

主键模型采用了Delete+Insert策略，保证同一主键下仅存在一条记录，避免Merge操作，支持实时和频繁更新场景，提供高效查询性能，支持谓词和索引下推。

**2. 索引下推的优化技术**

索引下推利用索引中的数据，在查询之前尽量过滤掉无效数据，减少回表次数和IO操作，从而提高查询性能。

**3. 动态分区和查询分析**

动态分区和查询分析是在查询过程中使用的技术。它们用于确定应使用哪些区和哪些桶来执行查询操作。这些技术主要适用于OLAP（Online Analytical Processing）场景，如多维分析、定制报表、实时数据分析和Ad-hoc数据分析等。

**4. 适用场景和性能优化建议**

主键模型适用于需要实时和频繁更新的场景，并提供高效的查询能力。索引下推、动态分区和查询分析等技术可用于提高查询性能。

为了进一步提升性能，建议在查询操作中只检索所需的列，以降低查询的复杂度和提高查询QPS（每秒查询率）。

与关系性数据库的区别：行式存储和列式存储的区别_行存储和列存储的区别_正在沿着IT树往上爬的博客-CSDN博客
- 行式存储和列式存储的区别：行式存储因为只要有一个varchar列的存在，就不是定长的，列式存储定长的可能性更大，列式存储不太适合事务。
- 列式存储的优化手段：
  - 块遍历：批量化的手段
  - 压缩：省空间，有些场景可以直接基于压缩后的数据做运算，减少IO
  - 延迟物化
  - 隐式链接 (论文创新性内容，不展开)

使用中有哪些坑：
- 在StarRocks中，字段名不区分大小写，表名区分大小写。
- 建表时，DISTRIBUTED BY为必填字段。
- 目前仅支持分区键的数据类型为日期和整数类型。
- 排序列必须从定义的第一列开始，并且是连续的。
- 在定义各列时，计划作为排序列的列必须定义在其他普通列之前。
- StarRocks不支持修改表中的列名。
- 一个查询中子查询的最大个数默认为10000。
- 老版本不支持update、delete。

原理篇 系统架构FE、BE介绍以及分区分桶概念：
- Catalog Manager: 目录管理
- Query Optimizer: 查询优化器
- 截图中的第二个分区里的Tablet，我觉得也是有可能和第一个分区里的Tablet分到同一个BE的 Tablet，也称作数据分桶

架构：系统架构 @ Architecture @ StarRocks Docs