You need to enable JavaScript to run this app.
导航

表存储格式介绍

最近更新时间2024.02.18 19:02:02

首次发布时间2024.01.12 14:29:13

EMR StarRocks支持列存和行存的存储格式、和行列混存。本文介绍行存和列存的概念, 实现的原理以及各自适用的应用场景。

1 列式存储


表数据按列存储。物理上,一列数据会经过分块编码、压缩等操作,然后持久化存储到非易失设备上。但在逻辑上,一列数据可以看成是由相同类型的元素构成的一个数组。 一行数据的所有列值在各自的数组中按照列顺序排列,即拥有相同的数组下标。数组下标是隐式的,不需要存储。表中所有的行按照维度列,做多重排序,排序后的位置就是该行的行号。

查询时,如果指定了维度列上的等值条件或者范围条件、并且这些条件中的维度列可以构成表的维度列前缀,则可以利用数据的有序性,使用二分查找法快速锁定目标行。原理可以参考官网理解StarRocks表设计

2 行式存储

alt
行存格式与列存正好相反, 数据按照每一行将所有列都紧凑的排列在一起, 每一行的数据经过编码后按照字节序存储到磁盘上.
行存表在查询时候非常直观, 数据一条一条的从存储引擎中获取到, 然后根据一系列的过滤选择聚合排序等计算返回相应的结果.

3 适用场景

存储格式适用场景使用限制使用说明

列存

适用于OLAP场景,适合各种复杂查询、数据关联、扫描、过滤和统计。

  • 查询QPS不建议超过100

  • 写入时延无法设置毫秒级别

与开源的StarRocks保持一致

行存

适合基于Primary Key点查点更新的场景,提供在线服务。

  • 每行文本格式数据不超过4M

  • 建议不超过100列

行存采用主键模型,采用主键查询、插入、更新时,性能较好。

3.1使用建议

是否使用行存表, 可以从下面几个维度考虑:

  • 查询场景

    • 基于主键等值条件的查询,而且需要非常高的QPS。
  • 更新场景

    • 基于主键时更新,而且需要非常高频的更新。
  • 插入场景

    • 整行插入或者部分列插入, 而且需要非常高频的插入

    • 数据链路时延要求低

3.2 使用限制

  1. 有大量非主键类扫描表的查询, 尽量谨慎使用行存表。

  2. 有复杂多表关联, 且表没有主键过滤的场景查询,不建议使用行存表。