GBase 8a最佳实践（一）性能调优

1.1  硬件配置建议

CPU

需注意 BIOS 中的设置是非省电模式，避免 CPU 自动降频运行。采 用 Intel   CPU   的 服 务 器 且 不 进 行 多 实 例 部 署 场 景 下 ， 建 议 关 闭 vm.zone_reclaim_mode 参数。设置 NUMA 参数关闭方法：

• A、修改当前系统值：echo 0 > /proc/sys/vm/zone_reclaim_mode 

• B、修改或新增到配置文件/etc/sysctl.conf   vm.zone_reclaim_mode = 0

在国产 CPU 芯片服务器上使用多实例方式部署时，需要进行 NUMA 节点与数据库 实例的绑定。绑定方法可参考《GBase 8a MPP Cluster V953 多实例最佳实践》。

内存

内存的使用方式需要配置 PCT  参数（gbase_memory_pct_target），该参数决定了 gbased 进程可以使用的内存占操作系统内存的比例，关闭 swap 后，可预留 20%给 其它程序使用。同时可以按需配置数据堆，算子堆和 TEMP 堆的大小。

SWAP

对于小内存服务器，SWAP 配置为物理内存的 2 倍。对于大内存服务器，可配置 SWAP 大小为 64GB~128GB。

网络

网络采用万兆网，需要提前测试各个节点间带宽。

硬盘

需根据硬盘块数以及 raid 方式计算磁盘 IO 并测试磁盘性能。对于多实例部署，如果磁盘块数足够，可以考虑各个实例使用不同的磁盘（目前需 要手动映射）。

1.2操作系统配置建议

1.2.1操作系统参数调整建议

GBase 8a 集群在安装时会对需要调整的操作系统参数进行自动调整，v8.6 版本在安 装时由 InstallTar.py 程序完成对操作系统参数的配置；v9.5 版本需要在安装前执行 SetSysEnv.py 程序完成操作系统参数的配置。如果修改或配置操作系统参数请联系Gbase工程师或参考。通常在 GBase 8a 集群运行期间，如遇到参数被修改可以参照产品手册进行调整。

在部分操作系统中（如 redhat6.7），修改打开文件数的配置，除修改 limits.conf 文 件外，还需要修改/etc/security/limits.d/90-nproc.conf 文件，需要手动在 90-nproc.conf 文件中增加如下内容：* soft  nproc 655360

1.2.2磁盘调度策略建议

数据库属于 I/O 密集型应用，建议 GBase 集群节点设置数据存储所在的磁盘 I/O 调 度策略如下：

• 机械磁盘的调度策略建议为 deadline。磁盘 I/O 调度策略修改方式：

 echo deadline > /sys/block/$数据所在的盘符/queue/scheduler

• 这种修改方法为修改当前系统配置，操作系统重启后需重新设置。 或者

修改/etc/default/grub 文件，找到 GRUB_CMDLINE_LINUX  这一行，在双引号 内加入 elevator=deadline transparent_hugepage=never，之后使用操作系统 root 用户执行 grub2-mkconfig -o /boot/grub2/grub.cfg。这种修改方法为永久性修改，修改 grub  启动参数，操作系统启动时全局生效。

 注：机械磁盘的调度策略 CentOS/Redhat 8.0 系列为mq_deadline。SSD 磁盘 I/O 调度策略为 Noop。

1.2.3cache 参数设置建议

建议设置操作系统趋向于回收 cache，避免 cache 满后进行内存分配性能差的问题：

• 修改方式 1：
  echo 1024 >/proc/sys/vm/vfs_cache_pressure   echo 8388608 >/proc/sys/vm/min_free_kbytes  

• 修改方式 2，编辑/etc/sysctl.conf 配置文件：
  vm.vfs_cache_pressure = 1024  vm.min_free_kbytes = 8388608
  /proc/sys/vm/min_free_kbytes  文件表示强制 Linux  VM  最低保 留多少空闲内存 （Kbytes），大小设置为物理内存的 1/12，如上述设置是在 96G 内存的服务器上设 置该参数取值为 8GB。

