确定性能调优范围

性能因素

多个性能因素会影响数据库性能，了解这些因素可以帮助定位和分析性能问题。

• 系统资源

数据库性能在很大程度上依赖于磁盘的I/O和内存使用情况。为了准确设置性能指标，用户需要了解集群部署硬件的基本性能。CPU，硬盘，磁盘控制器，内存和网络接口等这些硬件性能将显著影响数据库的运行速度。

• 负载

负载等于数据库系统的需求总量，它会随着时间变化。总体负载包含用户查询，应用程序，并行作业，事务以及数据库随时传递的系统命令。比如：多用户在执行多个查询时会提高负载。负载会显著地影响数据库的性能。了解工作负载高峰期可以帮助用户更合理地利用系统资源，更有效地完成系统任务。

• 吞吐量

使用系统的吞吐量来定义处理数据的整体能力。数据库的吞吐量以每秒的查询次数、每秒的处理事务数量或平均响应时间来测量。数据库的处理能力与底层系统（磁盘I/O，CPU速度，存储器带宽等）有密切的关系，所以当设置数据库吞吐量目标时，需要提前了解硬件的性能。

• 竞争

竞争是指两组或多组负载组件尝试使用冲突的方式使用系统的情况。比如，多条查询视图同一时间更新相同的数据，或者多个大量的负载争夺系统资源。随着竞争的增加，吞吐量下降。

• 优化

数据库优化可以影响到整个系统的性能。在执行SQL制定、数据库配置参数、表设计、数据分布等操作时，启用数据库查询优化器打造最有效的执行计划。

调优范围确定

性能调优主要通过查看集群各节点的CPU、内存、I/O和网络这些硬件资源的使用情况，确认这些资源是否已被充分利用，是否存在瓶颈点，然后针对性调优。

• 如果某个资源已达瓶颈，则：

a.检查关键的操作系统参数和数据库参数是否合理设置，进行系统调优。

b.通过查询最耗时的SQL语句、跑不出来的SQL语句，找出耗资源的SQL，进行SQL调优。

• 如果所有资源均未达瓶颈，则表明性能仍有提升潜力。可以查询最耗时的SQL语句，或者跑不出来的SQL语句，进行针对性的SQL调优。
• 获取集群各节点的CPU、内存、I/O和网络资源使用情况，确认这些资源是否已被充分利用，是否存在瓶颈点。

硬件瓶颈点分析

获取集群各节点的CPU、内存、I/O和网络资源使用情况，确认这些资源是否已被充分利用，是否存在瓶颈点。

 

• CPU

通过top命令或Database Manager工具查看集群内各节点CPU使用情况，分析是否存在由于CPU负载过高导致的性能瓶颈。

• 查看CPU状况

查询服务器CPU的使用情况主要有以下两种方式：

• 在所有存储节点，逐一执行top命令，查看CPU占用情况。执行该命令后，按“1”键，可查看每个CPU核的使用率。

top - 17:05:04 up 32 days, 20:34,  5 users,  load average: 0.02, 0.02, 0.00
Tasks: 124 total,   1 running, 123 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.3%sy,  0.0%ni, 69.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.3%us,  0.3%sy,  0.0%ni, 69.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.3%us,  0.3%sy,  0.0%ni, 69.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.3%us,  0.3%sy,  0.0%ni, 69.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8038844k total,  7165272k used,   873572k free,   530444k buffers
Swap:  4192924k total,     4920k used,  4188004k free,  4742904k cached
 
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                       
 32893 omm  20   0 41416 1648 1196 S   10  0.0  23:46.14 om_monitor                                                                                                                                                                     
 34874 omm  20   0  169m 4104 1664 S   20  0.1  20:23.48 cm_agent                                                                                                                                                                       
 35184 omm  20   0  822m 421m 128m S    0  5.4   5:28.15 gaussdb                                                                                                                                                                        
     1 root      20   0 13592  820  784 S    0  0.0   1:16.62 init            

分析时，请主要关注进程占用的CPU利用率。

其中，统计信息中“us”表示用户空间占用CPU百分比，“sy”表示内核空间占用CPU百分比，“id”表示空闲CPU百分比。如果“id”低于10%，即表明CPU负载较高，可尝试通过降低本节点任务量等手段降低CPU负载。

• Database Manager工具支持对集群或者单个节点进行监控。

