分布式数据库 Greenplum 基本原理和使用

OLTP 联机事务处理

OLTP 联机事务处理， on-line transaction processing 强调数据库内存效率 ，强调内存各种指标的命令率 ，强调绑定变量， 强调并发操作 数据在系统中产生 ，对响应时间要求非常高， 用户数量非常庞大，主要是操作人员，数据库的各种操作主要基于索引进行。

OLAP 联机分析处理

OLAP 联机分析处理 ，On-Line Analytical Processing 强调数据分析 强调 SQL 执行， 强调磁盘 I/O 强调分等。基于数据仓库的信息分析处理过程，是数据仓库的用户接口部分 响应时间与具体查询有很大关系， 用户数量相对较小，其用户主要是业务人员与管理人员， 由于业务问题不固定，数据库的各种操作不能完全基于索引进行。

Postgresql 特点

1、纯免费无风险开源产品(BSD 协议) 

2、诞生于大学 

3、关系型数据库，满足 ACID

4、亲近 ORACLE，在 LINUX 下是进程模型 

简单的说明

1、MySQL 的 slogon 是最流行的关系型数据库；Postgresql 的 slogon 是最先进的关系型数据库 

2、ACID 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability） 

Greenplum 的入库动作

需要存储的数据在进入数据库时的动作：

1、 将先进行数据分布的处理工作，将一个表中的数据平均分布到每个节点上

2、为每个表指定一个分发列（distribute Column），之后便根据 Hash 来分布数据。Greenplum 这样处理可以充分发挥每个节点处 I/O 的处理能力。

3、为了实现多个独立的 PostgreSQL 实例的分工和合作，呈现给用户一个逻辑的数据库，Greenplum 在不同层面对数据存储、计算、通信和管理进行了分布式集群化处理 

结果：Greenplum 虽然是一个集群，然而对用户而言，它封装了所有分布式的细节，为用户提供了单个逻辑数据库。

Greenplum 的组成部分

Greenplum 主要由 Master 节点、Segment 节点、interconnect 三大部分组成。Master  系统的入口，接受客户端连接及提交的 SQL 语句，将工作负载分发给其它数据库实例（segment 实例）,不存放任何用户数据，只是对客户端进行访问控制和存储表分布逻辑的元数据 Segment 节点负责数据的存储，可以对分布键进行优化以充分利用 Segment 节点的 io 性能来扩展整集群的 io 性能 

Segment：/greenplum/primary/gpseg0(gpseg1))  是独立的 PostgreSQL 数据库，每个 segment 存储一部分数据。大部分查询处理都由 segment 完成，每个 pg 都有端口和进程，但为了保证安全，没有提供连接方式

Interconnect 负责不同 PostgreSQL 实例之间的通信。

分布键 distributed 的特点

1、分布键是决定数据存储在哪个 segment 

2、分布键必须是主键的一部分 

3、分布键比较合理的话，就在 segment 上均匀分布把 IO 压力均摊到各个 segment，避免数据倾斜。

4、哈希分布是最常用的数据分布方式。根据预定义的分布键计算用户数据的哈希值，然后把哈希值映射到某个 segment 上。

5、分布键可以包含多个字段 

6、如果没有显式指定分布键，的据库服务器配置参数 gp_create_table_random_default_distribution 控制表的分布策略，使用 PRIMARY KEY（如果表有主键）或者表的第一个列作为分布键的哈希分布策略。

MySQL 和 Greenplum 的语法比较

 1、MySQL 一般会将数据合法性验证交给客户，PostgreSQL 在合法性难方面做得比较严格。比如 MySQL 里插入 “2012-02-30” 这个时间时，会成功，但结果会是 “0000-00-00”；PostgreSQL 不允许插入此值

2、MySQL 里需要 utf8mb4 才能显示 emoji 的坑, PostgreSQL 没这个坑。

3、新老数据一起存放，需要定时触发 VACUUM，会带来多余的 IO 和数据库对象加锁开销， 引起数据库整体的并发能力下降。而且 VACUUM 清理不及时，还可能会引发数据膨胀。

基本的坑和解决办法 1：内存不够用

错误日志：ERROR: XX000: Canceling query because of high VMEM usage. Used: 2433MB, available 266MB, red zone: 2430MB GreenPlum 自带策略：如果 使用内存 / gp 总内存 > 90%，则会取消后续的 SQL SQL 被取消，则数据丢失。

内存使用过大，可能的原因有：

