Part 3: distributed database storage

First, the distributed database storage

In the previous section; GreenPlum database is a distributed database architecture; segment data table distributed nodes. Then the data table based on what strategy to distribution?

GreenPlum database performance depends on uniformly distributed across the data node

1. GreenPlum database query response time completion time of all data nodes to measure. The system can only complete data nodes with the slowest time to decide. If the data storage is inclined. A data node needs to spend more time than other nodes to process the data, the situation hash distribution of data storage will exist tilt.
2. In GreenPlum database; table associated with the most common queries. If two or more tables associated with the distribution key field or with non-random distribution. This shows the relationship between the parent and not the other tables in a distributed architecture. To perform connections, matching rows must be on the same node. If the data is not in the same column are connected on the distribution, which is a required table rows dynamically redistributed to other nodes. In some cases, the implementation of a broadcast operation, each node sends its respective row to all other nodes, re-hashing the data instead of each node and the hash value according to the transmission line to the appropriate node re-allocation.
3. There is also a copy is not a table? Version GreenPlum6.0 more support replication table. 2 just avoid broadcast or redistribution operation.

Second, the distribution strategy

In GreenPlum database table can be specified when creating a distribution strategy: distribution of hashes ( DISTRIBUTED BY ), randomly distributed ( DISTRIBUTED RANDOMLY) , copy distribution (DISTRIBUTED REPLICATED ).

• Hash Distribution: need to specify the distribution key. Is assigned to the corresponding segment data node distribution key based on a hash value. It is assigned to a value close to the same data node.
• Random distribution: random distribution without specifying the distribution key. This does not guarantee the uniqueness of the fields in the table. Because the same values ​​may be located in different data nodes.
• Copy distribution: GreenPlum6.0 version supports copy table above; Greenplum database table for each row will be distributed to each node instance. Copy table data evenly distributed, since each node has the same row.

How to choose the distribution strategy? We now analyze

2.1, single-table queries situation

The results verify: It seems no difference

 2.2, table associated with the query

Now we create a table t_lottu; also insert 10,000 records

bingo = # truncate  table t_lottu;
Truncate  TABLE 
bingo = # insert  Into t_lottu select generate_series ( 1 , 10000 ), ' bingo ' ;
INSERT  0  10000

Random strategy: by t_random_01 associated with the table t_lottu

 Hash strategy:

 By comparing the two figures: based on a hash strategy slightly better; my environment segment only two nodes. no significant effect. We can clearly be seen in randomized strategies query plan which it has Redistribute Motion. This explains query plan later. This is called data redistribution. After Shave explain .

Why random strategy will Redistribute Motion?

在哈希策略中；同样的分布键的值肯定会分布到同一个segment节点。所以上面表t_hash_01和表t_lottu的分布键都是id字段。所就可以在每个Segment节点关联后，Segment节点把结果发送到Master节点，再由Master节点汇总，将最终的结果返还客户端。而随机分布则不能保证同样分布键的数据分布在同一个Segment节点上，这样在表关联的时候，就需要将数据发送到所有Segment节点去做运算，这样网络传输和大量数据运算都需要较长的时间，性能非常低下。所以在关联的时候不建议使用随机策略。

这里有一个问题了；是不是哈希策略查询计划就不会出现Redistribute Motion/Broadcast Motion(广播)。答案是错误的。若分布键跟关联的字段不一致的情况。就会出现。分布键跟关联的字段是否一致？在其它分布式架构叫表的亲和度。

2.3、数据分布倾斜的问题

既然不建议使用随机策略；那我们都是用哈希策略不就好了吗？

哈希策略是同样的分布键的值肯定会分布到同一个segment节点。有可能造成数据分布倾斜的问题。在随机策略不会出现这种情况。

数据分布倾斜的问题；待定。

-- 重新分布表数据

2.4、数据复制分布

在GreenPlum6.0版本中支持复制表。作用消除多表关联中Redistribute Motion/Broadcast Motion带来的性能消耗。也可用于单表的负载均衡。

