基于开发者空间部署OpenGauss完成AI智能索引和参数自调优实践

1 概述

1.1 案例介绍

从2015年,ORACLE公司提出让数据库自动化运维,即数据库中常见的问题,并且已经存在一套统一规范的处理解决方案的场景,应该让数据库在监控检测到此类问题,自动处理解决该问题,以减少运维工作人员人力的参与(因为Oracle的运维人力相对昂贵)。现如今,人工智能的高速发展,在行业各个领域辅助人们的决策和高效工作,故数据库研发人员也想把AI能力融入数据库中,让其自学习数据库常见故障的运维解决方案,并使数据库自我修复。

通过实际操作,让大家深入了解如何利用 OpenGaussDB开发并优化项目中业务应用的SQL语句等功能。在这个过程中,大家将学习到从AI函数的引用、AI功能的原理以及分析AI能力等一系列关键步骤,从而掌握 OpenGaussDB-AI的基本使用方法,体验其在应用开发中的优势。

1.2 适用对象

  • 企业
  • 个人开发者
  • 高校学生

1.3 案例时间

本案例总时长预计60分钟。

1.4 案例流程

1bffead9d6728b8f21b713686d553010.png{{{width="60%" height="auto"}}}

说明:

  1. 领取空间开发桌面,登录云主机;
  2. 在云主机终端进入OpenGaussDB;
  3. 进入开发者空间进行OpenGaussDB数据库之AI特性功能使用;

1.5 资源总览

资源名称规格单价(元)时长(分钟)
开发者空间-云主机ARM架构 | 4 vCPUs | 8 GB | OpenEuler 22.03 Server定制版 (40GB)免费60

2 鲲鹏和OpenGaussDB架构融合与AI特性

2.1 开发者空间配置

面向广大开发者群体,华为开发者空间提供一个随时访问的“开发桌面云主机”、丰富的“预配置工具集合”和灵活使用的“场景化资源池”,开发者开箱即用,快速体验华为根技术和资源。

如果还没有领取开发者空间云主机,可以参考免费领取云主机文档领取。

领取云主机后可以直接进入华为开发者空间工作台界面,点击打开云主机 > 进入桌面连接云主机。

a1aae6ff53aac98855ef597dd6899967.png

552fc96c3b58a06e294e4a760ae719e3.png

2.2 启动OpenGaussDB实例并登录

本案例中,使用OpenGaussDB开发平台,完成SQL的编程和自定义函数等多种功能。

基于之前案例《基于开发者空间部署OpenGauss主备集中式数据库系统》。在云主机部署OpenGaussDB实例。并启动数据库服务。

进入OpenGaussDB的安装目录的bin文件,该案例云主机环境中安装目录在环境变量\$GAUSSHOME中,读者根据自己云主机安装目录进行操作修改。

cd $GAUSSHOME/bin

初始化数据库实例,初始化数据库目录在当前目录下data,设置节点名称和初始化用户密码。如下所示

./gs_initdb -D data --nodename=n1 -w GaussDB@123

bc4c9086cc4dbb1598050419cec476da.png

以单节点模式启动数据库实例,并在当前目录下输出日志文件logfile

./gs_ctl start -D data -Z single_node -l logfile

0f652e9f9eee07b00cb8516f34ad694d.png

用gsql客户端工具,进入OpenGaussDB数据库。参数 -a表示追加、-r表示使用readline

./gsql -d postgres -ar

17fd3a6e9547f144785194c54de16c3d.png

2.3 鲲鹏CPU与OpenGaussDB面临的问题

  • 事务处理时锁冲突的比例会大幅增加。在事务处理环境下,由于有更多数量的处理线程同时在运行不同事务处理,对于系统中全局结构的修改将产生更大的冲突,而该冲突将导致处理器资源无法被充分使用,进而限制了数据库系统的可扩展能力和吞吐性能。
  • 事务处理的时延将在比较大的范围内波动,无法很好地满足面向客户的SLA。由于在鲲鹏处理器环境下,NUMA特性更加显著,导致内存访问的时延波动,特别是对一些原子操作(如CAS、FAA等),时延也会有较大的波动。最后导致单个事务处理的时延有较大波动,这给保证客户的SLA带来了一定的难度和挑战。
  • 处理器内部以及处理器核间通信能力提供了新的线程间同步机制。为了有效使用核间通信能力(POE),需要重新架构数据库内部的通信机制,包括通信原语(如spin lock、lock等)的实现以及数据库内部线程间的协作机制。

    面向鲲鹏处理器的OpenGaussDB系统的架构