1、单条 SQL 过大，来自于批量插入，或者查询的时候的 in 语句里查询过多 。

2、正常使用下，所需要的内存和配置不匹配

做法 

1、提高 gp 总内存，根据服务器配置来看情况配置 

2、降低空闲资源过期时间，默认是 18s，可改为 5s 3s，这样资源可提高回收速度和效率 

3、代码中检查会连接泄露的地方，入库有手动获取连接的，需要关闭 

4、SQL 拆分，设置 split 分批插入，优化大 in 语句的查询 

5、代码兜底，如果出现被取消的异常，需要做重试和异常记录 

基本的坑和解决办法 2：死锁

原因：同一张表的同一条记录，在同时插入或者更新，分了多个区，在不同分区下数据入库造成冲突，这时候的锁是 ROW EXCLUSIVE（行级排他锁） 锁竞争造成死锁，最后 SQL 被取消，入库失败

解决办法：

1、为了保持较高并发，提高入库效率，开启全局死锁检测器，开启并发更新，让全局死锁检测器检测死锁是否存在。

2、如果完成了 1，则死锁异常会被抛出，既然死锁这个情况在数据库层面不可避免（MySQL 也会有死锁，多线程代码也有死锁） 则考虑从入库逻辑上避免死锁。 

2.1 通过对 id 进行人为分区，相同 id 的一定会根据某种逻辑（哈希或者其他的）分到同一个区 

2.2 串行提交，同步入库，隔绝相同 id 与数据库的写操作 

3、代码兜底，如果出现死锁，则随机 sleep 时间，再重试。

说明

1、默认情况下，全局死锁检测器是被禁用的，Greenplum 数据库以串行方式对堆表执行并发更新和删除操作。

2、可以通过设置配置参数 gp_enable_global_deadlock_detector，开启并发更新并让全局死锁检测器检测死锁是否存在。

3、启用全局死锁检测器后，master 主机上会自动启动一个后端进程，有参数可以设置，可设置采集和分析锁等待数据的时间间隔。

4、如果全局死锁检测器发现了死锁，它会通过取消最新的事务所关联的一个或多个后端进程来避免死锁。

基本的坑和解决办法 3：hand 死

现象

1、查询变慢，查询没有返回数据，然后直接报错。

2、数据没有进行下去。

3、查看日志后发现卡住。

排查 

1、工程使用 Druid，观察到获取连接时，线程被挂起，多个线程都是如此。查询连接数，很多连接都在执行，但没有动静。

2、物化视图一直循环刷新，创建，然后卡住 

3、挑着人为杀掉几个连接，刷新物化视图的动作报错，代码继续执行。

解决

1、代码中检查会连接泄露的地方，入库有手动获取连接的，需要关闭。

2、Druid 连接配置优化，关闭 poolPreparedStatements，配置连接的最大生存时间，配置在 xx 秒后回收空闲连接 

3、测试环境开启日志监控，如果出现超时连接泄露，强行关闭连接（只能在测试环境配置，用于排查问题）

4、物化视图的刷新逻辑，从 refresh 改为定时刷，同时改为创建新的物化视图，在删掉旧的物化视图。

基本的坑和解决办法 4：连接的 jar 包使用和选择

PostgreSQL vs Pivotal 有两种 JDBC 连接包可以实现连接

1、通过 PostgreSQL 的接口库连接, className: org.postgresql.Driver 

2、官方 partner 提供的连接库（greenplum.jar），className: com.pivotal.jdbc.GreenplumDriver ，第二种专门针对 Greenplum 进行了优化，性能上稍优，

3、GreenplumDriver 没有实现 setSchema 和 getSchema ，当调用这两个方法时，改用 postgresql，所以 代码中两者都有用到 upsert vs rule 

4、github 中的 greenplum，发行版是 6.1 6.2；之前新闻说 gp7 支持 upsert，但来不及。第一开始使用的是 rule，比较慢 3、master 分支已合并 postgresql upsert 逻辑，支持，最后直接编译，upsert 的速度比 rule 快

资料来源和可逛的地方

1、https://www.modb.pro/ 墨天轮，信创和数据库帖子和资料多

2、PostgreSQL 完全免费，是 BSD 协议，如果你把 PostgreSQL 改一改，然后再拿去卖钱，应该没有人管你，国产化数据库很多都是基于 PostgreSQL 改造的。

3、Greenplum 的官方网站、官方微信公众号、官方 B 站账号。