1.2.4透明页管理设置建议

GBase 数据库没有针对透明页管理进行优化，所以需要关闭透明页管理功能。使用 root 用户修改/sys/kernel/mm/transparent_hugepage/ enabled 配置文件，命令如下：
echo never > /sys/kernel/mm/transparent_hugepage/ enabled

1.2.5最大任务数限制建议

在 Redhat7 、Suse11 及之后的操作系统中，还需要修改/etc/systemd/system.conf 文件 中的 DefaultTasksMax 配置项，修改为 DefaultTasksMax=infinity。

1.2.6文件系统缓存设置建议

默认情况下， Linux 会最多使用40%的可用内存作为文件系统缓存。当超过这个阈 值后，文件系统会把缓存中的内容全部写入磁盘， 导致后续的 IO 请求都是同步。 如果文件系统将全部缓存中的内容写入磁盘，影响 IO 系统响应，导致越来越多的 请求堆积，最终系统内存全部被占用，导致系统失去响应。
故可以通过调优文件系统缓存参数，来缓解数据库执行 SQL  任务阻塞根据应用程 序情况：
对 vm.dirty_ratio，vm.dirty_background_ratio 两个参数进行调优设置，根据应用程序 情况，通过文件系统参数 vm.dirty_ratio，vm.dirty_background_ratio 进行调整。例如，

推荐如下设置：
# sysctl -wvm.dirty_ratio=10

# sysctl -wvm.dirty_background_ratio=5 

# sysctl -p

如果系统永久生效，需修改/etc/sysctl.conf文件。加入如下两行然后重启系统生效。

 #vi /etc/sysctl.conf

vm.dirty_background_ratio = 5 

vm.dirty_ratio = 10

1.3数据分布规划

GBase 8a MPP  集群性能取决于各个节点整体的性能，每个节点存储的数据量对于 集群性能有很大影响，为了尽可能达到最好的性能，所有的数据节点应该尽量存储 等量的数据，因此在数据库表规划定义阶段要考虑表是复制表还是分布表，以及对 分布表上的某一些列设置为分布列进行 hash 分布。
例如根据数据的分布特性设计，可以：

1. 将字典表或者维度表建成复制表的方式将数据存储到各个节点上，即不须对其数 据进行分片存储。因为字典表的数据量相对较小，虽然在各个节点进行存储有一定 的数据冗余，但和事实表的 JOIN  运算就可在本地进行，避免节点间搬动数据。

2. 对于事实表（大表）可将数据分布到不同的节点上存储，分布方法可采用随机分 布(目前很少用)，或者单列 hash 分布，或者多列 hash 分布的方法，SQL 执行的查 询条件满足只在其中部分节点时，查询优化可决定 SQL  的执行仅在这些节点执行 即可。

1.3.1分布列选取原则

• 优先考虑大表间的 JOIN，尽量让大表 JOIN 条件的列为 Hash 分布列（相关子 查询的相关 JOIN 也可以参考此原则），以使得大表间的 JOIN 可以直接下发到 各节点分布式执行。
• 其次考虑 GROUP BY，尽量让 GROUP BY 带有 Hash 分布列，让分组聚合一步 完成。
• 当有多个 join 或 group 列可选择时，优先选择唯一值多（count(distinct)值大） 的列做 Hash 分布列，让数据均匀分布。
• 通常是等值查询的列，并且使用的频率很高的应考虑建立为 hash 分布列。

1.3.2注意事项

• hash 分布列只能选择数值和字符串类型的列。
• 作为 hash 分布列的列不能进行update（包括快速 update 模式下的更新）。
• 尽量保持 hash join 的等值关联列在类型定义上完全相同。
  如：char 和varchar 类型进行关联，可能出现结果为空情况，原因是 char 型不 足最大长度时用空格补齐，varchar 则没有空格，如果关联则需要 trim 空格。
  又如：gbase 中 decimal 和 bigint 类型join 时需要进行类型转换导致无法走最优 的执行计划，可以将两表的 hash 分布列统一为相同类型bigint。