21bb2c73044cfbb2f6c20f05f5ae415b.png

在OpenGaussDB系统的架构中包含如下创新内容:

  • 基于核间通信能力实现了全新的并发原语机制,特别是自旋锁(spin lock)、读写锁(read/write lock)的实现。全新的并发原语操作与传统的使用原子操作(CAS、FAA等)实现的自旋锁,包括票据锁(ticket lock)、MCS锁(John M. Mellor-Crummey and Michael L. Scott lock等)不同。全新的并发原语直接通过核间通信能力,而无须通过内存变量的原子性修改来达成协同一致,从而大幅提升了性能。
  • 异步流水线机制。数据库系统在执行事务时,可以根据任务的特点,切分成很多个子任务,这些子任务可以由特定线程执行,并绑定在特定处理核上,另一方面,这些子任务之间的协同处理可以通过核间通信能力来实现。进而实现异步流水线的调度/执行机制。

为了高效发挥鲲鹏芯片的优势,OpenGaussDB在设计时考虑以下特点:

  • 类似于多节点并行计算,计算和存储会在特定核上执行,即数据划分到不同的CPU模块和对应的内存,并在一个模块内考虑负载均衡的问题。
  • 为了支持共享数据结构的全局访问,例如LSN(Log Sequence Number日志序列号),XID(Transaction ID事务唯一标识)等数据类型,OpenGaussDB指派单独的核来进行处理,减少数据访问冲突。
  • 为了提高CPU模块内资源的利用率和多核的并发能力,设计新型的NUMA事务处理方法,如基于数据进行事务分发,减少核间冲突等。

2.4 OpenGaussDB在昇腾AI芯片的技术应用

OpenGaussDB内核除了具备传统数据库SQL能力,同时还能将 AI 推理、训练等操作集成到数据库内完成,通过扩展SQL语法来实现数据库内AI的训练和推理,结合昇腾 AI 芯片对训练和推理过程的加速释放昇腾 AI 计算能力,降低 AI 开发成本,实现训练、推理和管理数据一体化。DB4AI 有如下特点:

  • 库内集成 TensorFlow/MindSpore 机器学习深度框架,在数据库内部实现 CNNConvolutional Neural Network,卷积神经网络)、DNNDeep Neural Network,深度神经网络)等算法,并探索基于昇腾芯片的对接与加速。
  • 基于具体行业领域(如电信、智能驾驶业务场景)实现数据库的内置行业AI算法包,数据分析由“DB + BI”向“DB + AI”转变。探索数据库与机器学习算法的融合优化技术,利用数据库优化器索引、剪枝等技术实现机器学习模型训练与推理过程的加速。
  • 数据库充分利用昇腾AI芯片对 Vector、Cube 等计算模型的加速能力,实现传统数据库内聚集操作(Aggregation)、关联操作(Join)的加速。

OpenGaussDB与昇腾结合的AI加速与计算加速架构如图所示:

91f58ffa758b1e6fb3059fde5ee7bb8d.png

OpenGaussDB计算加速

6ad14963f99b2f8d00669f00c3e3e482.png

2.5 OpenGaussDB-AI特性简介

OpenGauss数据库在AI领域主要发为两个方向:

  • AI4DB(AI For DataBase)

    指用AI使能数据库,从而获得数据库更好的执行表现,实现数据库系统的自治、免运维等,主要包括自调优、自诊断、自安全、自运维 、自愈等子领域。

  • DB4AI(DataBase For AI)

指打通数据库到 AI 应用的端到端流程,统一 AI 技术栈,达到AI应用的开箱即用、高性能、低成本等目的。例如:通过类 SQL 语句使用推荐系统、图像检索、时序预测等功能,充分发挥 openGauss 高并行、列存储等优势,提高机器学习任务的执行效率。同时,在数据侧实现 AI 计算,还可以降低数据的网络传输成本,实现本地化计算。

