GreenPlum列存解密

简介: GreenPlum列存解密

GreenPlum支持列式存储。叫做AOCO表。那么AOCO列存是如何管理列存文件?如何实现MVCC?是否支持索引,若支持如何实现的呢?下面我们介绍下AOCO的实现机制。


1、存储结构

如上图所示,列存每一列单独存储一个文件。上面一个表有4个字段,那么对应分别存储在relfilenode.1,relfilenode.129,relfilenode.257,relfilenode.385文件中。其中relfilenode为该表的文件OID,若没进行过truncate、vacuum等操作,和表的OID相同。该值可以从pg_class系统表中查询到。上述文件,存储在segment上,master节点仅存储与数据无关的元数据信息。

列存文件里也是以block为单位,一个block最大值的范围是8KB--2MB(默认32KB)。创建表时可以指定:

create table t(id1 int,id2 int,id3 int) with  (appendonly=true, orientation = column, blocksize=65536) distributed by(id1);

也可以在列上指定,此时列上的限制会覆盖with中的限制:


create table t(
    id1 int encoding (blocksize = 65536),
    id2 int,
    id3 int
)with(appendonly=true,orientation=column,blocksize=65536) distributed by(id1);

2、并发


AOCO列存一列独立存储,每列最多128个文件,不同列值不会同时存储到同一个文件。比如并发操作第一列时,会话1使用filenode.1,会话2使用filenode.2。当会话1和会话2都结束后,再进行插入时,会轮流项filenode.1和filenode.2中插入,保持2个文件均衡。

当存在单列多个文件时,查询按照文件依次扫描,不会按照插入的顺序输出。


3、可见性


列存的可见性信息没有和列值存在一起,而是由一个辅助表管理。该辅助表为pg_aovisimap_OID,其中OID为表的OID。创建列存表后,会自动创建该表,另外还会自动创建辅助表的索引表pg_aovisimap_OID_index。pg_aovisimap_OID表有3个字段:

1)segno:文件ID,从1开始,并发使用

2)first_row_no:可见性map表开始的行号

3)visimap:bitmap,存储可见性信息

新创建的表,没有进行过更新、删除。那么pg_aovisimap_OID表里面没有数据,对应文件为空。当进行了更新或删除后,才会有数据。并且,仅存储被操作过的数据的可见性,以及和被操作数据在一个map内的行的可见性。一般情况下,32768行作为一个单位,存储在一个bitmap。没有被操作过,且不和其他操作过的在一个map里的行,其可见性不会体现在这个bitmap中,因为他就是可见的。


4、rownum


