GaussDB(DWS)免费试用(2021年4月)

论坛里发帖比较难找，搬运到blog

0元购买后，来创建集群，这个要选择免费规格 4C32G，鲲鹏的，标准数仓

提交后，大概5分钟左右，集群就创建好了，包含3个节点主机

然后是看下文档啥的

给绑定一个公网IP，这样客户端可以通过公网连接上进行访问。

因为之前有买鲲鹏的ECS，绑定过EIP，平时使用不频繁，所以辛苦点，先解绑EIP，再绑定到我的DWS

好了，试一下Data Studio客户端连接：，这里也有命令行客户端，回头可以在我的鲲鹏ECS上试一下，或者是直接在DWS节点上使用？

连接成功：

好的开始。

感觉还是比较顺利的，环境准备和配置不再痛苦~

然后是按照快速入门来操作，

首先引入的是一个“交通卡口”的用例，

先create database traffic，然后打开这个数据库，并连接

再create schema traffic_data, set current_schema ， create table

再create schema tpchobs, set current_schema='tpchobs' , create foreign table

这里'tpchobs'有引号，应该是有问题的，会导致后面的操作报错：去掉引号后重新在这里执行就可以。

错误代码：[0]SQL错误码: = 3F000
ERROR: schema "tpchobs" does not exist

然后从obs外表insert into本地表，执行时间12分钟，8亿9千万条数据，速度感觉还可以？不过表结构也不复杂

小总结：

以前postgres数据库没接触过，接触过mysql.oracle等。

原来这里有建立schema的动作，感觉管理层次上多于mysql而少于oracle，介于2者之间

另外在obs的基础上建立外表，倒是很新鲜~

试了一下gsql命令行工具在内网访问数据库，没有问题。ECS没有公网IP时，使用CloudShell也很不错~

那我可以把公网IP收回来还给ECS喽

另外gsql在鲲鹏平台的ubuntu18.04上运行看上去没啥问题，可以连接上前面建立的traffic数据库，创建表之类的操作。

接着把“交通卡口”的做完，使用gsql命令行

这个gsql使用的比较少，所以有不熟悉的感觉

结果显示和mysql的命令行有差异，也没有命令执行的时长展示。

交通卡口到这里就结束了。

执行sql前开始\timing 就会打印执行时间了.

找了一下帮助没有找到相关信息

就是执行一条SQL后

除了展示执行结果，还展示该执行花费了多长时间

gsql连上执行\timing后再执行sql即可

例：

postgres=# \timing
Timing is on.
postgres=# create table test0001(a int,b int);
NOTICE:  The 'DISTRIBUTE BY' clause is not specified. Using 'a' as the distribution column by default.
HINT:  Please use 'DISTRIBUTE BY' clause to specify suitable data distribution column.
CREATE TABLE
Time: 18.373 ms

\timing [on|off]       toggle timing of commands (currently off)

还是自己没看仔细...

第一天的学习之后，产生了一些问题，得到了热心网友的回答，现在开始第二天的学习

第一天的交通卡口的结束后，还有二个，一个是供应链需求分析，一个是百货公司经营分析，

从业务上来说，涵盖的行业比较丰富；但从技术上来说，操练起来有些些枯燥乏味了，所以做了供应链后，百货公司那个就没做了。

完了之后忽然失去了方向，于是从最佳实践开头看起：表设计最佳实践

对照着交通卡口，感觉理解有了一些深入

先用gsql连上traffic数据库，然后设置显示执行时间、设置后台超时为无限时、另外我还学会了注意提示符=> 与 -> 的差别~

既然表已经建立好了，我们来看一下表的结构。

这里就可以对照“表设计最佳实践”来一一理解了

1.首先这个表是列存的（orientation=column）。说列存，适合于统计分析类查询；而行存适合于点查询，增删改比较多的场景。在交通卡口这个例子里，好像都可以，没有特别偏好？因为后面也有一个根据主键的点查询啊

2.然后数据分布（distribute by : HASH(hphm) ），这是个大表，当然不适合replication。所以用Hash将表数据分布到集群里所有的DN上。Hash一个字段，也就是选择了一个分布列。

如果分布列选择不当，可能导致数据倾斜，出现IO短板而影响整体性能。这个就像是挑担子一样，一头重一头轻是吃力的，也挑不稳。像十八个吊桶打水，**也是不行的

那么这个简单的例子里，数据是均匀的吗？当然是的，看

每个DN都分布着相近的2亿9千多万条数据，说，相差5%以上就是倾斜，差10%以上就要调整分布列了哦！

​ 

从gcjl表的结构可以看到，该表是列存（压缩比为中），使用号牌号码列(hphm)做hash分布存储，

没有建立一个索引，

而点查询、模糊查询都可以秒级响应，

这应该是分布式处理的功劳吧~

点查询：

select hphm, kkbh, gcsj
from traffic_data.gcjl
where hphm =  'YD38641'
and gcsj between '2016-01-06' and '2016-01-07'
order by gcsj desc;

模糊查询：

select hphm, kkbh, gcsj 
from traffic_data.gcjl
where hphm like  'YA23F%'
and kkbh in('508', '1125', '2120') 
and gcsj between '2016-01-01' and '2016-01-07'  
order by hphm,gcsj desc;

​ 

“交通卡口”例子中用到了分布表；复制表，在“百货公司经营分析”里有例子，就是二个类似于配置和枚举信息的表，一个是地区表region，一个是国家表nation

因为这二个表的数据量不大，数据变化也不会大，所以适合做复制表。在每个DN都保留一份，这样和分布表配合使用，珠联璧合哦~

复制表建立的语句例子：

set current_schema = tpch;

drop table if exists region;
CREATE TABLE REGION
(
        R_REGIONKEY  INT NOT NULL , 
        R_NAME       CHAR(25) NOT NULL ,
        R_COMMENT    VARCHAR(152)
)
with (orientation = column, COMPRESSION=MIDDLE)
distribute by replication;

drop table if exists nation;
CREATE TABLE NATION
(
        N_NATIONKEY  INT NOT NULL, 
        N_NAME       CHAR(25) NOT NULL,
        N_REGIONKEY  INT NOT NULL,
        N_COMMENT    VARCHAR(152)
)
with (orientation = column,COMPRESSION=MIDDLE)
distribute by replication;

DWS天然是分布式数据库，

证据：

当我随便建立一个表时，没有显式指定分布列

它就默认第一个字段作为分布列了！