DB4AI里主要包含DeepSQL特性,由于该功能偏于内核,故本案例不做详细讲解。请读者自学DeepSQL。在源码目录路径openGauss-server/src/gausskernel/dbmind/deepsqltopenGauss-server/src/gausskernel/dbmind/db4ai里。

3 AI For OpenGaussDB功能

3.1 索引智能推荐

数据库的索引管理是一期非常普遍且重要的事情,任何数据库的性能优化都需要考虑索引的选择。openGauss支持原生的索引推荐功能,可以通过系统函数等形式进行使用。

3.1.1 使用场景

openGauss的智能索引推荐功能可覆盖多种任务级别和使用场景,具体包含以下三个特性。

  • 单条查询语句的索引推荐。该特性可基于查询语句的语义信息和数据库的统计信息,对用户输入的单条查询语句生成推荐的索引。
  • 虚拟索引。该特性可模拟真实索引的建立,同时避免真实索引创建所需的时间和空间开销,用户可通过优化器评估虚拟索引对指定查询语句的代价影响。
  • 基于工作负载的索引推荐。该特性将包含有多条DML语句的工作负载作为任务的输入,最终生成一批可优化整体工作负载执行时间的索引。该功能适用于多种使用场景,例如,当面对一批全新的业务SQL且当前系统中无索引时,本功能将针对该工作负载量身定制,推荐出效果最优的一批索引;当系统中已存在索引时,本功能仍可查漏补缺,对当前生产环境中运行的作业,通过获取日志来推荐可提升工作效率的索引,或者针对个别的慢SQL进行单条索引推荐。
3.1.2 实现原理
3.1.2.1 针对单条查询语句的索引推荐

单条查询语句的索引推荐是以数据库的系统函数形式提供的,用户可以通过调用gs_index_advise()命令使用。其原理是利用在SQL引擎、优化器等处获取到的信息,使用启发式算法进行推荐。该功能可以用来对因索引配置不当而导致的慢SQL进行优化。

单条查询语句的索引推荐流程图如下

5f856b43e4de11bcd69bb1f0f3e6ef45.png

  • 对给定的查询语句进行词法和语法解析,得到解析树。
  • 依次对解析树中的单个或多个查询子句的结构进行分析
  • 整理查询条件,分析各个子句中的谓词。
  • 解析from子句,提取其中的表信息,如果其中含有join子句,则解析并保存join关系。
  • 解析where子句,如果是谓词表达式,则计算各谓词的选择度,并将各谓词根据选择度的大小进行倒序排列,依据最左匹配原则添加候选索引,如果是join关系,则解析并保存join关系。
  • 如果是多表查询,即该语句中含有join关系,则将结果集最小的表作为驱动表,根据前述过程中保存的join关系和连接谓词为其他被驱动表添加候选索引。
  • 解析group和order子句,判断其中的谓词是否有效,如果有效则插入候选索引的合适位置,group子句中的谓词优于order子句,且两者只能同时存在一个。这里候选索引的排列优先级为:join中的谓词 > where等值表达式中的谓词 > group或order中的谓词 > where非等值表达式中的谓词。
  • 检查该索引是否在数据库中已存在,若存在则不再重复推荐。
  • 输出最终的索引推荐建议。
3.1.2.2 基于工作负载的索引推荐

基于工作负载的索引推荐功能的主要模块如图所示

bc79713b864b4182efae844b1abb5ddf.png

  • 对于给定的工作负载,首先对工作负载进行压缩。由于工作负载中通常存在大量相似的语句,为了减少数据库功能的调用次数,对工作负载中的SQL语句进行模板化和采样。
  • 对压缩后的工作负载,调用单条查询语句的索引推荐功能为每条语句生成推荐索引,作为候选索引集合。
  • 对候选索引集合中的每个索引,在数据库中创建对应的虚拟索引,根据优化器的代价估计来计算该索引对整个负载的收益。
  • 在候选索引集合的基础上,基于索引代价和收益进行索引的选择。openGauss实现了两种算法进行索引优选:一种是在限定索引集大小的条件下,根据索引的收益进行排序,然后选取靠前的候选索引来最大化索引集的总收益,最后采用微调策略,基于索引间的相关性进行调整和去重,得到最终的推荐索引集合;另一种方法是采用贪心算法来迭代地进行索引集合的添加和代价推断,最终生成推荐的索引集合。两种算法各有优势,第一种方法未充分考虑索引间的相互关系,而第二种方法会伴随较多的迭代过程。
  • 输出最终的索引推荐建议。
