Greenplum列存压缩表索引机制

列存压缩表,简称AOCS表

数据生成

create table testao(date text, time text, open float, high float,                                                                                                                           low float, volume int) with(APPENDONLY=true,ORIENTATION=column);

create index testao_idx on testao using btree (volume);

insert into testao select t, t, t, t, t, t from generate_series(1, 1000000) as t;

现象

执行计划如下:

postgres=> explain select * from testao where volume = 100 limit 1;
                                                 QUERY PLAN
------------------------------------------------------------------------------------------------------------
 Limit  (cost=100.95..200.98 rows=1 width=40)
   ->  Gather Motion 4:1  (slice1; segments: 4)  (cost=100.95..200.98 rows=1 width=40)
         ->  Limit  (cost=100.95..200.96 rows=1 width=40)
               ->  Bitmap Append-Only Column-Oriented Scan on testao  (cost=100.95..200.96 rows=1 width=40)
                     Recheck Cond: volume = 100
                     ->  Bitmap Index Scan on testao_idx  (cost=0.00..100.95 rows=1 width=0)
                           Index Cond: volume = 100
 Settings:  effective_cache_size=8GB; gp_statistics_use_fkeys=on
 Optimizer status: legacy query optimizer
(9 rows)

我们看到使用Bitmap Index Scan索引扫描

如何通过索引找到数据

索引页包含记录的tid,而tid包含segfileno和rownum信息,通过segfileno可以定位到文件,通过rownum可以定位到block及具体值。

如何通过rownum快速定位到block

对于索引,GP将会创建一个pg_aoblkdi_oid辅助表(block directory),里面包含每个block在文件的偏移位置fileOffset、segfileno、firstRowNum,并在firstRowNum列上创建索引,只要给出一个rownum,通过索引在pg_aoblkdi_oid辅助表中可以快速得到block在文件的偏移位置fileOffset,然后取出数据。

扫描方式的选择

为什么AOCS表使用的索引方法是Bitmap Index Scan,而不是我们常见的Index Scan呢?

AO表的扫描方向只能从前往后,而不能从后往前,heap表从前往后、从后往前都是支持的。通过索引找到的数据在AO文件位置并不是从前往后顺序的。如图所示,假设我们的条件是id<=7,通过索引找到的记录的顺序是1,3,5,7。如果是Index Scan,那么就要先从fileOffset位置扫描到第三个位置找到value=1,然后继续扫描到第四个位置value=3,然后继续从fileOffset位置开始扫描第一个位置value=5,继续扫描到第二个位置value=7,可以看到使用Index Scan可能会有多次回头重新开始扫描,增加了IO。为了避免这个问题,只使用Bitmap Index Scan,将会先扫描所有满足索引的值,然后按照tid排序,按照rownum从小到大扫描,一次从前往后扫描就可以得到索引对应的值了。

时间: 2024-09-23 08:49:37

Greenplum列存压缩表索引机制的相关文章

Greenplum列存压缩表事务机制

