同类产品: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,也称作数据分桶
文章评论