1. 硬件、系统、集群配置层面优化

工欲善其事必先利其器，GBase 8a 作为GBase南大通用的一款优秀的MPP 分析类的数据库软件，部署环境依赖硬件及操作系统，所以提前规划部署策略，提前介入优化考虑。

1. 1. RAID卡配置

Raid设置：依照顺序raid10 > raid50 >raid5

read策略：read ahead

wirte策略：write back

IO策略：enabled

strip size： 设置为1M（一般为128K、256k、512k、1M）

【注】写策略默认为write through，即透写，该方式无法利用raid卡缓存，写性能较低。如果设置always write back with BBU 则为强制回写，如果电池异常可能丢数据；条带块大小可参考百度信息，主要影响磁盘定位速度以及提取速度。考虑到数据库列存情况，建议设置为最大

• 1. BIOS——CPU设置
• CPU超线程：

建议开启。如果CPU整体资源使用不高，出现单CPU使用高情况较多，可关闭超线程提升单个CPU核处理能力。若CPU整体使用较高，各核吃满情况较少建议开启超线程。

• CPU高性能模式：

模式分为省电模式、均衡模式、高性能模式。建议设置为performance模式。

CentOS6修改：

echo “performance” > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

CentOS7修改：cpupower frequency-set -g performance 。

可加入开机启动项中。

1. 1. 系统层面磁盘设置

磁盘策略建议设置为deadline。目前集群安装会默认设置。手动设置方式参考如下:

echo deadline > /sys/block/sda/queue/scheduler

红色部分替换为数据盘盘符，将上面内容可添加到 /etc/rc.d/rc.local 实现开机自动设置，该文件需要赋予可执行权限 chmod +x。

1. 1. 系统优化

注意CentOS7 系列系统做如下修改，修改后重启。

1. 1. 开启numa

numa原理可参考：

NUMA_百度百科

单实例部署，可仅开启numa不做绑定；多实例部署需要考虑numa绑定。绑定操作较多，这里不做讲解。

1. 1. 部署规划——实例

部署需要考虑CPU线程数、内存、磁盘位置。 需要综合考虑这3类资源的配比。GBase 8a在部署多实例时，考虑的主要因素是：资源可覆盖以下要求。

实例个数考虑：1、2、4 。多实例在一定程度上能够提升性能。但一般不做过多实例。且实例个数一般与numa个数呈现等比关系。

CPU：低于40核使用1实例，40~80核使用2实例，超过80可考虑4实例。

内存：建议一个实例最好能够分到128GB（推荐256GB）

1. 1. 集群配置常见参数

手册中有详细介绍，可参考手册查看heap、buffer相关章节。

1. 表设计优化

表设计合理，能规避大部分性能问题。下面按照顺序分别说明，不光是对南大GBase 8a产品，通用适用于其他MPPDB。

• 1. 表分布
• Hash分布表

目标对象：数据量大的事实表，即需要数据打散到各节点存储。

分布列选取遵循：数据分布均匀、常用于group 、join的字段，不会被update的字段。

一般来说，分布列无法兼顾所有场景，需要结合数据量、SQL频率、性能要求来保证重要场景，牺牲其他场景。一般不建议选取2个列及以上作为分布列，此举仅能保证数据分布均匀，实际运算依然可能数据重分布。

• 随机分布表

目标对象：无，数据也可以随机打散到各节点

不指定分布列的基础上，默认创建的表即为随机分布表。一般来说不建议创建随机分布表。虽然数据是均匀的，但计算一般来说需要数据重分布，会有性能影响。

• 复制表

目标对象：数据量小的表，常见维表。数据需要在各节点存储一份。

主要为了join时候可以从本节点直接获取数据，当 join时不需要数据重分布。

一般来说复制表也可以创建为分布表，数据量小的情况下重分布速度很快。主要考虑对执行计划的影响、使用的频繁度问题。依照磁盘性能评估，扫描全表耗时符合要求的都可以创建为复制表，条数从几条~几百万不等。亦可按照条数直接划分，如低于50万。

• 小表是否可创建为hash分布

首先小表是可以创建为随机分布表也可以创建为hash分布表。一般来说建议创建为复制表。

当小表，经常以某个字段作为关联使用，且这个字段重复率较低，数据量低于几十万，是可以创建为hash分布表，也可以创建为随机分布表。但需要考虑高并发情况，当高并发时，分布表彼此在数据库内部链接、数据传输较多，则复制表性能会更好一些。

• 1. 使用
• 索引

索引的主要目的是定位数据位置，加快数据从磁盘提取。同样索引也有自身的一些缺点，比如：空间占用问题。

由于GBase 8a自带了粗粒度智能索引 smart index（不需要人工维护），能够满足绝大部分场景的数据过滤问题，所以一般不需要创建。自行过滤数据。可参考其他数据库产品表。在精确查询场景中，可考虑创建索引。

• 分区

首先GBase 8a支持常见的几类分区方式，但一般来说不建议创建，使用时可以综合考虑是否使用。

分区设计最初是想解决传统数据库在存储大量数据后对数据的快速扫描问题。由于mpp类产品自身已经是分布式存储，常用hash算法来进行数据分布策略，所以已经解决了绝大部分问题。

为何不建议使用分区？我们常见的是range，存储的数据一般是按照时间入库的，即有一定的顺序。GBase 8a产品（非 8c 或 8d产品）自身具有smart index能力。能够在使用时自动过滤数据块，0.1s以内可识别要扫描的数据块。如果创建分区，当然也可以。但是需要考虑分区所带来的工作量：比如分区的维护，进行ddl操作时集群的压力（分区表的ddl操作压力是普通表的倍数关系，参考分区数量）。

1. SQL优化篇
   1. SQL编写/改写

GBase南大通用的 8a产品在结构化数据分析的性能还是非常快的。但再完美的产品也不可能覆盖所有的场景。这是市面上所有MPPDB产品都会遇到的问题。都可能出现在这个场景好，在另一个场景表现会较差。性能差异的导致情况比较复杂，主要与计算引擎、执行计划有较大关系。

以下总结了几类常见的性能不好，需要人工改写的SQL类型。

• 多次计算改为1次计算
  where id +1 >100 改为 where id > 100 -1

where to_char (sj, 'YYYYMMDD')=’20110531’ 改为where sj between ‘’ and ‘’

• 选取合适数据类型
  时间类型、数值类型做运算要比字符类型快，尽量用合适的类型，避免varchar存时间类型、数值类型参与到运算。
• 避免SQL中隐式转换
  如 insert into t (col varchar类型） select int类型
• 避免在SQL投影列、where条件中出现子查询

Select a,b,c (select ...) from t1 join t2 ...

Select ... from t1 ,t2 where (select ...)