diff --git a/content/zh/post/2.png b/content/zh/post/2.png new file mode 100644 index 0000000000000000000000000000000000000000..4445edf8e724c7cf68651a740b9e685a1c0e537e Binary files /dev/null and b/content/zh/post/2.png differ diff --git a/content/zh/post/m/3.png b/content/zh/post/m/3.png new file mode 100644 index 0000000000000000000000000000000000000000..66bacf0fbb72bb5feb27634c2d9b0d0d9cb616a6 Binary files /dev/null and b/content/zh/post/m/3.png differ diff --git "a/content/zh/post/m/\343\200\220\346\210\221\344\270\216openGauss\347\232\204\346\225\205\344\272\213\343\200\221openGauss3.1.0\347\211\210\346\234\254\345\201\232\344\274\230\345\214\226.md" "b/content/zh/post/m/\343\200\220\346\210\221\344\270\216openGauss\347\232\204\346\225\205\344\272\213\343\200\221openGauss3.1.0\347\211\210\346\234\254\345\201\232\344\274\230\345\214\226.md" new file mode 100644 index 0000000000000000000000000000000000000000..566fec0f4cab35439bf28f9269250918b6eef1a9 --- /dev/null +++ "b/content/zh/post/m/\343\200\220\346\210\221\344\270\216openGauss\347\232\204\346\225\205\344\272\213\343\200\221openGauss3.1.0\347\211\210\346\234\254\345\201\232\344\274\230\345\214\226.md" @@ -0,0 +1,166 @@ +--- + +title : "【我与openGauss的故事】openGauss3.1.0版本做了哪些优化" + +date : "2022-11-13" + +category: "blog" + +tags : ["openGauss", "数据库", "性能优化"] + +archives : "2020-11" + +author : "m丶shine" + +summary : "Just about everything you'll need to style in the theme: headings, paragraphs, blockquotes, tables, code blocks, and more." +--- + +前言 + +![输入图片说明](3.png) + +从第一次使用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 的迁移性能。 + + + +(2)MySQL 增量迁移支持事务级并行消费，提升增量迁移性能 + + 基于开源三方件 mysql-binlog-connector-java 解析 mysql 的 binlog，并根据 mysql 主备并行复制的原理，对可并行的事务在 openGauss 端采用多线程进行并行回放，以实现 MySQL 到 openGauss 的在线迁移。 + 利用 sysbench 对 MySQL 压测，在 10 张表 30 个线程并发情况下，IUD 混合场景下，在 Kunpeng-920 2p 服务器上测试整体增量迁移性能可达 3w tps。 + + + +(3)支持支持基于默克尔树的数据校验 + + 实现基于默克尔树的数据实时校验工具，支持 MySQL 数据迁移到 openGauss 时，源端与目的端数据全量和增量校验。 + + + +(4)支持 openGauss 到 MySQL 迁移，满足 MySQL 反向迁移要求 + + 特性基于 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更稳定,技术也更成熟,向我们这种喜欢研究数据库技术的小伙伴们非常友好,希望可以一直讲技术完善下去. +![输入图片说明](../2.png) + + + + + diff --git "a/content/zh/post/m/\345\233\276\347\211\207.png" "b/content/zh/post/m/\345\233\276\347\211\207.png" new file mode 100644 index 0000000000000000000000000000000000000000..66bacf0fbb72bb5feb27634c2d9b0d0d9cb616a6 Binary files /dev/null and "b/content/zh/post/m/\345\233\276\347\211\207.png" differ