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表。