在“集群资源监控”页面上专门有对CPU使用情况监控的界面。

 

• 内存

通过top命令或Database Manager工具查看集群内各节点内存使用情况，分析是否存在由于内存占用率过高导致的性能瓶颈。

• 查看内存状况

查询服务器内存的使用情况主要有以下两种方式：

• 在所有存储节点，逐一使用root用户执行top命令，查看内存占用情况。执行该命令后，按“Shift+M”键，可按照内存大小排序。

top - 11:27:04 up 23 days,  1:15,  4 users,  load average: 1.43, 0.53, 0.56
Tasks: 437 total,   2 running, 435 sleeping,   0 stopped,   0 zombie
Cpu(s): 16.6%us,  2.2%sy,  0.0%ni, 80.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:     96717M total,    23777M used,    72940M free,       69M buffers 
Swap:    16394M total,        9M used,    16385M free,    18177M cached
 
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  1496 omm  20   0  9.9g 1.6g 1.3g S  177  1.7   0:49.57 gaussdb
  1490 omm  20   0  9.9g 1.6g 1.3g S  140  1.7   0:43.88 gaussdb
  1493 omm  20   0  9.9g 1.6g 1.3g S  123  1.7   0:42.77 gaussdb
  1499 omm  20   0  9.9g 1.6g 1.3g S  120  1.7   0:42.77 gaussdb
  2111 omm  20   0 9917m 1.5g 1.3g S    0  1.6   0:01.95 gaussdb
  2115 omm  20   0 9917m 1.5g 1.3g S    0  1.6   0:01.91 gaussdb
  2123 omm  20   0 9917m 1.5g 1.3g S    0  1.6   0:01.91 gaussdb
  2119 omm  20   0 9917m 1.5g 1.3g S    0  1.6   0:01.91 gaussdb
  1508 omm  20   0 1527m 1.3g 1.0g S    0  1.4   0:02.36 gaussdb
  1502 omm  20   0 1527m 1.3g 1.0g S    0  1.4   0:02.12 gaussdb
  1505 omm  20   0 1527m 1.3g 1.0g S    0  1.4   0:02.29 gaussdb
  1511 omm  20   0 1527m 1.3g 1.0g S    0  1.4   0:02.23 gaussdb
  1487 omm  20   0 2499m 1.3g 1.1g S    0  1.4   0:01.95 gaussdb

分析时，请主要关注每个进程占用的内存百分比（%MEM）、整系统的剩余内存。

显示信息中的主要属性解释如下：

−total：物理内存总量。

−used：已使用的物理内存总量。

−free：空闲内存总量。

−buffers：进程使用的虚拟内存总量。

−%MEM：进程占用的内存百分比。

−VIRT：进程使用的虚拟内存总量，VIRT=SWAP+RES。

−SWAP：进程使用的虚拟内存中已被换出到交换分区的量。

−RES：进程使用的虚拟内存中未被换出的量。

−SHR：共享内存大小。

• Database Manager工具支持对集群或者单个节点进行监控。

在“集群资源监控”页面上专门有对内存使用情况监控的界面。

 

 

• I/O

通过iostat、pidstat命令或Database Manager、集群健康检查工具查看集群内各节点I/O繁忙度和吞吐量，分析是否存在由于I/O导致的性能瓶颈。

查看I/O状况

查询服务器I/O的方法主要有以下四种方式：

l ●使用iostat命令查看I/O情况。此命令主要关注单个硬盘的I/O使用率和每秒读取、写入的数量。

iostat -xm 1  //1为间隔时间
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.01   519.62    2.35   44.10     0.31     2.17   109.66     0.68   14.62    2.80   15.25   0.31   1.42
sdb               0.01   515.95    5.84   44.78     0.89     2.16   123.51     0.72   14.19    1.55   15.84   0.31   1.55
sdd               0.02   519.93    2.36   43.91     0.32     2.17   110.16     0.65   14.12    2.58   14.74   0.30   1.38
sde               0.02   520.26    2.34   45.17     0.31     2.18   107.46     0.80   16.86    2.92   17.58   0.34   1.63
sda              12.07    15.72    3.97    5.01     0.07     0.08    34.11     0.28   30.64   10.11   46.92   0.98   0.88

“rMB/s”为每秒读取的MB数，“wMB/s”为每秒写入的MB数，“%util”为硬盘使用率。

