:GaussDB T上生产整体规划丨GaussDB野生教程( 二 )


单机和主备两种架构和传统的关系型数据库在使用上没有太大的区别 , 就某个角度而言 , 甚至可以说是“简化版” 。 至于分布式 , 在理解上则复杂一些 , 笔者将通过一个实际的例子读者理解 。
Database Manager(简称DM , 下同)是官方的运维工具 , 实际效果一般 , 而其内存消耗更是让虚拟机吃不消 , 然而考虑到实际生产中 , 此工具可用于数据库升级 。 因此笔者还是建议就学习而言 , 还是带上此工具 。
各种组件/术语的描述
下面的表格是笔者结合官方文档、官方教材以及个人理解 , 总结出的各种组件的要素 , 理解这部分内容是规划实例分布情况的前提 。
:GaussDB T上生产整体规划丨GaussDB野生教程
本文插图
理解分布式环境中的CN和DN
下面是笔者的其中一个分布式测试环境(注:GTS仅单实例是错误示范 , 笔者仅是方便测试GTS实例所在主机宕机的影响才这么做的) 。
:GaussDB T上生产整体规划丨GaussDB野生教程
本文插图
这是一个由3CN3DN组成的5节点分布式环境 , 具体描述如下:
1)DN组共三个 , 每组均为两副本 , 主DN分布在主机1、主机2、主机3上 , 备DN则分布在主机3、主机4、主机5 , 此环境的“分片数”为3 。
2)CN共三个 , 客户可以通过连接主机1、主机2或者主机4访问业务数据 。
假设这里有八条业务数据 , 其中ID为主键 , (NUM业务上也可以保证唯一且非空)详情如下:
:GaussDB T上生产整体规划丨GaussDB野生教程
本文插图
在把这八条数据存储到数据库之前 , 我们首先得创建一个数据库表 。 与在Oracle等传统关系型数据库上建表不同的是 , 我们需要考虑额外一个问题是 , 数据怎么在这三个DN组里面分配呢?这就是GaussDB里面的“水平分表” , 具体包括HASH、RANGE、LIST、Replication实在方式 , 具体可以参考产品文档相应描述 , 笔者这里选择使用ID字段做HASH分布 。
选定水平分表方式之后 , 笔者需要做的就是创建表并插入数据 , 问题来了 , 在哪里操作呢?作为业务数据 , 我们可以在主机1、主机2和主机4上随机选择一个执行操作即可 , 此处笔者选择主机1并完成相应执行 。
至此 , 表创建好 , 数据也导入好了 , 为了验证CN之间的平等性 , 我们可以连接分别主机2、主机4上验证确定相应表和数据均可被访问 。 这里引申出一个实际问题 , 生产环境中 , 应用程序该连哪个CN 。 官方给了F5硬负载均衡以及GaussDB软负载均衡两种方式 , 具体可以参考官方产品文档工作负载管理部分 。
接下去我们还可以分别连接到DN中 , 查看数据的分布情况 , 笔者实测的结果为三个DN里面分布含有5、2、1条记录 。 数据量实在太少 , 这也可以理解 。
最后 , 回到表里面 , 我们最初的描述里面 , NUM字段是唯一且非空的 , 那我们能不能直接基于NUM字段创建一个唯一索引呢?答案是否定的 , 创建索引语句直接遇到''GS-00101, Capability: table's distribute columns list not the subset of unique index columns list not supported''这个报错 , 好吧 , 不带DISTRIBUTE BY的字段玩是不行的 。 这也对应了官方开发者指南里面的一句话“不支持跨DN节点的唯一性约束;如果需要支持唯一性约束 , 唯一性约束列必须包含所有分片列 。 ”
通过上面的例子 , 我们可以大概了解CN和DN的作用了 , 也大概能看到分布式架构的难处:每个表都得考虑水平分布策略 , 而水平分表策略还可能和唯一性约束等常规项目相抵触 。
如何规划单机和主备架构
单机架构的规划一句话带过即可 , 集群包括三个ETCD、一个CM、一个DN , 均部署在一台主机上 。