3.1.2.3 关键源码解析

对应的gs_index_advise函数和虚拟索引列功能在源码目录路径openGauss-server/src/gausskernel/dbmind/kernel;

ef18447ca6c6a6dd5071a21faab34fec.png

读者感兴趣,自行阅读hypopg_index.cppindex_advisor.cpp

3.1.3 使用示例
  • 单条SQL的索引推荐

单条查询语句的索引推荐功能支持用户在数据库中直接进行操作,本功能基于查询语句的语义信息和数据库的统计信息,对面用户输入的单条查询语句生成推荐的索引。本功能涉及的函数接口如下所示

函数名参数返回值功能
gs_index_adviseSQL语句字符串针对单条查询语句生成推荐索引(只支持B树索引)

创建测试表结构:

drop table if exists partsupp;
create table partsupp (
    ps_partkey integer not null,
    ps_suppkey integer not null,
    ps_availqty integer not null,
    ps_supplycost decimal(15,2) not null,
    ps_comment varchar(199) not null);

drop table if exists supplier;
create table supplier (
    s_suppkey integer not null,
    s_name char(25) not null,
    s_address varchar(40) not null,
    s_nationkey integer not null,
    s_phone char(15) not null,
    s_acctbal decimal(15,2) not null,
    s_comment varchar(101) not null);

drop table if exists nation;
create table nation (
    n_nationkey integer not null,
    n_name char(25) not null,
    n_regionkey integer not null,
    n_comment varchar(152));

9a2b5ec593ee444d1601354a08236009.png

表数据文件(CSV),将3个表的csv文件放在\$GAUSSHOME/bin目录下:

CSV数据文件从云主机浏览器中访问下面三个链接下载到云主机。

https://dtse-mirrors.obs.cn-north-4.myhuaweicloud.com/case/0043/nation.csv

https://dtse-mirrors.obs.cn-north-4.myhuaweicloud.com/case/0043/partsupp.csv

https://dtse-mirrors.obs.cn-north-4.myhuaweicloud.com/case/0043/supplier.csv

image.png

b5bee5ebe440a2c21db0c4292ad7fce3.png

把csv数据文件,移动到主目录下。

mv *.csv ~
cd ~

8a0b7f3e6c687180e72d2cc6c6dc2525.png

导入数据(/home/developer/partsupp.csv是本案例当前的文件路径,请根据各自情况修改路径):

登录gsql客户端

cd $GAUSSHOME/bin
./gsql -d postgres -ar

ca7bcc741e7a00ab7527f0f15f94e07a.png

执行下列SQL语句:

\copy partsupp from '/home/developer/partsupp.csv' with ( FORMAT 'csv', DELIMITER ',',  ENCODING 'utf8');
\copy supplier from '/home/developer/supplier.csv' with ( FORMAT 'csv', DELIMITER ',',  ENCODING 'utf8');
\copy nation from '/home/developer/nation.csv' with ( FORMAT 'csv', DELIMITER ',',  ENCODING 'utf8');
select count(*) from partsupp;
select count(*) from supplier;
select count(*) from nation;

e508b04fca29f3ebe954e3eb012e5ad3.png

打开执行时间统计:

\timing

3540a510ae8a4b2fff0440167cf1975a.png

执行要测试的SQL查询语句:

select
    ps_partkey,
    sum(ps_supplycost * ps_availqty) as value
from
    partsupp,
    supplier,
    nation
where
    ps_suppkey = s_suppkey
    and s_nationkey = n_nationkey
    and n_name = 'GERMANY'