事务隔离级别 我们知道Heap表的事务隔离是通过MVCC实现,但是在列存表没有记录xmin,xmax等多版本信息,仅仅记录了块的元信息以及数据,那么它是如何实现事务隔离的? 仍然借助于Heap表,每创建一个列存表,同时创建一个heap辅助表表,通过select * from pg_appendonly可以看到辅助表的OID(segrelid),这个辅助表几面记录了什么呢? typedef struct AOCSVPInfoEntry { int64 eof; int64 eof_uncompre

Greenplum列存压缩表原理

用法 create table testao(id int, name text) with (APPENDONLY=true, ORIENTATION=column, COMPRESSTYPE=zlib, COMPRESSLEVEL=5, BLOCKSIZE=1048576, OIDS=false) APPENDONLY=true, ORIENTATION=column这两个属性决定了这是列存压缩表. COMPRESSTYPE: 压缩方式,支持zlip,RTE等 COMPRESSLEVEL:

阿里云HybridDB for PG实践 - 行存、列存,堆表、AO表的原理和选择

标签 PostgreSQL , Greenplum , 向量计算 , 行存储 , 列存 , AO表 背景 Greenplum支持行存和列存,支持堆表和AO表,那么他们有什么不同,如何选择呢? 行存和列存的原理 1.行存,以行为形式组织存储,一行是一个tuple,存在一起.当需要读取某列时,需要将这列前面的所有列都进行deform,所以访问第一列和访问最后一列的成本实际上是不一样的. 在这篇文档中,有deform的详细介绍.<PostgreSQL 向量化执行插件(瓦片式实现) 10x提速OLAP>

PostgreSQL 如何让 列存(外部列存) 并行起来

标签 PostgreSQL , 列存 , cstore , append parallel , 继承 背景 PostgreSQL 10已经实现了大部分操作的并行计算,例如(全表扫描,索引扫描,位图扫描,哈希JOIN,哈希聚合,分组聚合,排序,建索引等). 对于外部表,要实现并行扫描,PostgreSQL有什么方法呢? PostgreSQL不仅支持单个对象的并行计算,还支持多个对象的并行访问.多个对象的并行访问,包括继承表.分区表.继承外部表.UNION.UNION ALL等语义. 这个patch

行存、列存,堆表、AO表性能对比 - 阿里云HDB for PostgreSQL最佳实践

标签 PostgreSQL , GIS , PostGIS , Greenplum , 空间检索 , GiST , B-Tree , geohash 背景 <Greenplum 行存.列存,堆表.AO表的原理和选择> 以上文档详细的介绍了行存.列存,堆表.AO表的原理以及选择的依据. <一个简单算法可以帮助物联网,金融 用户 节约98%的数据存储成本 (PostgreSQL,Greenplum帮你做到)> 以上文档介绍了提升基于列存的全局数据压缩比的方法. <解密上帝之手 -

HybridDB for PostgreSQL 列存表(AO表)的膨胀、垃圾检查与空间收缩

标签 PostgreSQL , Greenplum , 垃圾检测 , 膨胀 , 列存表 , gp_appendonly_compaction_threshold 背景 Greenplum支持行存储(堆存储)与AO存储,堆存储的垃圾回收和膨胀检测方法请参考: <如何检测.清理Greenplum膨胀.垃圾 - 阿里云HybridDB for PG最佳实践> 对于AO存储,虽然是appendonly,但实际上GP是支持DELETE和UPDATE的,被删除或更新的行,通过BITMAP来标记. AO存储

Greenplum行存与列存的选择以及转换方法

背景 数据在数据库中的存储形式多种多样,比较常见的如 1. PostgreSQL的堆表,以行的形式存储,(当变成字段压缩后的长度超过数据块的四分之一时,会以TOAST的形式存储到TOAST表). 2. MySQL innodb则是以b+tree形式存储的. 在数据仓库产品中,如Greenplum,支持行存,也支持列存. 还有很多存储格式,本文将讨论行存和列存应该如何选择呢? 行存储优劣分析 Greenplum行存储(堆表)的优势在哪里? 数据顺序写入BLOCK中,持续写入的情况下,一条记录命中在

倒排与列存

一直傻傻分不清倒排和列存,今天有空梳理一下,主要有四个概念要明确:   1. 索引方式: 正向索引,反向索引(倒排)   2. 存储方式: 行存,列存   3. 数据结构: HashMap,B-Tree,BitMap...   4. 存储结构:      + 顺序组织(顺序文件)     + 索引组织(索引文件)     + 散列组织(散列文件)     + 链组织(多关键字文件) 索引方式 索引方式是种指导性的的思想,和具体数据结构和存储结构没有直接关系 正向索引:DocId->Value 反

MySQL · 引擎特性 · Infobright 列存数据库

简介 系统架构 存储引擎 优化器和执行器 数据装载和卸载 领域知识 查询优化 简单场景的示例 小结 存储结构 Data Pack Knowledge Node 数据压缩 总结 简介 Infobright 是一个面向 OLAP 场景的开源列存数据库.比较容易找到代码的版本是 Infobright Community Edition 4.0.7,大概是 2006 年前后的代码.2016 年6 月,Infobright 决定停止开源1.由于它同时提供企业版和社区版,开源版本的功能相比企业版而言,肯定是