1.4数据排序优化

数据在按某查询列进行排序后，则相同数据取值会集中存放在有限的数据包中，因此在以该列进行过滤时，利用智能索引命中的数据包会很少，不仅能降低 IO 量而 且会提高压缩比。其最大好处是可以将智能索引的过滤效果发挥到最优，从而使整 体查询性能大幅提升。建议在实际应用场景许可的前提下，将数据按照查询常用条 件列进行排序。
如在电信行业中，通常按照手机号码进行查询，因此可按一定的时间间隔对数据按 照手机号码进行排序，则在此时间范围内的手机号码有序，在进行查询时，便可通 过智能索引特性提高查询性能。

1.5压缩策略选择

大部分应用中性能的瓶颈是磁盘 IO，所以新型数据库的设计都以降低磁盘 IO 为主 要设计目标。压缩可减少 I/O 的时间，提升性能，8a 也不例外。压缩是提高性能的 主要技术之一，8a 并行执行器已经能够从上层并行调度解压，因此使解压的适用性 得到了很大的提升，很多场景下（尤其是针对超大数据量的场景），使用压缩数据 的方式都可以获得比不压缩更好的性能。

1.5.1压缩方式

【86 版本】
gbase_compression_num_method=<num_method>
gbase_compression_str_method=<str_method>
表级压缩方式：COMPRESS(<num_method>,<str_method>)
列级 int 型压缩方式选项：0 ，1，5
列级 varchar 型压缩方式选项：0 ，3，5 表级组合压缩方式为：00、13 、55

【95 版本】
gbase_compress_method=< ’method ’> gbase_compress_level=<level>
表级压缩方式：COMPRESS(< ’method ’>,<level>)
method    指定压缩算法，不设置时 show variables  显示“NO Setting”。可设置的值如 下，值不区分大小写：
No zip：没有压缩  High z：高压缩比 Rapid z：快速压缩 New Rapid z：
STDZ：
level指定压缩级别，0~9，1 压缩比最低，压缩/解压缩速度最快，9 反之。不设置时 show variables  显示为 0。默认级别为 0 ，针对不同的原型算法有不同的选取。

【86 版本&95 版本】映射关系
95 版本的压缩算法向上兼容 86 版本使用方式，当 gbase_compression_num_method 和gbase_compression_str_method参 数 与gbase_compress_method 和 gbase_compress_level 同时存 在 时， 以  gbase_compress_method和 gbase_compress_level 参数配置为准。映射关系如下：

1.5.2选取原则

31 压缩优势是压缩比高，比 55 压缩高一倍压缩比，但是执行效率一般，如果对存 储空间要求高，对性能不太要求时，建议使用 31 压缩；如果对存储空间要求不高， 对性能要求高时，建议使用 55 压缩。

1.6Hash 索引的选择

Hash Index  通常可以用来提升等值查询的定位效率，特别是对以单表精确查询为主 的应用场景尤为适合。如电信业务中的并发话单查询等（特别是内存基本充足的场 景）。

8a 中的 hash 索引分为 Global Hash 和分段 Hash，两者主要的区别是一个列上创建 hash 索引的范围不同。

Global hash 索引是在整个列数据上创建一个索引，分段 hash  索引是将整个列数据 根据指定的 dc 数（key_DC_size）分为几段，每段上创建一个索引。分段 hash 索引 主要是便于空间回收。在磁盘空间不充裕的情况下推荐分段 hash 索引。 现场中， 使用 Global Hash Index 的场景较多。
分段 hash 索引语法举例如下：
CREATE INDEX idx  t  a ON t(a) key_DC_size = 1000 USING HASH GLOBAL;
建议：分段 hash 索引的 Dc 个数（key_DC_size）和一次查询扫描命中的 dc 个数相 当，通常为 400~2000。