group by
    ps_partkey having
        sum(ps_supplycost * ps_availqty) > (
            select
                sum(ps_supplycost * ps_availqty) * 0.0001000000
            from
                partsupp,
                supplier,
                nation
            where
                ps_suppkey = s_suppkey
                and s_nationkey = n_nationkey
                and n_name = 'GERMANY'
        )
order by
    value desc;

执行结果耗时如下所示

2dccbd45875cca8b7d98f4543d3d14f4.png

使用gs_index_advise()智能推荐索引。

select * from gs_index_advise('select
    ps_partkey,
    sum(ps_supplycost * ps_availqty) as value
from
    partsupp,
    supplier,
    nation
where
    ps_suppkey = s_suppkey
    and s_nationkey = n_nationkey
    and n_name = ''GERMANY''
group by
    ps_partkey having
        sum(ps_supplycost * ps_availqty) > (
            select
                sum(ps_supplycost * ps_availqty) * 0.0001000000
            from
                partsupp,
                supplier,
                nation
            where
                ps_suppkey = s_suppkey
                and s_nationkey = n_nationkey
                and n_name = ''GERMANY''
        )
order by
    value desc');

结果如下

163292c4dfdc64d88cf6bd2e37dd8c54.png

根据索引推荐的结果,创建对应的索引

create index ps_suppkey_index on partsupp(ps_suppkey);
create index sl_suppkey_nationkey_index on supplier(s_suppkey, s_nationkey);

4f0d7d968cf5973760113df442ff1a8d.png

再执行上面的查询,查看耗时结果

464935e451b9e2554df4219eb193b87c.png

可以明显看出SQL执行时间从1471.799ms降到了585.621ms,速度提升了接近61%

再删除刚才创建的索引:

drop index ps_suppkey_index;
drop index sl_suppkey_nationkey_index;

7ca53f93e5658ae35cfb5ef6593dedfa.png

创建虚拟索引:

select * from hypopg_create_index(' create index ps_suppkey_index on partsupp(ps_suppkey)');
select * from hypopg_create_index('create index sl_suppkey_nationkey_index on supplier(s_suppkey, s_nationkey)');

f37ec76799921bb1228b4b675a453b00.png

删除索引虚拟列:

select * from hypopg_drop_index(indexrelid);

根据本案例在上面的查询结果,indexrelid是16402,16403。

select * from hypopg_drop_index(16402);
select * from hypopg_drop_index(16403);

7da508311799f86f6abd745ffaeb4968.png

查看虚拟索引列:

select * from hypopg_display_index();

再删除该虚拟索引:

select * from hypopg_drop_index(16401);
select * from hypopg_display_index();

30f4ef8e2a36275286cb8a6449c9b205.png

再创建之前的虚拟索引:

select * from hypopg_create_index(' create index ps_suppkey_index on partsupp(ps_suppkey)');

获取索引虚拟列大小结果:

select * from hypopg_estimate_size(indexrelid);

根据上面返回的indexrelid结果,则为

select * from hypopg_estimate_size(16404);

f44ca08126235e65c93e351c59cda408.png

删除所有索引虚拟列:

select * from hypopg_reset_index();

再查看虚拟列索引,确认所有虚拟列索引都已经被删除了。

select * from hypopg_display_index();

b4cfc0eb370a2dbaefdd277ac84b370e.png

3.2 自调优

数据库自调优技术是一个较大范畴,通常包括对数据库参数配置、自身代价优化模型的调优等。本案例主要介绍对数据库参数配置进行自动调优的功能。

3.2.1 参数自调优的使用场景

数据库系统会提供大量参数供DBA进行调优,OpenGauss提供了500多个参数。很多参数都与数据库的表现密切相关,如负载调度、资源控制、WAL机制等。

数据库参数调优的目的是满足用户对性能的期望,保障数据库系统的稳定可靠。大部分场景中,数据库参数调优依赖DBA去识别和调整,但DBA调优存在很多限制。主要包括三个方面:

  1. DBA要花费大量时间,在测试环境中参考所要部署的业务进行调优;而每次上线新业务,调优过程需要重新进行一 ,对于企业来说,人力成本巨大。
  2. DBA通常仅关注少部分关键调优参数,使得调优过程不能完全匹配业务,而且资源利用率及数据库性能并不一定是最优的,而且其他次优参数与数据库表现的隐式关系也没有被充分挖掘出来。
  3. DBA通常只精通某一个特定的数据库调优,譬如擅长调优A数据库的DBA很可能不擅长调优B数据库,因为二者的底层实现存在很大差异,不可以使用同一套经验进行调优。同时,若硬件环境发生了变化,DBA的经验不一定能发挥作用,多业务混合负载场景下也是如此。
3.2.2 X-Tuner的调优策略

对数据库进行参数调优可以分为两类模式,分别是离线参数调优和在线参数调优,X-Tuner同时支持上述两类调优模式。

  1. 离线参数调优是指在数据库脱离生产环境的基础上进行调优,一般是在上线真实业务前进行压力测试,并通过压力测试的反馈结果进行参数调优。
  2. 在线参数没去优是指不阻塞数据库的正常运行,在数据库运行中进行参数调优或推荐的过程。

具体来说,调优程序X-Tuner包含三种运行模式。

  1. recommend:获取当前正在运行的workload特征信息,根据该特征信息生成参数推荐报告。报告当前数据库中不合理的参数配置和潜在风险等;输出当前正在运行的workload行为和特征;输出推荐的参数配置。该模式是秒级的,不涉及数据库的重启操作,其他模式可能需要反复重启数据库。
  2. train:通过用户提供的benchmark信息,迭代地进行参数修改和benchmark(一种用于测量硬件或软件性能的测试程序)执行过程,训练强化学习模型。通过反复的迭代过程,训练强化学习模型,以便用户在后面通过tune模式加载该模型进行调优。
  3. tune:使用优化算法进行数据库参数的调优,当前支持两大类算法,一种是深度强化学习,另一种是全局搜索算法(全局优化算法)。深度强化学习模式要求先运行train模式,生成训练后的调优模型,而使用全局搜索算法则不需要提前进行训练,可以直接进行搜索调优。如果在tune模式下使用深度强化学习算法,要求必须有一个训练好的模型,且训练该模型时的参数与进行调优时的参数列表(包括max与min)必须一致。

无论是离线参数调优还是在线参数调优,X-Tuner都是支持的,它们的基本结构也是共用的。X-Tuner的结构示意图及交互形式如图所示。

X-Tuner的结构示意图及交互形式

67aaabce3361c4c83162eaa14175ec68.png

X-Tuner大致分为DB侧、算法侧、主体逻辑模块及benchmark,其各部分的功能说明如表所示。

X-Tuner结构功能说明
DB侧通过DB_Agent模块对数据库实例进行抽象,通过该模块可以获取数据库内部的状态信息、当前数据库参数及设置数据库参数等。DB侧包括登录数据库环境使用的SSH连接
算法侧用于调优的算法包,包括全局搜索算法(如贝叶斯优化、粒子群算法等)和深度强化学习(如DDPG)
主体逻辑模块通过Enviroment模块进行封装,每个“sleep”就是一次调优过程。整个调优过程通过多个“step”进行迭代
benchmark由用户指定的benchmark性能脚本,用于运行benchmark作业,通过跑分结果反映数据库系统性能优劣
  1. 离线参数调优

X-Tuner利用长期在openGaussDB上进行参数调优的先验规则,根据系统的workload、环境特征推荐初始参数调优范围,该范围便是待搜索的配置参数空间。利用算法(如强化学习、启发式算法等)在给定的参数空间上不断进行搜索,即可找到最优的参数配置。

常规评价调优效果好坏的方法是运行benchmark,包括TPC-C、TPC-H及用户自定义的benchmark,用户只需要进行少量适配即可。离线参数调优的流程如图所示,

离线参数调优的流程

d51039d81746f193f1db895f6dc9acab.png

对于离线调优,用户通过benchmark模拟真实环境中的workload,使用调优工具 X-Tuner根据不同参数在benchmark上的表现来判断什么参数能够取得最佳表现。需要注意的是,整个离线调优过程是迭代式的,即设置完一次参数后,执行一次benchmark用于检验本次设置的参数好坏。上述过程称为一次调优过程,那么X-Tuner只需要多次执行上述过程,即可找到一个最佳的参数配置。X-Tuner可以根据上一个调优过程的反馈,决定下一次调优中参数的寻找方向,这个过程也是优化算法的探索过程。

上述过程需要一个初始参数配置,已经训练好的强化学习模型会利用模型初始化这个初始参数配置。若采用搜索算法,则根据先验规则进行初始化。

由于某些数据库参数需要重启后才可生效,因此离线参数调优过程也可能是需要频繁地重启数据库的。离线调优过程与DBA手动调优过程比较相似,都是通过观察—试探—再观察—再试探进行的,只不过这个试探过程不是基于DBA的人工经验,而是通过算法的分析进行的。该过程也是比较耗时的,主要耗在执行benchmark上。

对于一些场景,可以采用EXPLAIN命令替代,这样就可以省掉执行benchmark的间,但是EXPLAIN并不能直接反映参数对缓冲区、WAL等数据库系统内部模块的影响,因此可使用的场景是有限的。业内一个比较前沿的方法,是通过AI的方法,预估数据库的性能表现,一般称之为性能评估模型(performance model),通过该模型,可以省去执行benchmark的时间,从而压缩调优时间。不过该方法主要停留在理论层面,距在普适场景上的应用尚有差距,目前也在openGaussDB的演进方向中。

X-Tuner目前支持的强化学习算法主要为DDPG,支持的搜索算法主要为粒子群算法(Particle Swarm Optimization,PSO)与贝叶斯优化算法(bayesian optimization)。

  1. 在线参数调优

X-Tuner采集操作系统的统计信息和workload特征,根据训练好的监督学习模型或先验规则,推荐给用户对应的参数修改建议。在线参数调优的流程图如下所示。

在线参数调优流程图

608c54eec7cb9bc0da6d729e998a002d.png

3.2.3 OpenGaussDB关键源码说明

X-Tuner的代码,华为开源社区已经从OpenGauss内核源码里脱离出来,形成了一个单独的开源项目DBMind,链接如下:

https://gitee.com/opengauss/openGauss-DBMind

下载DBMind源码

git clone --depth 1 https://gitee.com/opengauss/openGauss-DBMind.git
ls openGauss-DBMind/
chmod +x openGauss-DBMind/gs_dbmind
echo PATH=`pwd`/openGauss-DBMind:'$PATH' >> ~/.bashrc
echo 'export PATH' >> ~/.bashrc
source ~/.bashrc

ec5b20c582323cefc8200d88725d9057.png

cd openGauss-DBMind/
python3 -m pip install -r requirements-aarch64.txt

04a6f6af6874f72c66e184472909ec34.png

74497d57f7faadadaa65a4e4a6b3f9fc.png

cd openGauss-DBMind/dbmind/components/xtuner
ls -al

7e1c3262692b4773858c942a463d4b7b.png

share为配置文件示例目录,tuner目录调优程序主代码目录。

ls -al tuner/

4070c696507f5febbc9234ce629af82b.png

tuner/algorithms算法子模块
tuner/benchmark压力测试驱动脚本存储目录
tuner/character.py获取系统workload特征的模块
tuner/db_agent.py封装数据库操作的模块
tuner/db_env.py离线调优流程控制模块
tuner/env.py保持与强化学习gym库的接口一致
tuner/exception.py定义常见异常
tuner/knob.py定义参数相关类
tuner/main.py入口文件
tuner/recommend.py定义参数推荐的算法与规则
tuner/recorder.py记录调优过程的模块
tuner/utils.py定义一些工具函数
tuner/xtuner.conf默认配置文件
tuner/xtuner.py调优主流程控制模块
ls -al tuner/algorithms/

7f1f34d8cab8ba220b77d67d5d660e42.png

tuner/algorithms/pso.py文件是粒子群算法文件。

ls -al tuner/benchmark/

924324f72e89c4128cc8027e333ef3fc.png

X-Tuner主要源码文件结构

tuner/benchmark/sysbench.pysysbench驱动脚本
tuner/benchmark/template.py压力测试驱动脚本的模板
tuner/benchmark/tpcc.pyTPC-C驱动脚本
tuner/benchmark/tpcds.pyTPC-DS驱动脚本
tuner/benchmark/tpch.pyTPC-H驱动脚本

注:具体源码本案例不用详解,请读者自行研究。

3.2.4 使用示例

给openGaussDB初始化用户:

cd $GAUSSHOME/bin
./gsql -d postgres -ar
create user dbmind_monitor sysadmin password 'GaussDB_123';
alter user dbmind_monitor monadmin;

进入tuner目录(main.py文件所在路径),添加环境变量PYTHONPATH。

cd openGauss-DBMind/dbmind/components/xtuner/tuner
export PYTHONPATH=`pwd`/..
sudo yum install lapack lapack-devel blas blas-devel
pip install paramiko bayesian-optimization ptable
pip install tensorflow>=2.2.0 keras-rl2 keras>=2.4.0
python3 -m pip install -r ~/openGauss-DBMind/requirements-optional.txt

根据openGauss-DBMind/dbmind/components/xtuner/share里的jsoin模板,拷贝对应的josn文件到tuner文件中。其中模板有knobs.json.template,server.json.template,xtuner.conf.template。到\~/openGauss-DBMind/dbmind/components/xtuner/tuner目录下对应的knobs.json,server.json,xtuner.conf文件。

cp ~/openGauss-DBMind/dbmind/components/xtuner/share/knobs.json.template ~/openGauss-DBMind/dbmind/components/xtuner/tuner/knobs.json
cp ~/openGauss-DBMind/dbmind/components/xtuner/share/server.json.template ~/openGauss-DBMind/dbmind/components/xtuner/tuner/server.json
cp ~/openGauss-DBMind/dbmind/components/xtuner/share/xtuner.json.template ~/openGauss-DBMind/dbmind/components/xtuner/tuner/xtuner.json

根据各自的环境参数,修改server.json配置文件。

vim ~/openGauss-DBMind/dbmind/components/xtuner/tuner/server.json

本案例参数如下,仅做参考:

318dbf4be389f792c1b7837892253946.png

xtuner.conf里需要修改的是benchmark_path, tuning_list

b1b2cd7481257c6b3c67abdcf487b110.png

0265f262405e129177be99fbc876488b.png

注:由于运行过程中,需要输入host_user的passwrod,所以如果不清楚云主机developer用户的密码时,可以通过如下命令修改该用户密码

sudo passwd developer

切换到tuner目录,执行如下命令:

cd ~/openGauss-DBMind/dbmind/components/xtuner/tuner
gs_dbmind component xtuner tune -f server.json

本案例由于是openEuler的arm架构环境,故在运行时会报错,根据报错信息自行修改代码。如下:

在openGauss-DBMind/dbmind/components/xtuner/tuner/character.py里的368行处,由于本案例的系统环境,lscpu命令返回的数据库CPU没有' (s) ',所以应该修改代码,如下:

7cc28aaca1714d730122ed35d2c4b24d.png

根据本案例云主机环境的实际情况,执行shell命令:

lscpu | grep 'CPU'

078d3e7ca8c00dd9e94399c632d9990b.png

根据character.py的代码逻辑,此处应该是返回cpu的核心数量,所以exec_command_on_host()的命令应该做修改处理。

lscpu | grep 'CPU:' | head -1 | awk '{print $2}'

1f0d629e8f58143274f73ca47ddc0db1.png

修改源码如下:

2da152e0e2f16350b1ed0be80980de98.png

再运行命令:

gs_dbmind component xtuner tune -f server.json

f139e429a77a02365a1434d2a1fb08f9.png

81ad93c3888b5b4248e7eeb7af4ffca9.png

该过程是根据benchmark做性能压力测试,根据数据不停的迭代openGaussDB的配置参数,根据实际测试的性能结果,自学习调优配置参数。该过程耗时较长。

0fc9df9237887377eae0ef2510833148.png

根据结果可知,目前DBMind工具中的xtuner组件功能存在问题,功能不完善,需要后续优化。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值