GBase8a 数据库部署及数据存储原理

部署方案

网络平面类型

GBase 8a MPP Cluster 的网络部署规划可划分为 2 个物理隔离的平面网络，分别是 数据平面网络和业务平面网络。

•   数据平面网络用于集群内部的数据运算及集群管理，也叫集群内部网络；
•   业务平面网络用于业务系统访问，也叫集群外部网络；
•   GBase 8a MPP Cluster 由GCluster Cluster、 GCware Cluster 和Data Cluster 组成，采用两平面网络组网时，GCluster Cluster 中节点分别接入数据平面和业务平面，可以为每个 GCluster Cluster 中节点配置内部网IP 和外部网 IP；数据集群中的每个 data 节点只接入数据平面，只需配置内部网IP；GCware Cluster 集群中的每个节点只接入数据平面，只需配置内部网IP；
• 建议 GCware 节点与 GCluster 节点部署在同一服务器上，GCware 节点和GCluster 节点使用相同的内部网IP 即可。

规划方案

集群规模及节点类型建议

根据集群规模建议集群中Data 节点、GCluster 节点和GCware 节点个数分配如下：

集群部署方案建议

 对称部署

将 GCWare、GCluster 和 GNode 部署在同一节点，即同一服务器既是 Coordinator节点也是Data 节点。

 非对称部署

将 GCWare、GCluster 和GNode 部署在不同节点上

•  将 GCluster Cluster、GCware Cluster、Data Cluster 分别部署在不同的服务器上；
•  将 GCluster Cluster 和 GCware Cluster 部署在一台服务器上，将 Data Cluster 部署在单独的服务器上。

数据分布式存储

列存和行列混存

数据在磁盘中按照列的方式进行组织和物理存储。面对海量数据分析的磁盘 I/O 瓶颈，分析型数据库把表数据按列的方式存储，列存储架构对查询、统计和分析类操作具备天然的优势。其优势体现在以下几个方面：

降低 I/O

只有访问查询所涉及的列才会产生磁盘 I/O，查询中没有涉及的列不需要访问也不产生磁盘I/O。

高压缩比

压缩比可以达到 2 ~ 20 倍。

支持行列混存

GBase 8a MPP Cluster 支持行列混存。对于列存储的集群架构，当操作涉及的列数较多，访问的数据记录非常离散时，会造成大量的离散 I/O。行列混存功能通过存储冗余行的信息，提高磁盘 I/O 性能。

分布式存储

GBase 8a MPP Cluster 可处理PB 级以上的结构化数据，对于大表数据可采用随机数据存储分布策略模式或哈希数据存储分布策略模式。用户可以按照业务场景的需求，选择合适的数据存储分布策略，从而在性能、可靠性和灵活性间获得最佳平衡方案。

随机数据存储分布策略模式

随机数据存储分布策略模式是指数据库创建随机分布的分布表，在进行数据入库时数据将随机均等的分布到各个数据节点上。

哈希数据存储分布策略模式

哈希数据存储分布策略模式是指在数据入库时对原始数据中的每条数据按指定的哈希分布列进行处理，处理后的数据按照哈希值装入特定的哈希桶中，每个哈希桶对应一个集群数据节点。这样每个节点所得到的数据就都具有了某种共同特征（指定列都具有相同的哈希值），在查询时优化引擎可以根据这些共同特征对查询计划进行优化，以达到缩短查询时间的目的。

数据库支持创建两种类型表，分布表与复制表。

分布表又分为两种，一种是随机表，数据存储使用随机数据存储分布策略。另一种哈希分布表，数据存储使用哈希数据存储分布策略模式。

复制表，数据存储为各个 data 节点上存放的是完整数据。是每个数据节点存储一份数据。

CREATE TABLE 创建新表时：

1、使用关键词 REPLICATED 创建复制表。

2、使用关键词 DISTRIBUTED 指定创建表中的物理列 column_name 是哈希列，称为哈希分布表。哈希列可以是整数类型（INT、BIGINT 等）、VARCHAR 或者 DECIMAL 类型。

3、默认创建为无关键词，为随机表。

集群的存储

数据库的数据一般分为两类:元数据和用户数据

1、元数据 元数据是描述数据的数据，主要用来描述数据的属性信息，包括数据存储位置、数据之间的关系等。 元数据主要由 Gcluster 组件负责管理和保存。所有 gcluster 节点的元数据内容保持一致。
gcluster 节点保存的元数据包括: VC 信息、TableID 信息、库字符集信息、表结构信息、列属性信息、表属性信息和索引信息等。一般可通过查询系统库 information_schema 和 gbase 库查看。
Gcware 组件负责记录集群所需的一致性信息。包括:集群的拓扑结构和分片规则、SCN 号 、TABLE_ID 、COMMIT_ID 、 TASK_ID、VCID、集群恢复日志、集群状态、集群锁等信息。gcadmin 工具可查询部分内容。 gnode 节点上只保存属于自己的元数据。包括:读写标志信息、DC 信息等。

2、用户数据:
用户数据主要指业务数据，是表内的实际数据。它们分布存储在不同的 gnode 节点上。 在物理集群中，多个 gnode 节点按照业务主题不同被划分到不同的 VC 中，每个 VC 内参照用户为这个VC 创建的 distribution 分布信息表来分配数据分片。每个数据分片对应若干个 hash 值，与这些 hash 值匹配 的数据都会被存储到对应分片所在的节点上。分片与节点的对应关系可查看 distribution 分布信息表。

参考下图:

VC1 内的 product 库中有一张 stock 数据表，分别记录着 ProID、ProType、Matenal、Customer Name、 Quantity 五列数据。该表的 ProType 列被选为 hash 分布列。

在系统库 gbase 库的 nodedatamap 系统表中，记录着 hash 结果(hashkey)、分片(Nodeid)、分布表 (Date_distribution_id)的对应关系。如上图，hash 结果为 40610 的数据，它存在第一个分片中(Nodeid 为 0)，该分片属于 distributon_Id 为 1 的分布信息表中。

在系统库 gbase 库的 table_distribution 系统表中，记录着库、表、hash 列、分布表 id 和 vc_id 的对应关 系。product 库的 stock 表的 hash 分布列是 ProType，对应的 distribution 分布信息表是 1，对应的 VC 是 VC1 的默认 ID“vc00001”。

我们以 VC1.product.stock 表为例，hash 分布列中第一行数据的值为 845，通过 hash 计算得到的结果是 40611(hashkey=(crc32(‘845’)) mod 65536)，对应 VC1 中的分片 2(Nodeid 为 1)，该分片属于 VC1 的 distribution1。

上图左下角 VC1 的 distribution1 中罗列了 VC1 内的 4 个分片，分别是:DN0、DN1、DN2、DN3。

VC1.product.stock 表中第一行数据，就对应第二个分片，所以第一行数据就存储到第二个分片对应的节 点上。因为采用列存储方式，每一列都会有一个文件存储它的列数据。

第二行的数据，其 hash 分布列数值是 851，它的 hash 结果是 64888(图中省略了对应分片)，该行数 据会存到那个分片对应的节点上。

第三行的数据，其 hash 分布列数值也是 845，与第一行数据一样，所以它的 hash 结果也对应到了第二 个分片中，其数据也存在第二个分片对应的节点上。