8a 删除数据 sql 的实现是给被删除数据打删除标记，数据本身仍在磁盘中存在，8a 的 fast update 模式下update sql 实现是先删除原始数据行，插入新数据行。8a 对于 磁盘中有删除标记的数据提供了手动清除的 sql：shrink space 语句，即执行时将具 有删除标记的数据从磁盘彻底清除，释放磁盘空间，shrink space 的块级回收和行级 回收模式下会同时对索引文件进行回收，即当索引文件对应的 DC 全都被回收删除时将该索引文件也回收删除。这种批量从磁盘删除数据的模式在大数据分析型数据 库中，可以有效且大幅的提升数据库管理性能。
以 shrink space 的块级回收举例如下：alter tablet shrink space full block_reuse_ratio=30;

有效数据占比低于 30%的 DC 空间进行整合回收，将需要整合回收的 DC 中具有删 除标记的无效数据进行彻底清除，DC 整合后重新落盘写 seg 文件，无法保证原始 顺序。同时，如果有分段索引文件的数据段全部在需要整合的 DC 集内，则将该分 段索引也回收清除，并在整合后重建该分段索引以保证索引的有效性。

在使用上，GBase8a 一定是首先进行智能索引过滤的，之后，如果发现查询条件中 的等值查询条件列上建立了 Hash Index，则使用 Hash Index，否则进行全 DC 扫描。 这一点，可以在 Trace Log 中明显观察到。

对有实时数据加载的场景，可以根据实际情况设置一定时长的时间窗口，在时间窗 口内先建立无索引的临时表加载数据，积累到指定时长后再将临时表内数据插入到 带索引的同结构目标表中或在临时表上创建索引。一次性处理索引建立，可较大幅 度的降低索引带来的维护成本。

注意事项

• 索引是一种有损的优化手段，使用索引通常会带来维护的成本，会影响数据加载及DML操作的性能，实际使用时需根据具体需求而定 。

• 选择建立 hash 索引的列应尽量选择重复值较少的列，否则hash 冲突严重，影响hash 索引的性能

• 二进制类型的列不适合使用 HASH 索引

• 创建索引时，只能指定单列，不能指定多列创建联合索引

1.7Kafka Consumer 调优

1.7.1kafka 设计

以 Kafka consumer  进行增量数据的同步适用于数据源为数据库（oracle/mysql  等 OLTP 事务型数据库）的增量数据同步场景，相比于加载的方式，使用上更加方便。
Kafka consumer 从 kafka 里拉取消息，解析消息中描述的操作类型、表名称、主键 名称、列名称和数据，以中间结果的形式，暂存到本地队列；事务线程从本地队列 取出数据，进行合并、攒批后，以事务方式组织 dml 语句，发到 gnode 执行，最终 提交。
Kafka consumer 主要靠合并、攒批两种手段，实现性能的提升。合并是指在内存中 对冲 delete 和insert 两种操作，这是攒批的前提条件； 攒批是指一次提交尽可能多 的数据，发挥 Gbase8a 吞吐量大的优势。

1.7.2影响性能因素

影响 consumer 同步数据性能的因素很多，列举如下（按影响严重程度排序）：
1.源库对大表(超过几十亿行数据)频繁执行 delete 、update 操作。这种操作，即使经 过 consumer 合并攒批后，在 gnode 执行的时候，还是很慢。
2.表的数量多。如果上万张表都通过 consumer 方式同步数据，将严重降低 consumer 的攒批效果。
3.表的列数多。由于 8A 是列存数据库，列数与磁盘访问次数线性相关，性能则线性 下降。
4.并发的用户业务。在 consumer 同步数据时，用户业务对 Gbase8a 有很多的操作， 这些操作与 consumer 争抢资源。
具体可调整的参数敬请关注后续文章。