Brin Index在Greenplum 7中的理论与实现


Brin Index在Greenplum 7中的理论与实现

《Greenplum 7新版本大剧透》系列 II

🏷️主题: Brin Index在Greenplum 7中的理论与实现
⏰时间:2021年4月28日 20:00-21:00

演讲大纲:

1、Append Only Table简介
2、Brin Index简介
3、Brin Index on Append Only Table的实现原理
4、性能特性描述和测试结果

直播链接:https://www.modb.pro/event/301

Btree数据空间占用量和原始数据几乎是一样的。

大部分OLAP数据库符合这个场景。常规索引占用空间太大,不适合。

segscan 全表扫描。

brin索引一个或一组block。

如果新增加值落在范围之内,则不需要更新BRIN

删除某条数据,范围不变化。

普通Bacuum 不做任何操作,而vacuum full 发生可block之间的数据移动,重建索引。

Brin Storage 存储结构

heap表占用空间很大,适合update,不适合OLAP的顺序扫描。

写入的不能在修改,只能后面追加。

每个AO表,逻辑上有128个aoseg, 每个并发向特定的aoseg追加数据。

Brin是一维的连续结构,而AO是多个不连续的。

通过tuple ID, block number和偏移量。 使用逻辑block..

128个aoseg 的block number是分散到每个aoseg里面的。 各自占用一部分 2的32次方/128*aoseg编号

增加上层结构 upperLevel 记录的是revmap block的block number

千万分之一的选择率

千分之一的选择率

10%的选择率

空间占用

QA

Q:对字符串有效吗?

A:可以,可以比较大小的都可以

Q:1个brin对应的block数是固定20个吗?

A:有参数限制

Q:根据时间范围查询的时序数据,使用brin index是否合适?我自己在postgresql上做的性能对比测试来看,btree性能还是要比brin要好的

A:brin代价小,性能凑合。 btree代价大,性能好

Q:gp在是基于pg开发的吗?做了那些改变使gp适合了OLAP的场景了?pg主要还是用在TP场景吧?

A: 查询优化器和执行优化器。 分布式改造,适合OLAP场景。 存储上实现了AO表。