• 使用pidstat命令查看I/O情况。此命令主要关注单个进程每秒读取、写入的数量。

pidstat -d 1 10  //1为间隔时间，10表示查看占用I/O最多的Top10进程
03:17:12 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
03:17:13 PM  1006     36134      0.00  59436.00      0.00  gaussdb
03:17:13 PM  1006     36137      0.00  73528.00      0.00  gaussdb
03:17:13 PM  1006     36140      4.00  39000.00      0.00  gaussdb
03:17:13 PM  1006     36143      0.00  57972.00      0.00  gaussdb
03:17:13 PM  1006     36743      0.00  54660.00      0.00  gaussdb
03:17:13 PM  1006     36747      0.00  66116.00      0.00  gaussdb
03:17:13 PM  1006     36751      0.00  61260.00      0.00  gaussdb
03:17:13 PM  1006     36755      0.00  69372.00      0.00  gaussdb

“kB_rd/s”为每秒读取的kB数，“kB_wr/s”为每秒写入的kB数。

• 使用gs_checkperf工具对集群进行性能检查，需要以omm用户登录，并执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。

gs_checkperf
Cluster statistics information:
    Host CPU busy time ratio                     :    .69        %
    MPPDB CPU time % in busy time                :    .35        %
    Shared Buffer Hit ratio                      :    99.92      %
    In-memory sort ratio                         :    100.00     %
    Physical Reads                               :    8581
    Physical Writes                              :    2603
    DB size                                      :    281        MB
    Total Physical writes                        :    1944
    Active SQL count                             :    3
    Session count                                :    11

显示结果包括每个节点的I/O使用情况，文件读写次数和时间。

也可以使用gs_checkperf --detail命令查询每个节点的详细性能信息。

• Database Manager工具支持对集群或者单个节点进行监控。

在“集群资源监控”页面上专门有对I/O情况监控的界面。

 

网络

通过sar、ifconfig命令或Database Manager工具查看集群内各节点网络使用情况，分析是否存在由于网络导致的性能瓶颈。

• 查看网络状况

查询服务器网络状况的方法主要有以下三种方式：

l ●使用root用户身份登录服务器，执行如下命令查看服务器网络连接。

SIA1000056771:~ # ifconfig 
eth0      Link encap:Ethernet  HWaddr 28:6E:D4:86:7D:D5   
          inet addr:10.180.123.163  Bcast:10.180.123.255  Mask:255.255.254.0
          inet6 addr: fe80::2a6e:d4ff:fe86:7dd5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5669314 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4955927 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000  
          RX bytes:508077795 (484.5 Mb)  TX bytes:818004366 (780.1 Mb)
 
lo        Link encap:Local Loopback   
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:711938 errors:0 dropped:0 overruns:0 frame:0
          TX packets:711938 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0  
          RX bytes:164158862 (156.5 Mb)  TX bytes:164158862 (156.5 Mb)

−“errors”表示收包错误的总数量。

−“dropped”表示数据包已经进入了Ring Buffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃的总数量。

−“overruns”表示Ring Buffer队列中被丢弃的报文数目，由于Ring Buffer(aka Driver Queue)传输的IO大于kernel能够处理的IO导致。

分析时，如果发现上述三个值持续增长，则表示网络负载过大或者存在网卡、内存等硬件故障。

• 使用sar命令查看服务器网络连接。

sar -n DEV 1  //1为间隔时间
Average: IFACE  rxpck/s  txpck/s    rxkB/s    txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average:    lo  1926.94  1926.94  25573.92  25573.92    0.00    0.00     0.00    0.00
Average:  A1-0     0.00     0.00      0.00      0.00    0.00    0.00     0.00    0.00
Average:  A1-1     0.00     0.00      0.00      0.00    0.00    0.00     0.00    0.00
Average:  NIC0     5.17     1.48      0.44      0.92    0.00    0.00     0.00    0.00
Average:  NIC1     0.00     0.00      0.00      0.00    0.00    0.00     0.00    0.00
Average:  A0-0  8173.06 92420.66  97102.22 133305.09    0.00    0.00     0.00    0.00
Average:  A0-1 11431.37  9373.06 156950.45    494.40    0.00    0.00     0.00    0.00
Average:  B3-0     0.00     0.00      0.00      0.00    0.00    0.00     0.00    0.00
Average:  B3-1     0.00     0.00      0.00      0.00    0.00    0.00     0.00    0.00

