作者介绍
黎君原，新炬网络服役10+年的老鸟，期间打过杂、搬过砖、挖过坑（运维、割接、系统建设），目前对于国产数据库来说只是个新兵。
本文是“GaussDB野生教程”系列文章第一篇——整体规划，后续将陆续发出包括：软件部署、资源申请、简要测试、常规变更等内容的GaussDBT应用解析与排坑，敬请期待。
前言“学习GaussDB是一种什么体验？”
“路漫漫其修远兮，吾将上下而求索！”
“说人话。”
“打脸，打脸，再打脸……”
上面就是笔者写这个系列文章的原因了，笔者学习GaussDB的过程中被“打脸”太多，现在想稍稍停步，做个总结。而为了掩饰自己个人能力不足，笔者还补充了下面几个学习困难的原因：
GaussDBT方面资料有限，目前仅有官方教材、产品文档、开发指南等十份左右的文档，部分内容语焉不详甚至相互矛盾；
Oracle等传统数据库的思维限制；
作为发展中的国产数据库，产品确有不足；
项目经历有限。
笔者写这个系列文章的契机为GaussDBT1.0.2刚发布不久，想借着“安装数据库”这种最基础的操作，以加固对GaussDBT的理解。与着重展示搭建步骤的文章不同，本文是奔着生产部署以及后续运维而去的，安装只是过程，理解才是关键，而实际运维怎么办才是重中之重。这个系列的文章将由五部分组成：
整体规划（即本文）：着重介绍GaussDBT的软件架构并给出规划建议。
资源申请：以提升沟通效率为出发点，探讨GaussDBT在搭建前的环境准备要素，此外笔者还总结了一份“系统变更汇总”，分享了部分学习环境虚拟机使用经验。
软件部署：除了GaussDBT、DatabaseManager的基本安装命令以外，笔者还附带了大量“过于真实”的补充说明和建议。
简要测试：介绍了如何使用zql、gs_om、gs_gucZenith工具，并附带了几个实验案例，供读者更好地理解GaussDBT。
常规变更：探讨了真实生产环境中安装GaussDBT后常见且必须的各种操作，如数据库参数调整、表空间管理、黑白名单管理等。
如何理解单机、主备、分布式三种架构共性和差异上面是从官方产品文档中摘录出来的三种软件架构图，从图中我们可以看到：
ETCD、DN、CM是三种软件架构共有的组件；
GTS、CN则是分布式架构独有的组件；
各种架构均可接入运维工具DM以及开发工具DataStudio。
对于单机、主备两种架构来说，值得商榷的一点是，到底ETCD以及CM需不需要安装。根据官方教材中所描述的“数据库安装”以及官方培训，单机和主备的安装步骤均为上传一个不到10MB的安装包，然后执行几条简单的命令，即可完成安装步骤，此处的安装对应的是DN，至于ETCD和CM是不涉及其中的。
而笔者所实际接触的某个架构为主备的项目中是完整部署ETCD以及CM的，由此，笔者偏向于实际生产是需要安装ETCD和CM的。而从理论而言，CM可以在主备架构中承担“主备倒换”的功能从而实现故障自动切换，ETCD则为CM运行的基础，故而应当在主备环境中部署这两个组件；至于单机模块，基本仅会在测试环境中涉及，whocare?本系列文章以完整安装CM、ETCD的前提下进行。装与不装这两类实例对于生产而言最大的差异在于运维的命令都得改变，这点会在后续软件部署的章节中探讨。
单机和主备两种架构和传统的关系型数据库在使用上没有太大的区别，就某个角度而言，甚至可以说是“简化版”。至于分布式，在理解上则复杂一些，笔者将通过一个实际的例子读者理解。
DatabaseManager（简称DM，下同）是官方的运维工具，实际效果一般，而其内存消耗更是让虚拟机吃不消，然而考虑到实际生产中，此工具可用于数据库升级。因此笔者还是建议就学习而言，还是带上此工具。
各种组件/术语的描述下面的表格是笔者结合官方文档、官方教材以及个人理解，总结出的各种组件的要素，理解这部分内容是规划实例分布情况的前提。
理解分布式环境中的CN和DN下面是笔者的其中一个分布式测试环境（注：GTS仅单实例是错误示范，笔者仅是方便测试GTS实例所在主机宕机的影响才这么做的）。
这是一个由3CN3DN组成的5节点分布式环境，具体描述如下：
1）DN组共三个，每组均为两副本，主DN分布在主机1、主机2、主机3上，备DN则分布在主机3、主机4、主机5，此环境的“分片数”为3。
2）CN共三个，客户可以通过连接主机1、主机2或者主机4访问业务数据。
假设这里有八条业务数据，其中ID为主键，（NUM业务上也可以保证唯一且非空）详情如下：
在把这八条数据存储到数据库之前，我们首先得创建一个数据库表。与在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-,Capability:tablesdistributecolumnslistnotthesubsetofuniqueindexcolumnslistnotsupported"这个报错，好吧，不带DISTRIBUTEBY的字段玩是不行的。这也对应了官方开发者指南里面的一句话“不支持跨DN节点的唯一性约束；如果需要支持唯一性约束，唯一性约束列必须包含所有分片列。”
通过上面的例子，我们可以大概了解CN和DN的作用了，也大概能看到分布式架构的难处：每个表都得考虑水平分布策略，而水平分表策略还可能和唯一性约束等常规项目相抵触。
如何规划单机和主备架构单机架构的规划一句话带过即可，集群包括三个ETCD、一个CM、一个DN，均部署在一台主机上。
主备架构的规划方面可以说的有如下几点：
1）建议配置浮动IP共业务使用
如上文所述，这可以减少主备切换对业务的影响。
2）重点