聊聊分布式 SQL 数据库Doris(八)

2023-11-30 09:05:22 浏览数 (1)

稀疏索引

密集索引:文件中的每个搜索码值都对应一个索引值,就是叶子节点保存了整行.

稀疏索引:文件只为索引码的某些值建立索引项.

稀疏索引的创建过程包括将集合中的元素分段,并给每个分段中的最小元素创建索引。在搜索时,先定位到第一个大于搜索值的索引的前一个索引,然后从该索引所在的分段中从前向后顺序遍历,直到找到该搜索值的元素或第一个大于该搜索值的元素。

Doris中的前缀索引、Bloom Filter属于稀疏索引.

以mysql为例,主键索引是稠密索引; 非主键索引(非聚簇索引)是稀疏索引. 如下是mysql的B 树索引结构图.

主键索引, 注意叶子节点的主键值时有序的.

非主键索引

联合索引

稀疏索引占用空间少,但是在查询的精确率上还是相对于稠密索引还是比较慢的,因为不需要顺序查找,还有回表。

稠密索引那就是相对来说比较快,因为他可以精确定位数据,但是占用的空间比较大。

参考:

密集索引和稀疏索引

一文读懂MySQL的索引结构及查询优化

delete

delete: 本质上是存储了一个删除条件,在查询时会对每一行记录应用这个删除条件做过滤,因此当有大量删除条件时,查询效率就会降低。

批量删除: 仅适用于 UNIQUE KEY 模型,解决了delete大批量数据的性能问题; Doris内部会增加一个隐藏列__DORIS_DELETE_SIGN__. 该列的类型为bool,聚合函数为replace. 在导入与读取时,增加隐藏列的判断,筛选过滤掉不必要的数据.

参考:

数据删除

批量删除

更新

Doris中存储的数据都是以追加(Append)的方式进入系统,这意味着所有已写入的数据是不可变更(immutable)的。所以Doris采用标记的方式来实现数据更新的目的; 利用查询引擎自身的 where 过滤逻辑,从待更新表中筛选出需要被更新(被标记)的行。再利用 Unique 模型自带的 Value 列新数据替换旧数据的逻辑,将待更新的行变更后,再重新插入到表中,从而实现行级别更新。

适用场景

  • 对满足某些条件的行,修改其取值;
  • 点更新,小范围更新,待更新的行最好是整个表的非常小的一部分;因为大批量数据下整行更新,会导致性能较低。
  • update 命令只能在 Unique 数据模型的表中执行;因为只有该模型可以保证主键的唯一性,从而支持按主键对数据进行更新。

假设 Doris 中存在一张订单表,其中 订单id 是 Key 列,订单状态,订单金额是 Value 列。数据状态如下:

订单

订单金额

订单状态

1

100

待付款

这时候,用户点击付款后,Doris 系统需要将订单id 为 '1' 的订单状态变更为 '待发货',就需要用到 Update 功能。

代码语言:javascript复制
UPDATE test_order SET order_status = '待发货' WHERE order_id = 1;

更新结果如下:

订单

订单金额

订单状态

1

100

待发货

用户执行 UPDATE 命令后,系统会进行如下三步:

  1. 第一步:读取满足 WHERE 订单id=1 的行 (1,100,'待付款')
  2. 第二步:变更该行的订单状态,从'待付款'改为'待发货' (1,100,'待发货')
  3. 第三步:将更新后的行再插入原表中,从而达到更新的效果。

订单

订单金额

订单状态

1

100

待付款

1

100

待发货

由于表 test_order 是 UNIQUE 模型,所以相同 Key 的行,之后后者才会生效,所以最终效果如下:

订单

订单金额

订单状态

1

100

待发货

部分列更新

Doris默认的更新是行更新. 列更新可以很大程度上提高写入与并发性能.

Unique Key模型的Merge-on-Write结合MVCC支持部分列更新.

Aggregate Key模型将聚合函数设置为REPLACE_IF_NOT_NULL支持部分列更新.

更新原理

Unique Key模型的列更新实现:用户通过正常的导入方式将一部分列的数据写入Doris的Memtable,此时Memtable中并没有整行数据,在Memtable下刷的时候,会查找历史数据,用历史数据补齐一整行,并写入数据文件中,同时将历史数据文件中相同key的数据行标记删除。

Aggregate Key模型,则是直接利用聚合函数筛选过滤。

使用建议:

  • 对写入性能要求较高,查询性能要求较低的用户,建议使用Aggregate Key模型
  • 对查询性能要求较高,对写入性能要求不高(例如数据的写入和更新基本都在凌晨低峰期完成),或者写入频率不高的用户,建议使用Unique Key模型merge-on-write实现

参考:

数据更新

0 人点赞