对于heap表,tupleid决定了每个记录的位置(记录在文件中的偏移)。AOCO表因为数据是压缩的,无法确定在文件中的偏移,因此引入了rownum。每个记录都有一个rownum且单调递增。通过和segno一起存储在AOTupleId中。AOTupleId和heap的ItemPointer结构用的是一个:

    typedef struct ItemPointerData
    {
      BlockIdData ip_blkid;//块号
      OffsetNumber ip_posid;//块内偏移
    }
      typedef struct BlockIdData
      {
        uint16    bi_hi;
        uint16    bi_lo;
      } BlockIdData;
      typedef uint16 OffsetNumber;

      所以ItemPointerData是3个uint16的空间。而AOTupleId:

        typedef struct AOTupleId
        {
          uint16    bytes_0_1;
          uint16    bytes_2_3;
          uint16    bytes_4_5;
        } AOTupleId;

        0-6位存储segno;紧接着7-15及bytes_2_3和bytes_4_5的低15位一起来表示rownum。


        5、MVCC


        列存文件中不包含MVCC信息(xmin,xmax)。为实现MVCC,又引入一个辅助表pg_aoseg_OID。该表的vpinfo中存有重要信息,eof为实际情况下结束位置。辅助表是heap表,MVCC其实通过heap表的MVCC机制加上eof来实现。


        6、索引


        列存支持索引,但是非唯一索引。索引也是通过一个辅助表来完成。创建索引后会自动创建pg_aoblkdir_OID表及其索引pg_aoblkdir_OID_index。pg_aoblkdir_OID中有字段:

        segno:文件号

        1)columngroup_no:列号

        2)first_row_no:行号

        3)minipage:存储每个block的偏移。用于快速定位到列存文件中数据的位置。

        注:

        上述引入的辅助表都在pg_aoseg下。


        7、总结


        1、pg_aoseg_oid存储列存文件的结束信息,从而结合heap表的MVCC来实现列存的MVCC和事务隔离。

        2、pg_aoblkdir_oid创建索引的时候生成,根据rownum行号查找数据block的偏移。列存的索引其实仍旧是btree。通过btree根据key找到其segno+rownum。然后通过segno+rownum从该辅助表找到位于哪个minipage,定位到minipage后,从里面找rownum对应的block号及偏移。

        3、保持列数据的可见性,也是根据rownum来定位位于哪个vismap区,然后再从该bitmap中查看对应的位是否为1。

        目录
        相关文章
        |
        10月前
        GreenPlum on K8s
        GreenPlum on K8s
        139 0
        |
        存储 OLAP OLTP
        漫谈OceanBase 列式存储
        列式存储主要的目的有两个: 大部分OLAP查询只需要读取部分列而不是全部列数据,列式存储可以避免读取无用数据; 将同一列的数据在物理上存放在一起,能够极大地提高数据压缩率。 OLAP和OLTP OLAP,也叫联机分析处理(Online Analytical Processing)系统,有的时候也叫DSS决策支持系统,就是我们说的数据仓库。
        6077 0
        |
        5月前
        |
        存储 关系型数据库 分布式数据库
        PolarDB-X HTAP新特性 ~ 列存索引
        随着数据爆炸式的增长,传统的OLTP和OLAP解决方案基于简单的读写分离或ETL模型,将在线库的数据以T+1的方式抽取到数据仓库中进行计算,这种方案存在存储成本高、实时性差、链路和维护成本高等缺陷。 为应对数据爆炸式增长的挑战,PolarDB分布式版本基于对象存储设计了一套列存索引(Clustered Columnar Index,CCI)功能,支持将行存数据实时同步到列存存储上
        76008 148
        |
        10月前
        |
        存储 算法
        GreenPlum AOCO列存如何将数据刷写磁盘
        GreenPlum AOCO列存如何将数据刷写磁盘
        72 0
        |
        11月前
        |
        存储 SQL 分布式计算
        GreenPlum小结
        GreenPlum小结
        245 0
        |
        9天前
        |
        关系型数据库 OLAP 分布式数据库
        PolarDB 开源版通过 duckdb_fdw 支持 parquet 列存数据文件以及高效OLAP
        背景PolarDB 的云原生存算分离架构, 具备低廉的数据存储、高效扩展弹性、高速多机并行计算能力、高速数据搜索和处理; PolarDB与计算算法结合, 将实现双剑合璧, 推动业务数据的价值产出, 将数据变成生产力.本文将介绍PolarDB 开源版通过duckdb_fdw 支持 parquet 列存...
        28 0
        |
        存储 并行计算 算法
        PolarDB 开源版通过 duckdb_fdw 支持 parquet 列存数据文件以及高效OLAP
        PolarDB 的云原生存算分离架构, 具备低廉的数据存储、高效扩展弹性、高速多机并行计算能力、高速数据搜索和处理; PolarDB与计算算法结合, 将实现双剑合璧, 推动业务数据的价值产出, 将数据变成生产力. 本文将介绍PolarDB 开源版通过duckdb_fdw 支持 parquet 列存数据文件以及高效OLAP.
        1218 0
        |
        存储 算法 关系型数据库
        一文剖析PolarDB HTAP的列存数据压缩
        PolarDB MySQL是阿里云自研的OLTP云原生数据库,为满足客户HTAP的需求,PolarDB技术团队提出了基于In-Memory Column Index的技术方案,本文介绍数据的压缩方法以及PolarDB HTAP在列存数据压缩上的工作。通过压缩,PolarDB HTAP在大部分业务场景将列存存储空间减少到十分之一,大幅减少客户的存储成本。在计算性能上,PolarDB技术团队探究将计算下推到压缩数据从而加速分析,进一步为客户提供更好的OLAP查询性能,实现HTAP系统性能和成本的兼得。
        346 0
        |
        存储 SQL 算法
        列式存储?OLAP?ClickHouse究竟是何方神圣
        列式存储?OLAP?ClickHouse究竟是何方神圣
        列式存储?OLAP?ClickHouse究竟是何方神圣