“rxkB/s”为每秒接收的kB数，“txkB/s”为每秒发送的kB数。

分析时，请主要关注每个网卡的传输量和是否达到传输上限。

检查完后，按“Ctrl+Z”键退出查看。

• Database Manager工具支持对集群或者单个节点进行监控。

在“集群资源监控”页面上专门有对网络状况监控的界面。

 

备份与恢复

Roach工具主要分为两部分：

• 单集群备份恢复工具GaussRocah.py
• 双集群容灾工具SyncDataToStby.py

 

GaussRoach.py

序号	功能
1	物理备份恢复整个集群（全量备份，增量备份）
2	逻辑备份恢复单表（全量备份）
3	逻辑备份恢复多表（全量备份）
4	备份数据到本地DISK，远端DISK，NBU,OBS,EISOO
5	恢复到新集群
6	显示备份集
7	删除备份集
8	校验备份集
9	终止备份操作
10	生成集群配置拓扑

 

单集群备份

全量备份

Roach的集群级备份采用的是物理备份，即通过物理文件拷贝的方式对数据库进行备份，通过备份的数据文件及日志等文件，数据库可以进行完全恢复。全量备份则是将当前时间点数据库中所有的数据进行备份。

 

优点：物理备份速度快，通过合理规划，可以低成本进行备份和恢复。

缺点：相较于增量备份备份时间较长。

 

存储形式：

备份的数据会进行压缩后写入到rch文件后存储到备份路径下的实例文件夹下，且每个rch文件大小是4GB

 

备份命令的特殊参数对备份的影响：

• --parrallel-process：

Roach支持多并发备份，可提高备份效率。

• --compression-level：

Roach在备份的时候会对备份进行压缩，其中可设置压缩级别，0代表快速或无压缩，9代表慢速或最大压缩。

• --compression-type：

Roach对备份的压缩分为两类，可采用zilb以及lz4算法。

增量备份

Roach支持增量备份的类型分为累积增量备份和差分增量备份。

 

累计增量备份：

每次的增量备份都是基于同一个全量备份。备份的内容为全量备份与当前时刻的数据修改。

 

 

差分增量备份：

每次的增量备份都是基于上一次的备份（全量或者增量）。备份的内容为两次备份之间的数据修改。

 

 

 

 

单集群恢复

全量恢复

当灾难发生时可根据之前的备份进行恢复，将数据恢复到某个时间点，从而降低损失。

 

流程：

• 将各个实例下的文件进行clean
• 备份的文件解压到相应的实例路径下
• Srart各个实例，并replay xlog日志，集群恢复成功，集群状态为Normal

 

增量恢复

流程：

• 将各个实例下的文件进行clean
• 查找整个增量依赖的备份，直至找到一个全量备份，这样就会产生一个备份链，Full backup -> inc backup1 -> inc backup2 ->inc backup3（当前的增量备份）
• 依次恢复这些备份
• Start各个实例，并replay xlog日志，集群恢复成功，集群状态为Normal

 

表级备份

Roach除了支持集群级备份，同样也支持表级备份，不同的时两者的备份方式并不一样，从前面的内容可以知道集群级备份为物理备份，而表级备份则采用的是逻辑备份。

 

逻辑备份的定义：

逻辑备份是数据库对象级备份，备份的内容是表、索引、存储过程等数据库对象，而物理备份则是数据库文件级备份，备份内容是数据库中的文件。

 

单表和多表的使用：

表级备份可以备份单表，也可以备份多表。

• 单表：在备份命令中添加--tablename参数，值为需要备份的表名；
• 多表：在备份命令中需要添加--table -list 参数，值为需要备份的表清单文件。

 

表级备份的原理：

将需要备份的表查询出来导入到一个外表中，压缩存储到备份集路径下。

 

 

表级恢复

原理

恢复的流程与备份的流程相反，表级恢复是将备份集中的外表再insert到之前备份的表中。

 

单表和多表的使用：

与表备份相对应，表级恢复也分为单表恢复与多表恢复。

• 单表：在恢复命令中添加--tablename参数，值为需要恢复的表名；
• 多表：在恢复命令中需要添加--table -list 参数，值为需要恢复的表清单文件。

 

备份恢复限制

