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站账号。
