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