• 备份和恢复过程中的集群和节点配置以及版本号必须相同。
• 仅支持数据库管理员用户执行Roach命令。
• 备份到本地磁盘时，必须要保证存储备份集的分区有足够大的存储空间。
• 除集群级别外，其他备份类型不支持备份系统表。
• 备份操作需要在集群状态为Normal时才可以进行。
• 同一用户在一个集群上，同一时间只能进行一次备份操作。
• 本地备份时，media destination 和 meta destination命令行参数请勿设置到集群安装目录下，避免卸载集群后备份内容丢失。
• 增量备份和前一次全量备份（或增量备份）时，集群内DN实例的主、备关系必须保持一致。

断点续备份

备份中途失败不需要从头备份，可以从上次失败的地方开始备份，节约时间，提高用户备份效率。

 

断点续备份的思想：

断点续备份需要一个状态文件来记录上次备份失败备份到哪个阶段，这样再次续做的时候就可以获取其阶段，继续往下进行。

其他功能特性

停止备份

命令： python GaussRoach.py -t stop

 

使用场景：

• 想停止当前正在运行的备份，则需要在另一个窗口执行此命令来结束备份进程。
• 在做断点续做的时候不想再基于此前的备份做续备份，需要再加上--resume-backup，--metadata -destination，--media-destination。

 

删除备份

命令：

Python GaussRoach.py -t delete --media-type <media_type> --media-destination <media_destination_path> | <policy_name> --master-port <master_port> --metadata-destination <metadata_path> --backup-key <backup_key>

显示目录信息（显示出当前备份目录下存在的备份集的详细信息）

命令：

Python GaussRoach.py -t show -all-backups --metadata-destination <metadata_path>

验证备份（验证备份文件、识别损坏的文件）

命令：

Python GaussRoach.py -t validate --master-port <master-port> --media-type <media_type> --media-destination <media_destination_path>

--backup-key <backup_key> --validation-type <validation_type> --metadata-destination <metadata_path>

Roach双集群容灾部署

 

基于Roach备份恢复工具，在两套集群之间实现周期性的同步机制。该同步机制，自由灵活，两套集群之间，可分可合，无相互影响。可以实现小时级别的RTO和RPO，并且在非恢复期间，备集群是一个热备的状态，可以提供只读服务。

如图所示，AZ1与AZ2分别为主备集群，通过roach工具定时将主集群的数据同步到备集群，防止主集群出现数据丢失备集群能够正常对客户提供服务，达到容灾的目的。

基本原理

 

主集群：在每个备份周期内，执行全量/增量备份，并将备份数据发送到备集群上，再等待下个备份周期。主集群备份内容包括行存文件、日志文件、列存文件，周期性的执行全量备份与增量备份。

备集群：在每个恢复周期内，执行已经备份数据的恢复，在恢复期间，无法提供服务。等本轮恢复完以后，可以提供只读服务。再等待下个恢复周期。

 

SyncDataToStby.py

序号	功能	描述
1	主集群周期性备份	周期性进行全量/增量备份并将备份数据同步给备集群
2	备集群周期性恢复与备份生命周期管理	对主集群同步的数据周期性进行恢复，清除超过生命周期的备份文件
3	显示主备集群同步进度	显示主备集群同步数据的进度情况
4	显示当前集群角色	执行备份或恢复命令时需要明确是再主集群或备集群
5	停止周期性备份/恢复	停止主集群备份同步/备集群恢复同步
6	主备集群角色切换	原来的备集群升为主集群，原来的主集群降为备集群
7	解除主备集群关系	在集群升级或者扩容时，需要先接触两个集群的主备关系
8	解除备集群只读限制	备集群发生故障时，对备集群修复前需要解除只读限制
9	备集群提供读写业务	不需要双集群框架时，设置备集群为单独可提供正常读写的集群

GaussDB(DWS)数据库对象设计

GaussDB(DWS)数据库整体设计

