前言
从第一次使用openGauss到现在，大约已经有4个月的时间了，参加了有关openGauss的活动和技术分享，慢慢的我对openGauss数据库的使用越来越熟悉，上手也很快，就在前段时间官方更新了最新一版的openGauss3.1.0版本，通过了解发现，相对于上一版本有了很多方面的优化，那么我们今天就来聊一聊openGauss3.1.0版本做了哪些优化吧！
openGauss 3.1.0 版本与之前版本特性功能保持兼容，在 可扩展性、企业级特性、高可用、高性能、高智能、高安全、工具链 等七大特性上全面增强。
一、优化升级
1.企业级特性
(1)行存表压缩能力增强
通过对行存数据进行压缩的操作，改变数据页面的存储状态。通过增加一个映射管理层将压缩页面分块落盘。整体过程发生在数据库脏页刷盘过程，对数据库的上层逻辑不影响，对用户不感知。
满足 TPCC 测试模型中，压缩率 2:1 以上，且性能劣化小于 5%。
个人理解：也就是说对数据库添加了一个映射层，可以理解为备份或者镜像的操作，为了让这个镜像投射出来的数据更完整，量更大，对数据进行压缩，可以理解压缩包存储文件之后进行的映射，个人理解大概是这个意思。
(2)发布订阅能力增强
轻量化版本支持发布订阅功能，满足边云协同场景需求。
支持发布端主备切换后订阅关系不断开。
支持同步订阅关系创建前的基础数据。
支持备份恢复后复制槽不丢失，保证发布订阅的连接正常。
支持以二进制格式发送数据。
个人理解：也就是数据的传输和发布上云的速度更快，这可能是调整了一些传输的协议吧，另外对数据传输中的安全性做了优化，如果数据丢失怎么办，所以这个版本也做了备份的优化
(3)细粒度滚动升级
在灰度升级下，提供一种升级指定部分节点的功能。保证在不中断业务的情况下，先升级部分节点再升级剩余节点，减少升级场景业务中断时间。
个人理解：也就是说,对于使用过程中,如果出现一些其他的中断情况,那么这个是分布式操作的,所以可以更好防止业务中断
(4)statement_history 视图诊断能力增强
备机支持 statement_history 视图，满足备机慢 SQL 诊断要求。
statement_history 增加对 waitevents 的统计，记录慢 SQL 执行时等待事件耗时和次数。
个人理解：也就是专门对才做和执行做了一个日志的视图表现.
2.高可用
(1)两地三中心跨 Region 容灾
支持灾备数据库 failover，满足主备集群异地网络时延<=100ms 时，数据库典型配置下灾备升主 RTO<=10min，RPO<=10s。
支持容灾主备数据库实例计划内 switchover，满足主备集群异地网络时延<=100ms 时，数据库典型配置下主备倒换，RTO<=20min，RPO=0。
(2)CM 支持对外状态查询和推送能力
通过 http/https 服务远程查询到集群的状态，便于管理人员、运维平台等监控集群状态。
在数据库集群发生切主事件时，通过 http/https 服务及时地将集群最新的主备信息推送到应用端注册的接收地址，便于应用端及时的感知到集群的主备变化，从而能够快速的连接到新的主机和备机。
(3)DCF 支持策略化多数派
DCF（Distributed Consensus Framework，分布式共识框架，基于 Paxos 算法实现数据同步强一致。）支持策略化多数派能力，以多数派为前提，同时根据用户配置的 AZ，保证 AZ 内至少有一个节点同步复制日志。
3.高性能
基础算子性能提升
新选择率模型典型场景选择率估算准确率提升 1X，性能提升 1X。
分区表页面估算优化典型场景性能提升 20%。
Partition Iterator 算子优化典型场景性能提升 5%。
函数依赖特性支撑多列查询典型场景行数估算准确率提升 1X 。
SeqScan 算子优化典型场景性能提升 10%。
个人理解：也就是说对于计算能力进行了优化
4.高智能
(1)DBMind 自治运维平台
构建端到端自治运维平台：新增异常检测能力，完善自监控、自诊断、自调优能力。
DBMind 服务化：提供简易的部署能力、通过新增 cmd exporter 扩充采集指标；将原有的 openGauss-exporter 扩展为 Agent, 便于获得即时信息；提供多种形式的功能 API，便于与用户已有的运维平台对接和集成。
异常检测：通过对监控到的指标进行分析，可以给出系统异常状态波动告警，包括基于规则的和基于算法的两种模式。其中，基于算法的包括对 spike, mean shift 等典型异常场景进行分析。
个人理解：也就是说搭建了一个为服务器服务的平台,对数据库平时的运行维护可以智能处理.
(2)智能优化器
实现库内 Bayes 网络算法并基于此实现智能统计信息以提高多列基数估计准确度，进而提升生成的执行计划质量。
计划自适应选择解决因数据倾斜、索引不准、使用 Offset 查询等引起的计划跳变难题，性能提升 1x 以上。
个人理解：也就是在上面平台搭建好之后,对这个智能优化的算法进行了优化,或者说对功能点进行了优化
5.高安全
细粒度 Any 权限增强
Any 权限管理，新增支持以下 5 种对象共 12 种 ANY 权限功能：
ALTER ANY TYPE、DROP ANY TYPE
ALTER ANY SEQUENCE、DROP ANY SEQUENCE、SELECT ANY SEQUENCE
ALTER ANY INDEX、DROP ANY INDEX
CREATE ANY TRIGGER、ALTER ANY TRIGGER、DROP ANY TRIGGER
CREATE ANY SYNONYM、DROP ANY SYNONYM
个人理解：目前国家对数据安全很重视,说明数据安全对我们的重要性,数据库权限的细致划分是很有必要的,但是分类越多的话,其实容易产生漏洞的可能性更大,这个地方其实可以进一步测试,加固权限之间切换的过程.
6.工具链
(1)MySQL 全量迁移性能提升，提升全量迁移性能
通过支持表级并行迁移，提升 MySQL 全量迁移性能，基于 sysbench 测试模型，在 Kunpeng-920 2p 服务器上，10 张表（单表容量三百万以上）使用 10 并发迁移，可达到大于 300M/s 的迁移性能。
基于开源三方件 mysql-binlog-connector-java 解析 mysql 的 binlog，并根据 mysql 主备并行复制的原理，对可并行的事务在 openGauss 端采用多线程进行并行回放，以实现 MySQL 到 openGauss 的在线迁移。
利用 sysbench 对 MySQL 压测，在 10 张表 30 个线程并发情况下，IUD 混合场景下，在 Kunpeng-920 2p 服务器上测试整体增量迁移性能可达 3w tps。
实现基于默克尔树的数据实时校验工具，支持 MySQL 数据迁移到 openGauss 时，源端与目的端数据全量和增量校验。
特性基于 openGauss 的逻辑复制实现，在 openGauss 端开启逻辑复制，使用 JDBC 获取逻辑解码，对逻辑解码进行 SQL 解析，通过多线程并发迁移到 MySQL 端，满足用户数据从 MySQL 迁移到 openGauss 后，两个数据库并行运行或迁移后逃生的诉求。
sysbench 对 openGauss 进行压测，在 100 张表 100 个线程并发情况下，针对 insert 场景，在 Kunpeng-920 2p 服务器上测试整体迁移性能可达 3w tps。
7.可扩展性
(1)集成 openLookeng，提供分布式 OLAP 能力
基于 openLookeng 实现分布式分析能力，openLookeng 复用 shardingsphere 中间件的分库分表能力，使 openLookeng 可以获取 openGauss 数据进行分析运算。加上 shardingSphere 搭配 openGauss 形成的分布式 OLTP 能力一起组合成分布式的 HTAP 能力。
(2)CM 支持管理 shardingSphere Proxy 和注册中心
CM 支持自定义资源管理，支持管理 shardingSphere Proxy 和注册中心，支持异常情况自动拉起。
二、结语
openGauss3.1.0对七大特性进行了全面增强,能明显感觉到openGauss更稳定,技术也更成熟,向我们这种喜欢研究数据库技术的小伙伴们非常友好,希望可以一直讲技术完善下去.
