共计 3640 个字符，预计需要花费 10 分钟才能阅读完成。
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 站账号。