分类		建议
对象命名规范	命名规范	数据库对象命名要规范，做到望文知义；避免使用关键字
对象设计原则	DB设计	字符集选择（SQL-ASCII、UTF-8、G8K）、兼容模式选择（Oracle、TD）
	USER设计	对于业务要新创建普通用户，而不要使用超级用户；业务之间创建不同用户
	SCHEMA设计	通过SCHEMA进行同一用户下的不同表的隔离
	TABLESPACE设计	不建议创建tablespace，使用默认即可；如果需要控制用户使用空间，建议使用多租户
	表设计-字段类型	遵循字段最小/短原则、字段高效原则
	表设计-存储模式	根据场景选择行存和列存
	表设计-数据分布	根据场景选择复制表和hash表、对于hash表要选择合适的分布列
	表设计-数据分区	对于大表要设计合适的分区
	索引设计	索引类型包括btree、psort、gin；在过滤效果明显的列上建立索引；索引不宜创建过多
	约束设计	合适的约束也可以提升查询性能（not null、partial cluster key等）
	Sequence设计	不建议使用sequence，如果使用建议cache方式
SQL编写建议	DDL语句	合理使用truncate、analyze、vacuum full等
	数据加载语句	避免单条入库；用copymanager、GDS、SQL on Hadoop/OBS等实现批量导入
	查询语句	使用性能更优的sql语句

对象命名规范

数据库命名格式：db_[含义]

用户命名格式：u_[应用名]_[角色]

SCHEMA命名格式：s_[应用名]_[含义]

表命名格式：t_[应用名]_[含义]

视图命名格式：v_[应用名]_[可扩展字段]

索引命名格式：idx_[表名]_[字段名1]_[字段名2]

序列命名格式：seq_[应用名]_[含义]

函数命名格式：func_[应用名]_[函数名]

存储过程命名格式：pro_[应用名]_[存储过程名]

GDS外表命名格式：foreign_[应用名]_[含义]

临时表命名格式：tmp_[应用名]_[含义]

无日志表命名格式：unlog_[应用名]_[含义]

对象设计原则

DB设计

GaussDB DWS可以使用Database、User、Schema实现业务的隔离，区别在于Database的隔离更加彻底，各个Database之间共享资源极少，可实现连接隔离、权限隔离等，Database之间无法直接互访。User、Schema隔离的方式公用资源较多，可以通过grant与revoke语法便携地控制User、Schema对象的权限。

 

【建议】建议系统管理员创建Database和User，普通童虎创建自有Schema，再赋予其他用户对应的权限。

【强制】在实际业务中，根据需要创建新的Database，不要直接使用默认postgres数据库。

【建议】为了适应全球化的需求，使数据库编码能够存储与表示绝大多数的字符，建议创建Database的时候使用UTF-8编码。数据库默认是SQL-ASCII字符集的。

【关注】创建Database时，需要重点关注数据库兼容性（dbcompatibility）

GaussDB DWS支持Teradata和Oracle两种兼容模式，分别兼容Teradata语法和Oracle语法，不同兼容模式下的语法行为可能有一些差异。dbcompatibility默认时ORA，兼容Oracle语法。

【关注】Database的owner默认拥有该Database下所有对象的所有权限，包括和三处权限。删除权限影响较大，请谨慎使用。

【建议】一个集群内，用户自定义的Database数量建议不超过3个。

 

User/Schema/Tablespace设计

【强制】在实际业务中，根据需要创建新的User，不要直接使用超级管理员omn。

【推荐】不同的业务系统，可以创建不同的用户，以进行对象权限隔离。

 

【关注】如果该用户不具有sysadmin权限或者不是该schema的owner，要访问schema下的对象，需要同时给用户赋予schema的usage权限和对象的相应权限。

【关注】如果要在schema下创建对象，需要赋予操作用户该schema的create权限。

【关注】schema的owner默认拥有该schema下对象的所有权限，包括删除权限。删除权限影响较大，请谨慎使用。

 

【建议】建表时，建议不要显式建tablespace，会使用默认的tablespace；如果先使用tablespace进行容量控制，从多租户端来设置。

【关注】如果实在需要建tablespace，关注时需要建相对路径表空间还是绝对路径表空间；

绝对路径表空间会导致一个数据节点上多个DN的数据存储到一个路径下，很容易磁盘满。

表设计

 

 

字段类型

【强制】字段高效原则：选择最高效得类型存储数据，这可以提高数据库得有效容量及查询执行性能。如能用整型就用整型而不用浮点型、字符型。

【建议】字段最小原则：使用满足需求得最小数值类型。如果int或smallint够用，那么选择bigint会浪费空间。

【建议】字段最短原则：建议使用边长字符串数据类型，并指定最大长度。

