前言
随着传统的关系型SQL数据库（Oracle，MySQL，PostgreSQL等）难以满足日益增长的高数据量、快速数据处理要求、高数据库安全及强容灾能力要求（RPO，RTO）等挑战，尽管NoSQL非关系型数据库以非结构化、数据格式灵活、无通用SQL语言、使用API、支持PB级存储等优势而一跃而上。 但NewSQL（Gbase等）数据库的出现，使得数据库使用者更需要去熟悉这种SQL+NoSQL特性兼具，查询效率高，保留了对SQL数据库的支持以及SQL语句的使用，支持ACID和数据一致性，实行MPP大规模并行处理的数据库。
写这篇文章的目的是记录并分享学习国产分布式数据Gbase的心得体会，欢迎感兴趣的伙伴一起交流，不足和错误之处敬请批评指正，文章会保持修改更新。
感谢
感谢南大通用提供的《GBase 8c多摸多态分布式数据库认证课程》及课件PPT，有进一步了解的伙伴，请自行前往官网天津南大通用数据技术股份有限公司|GBASE了解，并去报名培训所感兴趣的产品和知识。
一、基本介绍
GBase 8C是基于openGauss构建的一款多模多态的分布式数据库。支持行存、列存、内存等多种存储方式（多模：多种存储模式）和单机、主备式、分布式等多种部署形态（多态：多种部署形态）。
具备高性能、高可用、弹性伸缩、高安全性等特性，可部署在物理机、虚拟机、容器、云服务，为关键行业核心系统、互联网业务系统和政企业务系统提供安全、稳定、可靠的数据存储和管理服务。
支持标准SQL语法，兼容PostgreSQL和Oracle语法。
支持国产主流芯片、服务器、操作系统、中间件产品、服务完全本地化。
1. OLTP和OLAP
| 区别 | OLAP（Online Analytical Processing） | OLTP（Online Transaction Processing） |
| 名称 | 联机分析处理 | 联机事务处理 |
| 定义 | 是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 | 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易、数据操纵（要求响应时间快） |
| 功能 | 专门为支持复杂的分析操作而设计的用于分析数据。 | 以业务处理为主，主要用事务更新 |
| 响应要求 | 要求系统的响应时间合理。 | 响应时间要求非常高 |
| 面向人群 | 面向决策人员、高级管理人员 | 面向操作人员、底层管理人员 |
| 并发数 | 并发连接数大 | 并发连接数小 |
| 多纬操作 | 钻取，切片，切块，上卷，旋转 |
2.GBase 8c名词概念
| 名次 | 角色 | 功能 | 配置方式 | 备注 |
| GHA Server | 高可用（High availability）管理器 | 管理各整个集群各节点的高可用状态。 | 主备高可用架构，主备之间可以配置同步或异步方式 | 读取各节点的高可用状态。GHA和DCS合起来完成一个高可用功能。 |
| DCS/HA Center | 集群状态管理器 | 存储各节点的高可用状态，负责在故障情况下判断集群各个节点状态并进行状态切换。 | 采用Raft的复制协议 | 存储各点的高可用状态 |
| GTM （Global Transaction Manager） | 全局事务管理器 | 负责生成并维护全局时间戳，保证集群数据一致性。 | 主备高可用架构，主备之间可以配置同步或异步方式 | 采用2pc方式，保证强一致性 |
| CN（Coordinator·） | 协调器 | 对外提供接口，负责进行SQL解析和优化、生成执行计划、并协调数据节点进行数据查询和写入 | 采用完全对等的部署方式 | |
| DN（Datenode） | 数据节点 | 用于处理存储本节点相关的元数据以及所在的业务数据的分片。 | 主备高可用架构，主备之间可以配置同步或异步方式 | |
| HG | 高可用组 | 管理同一DN，主备节点的群组。 | HG的个数取决于不同DN节点的数量 | 每个高可用足，包含多个DN节点 |
3.架构演进
- 集中式数据库的缺点：
无法横行拓展；存在单机性能上限；软硬件成本高；
- 分布式中间件：中间件解决了横向拓展问题，但是底层架构仍不具备分布式能力；
- 采用LSM-tree的分布式数据库，适用于写多读少场景，读性能不高；
- 分布式数据的诞生是为了解决集中式数据库横向拓展的问题。
4.名词—分片及分片键
- 为什么要分片：
对于大业务量的应用（淘宝，京东）来说，单实例MySQL数据库在性能和容量上无法满足高需求，例如双十一，618购物节。所以，分布式数据库架构设计的原则是：选择一个适合的分片键和分片算法，把数据打散，并且业务的绝大部分查询都是根据分片键进行访问。
- 最推荐的分片规则：分库分表—每个分片的库名不一样，表名也不一样。
- 分库分表的好处：
- 不同分片的数据可以在同一 MySQL 数据库实例上，便于做容量的规划和后期的扩展；
- 同一分片键的表都在同一库下，方便做整体数据的迁移和扩容。
- 分片键（Shard Key），即用户可以通过这个字段进行数据的水平拆分
- 分片键的要求是业务经常访问的字段，且业务之间的表大多能根据这个分片键进行单元化；
- 选择完分片键后，就要选择分片算法，通常是 RANGE 或 HASH 算法；
- 海量 OLTP 业务推荐使用 HASH 算法，强烈不推荐使用 RANGE 算法；
5.分布式环境下的一致性
在分布式环境下，一致性指数据的多个副本之间是否保持一致的特性。
分布式一致性协议：两阶段提交协议2PC（GBase 8c采用2PC协议）
参考资料：分布式一致性，看一遍就懂 - 知乎
二、产品特性
1.多模——多存储模式
GBase 8c支持多个存储引擎以满足不同场景的业务需求
行存储引擎：主要面向OLTP场景设计，例如订货、发货、银行交易系统；
列存储引擎：主要面向OLAP场景分析，例如数据统计报表分析系统；
内存引擎：主要面向极致性能场景设计，完全支持ACID，包括严格的持久性和可用性支持，例如银行风控场景。
行存表和列存表可以互相调用；（内存表不可以）
2.多态——多部署形态
-
分布式形态
CN协调器负责接收客户端的请求，进行SQL解析和优化，生成执行计划，并协调数据节点DN进行数据查询和写入，同时全局事务管理器GTM生成并维护全局时间戳，保证集群数据的强一致性。
支持“读已提交”RC（Read Committed）和“可重复读”RR（Repeatable Read）。
优势：可根据业务需求针对计算和存储能力分别进行水平拓展，适用于大数据量、高并发且追求高数据安全性的场景。
-
主备式形态
GBase 8c主/备：负责存储业务数据、执行数据查询及向客户端驱动返回执行结果。
Storage：服务器的本地存储资源。
优势：部署简洁、交付高效、适用于低数据量场景，追求极致单机性能且要求数据备份的场景。
-
单节点形态
单节点部署。
优势：低成本，部署简洁。
3.核心特性
4. OLTP特性
5.分布式特性
6.企业级特性
7.管理平台特性
三、核心技术
1.数据分布策略
通过复制表，分布表实现从共享架构==>分布式架构
2.单节点事务/本地事务
本地事务：落在本地节点的事务直接走本地事务引擎，无需启动分布式事务。
性能高：不走两阶段提交过程，并发度高，满足吞吐量要求。
包含：单节点的查询、写入和更新。
3.分布式事务
跨节点的事务，通过GTM管理来执行分布式事务，按需分配资源。
刚性事务：严格的两阶段提交过程，实现跨节点分布式事务。
两阶段提交过程：分布事务和DN之间，Prepare => Prepare OK，Commit => Commit OK。
4.单表查询下推
单表查询：只涉及单表的查询
分片键上的where条件
直接下推到对应的DN执行：
非分片键where条件
DN先做计算，CN做结果汇总（扫描所有数据节点），order by可以直接下推到DN：
5. Join查询下推
分片键上的join条件
直接下推到对应的DN执行：
非分片键上的join条件
DN直接做数据交换，避免CN成为性能瓶颈：
6.异地灾备—两地三中心
7.异地多活
8.基于全局事务提交时间戳TSO
GTM采用基于全局事务提交时间戳的方案代替全局活跃事务列表的方案来管理全局事务；
GBase 8c的DN节点部分场景仍采用活跃事务列表的方式管理事务；
GTM生成并维护全局时间戳CSN，是一样自增的整数值“提交序列号”；
当事务开启时从GTM获取当前时间戳CSN，事务提交时 commit，“提交序列号”+=1；
CSN为8个字节，64位，8K大小。8位系统位，支持2的56次方的事务级别。
9.全局死锁解除
10.事务状态保持
当CN2故障宕机，切换至CN3进行数据协调。
11.原位更新
12.灰度发布
GBase 8c 支持灰度发布，可以在保证业务持续可用的条件下，进行数据库版本升级和发布。 在灰度发布的过程中，GBase 8c 可以秒级切换，具备系统持续可用的能力。
13.弹性伸缩
GBase 8c 具备弹性伸缩能力，用户可以根据业务需求和策略设置伸缩规则。在业务需求增长时，系统自动增加数据库节点以保证计算存储能力，在业务需求下降时，系统自动减少数据库节点以节约成本。
GBase 8c按表做hash（一种分片的方式），做扩容和缩容。
一致性hash表在扩缩容时性能比较好，但是因为表拆分太多导致DML比较慢。一般建议大表创建一致性hash，小表采用普通hash表（建表默认是普通hahs）。
GBase 8c的在线扩容功能，支持任意节点的扩容。
14.周边工具—数据迁移工具
