2013年，由百度凤巢团队自研MMP数据库Palo，后提交开源命名为Apache Doris，使用协议为Apache License 2.0。2020年Doris团队其中部分员工跳槽创业，以Doris大量原始代码推出DorisDB，后因品牌名称问题改为StarRocks，使用协议为Elastic License 2.0。
官网简介
什么是 StarRocks：StarRocks 是新一代极速全场景MPP数据库。StarRocks 的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需经过复杂的预处理，就可以用 StarRocks 来支持多种数据分析场景的极速分析。StarRocks 的架构简洁，采用了全面向量化引擎，并配备全新设计的 CBO 优化器，查询速度（尤其是多表关联查询）远超同类产品。StarRocks 能很好地支持实时数据分析，并能实现对实时更新数据的高效查询。StarRocks 还支持现代化物化视图，以进一步加速查询。使用 StarRocks，用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型。StarRocks 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。
MPP数据库
提到MMP就会联想到以下属性：
-
硬件成本
-
无主集群
-
分布式存储
-
拓展性
-
可靠性
-
高可用
-
高并发
-
列式存储
-
标准化
-
PB级
SMP->NUMA->MMP结构发展和区别：
-
SMP Symmetric Multi-Processor 对称多处理器
-
NUMA Non-Uniform Memory Access 非一致存储访问结构
-
MPP Massive Parallel Processing 海量并行处理结构
向量化执行引擎
火山模型：next()每次处理一个Tuple
物化模型：next()一次处理所有数据
批处理模型：next()每次处理一批数据，具体批次贴合CPU cache
早期数据库因为资源问题，采用火山模型进行计算，到使用所有资源，最大化计算速度的物化模型，再到根据计算资源而适应性控制数据、计算量的批处理模型。
CBO优化器
RBO: Rule-Based Optimization 基于规则的优化器
CBO: Cost-Based Optimization 基于成本的优化器
SR CBO 默认选择每日定期采样抽取20万行数据更新统计信息，每2小时检查一次元数据更新，根据最新的统计信息，选择最优的物理执行计划。
SQL执行顺序：
-
SQL Rewriter：输入SQL重写，如删除注释等。
-
Parser：将SQL转化为抽象语法树
-
Binder：查询数据库元信息，将表格元数据绑定在抽象语法树上，最终生成逻辑语法树
-
Tree Rewrite：将逻辑执行树优化，大部分是RBO规则。
-
Optimizer：基于CBO规则，引入了Cost estimates模型，估算出所有推导出的plan，选择代价最小的plan作为physical plan。
物化视图
物化视图包含以下特性：
-
包含查询结果的数据库对象
-
不确定性的多维度分析
-
基于明细表
-
查询时需要命中建视图时指定的函数，explain可以查看命中情况
-
基于Base表数据单独占用空间，避免滥用预计算、新增维度列排序方式
-
和Molap相似的方式，以空间换时间，预计算减少结果数据的延迟
兼容MySQL协议
StarRocks提供MySQL协议接口，支持标准SQL语法。用户可通过MySQL客户端方便地查询和分析StarRocks里的数据、使用JDBC接口发起请求。
基础架构
FE：管理元数据，管理客户端连接，进行查询规划，查询调度
BE：数据存储以及SQL执行
Broker：数据导入导出中转，选装
Manager：管理看板、在线查询、故障查询、监控报警
Tablet：逻辑切片，副本管理基本单位，存储在不同节点
在扩容、缩容时，StarRocks可以做到无需停止服务，直接完成节点的增减。节点的变化会触发Tablet的自动迁移
前缀索引
维度列：索引字段，主键外键等
指标列：内容字段，需要分析的数据
前缀索引有以下约束条件：
-
前缀索引逐列使用二分法定位
-
前缀索引不能超过3个
-
前缀索引必须满足“维度列排序键顺序=字段顺序”
-
varchar类型列只能出现一次，并且在末尾位置
-
最佳左前缀原则：频次最高的字段放最前，提高索引命中，尽量避免从靠后的排序键查询过滤
稀疏索引
前缀索引是一种特殊的稀疏索引，以下是稀疏索引的逻辑顺序：
-
先查找前缀索引，获得逻辑数据块的起始行号
-
查找维度列的行号索引，定位到维度列的数据块
-
读取数据块
-
解压、解码数据块
-
从数据块中找到维度列前缀对应的数据项
数据模型
| 模型类型 | 适应场景 | 指标列 |
|---|---|---|
| 明细模型 | 明细数据 | duplicate key |
| 聚合模型 | 分析数据 | aggregate key |
| 更新模型 | 缓冲数据 | unique key |
| 主键模型 | 实时场景 | primary key |
明细模型
-
需要指定前缀索引
-
保留所有历史数据，建表默认模型
聚合模型
-
需要指定聚合列和聚合函数
-
适合不需要明细，只想看函数结果的场景
-
自动聚合，减少数据量
更新模型
-
需要指定唯一索引，插入的时候决定新增还是更新
-
适合实时分析和大量更新，例如CDC监控Binlog增删改
-
类似HBase，存所有数据，取时先Merge再拿出最新数据，写快读慢
主键模型
-
需要指定主键，插入的时候决定新增还是更新
-
主键模型是更新模型plus，只留最新数据，处理速度更快（支持只更新部分字段）
-
导入模型时把索引加载到内存，场景条件苛刻，适合冷热特征数据和大宽表
列式存储
一张表的列可以分为维度列（也称为 Key 列）和指标列（也称为 Value 列）。维度列用于分组和排序，指标列的值可以通过聚合函数累加起来。多维数据自动计算合并。
前缀索引可以依赖维度列的排列次序进行查询加速。假如维度列event_day、siteid、citycode 和 username，需要把这张表中的数据按照 pv 字段做聚合查询。如果查询条件为 event_day > 2020-09-18 and siteid = 2，则可以使用范围查找；如果查询条件为 citycode = 4 and username in [“Andy”, “Boby”, “Christian”, “StarRocks”]，则无法使用范围查找。
加速处理
预先聚合：
建表时，指定聚合模型，自动对指标列数据预处理进行合并，从而加速查询。
分区分桶：
建表时的分区分桶操作，把表划分成多个 Tablet，每个 Tablet 多副本冗余存储在 BE 上。BE 和 Tablet 的数量可以根据计算资源和数据规模的变化而弹性伸缩。查询时，多台 BE 可以并行地查找 Tablet，从而快速获取数据。
物化视图（RollUp）：
类似于前缀索引的加速逻辑，但物化视图拥有自己的前缀索引次序。在为物化视图创建索引时，可指定聚合的粒度、列的数量和维度列的次序，使频繁使用的查询条件能够命中相应的物化视图索引。
列级索引：
StarRocks 支持布隆过滤器 (Bloom Filter)、ZoneMap 索引和 位图 (Bitmap) 索引等列级别的索引技术。
开发优化
Colocate Join
-
没有shuffle，类似于Spark的Bucket Join
-
建表时做分组 colocate_with = group1
-
把需要join的表设置group同组，分桶、副本数保持一致
-
不建议广泛使用，导致某些BE压力过大
Lateral Join
-
类似于Hive的lateral view
-
可以选择多个列为数组进行join，也可以split一个列的字符串进行拆分
-
可以配合unnest()进行行转列
其他亮点
-
与Hive不同，SR可以直接插入数据
-
StarRocks只支持UTF8
-
StarRocks不支持修改列名，可以增删列
-
StarRocks的varchar保存的是字节数，utf-8 1:3
-
分区只能date/datetime/int
-
show data 查看数据所占存储空间以及数据量、副本数量和行数
-
不支持update/upsert，支持更新模型/主键模型
-
2.2版本支持Java UDF支持Array/JSON/BitMap/HLL类型字段
-
2.2.1 版本开发注意事项
- ODS主键模型的主键就是排序键，要和原库一致才能集成
- 爆破语法：select ranks,unnest as type from ods.safe_test_simulate_data_1,unnest(split(genre, “,”))
- 集成任务不用划分，SR擅长整库集成，会自动分配资源，串行集成数据，调整并行度即可
- 库表大小写敏感，字段不敏感
- group_concat(distinct field separator ‘,’)不支持，使用array_join(array_distinct(array_agg(field)), “,”)
- 现版本不支持substring_index()函数
- varchar最大长度1048576字节，string最大长度65533字节，编码为GBK（1048576/8=131072）
- 1replace()特殊字符需要转义