请务必确保指定的最大长度大于需要存储的最大字符数，避免超出最大长度时出现字符截断现象。

除非明确知道数据类型为固定长度字符串，否则，不建议使用char(n)、bpchar(n)、character(n)。

Char(n)表示定长n个字符，不足补空格；varchar(n)表示边长n个字节；nvarchar2(n)表示变长n个字符。

【建议】当多个表存在逻辑关系时，表示同一含义的字段应该使用相同的数据类型。

 

存储模式

列存适合的场景	统计分析类查询（group、join多的场景）
	即席查询（查询条件列不确定，行存无法确定索引）
	追求高压缩比
行存适合的场景	点查询（返回记录少，基于索引的简单查询），如按照电话号码查通信记录
	增删改比较多的场景。

 

数据分布

分布方式	描述	适用场景
Hash	表数据通过Hash方式散列到集群的所有DataNode上	数据量较大的事实表
Replication	集群中每一个DataNode都有一份全量表数据。	维度表、数据量较小的事实表。

 

分布列

【强制】显式指定分布列原则：为所有表要明确地指明其分布字段，而不要使用默认方式。

【强制】数据均匀分布原则1：理想情况下，使用能够将数据均匀分布到所有DN实例上的一个字段做分布键。例如：身份证。

【建议】数据均匀分布原则2：如果单个字段不能实现数据均匀分布，则考虑使用两个字段做分布键。作为分布键的字段最好不要超过两个。

使用更多的字段做分布列，会耗费更多的时间计算哈希值。

【建议】本地操作原则：在保证均匀分布的情况下，选择join列、group by 列做分布列，可以减少计算过程中数据重分布。

Join任务的相关数据都分布在DN本地，将极大减少DN之间的数据流动代价。

【建议】不要使用日期或者时间字段做分布键。

【建议】中间过程表、临时表、Unlogged表的分布列应尽可能和源表保持一致。

【建议】确定hash表的分布策略之后，需要对表数据进行倾斜性检查，以确保数据的均匀分布。

 

数据分区

【强制】只为大表设置分区，不要为小表设置分区。

【强制】在根据查询条件可以实现分区剪枝时对大表使用分区。

【建议】如果对数据有生命周期管理，需要使用分区。

【建议】对于列存储的表，慎用过多的分区，建议在一千以内。

【建议】使用具有明显区间性的字段进行分区，比如日期字段上建立分区。

【建议】分区名称应当体现分区的数据特征。

【建议】将分区上边界的分区值定义为MAXVALUE，以防止可能出现的数据溢出。

【建议】分区范围是上开下闭，所以p_gcxx_20180101 values less than (‘2018-01-02’)

 

索引设计

索引类型	描述
Btree	使用一种类型于B+树的结构来存储数据的键值，通过这种结构能够快速的查找索引
Gin	倒排索引
Psort	针对列存表进行局部排序索引

【强制】在经常执行精确查询的字段上建立索引，比如身份证、车牌号码、账号等

【建议】索引不适合创建过多，控制在几个以内，过多会消耗大量存储空间，影响数据入库性能。

【建议】在连接条件上创建索引，对于存在多字段连接的查询，建议在这些字段上建立组合索引。

【建议】where子句的过滤条件字段上（尤其是范围条件）可以创建索引。

【建议】在经常出现在order by limit xx 的列可以创建索引。

【建议】创建选择度高的索引。

比如常驻人口表，对于性别列只有男女选择度就很低，对于身份证选择度就很高。

【建议】经常被更新的字段不易建立索引。

【建议】仅当表达式常在查询中使用时才建立基于表达式的索引。

【建议】避免重复索引。具有相同前缀字段的索引时冗余的。

【建议】如果创建索引后查询性能没有显著地提升，则删除该索引。

【建议】索引会影响数据加载速度，加载数据前可以设置索引失效，加载完成后重建索引。

 

约束设计

【建议】如果能够从业务层面不全字段值，那么不建议使用DEFAULT约束。

【建议】给明确不存在NULL值的字段加上NOT NULL约束，优化器会在特定场景下对其进行自动优化。

【建议】给可以显式命名的约束显式命名。除了NOT NULL和DEFAULT约束外，其他都可以显式命名。

【关注】行存表支持唯一约束，而列存不支持

【关注】行存表支持主键约束，而列存不支持

 

Sequence设计

【建议】不建议在GaussDB DWS中使用sequence