在用于单表查询；可以看出只需查询一个节点即可。

 用于多表关联消除多表关联中Redistribute Motion/Broadcast Motion带来的性能消耗 

 三、数据是如何存储

创建表的DDL语句还可以通过with子句来定义表的存储类型

where storage_parameter is:
   APPENDONLY={TRUE|FALSE}
   BLOCKSIZE={8192-2097152}
   ORIENTATION={COLUMN|ROW}
   COMPRESSTYPE={ZLIB|QUICKLZ|RLE_TYPE|NONE}
   COMPRESSLEVEL={0-9}
   CHECKSUM={TRUE|FALSE}
   FILLFACTOR={10-100}
   OIDS[=TRUE|FALSE]
where column_constraint is:

在前面有说到

参考：https://github.com/digoal/blog/blob/master/201708/20170818_02.md

Greenplum数据库可以使用追加优化（append-optimized，AO）的存储个事来批量装载和读取数据，并且能提供HEAP表上的性能优势。 追加优化的存储为数据保护、压缩和行/列方向提供了校验和。行式或者列式追加优化的表都可以被压缩。

在创建表指定 APPENDONLY = TRUE为AO表。若不指定或者APPENDONLY = FALSE为堆表。

3.1、堆表

堆表是PostgreSQL数据库原生存储格式，GreenPlum默认的存储格式。堆表存储在OLTP类型负载下表现最好，这种环境中数据会在初始载入后被频繁地修改。 UPDATE和DELETE操作要求存储行级版本信息来确保可靠的数据库事务处理。 堆表最适合于较小的表，例如维度表，它们在初始载入数据后会经常被更新。

多适合用于OLTP系统。但GreenPlum常定位是用于OLAP系统。为了更适合OLAP系统。GreenPlum提供来AO表

应用场景：

堆表是万油金；只是有些场景其他存储方式更加适合。更能提升性能。

3.2、AO表

AO表在4.3版本之前取意为（APPEND-ONLY，AO）。根据其意义只能追加，在4.3版本之后取意为（append-optimized，AO）追加优化。支持update/delete。跟堆表一样。但实现原理不一样。删除更新数据时，通过另一个BITMAP文件来标记被删除的行，通过bit以及偏移对齐来判定AO表上的某一行是否被删除。

追加优化表存储在数据仓库环境中的非规范表表现最好。 非规范表通常是系统中最大的表。 事实表通常成批地被载入并且被只读查询访问。 将大型的事实表改为追加优化存储模型可以消除每行中的更新可见性信息负担，这可以为每一行节约大概20字节。 这可以得到一种更加简洁并且更容易优化的页面结构。 追加优化表的存储模型是为批量数据装载优化的，因此不推荐单行的INSERT语句

AO支持压缩以及列存

应用场景：

• 使用列存、压缩数据使用AO表。
• 数据批量写入使用AO表

3.3、行存和列存

ORIENTATION=COLUMN可以指定创建列存的AO表。列存的表只能是AO表。

• 行存：以行形式存储表中。一行数据存在一个数据文件中。适用于具有许多迭代事务的OLTP类型的工作负载以及一次需要多列的单行，因此检索是高效的
• 列存：以列为形式组织存储，每列对应一个或一批文件。而且压缩比例比较高。适合于在少量列上计算数据聚集的数据仓库负载，或者是用于需要对单列定期更新但不修改其他列数据的情况

若一个宽表。在读取某一个列数据；行存需要把匹配的列的所在的行数据块都要扫描一遍。整好列存可以避免。但是带来的问题是一个表对应多个数据文件。

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

类型	创建选项	适用场景
堆表	默认/APPENDONLY = FALSE	适合OLTP系统，适合单条记录插入，适合小表
AO表	APPENDONLY = TRUE	适合OLAP系统，同时支持压缩。适合批量记录插入
行存	ORIENTATION=ROW	适合小量数据、多列查询
列存	ORIENTATION=COLUMN	适合OLAP系统、宽表

备注：以上为本人理解；若有不对的地方；烦请指出。谢谢！