【建议】如果只是想获取一个唯一标识，建议使用UUID，而不是使用sequence

【建议】如果必须使用，如果没有严格递增的需求，要设置CACHE。

GaussDB(DWS)补丁、升级及扩容

安装补丁

时间窗评估

安装方式：仅支持离线方式安装

时间评估：仅GaussDB（DWS）集群补丁安装大约需要4小时（不包含补丁安装过程中出现的硬件或软件古装处理时间，一次硬件故障按照8小时评估，一次软件故障按照4小时评估）

流程

 

安装前巡检

• 在support网站下载巡检工具FusionInsight Tool Prober的最新版本

巡检工具使用方法请参考对应版本的巡检指导书

• 在FusionCare创建补丁前巡检任务
• 分析升级前检查结果并修复不满足升级条件的NG项

NG项修复方法参考巡检指导书

• 修复完NG项后再巡检，无NG项即集群满足升级条件
• 从安装SysChecker的OMS节点拷贝出巡检报告

升级前确认业务是否已停止

• 注释掉所有CN pg_hba.conf文件配置的白名单
  • 分别备份各个CN上conf文件

Cp pg_hba.conf pg_hba.conf_20200221

• 注释掉conf文件配置的白名单

• 通过检查CN上视图pxxc_stat_activity确认，是否还有业务SQL

过程日志

补丁安装日志目录 /var/log/Bigdata/patch/

OMS补丁安装日志：oms_installPatch.log

Agent补丁安装日志：agent_installPatch.log

MPPDB补丁安装日志：MPPDB_MPPDBServer_installPatch.log

集群升级

时间窗评估

安装方式：仅支持离线方式安装

时间评估：仅GaussDB（DWS）集群补丁安装大约需要8小时（不包含补丁安装过程中出现的硬件或软件古装处理时间，一次硬件故障按照8小时评估，一次软件故障按照4小时评估）

流程

 

升级前巡检

1、在support网站下载巡检工具FusionInsight Tool Prober的最新版本

巡检工具使用方法请参考对应版本的巡检指导书

2、在FusionCare创建升级前巡检任务

3、分析升级前检查结果并修复不满足升级条件的NG项

NG项修复方法参考巡检指导书

4、修复完NG项后再巡检，无NG项即集群满足升级条件

5、从安装SysChecker的OMS节点拷贝出巡检报告

升级前确认业务是否已停止

1、注释掉所有CN pg_hba.conf文件配置的白名单

• 分别备份各个CN上conf文件

Cp pg_hba.conf pg_hba.conf_20200221

• 注释掉conf文件配置的白名单

2、通过检查CN上视图pxxc_stat_activity确认，是否还有业务SQL

日志清单

 

集群扩容

流程

 

扩容前巡检、信息收集及时间评估

• 使用syschecker进行扩容前信息收集、巡检及巡检不合格项修复
  • 进行信息收集，命令：

./gs_check -i CheckCollector

• 进行扩容前检查，命令：

./gs_check -e expand -U omn -l ./check.log

• 进行扩容前需要数据倾斜检查

./gs_check -i CheckTableSkew -l ./check.log

 

• 时间评估

安装方式：仅支持离线方式安装

时间评估：

• 实例添加时间评估：

仅GaussDB（DWS）集群补丁安装大约需要4小时（不包含补丁安装过程中出现的硬件或软件古装处理时间，一次硬件故障按照8小时评估，一次软件故障按照4小时评估）

• 数据重分布时间评估：

 

扩容前准备

• 根据LLD生成扩容模板
• 对新节点执行preinstall
• 对新老节点巡检

扩容操作

• 关闭所有定时任务
• 添加新节点到集群
  • 模板添加新节点
  • 手动添加节点
• 添加组件实例
• 开始所有定时任务
• 进行数据重分布
• 重分布进度查新

扩容过程日志

• 登录报错的新扩容节点，查看日志：

/var/log/Bigdata/mpp/scriptlog/postinstall.log

• 如果是扩容加节点失败，则使用Omn用户登录第一个老节点，进入/var/log/Bigdata/mpp/scriptlog/目录下，查看gs_postinstall_*.log扩容日志文件，根据日志内容判断扩容失败原因。
• 如果是重分布失败，登录集群第一个CN节点，查看$GAUSSLOG/bin/gs_redis/目录下的日志文件