1.1 数据倾斜1.1.1 问题描述某局点SQL执行慢，涉及大表的SQL执行不出来结果。1.1.2 分析过程数据倾斜在很多方面都会有体现：1.       gs_ssh –c “df -h”查看各个数据磁盘的利用率，会有不均衡的现象。正常情况下，利用率最高和利用率最高的磁盘空间相差不大，如果磁盘利用率相差超过了5%就要引起重视。2.       通过等待视图查看作业的运行情况，发现作业总是等待部分DN，或者个别DN。Select wait_status, count(*) cnt from pgxc_thread_wait_status where wait_status not like ‘%cmd%’ and wait_status not like ‘%none%’ and wait_status not like ‘%quit%’ group by 1 order by 2 desc;3.       慢语句的explain performance显示，基表scan的时间和行数各个DN之间不均衡。       基表scan的时间最快的dn耗时5ms，最慢的dn耗时1173ms数据最多的dn有22831616行，其他dn都是0行，数据有严重倾斜。4.       通过倾斜检查接口可以发现数据倾斜。select table_skewness('store_sales'); select table_distribution('public','store_sales');5.       通过资源监控发现，个别节点的CPU/IO明显比其他节点高。1.1.3 问题根因GaussDB当前支持Hash表和复制表两种分布方式。默认创建的表是Hash分布的，如果不指定分布键，则选择表的第一列作为分布键。那么这种情况就可能存在倾斜的。倾斜造成的负面影响非常大。首先，SQL的性能会非常差，因为数据只分布在部分DN，那么SQL运行的时候就只有部分DN参与计算，没有发挥分布式的优势。其次，会导致资源倾斜，尤其是磁盘。可能部分磁盘的空间已经接近极限，但是其他磁盘利用率很低。可能出现部分节点CPU过高等等问题。1.1.4 解决详情如何找到倾斜的表：1.在库中表个数少于1W的场景，直接使用倾斜视图查询当前库内所有表的数据倾斜情况。SELECT * FROM pgxc_get_table_skewness ORDER BY totalsize DESC;2.在库中表个数非常多（至少大于1W）的场景，因PGXC_GET_TABLE_SKEWNESS涉及全库查并计算非常全面的倾斜字段，所以可能会花费比较长的时间（小时级），建议参考PGXC_GET_TABLE_SKEWNESS视图定义，直接使用table_distribution()函数自定义输出，减少输出列进行计算优化，例如：SELECT schemaname,tablename,max(dnsize) AS maxsize, min(dnsize) AS minsize  FROM pg_catalog.pg_class c  INNER JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace  INNER JOIN pg_catalog.table_distribution() s ON s.schemaname = n.nspname AND s.tablename = c.relname  INNER JOIN pg_catalog.pgxc_class x ON c.oid = x.pcrelid AND x.pclocatortype = 'H'  GROUP BY schemaname,tablename;表的分布键的选择方法：1)      这个列的distinct值比较大，并且没有明显的数据倾斜。也可以把多列定义成分布列。怎么看distinct的大小？select count(distinct column1) from table;怎么看数据是不是有倾斜？select count(*) cnt, column1 from table group by column1 order by cnt limint 100;2)      选用经常做JOIN字段/group by的列，可以减少STREAM运算。3)      不好的实践：分布列用默认值（第一列）分布列用sequence自增生成分布列用随机数生成(除非任意列，或者任意两列的组合做分布键都是倾斜的，一般不选用这种方法)。 1.2 统计信息未收集1.2.1 问题描述略1.2.2 分析过程1.       通过explain verbose/explain performance打印语句的执行计划2.       执行计划中会有语句未收集统计信息的告警，并且通常E-rows估算非常小。3.       上述例子中，在打印的执行计划中有Warning提示信息，提示有哪些列在这个执行计划中用到了，但是这些列没有统计信息。在CN的pg_log日志中也有会有类似的Warning信息。同时，E-rows会比实际值小很多。1.2.3 问题根因优化器是基于代价的优化 (Cost-Based Optimization，简称CBO)。在这种优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值，以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost)，进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。统计信息是优化器生成执行计划的基础，没有收集统计信息，优化器生成的执行计划会非常差，如果统计信息未收集，会导致多种多样表现形式的性能问题。例如，等值关联走NestLoop，大表broadcast，集群CPU持续增高等等问题。1.2.4 解决详情周期性地运行ANALYZE，或者在对表的大部分内容做了更改之后马上执行analyze。1.3 语句不下推1.3.1 问题描述略1.3.2 分析过程1.       通过explain verbose打印语句执行计划2.       上述执行计划中有__REMOTE关键字，这就表明当前的语句是不下推执行的。3.       不下推语句在pg_log中会打印不下推的原因。上述语句在CN的日志中会找到类似以下的日志：1.3.3 问题根因目前最新版本可以支持绝大多数常用函数的下推。不下推函数的场景主要出现在自定义函数属性定义错误的场景。不下推语句的执行方式没有利用分布式的优势，他的执行过程相当于把大量的数据和计算过程汇集到一个节点上去做，因此性能往往非常差。1.3.4 解决详情审视用户自定义函数的provolatile属性是否定义正确。如果定义不正确，要修改对应的属性，使它能够下推执行。 具体判断方法可以参考如下说明：函数相关的所有属性都在pg_proc这张系统表中可以查到。其中与函数能否下推相关的两个属性是provolatile 和 proshippable。其中provolatile是继承自PG的字段，他的本质含义是描述函数是IMMUTABLE/STABLE/VOLATILE的。简单来讲，如果一个函数对于同样的输入，一定有相同的输出，那么这类函数就是IMMUTABLE的，例如绝大部分的字符串处理函数。如果一个函数的返回结果在一个SQL语句的调用过程中，结果是相同的，那么他就是STABLE的。例如时间相关的处理函数，他的最终显示结果可能与具体的GUC参数相关（例如控制时间显示格式的参数），这类函数都是STABLE的。如果一个函数的返回结果可能随着每一次的调用而返回不同的结果。例如nextval，random这种函数，每次调用结果都是不可预期的，那么他就是VOLATILE的。1.4 not in 和 not exists1.4.1 问题描述客户的SQL语句执行慢，执行计划中有NestLoop1.4.2 问题定位1.       首先观察SQL语句中有not in 语法2.       执行计划中有NestLoop 1.4.3 问题根因NestLoop是导致语句性能慢的主要原因。Hashjoin只能做等值关联。NestLoop的条件中有or条件，所以无法用Hashjoin求解。导致出现这个现象的原因是由not in的语义决定的(具体可以参考外网关于not in 和 not exists的介绍)。 1.4.4 解决详情大多数场景下，客户需要的结果集其实是可以通过not exists获得的，因此上述语句可以通过修改将not in 修改为not exists。  1.5 未分区剪枝1.5.1 问题描述三条sql查询慢，查询的分区表总共185亿条数据，查询条件中没有涉及分区键select passtime from 表 where passtime<'2020-02-19 15:28:14' and passtime>'2020-02-18 15:28:37' order by passtime desc limit 10; select max(passtime) from 表 where passtime<'2020-02-19 15:28:14' and passtime>'2020-02-18 15:28:37'; 列存表，分区键为createtime,哈希分布键为motorvehicleid 1.5.2 分析过程1.       和客户确认部分业务慢，慢的业务中都涉及到了同一张表tb_motor_vehicle2.       和客户收集几个典型的慢sql，分别打印执行计划从执行计划中可以看出来，两条sql的耗时都集中在Partitioned CStore Scan on public.tb_motor_vehicle列存表的分区扫描上3.       和客户确认，该表的分区键为createtime，而涉及到的sql中无任何createtime的筛选和过滤条件，基本可以确认是由于慢sql的计划没有走分区剪枝，导致了全表扫描，对于185亿条数据量的表，全表扫描性能会很差。4.       通过在筛选条件中增加分区键过滤条件，优化后的sql和执行计划如下：SELECT passtime FROM tb_motor_vehicle WHERE createtime > '2020-02-19 00:00:00' AND createtime < '2020-02-20 00:00:00' AND passtime > '2020-02-19 00:00:00' AND passtime < '2020-02-20 00:00:00' ORDER BY passtime DESC LIMIT 10000;性能从十几分钟，优化到了12秒左右，性能有明显提升1.5.3 问题根因慢sql过滤条件中未涉及分区字段，导致执行计划未分区剪枝，走了全表扫描，性能严重裂化1.5.4 解决详情在慢sql的过滤条件中增加分区筛选条件，避免走全表扫描1.6 行数估算过小，走了nestloop1.6.1 问题描述查询语句执行慢，卡住无法返回结果sql特点是2-3张表left join，然后通过select查询结果，执行计划如下： 1.6.2 分析过程1.       排查当前的IO，内存，CPU使用情况，没有发现资源占用高的情况2.       查看慢sql的线程等待状态select * from pg_thread_wait_status where query_id=’149181737656737395’;根据线程等待状态，并没有出现都在等待某个DN的情况，初步排除中间结果集偏斜到了同一个DN的情况。3.       到相应的实例节点上，打印等待状态为none的线程堆栈信息如下：gstack 14104通过反复打印堆栈信息，发现堆栈在变化，并没有hang死，所以初步判断该问题未性能慢的问题，堆栈中有VecNestLoopRuntime，以及结合执行计划，初步判断是由于统计信息不准，优化器评估结果集较少，计划走了nestloop导致性能下降。4.       对表执行analyze后性能并没有太大改善5.       对sql增加hint关闭索引，让优化器强行走hashjoin，发现hint功能没有生效，原因是hint无法改变子查询中的计划6.       通过set enable_indexscan = off;执行计划被改变，走了Hash Left Join，慢sql在3秒左右跑出结果，满足客户需求。1.6.3 问题根因优化器在选择执行计划时，对结果集评估较小，导致计划走了nestloop，性能下降1.6.4 解决详情通过set set enable_indexscan = off;关闭索引功能，让优化器生成的执行计划不走nestloop，而走Hashjoin1.7 表数据膨胀，未清理脏数据1.7.1 问题描述 数据库性能时快时慢问题GaussDB 数据库性能时快时慢问题，原先几秒钟的sql，目前20几秒出来，导致前台IOC页面数据加载超时，无法对用户提供图表显示1.7.2 分析过程1.       raid卡缓存策略未开启、CPU开启了节能模式，查询并未开启/opt/MegaRAID/MegaCli/MegaCli64 -LDinfo -Lall –aAll |grep 'Write Cache'（root用户）cat /proc/cpuinfo |grep MHz2.       和客户确认是部分业务慢，可以提供部分慢sql，打印执行计划，耗时主要在index scan上，怀疑是IO争抢导致，通过监控IO，发现并没有IO资源使用瓶颈。 3.       查询当前活跃sql，发现有大量的create index语句，需要和客户确认该业务是否合理select * from pg_stat_activity where state !=’idle’ and usename !=’omm’;4.       根据执行计划，发现在部分DN上耗时较高，查询表的倾斜情况，并未发现有倾斜的情况select table_skewness(‘ioc_dm.m_ss_index_event’);5.       检查内存相关参数，设置不合理，需要优化单节点总内存大小为256Gmax_process_memory为12G，设置过小shared_buffers为32M，设置过小work_mem：CN：64M 、DN：64Mmax_active_statements: -1（不限制并发数）设置方式如下：gs_guc set -Z coordinator -Z datanode -N all -I all -c "max_process_memory=25GB" gs_guc set -Z coordinator -Z datanode -N all -I all -c "shared_buffers=8GB"gs_guc set -Z coordinator -Z datanode -N all -I all -c "work_mem=128MB"6.       进一步分析扫描慢的原因，发现表数据膨胀严重，对其中一张8G大小的表，总数据量5万条，做完vacuum full后大小减小为5.6M 1.7.3 问题根因1.       大量表频繁增删改，未及时清理，导致脏数据过多，表数据膨胀，查询慢2.       交付时，内存参数设置不合理1.7.4 解决详情1.       对业务涉及到的常用的大表，执行vacuum full操作，清理脏数据；2.       设置GUC内存参数 1.8 “in 常量”优化1.8.1 问题描述简单的大表过滤的SQL语句中有一个“in 常量”的过滤条件，常量的个数非常多(约有2000多个)，基表数据量比较大，SQL语句执行不出来。1.8.2 分析过程1.       打印语句的执行计划：2.       执行计划中，in条件还是作为普通的过滤条件存在。这种场景下，最优的执行计划应该是将“in 常量”转化为join操作性能更好。1.8.3 问题根因执行计划中，in条件还是作为普通的过滤条件存在。这种场景下，最优的执行计划应该是将“in 常量”转化为join操作性能更好。1.8.4 解决详情qrw_inlist2join_optmode可以控制把“in 常量”转join的行为。默认是cost_base的。如果优化器估算不准，可能会出现需要转化的场景没有做转化，导致性能较差。这种情况下可以通过设置qrw_inlist2join_optmode为rule_base来规避解决。 1.9 相关子查询11.9.1 问题描述用户的SQL性能差，执行计划中有SubPlan的关键字1.9.2 分析过程执行计划中有SubPlan，这类语句的性能往往比较差。1.9.3 问题根因执行计划中有SubPlan的语句往往性能比较差，这是因为，引用SubPlan结果的算子可能需要反复的调用获取这个SubPlan的值，即SubPlan以下的结果要重复执行很多次。1.9.4 解决详情这类问题通常通过改写SQL来规避。往往这种场景的SQL语句的改写是比较困难，而且很容易出现改写后的结果不一致问题。由于我们在比较高的版本上已经支持了很多场景想的SubPlan的自动转化为join操作，因此一种比较方便的思路是打印他在高版本下的执行计划(explain verbose)，然后根据explain verbose 演绎出来改写后的SQL语句。以上述为例，他在高版本的执行计划如下：那么根据上述信息，SQL语句可以改写为：为了确认改写后的语句与原来的语句是等价的，可以再次打印改写后的执行计划，对比：1.11 相关子查询21.11.1 问题描述UPDATE场景下出现了SubPlan导致语句执行性能差1.11.2 分析过程上述执行计划中有SubPlan，这类语句的性能往往比较差。1.11.3 问题根因执行计划中有SubPlan的语句往往性能比较差，原因与1.9章节案例类似。1.11.4 解决详情上述问题可以通过特定的改写方法来解决：  1.12 单表点查性能差1.12.1 问题描述单表查询的场景下，客户预期1s以内返回结果，实际执行耗时超过10s1.12.2 分析过程1.       通过抓取问题SQL的执行信息，发现大部分的耗时都在“CStore Scan”2．分析出问题的场景：基表是一张十亿级别的表，每晚有批量增量数据入库，同时会有少量的数据清洗的工作。白天会有高并发的查询操作，查询不涉及表关联，并且返回结果都不大。1.12.3 问题根因这种场景属于行列存表选择错误导致的问题。这种场景应该使用行存表+btree索引。1.12.4 解决详情调整表定义，表修改为行存表。同时建立btree索引，索引建立的原则：1.       基于充分分析客户SQL的背景下去建立索引。2.       索引要建立的刚刚好，不要有冗余3.       建立组合索引时候，要把过滤性比较好的列往前放4.       尽可能多的过滤条件都用到索引1.13 NestLoop+indexscan的适用场景1.13.1 问题描述某客户反馈两个表的关联要去秒级返回，其中大表有2.7T，小表有100GB左右，查询结果一般都不大，过滤条件中有过滤性比价好的条件。1.13.2 分析过程1.       原始的执行计划：2.       可以看到两个表关联走了HashJoin，主要的耗时在基表扫描和HashJoin操作上。1.13.3 问题根因主要的耗时点是在Hashjoin 和基表扫描上，这种情况下可以考用NestLoop+indexScan的计划。这种计划会把join条件下推到基表扫描上，然后利用基表的索引，提前把数据过滤掉。1.13.4 解决详情由于NestLoop+indexScan的计划有一些约束：1.       Join的时候不能有stream（不能通过stream来传递join条件的下推）2.       大表上要有合适的索引。修改后的执行计划如下： 

【功能模块】GaussDB A8 mppdb新增加实例失败，其中一个节点获取xlog日志失败。【操作步骤&问题现象】mppdb 服务增加实例失败，原因是其中一个新增节点获取xlog失败（另外两个新增节点能获取xlog日志，网络也没问题。），而造成这个节点添加失败，从而引起的dn节点无法满足容错。请问无法获取xlog日志的问题怎么解决？

【问题现象】6.5.1客户来电反馈充当GDS的服务器异常，当前更换为新服务器进行GDS连接，配置好后在启动GDS时报错。【问题影响】【客户态度】【处理过程】报错如下：执行ldd /opt/bin/gds/gds发现libcjson.so.1文件缺失丢失。针对该问题有两种方法：方法一：往/lib64目录下放置libcjson.so.1文件。1、通过ldd /opt/bin/gds/gds查看缺少的依赖包。2、在集群cn节点服务器omm用户执行以下操作。source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile which gdscd /opt/huawei/Bigdata/mppdb/core/libfind ./ -name libcjson.so.13、将找到的so文件拷贝至gds服务器的/lib64目录下。4、如果第2步找不到，可以在/lib64下查找，找到后进行拷贝。find /lib64/ -name libcjson.so.15、重新启动gds服务。方法二：定向指定/opt/bin/lib/目录进行调用使用root用户执行一下find / -namelibcjson.so.1     确认该文件所在的目录再切换回gds_user用户，执行exportLD_LIBRARY_PATH="/opt/bin/lib:$LD_LIBRARY_PATH" (请将/opt/bin/lib 上一步查出来的目录)

GaussDB NoSQL支持多模融合技术，支持MongoDB、Cassandra、Redis和InfluxDB，请问支持跨模型查询吗？如果支持的话，具体又是怎么实现的呢？

 摘要：数据仓库服务（ Data Warehouse Service，简称DWS）是一种基于公有云基础架构和平台的在线数据处理数据库，提供即开即用、可扩展且完全托管的分析型数据库服务。DWS是基于华为融合数据仓库GaussDB产品的云原生服务，为各行业PB级海量大数据分析提供有竞争力的解决方案。数据仓库是企业的重要数据分析系统，随着业务量的增长，自建数仓性能逐渐不能满足实际要求，同时扩展性差、成本高，扩容极为困难。如果企业想要扩大业务和不断创新，上云已经成为了必经之路。而DWS作为云上企业级数据仓库，具备高性能、低成本、易扩展等特性，满足大数据时代企业数据仓库业务诉求。

 11月20日，以“自研·智能·新基建——云和数据促创新 生态融合新十年” 为主题的数据技术嘉年华（DTC）在北京举行，华为云数据库业务总裁苏光牛受邀出席并发表主题演讲，分享了华为云GaussDB在生态融合、战略投入、能力优势、行业实践等方面内容，积极打造开源开放生态和优秀解决方案，加速政企智能升级。 新基建浪潮下，云、AI、5G成为推动数字中国建设与发展的重要基石，云数据库作为数据基础设施的重要一环，不仅是IT软件皇冠的明珠，也是数据库领域产业升级的转折点，客户对数据库生态融合开放的呼声也越来越强烈。       苏光牛提到：开放生态的核心是内核开源，我们一方面积极拥抱开源生态，统一架构，避免客户从原先传统封闭数据库生态，再走向另一个新的封闭生态；另一方面我们开源自主生态openGauss，加速生态培养和人才培养，积极创新，打造繁荣与安全的生态。华为云数据库业务总裁苏光牛发表主题演讲持续战略投入，软硬协同 云数据库作为人才密集型领域，对从业人员要求很高。为统一人才培育，华为云GaussDB布局全球7大区域研究所，拥有近千名数据库专业人才，坚持长期战略投入超过10年，有着强大的专家团和研发团队做后盾。除了人才统一，华为还统一底层DFV分布式存储架构，基于RDMA高速网络、分布式存储等底层硬件的积累和软硬协同，打造全栈硬核能力。生态全开源，聚力创新       华为云GaussDB基于融合开放理念，广泛兼容数据库开源生态和华为自主生态openGauss，并于今年6月正式开源openGauss社区版。openGauss作为GaussDB云数据库与内部配套的公共内核，将保持长期演进，同时减少低效重复造轮子，通过数据库发行伙伴快速形成应用生态体系，帮助数据库服务商复用产业长期积累的DBA人才，快速形成作战能力。服务全场景，助力客户轻松上云 华为云GaussDB提供了全场景、全开放的数据库生态选择，为客户量身打造了数据库架构+应用+数据一体化的迁移方案。华为云GaussDB不仅兼容关系型和非关系型数据库，还支持一众华为云数据库服务生态工具，面对全场景提供了高性能、高可用、极速扩展、稳定可靠的数据库能力，帮助政企客户选型安心、迁移放心、管理省心。千行百业锤炼极致能 华为云GaussDB覆盖全场景，遍布金融、政府、电信、能源、交通、物流、电商等行业，在500+大客户中规模商用，稳定性历经千行百业的考验，打造出了极致可靠、性能强劲的数据库能力，是金融政企客户核心数据上云的信赖之选。 未来，华为云GaussDB将持续开源开放，秉持开放、合作、共赢的态度，诚邀合作伙伴、高校、开发者等产学研共同发展，共创未来！同时积极构建技术硬实力和优秀解决方案，加速政企智能升级，普惠千行百业。  Ps：【11·11云数据库专场】深度剖析行业痛点，提供全套解决方案，云数据库2折起，ECS+MySQL组合购享折上9折，体验请前往华为云官网： https://activity.huaweicloud.com/dbs_Promotion/index.html

前言：磁盘使用率100%有多种场景，在此讨论一个主机故障长时间导致从备数据积压较多占满磁盘空间，对于此类问题如何处理。【处理思路】对于从备数据占满磁盘的场景，大体思路为首先保证集群为降级状态，若有从备实例异常不可用先修复从备实例，待集群处于降级状态后使用gs_replace修复故障节点，待故障节点修复后从备数据会自动清理。【问题描述&&场景判断】查看集群状态发现有一组实例的备机与从备都为disk damaged，此时需要先将从备实例修复让主机升主才能继续修复其他问题。【问题分析】登录04节点发现从备实例有1.4T的数据积压进入dummyslave4路径下查看磁盘使用情况如下：手动将base/dummystand路径下数据移至其他路径，修复从备实例。若对应主实例处于promoting状态，手动让主实例强制升主（其他场景慎用）。kill -9 pid; sleep 5;gs_ctl notify -M primary -D按照以上方式将集群修复至降级状态，使用gs_replace修复故障实例即可。

GaussDB核心能力大揭秘，华为云在ACMUG技术沙龙聊了啥11月18日下午，由ACMUG中国MySQL用户组主办的 “华为云专场” 技术沙龙在北京进行，华为云数据库业务总裁苏光牛及多位技术专家在会上分享了华为云数据库重磅新品GaussDB的核心能力与竞争优势，并表示华为云会不断进行技术创新，满足客户多样化需求，激发数据新动能，推动千行百业智能升级。苏光牛提到：未来云数据库会朝多元化、开放融合、云原生分布式方向发展，智能运维与自治数据库会大有可为。云数据库需要根据市场变化和客户需求，不断进行产品和技术创新，解决数据库卡脖子的问题，以领先的技术和服务推动云数据库跃迁式发展。华为云数据库会以全新品牌GaussDB为站点，面向全场景，服务全行业，持续创新，打造企业级云数据库服务。ACMUG华为云专场数据库技术闭门讨论会现场图华为云数据库资深内核专家饶珑辉，对华为云MySQL系列产品若干内核特性进行了分享。如云数据库RDS for MySQL提供的全量SQL日志、连接线程池、SQL防火墙、热点更新优化、表回收站、复制双通道等能力优势。华为云新一代高性能企业级分布式数据库GaussDB(for MySQL) 除具备RDS for MySQL所有能力外，还提供了高达128TB的海量存储，支持1写15读的只读节点极速扩展，可实现超百万级QPS吞吐，完全兼容MySQL，单节点相比原生MySQL性能提升7倍，支持跨AZ部署，数据0丢失。华为云数据库产品总监张昆，分享了华为云数据库GaussDB的产品革新与实践。他提到，云、AI、5G等技术驱动数据库行业新需求，云数据库不断演进升级。依托华为云与华为云Stack，通过全栈软硬件优化，华为云GaussDB进行了进阶与革新，以统一的分布式架构，支持关系型与非关系型的数据库引擎，并分享了GaussDB在金融、电商、游戏等行业中的优秀实践。在关系型领域，GaussDB除支持华为开源生态openGauss外，也100%兼容MySQL和PostgreSQL开放生态，存储容量更大，性能更优，适用于企业多样化的数据库应用场景。非关系型领域，GaussDB 100%支持MongoDB、Cassandra、Redis、InfluxDB等NoSQL协议接口，提供极致性能、企业级可靠性、灵活全托管等服务能力。华为云数据库资深内核专家范逸鸣，分享了华为云GaussDB社区及商业版的关键特性。GaussDB是华为云深度融合数据库领域多年经验，结合企业级场景需求，推出的新一代企业级分布式数据库。openGauss社区版以集中式主备部署为形态，继承GaussDB稳定可靠、高性能、丰富特性等优势，同时积极参与openGauss社区，保持长期演进。GaussDB商业版架构上着重构筑传统数据库的企业级能力和互联网分布式数据库的高扩展和高可用能力，在支撑传统业务的基础上，持续构建高性能、高安全、生态兼容等竞争优势，为企业面向5G时代的挑战，提供了无限可能。此外，华为云数据库MySQL生态域研发总监肖永，还结合客户实践讲述了GaussDB(for MySQL)从云化到Cloud Native的演进之路。他表示：数据库已经发展了三十多年，传统数据库架构在新的介质、需求下已经有所瓶颈，同时客户业务不断进化，大数据量、中心化处理趋势明显。针对变化，华为基于自身上云经验，在下一代存储DFV上打造了企业级Cloud Native数据库产品GaussDB(for MySQL) ，基于存算分离的分布式架构提供了优于开源MySQL 7倍性能、故障闪恢复、分钟级快速备份和恢复TB级数据等能力。基于丰富的产品线和优秀的技术能力，华为云数据库服务已在500+大客户中规模商用，遍布金融、政府、电信、能源、交通、物流、电商等行业。未来，华为云数据库将持续构建技术硬实力和优秀解决方案，使能行业数字化转型。Ps：错过直播的小伙伴们，可以点击链接回顾：cid:link_0

请问一下GaussDB100如何通过连接池连接数据库（希望有具体步骤），创建的DataSource能使用JDBCTemplate吗？球球各位大神解答。

        伴随5G、大数据、AI、IoT的飞速发展，数据呈现大规模、多样性的极速增长，为了应对多变的业务诉求，政企客户对数据处理分析的实时性和融合性提出了更高的要求，“湖仓一体”的概念应运而生，它打破数据湖与数仓间的壁垒，使得割裂数据融合统一，减少数据分析中的搬迁，实现统一的数据管理。华为云CTO张宇昕在2020HAS上提出“湖仓一体”概念        早在2020年5月份的华为全球分析师大会上，华为云CTO张宇昕提出了“湖仓一体”，在刚结束的HC2020上，张宇昕在发布新一代智能数据湖华为云FusionInsight时再次提到了湖仓一体。那我们就来看看湖仓一体的来世今生。数据湖和数据仓库的发展历程和挑战        早在1990年，比尔·恩门（Bill Inmon）提出了数据仓库，主要是将组织内信息系统联机事务处理(OLTP)常年累积的大量资料，按数据仓库特有的资料储存架构进行联机分析处理(OLAP)、数据挖掘(Data Mining)等分析，帮助决策者快速有效地从大量资料中分析出有价值的资讯，以利决策制定及快速响应外在环境变化，帮助构建商业智能(BI)。        大约十年前，企业开始构建数据湖来应对大数据时代，它通常把所有的企业数据统一存储，既包括源系统中的原始副本，也包括转换后的数据，比如那些用于报表, 可视化, 数据分析和机器学习的数据。        纵观数据湖与数据仓库的技术发展，不难发现两者有着各自的优劣，具体表现如下：特性数据湖数据仓库数据源来自 IoT 设备、网站、移动应用程序、社交媒体和企业应用程序的非关系和关系来自交易系统、运营数据库和业务线应用程序的关系Schema在分析时写入（读取型 Schema）在 DW 实现之前设计（写入型 Schema）性价比低成本存储获得较快的查询结果较高成本的存储获得最快的查询结果数据质量任何可以或无法进行监管的数据 (例如原始数据)可作为重要事实依据的高度监管数据用户数据科学家、数据开发人员、业务分析师业务分析师分析机器学习、预测分析、数据发现和描述批处理报告、BI 和可视化        企业在进行系统架构设计选型时，需要从具体的分析场景出发，单一的模式已经无法满足企业发展的业务诉求，集中表现在以下两个痛点：湖仓对比, 各有千秋数据湖主要以离线批量计算为主，因为不支持数据仓库的数据管理能力，难以提高数据质量；数据入湖时效差不支持实时更新，数据无法强一致性；主题建模不友好，无法直接历史拉链建模；同时交互分析通常将数据搬迁到数据仓库平台，造成分析链路长，数据冗余存储；批&流等场景融合不够，无法满足企业的海量数据处理诉求。数据仓库满足不了非结构化数据的分析需求，性价比不高；同时仓&湖间难以互联互通，数据协同效率较低，无法支持跨平台透明访问，形成了事实上的数据孤岛，找数困难；缺乏全局数据视图，不同平台接口差异和不同开发管理工具，造成用户开发使用复杂，数据分别管理维护代价高体验差。数据湖和数据仓库正在从两条技术演进路线走向融合        综上，数据湖和数据仓库在企业数据分析场景分别承担一湖一仓的重要角色，形成了完整的数据分析生态系统，上述企业场景面临的2个关键痛点也在驱动数据湖和数据仓库在技术演进上走向融合：        第一个融合方向是基于Hadoop体系的数据湖向数据仓库能力扩展，湖中建仓，从DataLake进化到LakeHouse。LakeHouse结合了数据湖和数据仓库特点，直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。目前业界已经涌现了一些LakeHouse产品，如Netflix开源Iceberg、Uber开源Hudi、Databricks的 DeltaLake。从DataLake进化到LakeHouse，数据湖扩展数仓能力         以目前生态发展迅速的Apache Hudi为例：统一数据存储，分布式存储不同应用所需的各种类型数据；数仓模式执行和治理，实现事务&更新机制，保证数据完整性和一致性，具有健壮的治理&审计机制；支持各种分析引擎，统一数据存储通过开放和标准化的存储格式（如Parquet），提供API以便各类工具和引擎（包括机器学习和Python / R库）直接有效地访问数据。        虽然LakeHouse并不能完全替代数据仓库，但通过增强性能，支持实时入湖、建模、交互分析等场景，将在企业分析环境中发挥更大作用。        第二个融合方向是数据湖和数据仓库协同起来向湖仓一体的融合分析架构发展，随着企业数据量快速增长，不仅是结构化数据，也有非结构化数据，同时提出了对搜索/机器学习更多的能力要求，使得原来数仓技术不能够有效的处理复杂场景，为此需扩展原有系统，引入Hadoop大数据平台实现新类型数据、新业务场景的支持。在这个背景下由Gartner在2011年提出逻辑数据仓库的概念，预测企业数据分析倾向于转向一种更加逻辑化的架构，利用分布式处理、数据虚拟化以及元数据管理等技术，实现逻辑统一物理分开的协同体系。逻辑数仓的高阶架构        湖仓一体可以认为是逻辑数据仓库架构理念下针对Hadoop数据湖和MPPDB数据仓库的融合架构的最好诠释，数据对用户将完全实现虚拟化，以逻辑统一的数据分析系统为企业提供数据分析服务：        用户使用层面提供统一元数据管理和数据视图，实现全局数据可见可查，支持标准统一访问接口简化用户开发，提供统一开发和治理的工具体系。        平台层面Hadoop与MPPDB具备数据共享和跨库分析能力，支持互联互通、计算下推、协同计算，实现数据多平台之间透明流动。华为云FusionInsight湖仓一体解决方案参考架构           华为云FusionInsight智能数据湖涵盖了分布式存储、大数据、数据仓库、数据治理等，融合了上述两个技术演进方向，为企业用户提供云原生湖仓一体解决方案，整体的参考架构如下：华为云FusionInsight湖仓一体解决方案参考架构        下面一起来看看：        数据存储层：通过OBS统一管理湖&仓的存储底座，将存储在EC（Erasure Code纠错码）、可靠性方面的优势融入进了大数据生态：云原生架构领先：基于云原生架构的OBS存储，具有高带宽，大并发，分布式元数据等特征，因此相同成本的华为存算分离的湖仓一体化集群，数据读写性能领先业界30%。存储计算分离有效降低TCO：支持大比例EC, 副本数从3最低可降低至1.09，TCO下降20%+。统一元数据管理实现湖仓共享存储资源池：通过独立的Data Lake Catalog提供统一元数据管理，兼容Hive Metastore接口，可以无缝对接各类大数据组件。实现针对同一份元数据定义支持各类场景、对象、文件、大数据等不同协议间的数据共享，让数据仓库、数据湖、图引擎、AI等多种计算引擎共享统一的数据存储池。此方案不仅消除了孤立系统中的数据副本，还使得客户可以按照业务按需使用计算存储资源，不仅降低了CAPEX，还简化了运维，从而达成最佳TCO。同时，Data Lake Catalog开放接口，支持和第三方的计算引擎层、数据治理层对接。        计算引擎层：把事务能力引入数据湖，通过HetuEngine标准SQL实现跨域多源统一访问，湖&仓数据互通协同计算，数据免搬迁：CarbonData & Hudi数据实时入湖，实现数据湖事务能力：企业内部许多数据管道通常会并发读写数据，我们通过CarbonData& Hudi数据存储引擎实现数据实时、增量更新，数据T+0实时入湖，大幅缩短传统T+1、T+2时延；引入的增量处理框架，实现了数据湖事务能力，支持入湖过程中的Update/Delete等。HetuEngine支持跨源跨域统一SQL访问，简单易用：用户层基于统一的标准SQL接口，对接多个数据源（HDFS, HBase, DWS等），提供秒级交互式访问，满足各种统计分析、多表Join关联等，让分析建模人员数据分析更容易，降低访问门槛。HetuEngine & DWS-Express打破数据墙，数据免搬迁创新更敏捷：支持数据湖与数据仓库间的数据互联互通、跨平台协同计算，数据免搬迁。HetuEngine在湖内基于统一数据目录，实现高并发，高性能的交互式查询，基于一份数据进行批、流、交互式融合分析，贴源加工、整合关联、主题加工等都在湖内，数据不出湖，分析链路短，加速业务创新；用户可使用DWS-Express提供由成百上千节点组成的加速集群，对存储在OBS上的海量数据进行在线分析，相比本地托管集群，效率提升数百倍。自研Superior调度器支持单集群2万+节点规模，业界最佳：在一个集群内，通过华为自研的Superior调度器支持各种工作负载统一调度，包括数据科学、机器学习以及SQL和分析，调度速率达35万Container/s，资源利用率达90%+，大幅降低企业投入成本。数据冷热分级存储实现更高效的全生命周期管理：DWS具备与OBS的双向互通的能力，既能直接读取OBS上的海量历史数据，也能够直接写入数据到OBS。通过这个特性，我们可以对企业中的海量数据进行更加高效的全生命周期管理，分析中经常使用到的热/温数据存放在DWS中，较少使用的冷数据存放到OBS中，兼顾企业对分析性能和存储经济性的诉求。无缝衔接AI挖掘更多数据价值：深度优化一站式开发平台ModelArts&分布式图计算引擎GES提高开发效率。提供基于数据湖的AI训练推理能力，减少数据搬迁次数，基于100+机器学习算子和NLP算法，实现海量数据快速价值挖掘，满足场景预测、自然语言处理及企业知识图谱等应用； 让GES更快捷地为金融等场景提供关系网络分析等服务。        运营管理层：通过DAYU实现了湖&仓统一的数据集成、开发、目录、治理、开放服务等的运营管理：数据集成：实现多源异构数据高效入湖，支持批/流/实时数据多种方式接入。其中，批量数据迁移基于分布式计算框架，利用并行化处理技术，支持用户稳定高效地对海量数据进行移动，实现不停服数据迁移，快速构建所需的数据架构；流和实时数据接入每小时可从数十万种数据源（例如日志和定位追踪事件、网站点击流、社交媒体源等）中连续捕获、传送和存储数TB数据。数据开发：提供一站式敏捷数据开发平台，提供可视化的图形开发界面、丰富的数据开发类型（脚本开发和作业开发）、全托管的作业调度和运维监控能力，内置行业数据处理pipeline，一键式开发，全流程可视化，支持多人在线协同开发，支持管理多种大数据云服务，极大地降低了用户使用大数据的门槛，帮助用户快速构建数据湖数据处理中心。数据治理：为企业提供数据体系标准和数据规范定义的方法论，统一数据语言和数据建模；为普通业务人员提供高效、准确的数据搜索工具，高效找到数据；提供技术元数据与业务元数据的关联，业务人员快速读懂数据；为数据提供有效的质量管控和评估手段，数据可信质量高。数据开放：为数据湖搭建统一的数据服务总线，帮助企业统一管理对内对外的API服务，支撑业务主题/画像/指标的访问、查询和检索，提升数据消费体验和效率；支持100+开放API，拥有10+行业模板，使能行业ISV快速集成，助力客户数据标准资产沉淀。        综上所述，正是在三层架构都打通了湖仓的技术壁垒，我们才看到了真正的湖仓一体：        数据存储层基于云原生领先架构，存算分离有效降低TCO，统一元数据管理实现湖仓共享存储资源池，针对同一份元数据定义支持各种场景，提供API方便各类工具和引擎（包括机器学习、Python、R等）直接有效地访问数据，这是实现湖仓一体的一个关键点；        计算引擎层为数据湖增加了事务能力提升了数据质量；利用HetuEngine通过标准SQL访问跨域多源数据，实现湖&仓数据关联分析协同计算，简单易用; 打破数据墙，在湖内基于统一数据目录，可基于数据湖实现融合分析&AI训练推理，减少数据搬迁，实现海量数据快速价值挖掘。        运营管理层则提供统一的数据开发和治理环境，具备安全管理功能，支持多引擎任务统一开发和编排，数据统一建模和质量监测，实现湖仓一致的开发治理体验。未来展望        华为云FusionInsight智能数据湖基于客户需求和技术演进趋势持续创新，为企业客户提供湖仓一体解决方案，致力于打造业界最佳的数据底座，让企业业务的创新更敏捷，业务洞察更准确，加速释放数据价值，和数据使能协同更好地服务千行万业！

近日，由中国信通院主办的“2020云原生产业大会”在北京隆重召开。大会公布了首批云原生数据库评估结果，华为云GaussDB数据库服务通过可信云权威认证，成为国内云原生数据库领域首批通过可信云认证的云服务厂商之一。随着云计算的快速发展和深入应用，广大用户更加聚焦于发挥云计算的效能，以云数据库为代表的云原生技术蓬勃发展，促进了越来越多的企业核心业务切换上云。为了更好推动云原生实践落地和数字化转型，信通院发布了业内首个云原生数据库服务能力的测评结果。此次测评范围涉及数据库基础能力、平台可观测能力、资源管理能力、服务可用性、数据可靠性、服务安全、计量计费能力和数据库性能等，客观真实的反映了云原生数据库的服务能力。那么华为云GaussDB数据库是凭借什么获得这项殊荣呢？极致架构成就硬核实力华为云GaussDB数据库统一基于华为最新一代DFV分布式存储，遵循“日志即数据”的原则，采用计算存储分离的架构，所有计算节点共享一份数据，提供分钟级配置升降级、秒级扩容能力、秒级故障恢复、数据强一致性，既拥有商业数据库的高性能和可靠性，又具备开源数据库的灵活性。华为云GaussDB基于存算分离架构构建的技术实力和相关研究成果，在2020年被SIGMOD、SSDBM等国际顶级数据库会议多次收录，有着强有力的技术权威背书。 聚焦全场景，服务全行业GaussDB数据库作为华为云倾力打造的新一代数据库服务，覆盖关系型和非关系型场景，依托华为云与华为云Stack，持续为客户提供更高可用、高可靠、高安全的数据库解决方案。在关系型领域，GaussDB除支持华为开源生态openGauss外，还分别推出了100%兼容MySQL和PostgreSQL开放生态的GaussDB(for MySQL)和GaussDB(for PostgreSQL)，存储容量最高可达128TB，性能最高提升7倍，1写15读，百万级QPS吞吐，适用于企业多样化的数据库应用场景。非关系型领域，GaussDB 100%支持MongoDB、Cassandra、Redis、InfluxDB等NoSQL协议接口，提供极致性能、企业级可靠性、灵活全托管等服务能力。华为云数据库涵盖丰富的行业应用场景，覆盖政府、金融、电商、互联网、物流、汽车、保险、游戏、交通等各个领域 ，目前已累计服务超过500家大型政企客户。云原生时代下，华为云GaussDB会凭借华为软硬件优势，以及云+AI+5G的助力，构建更加高性能、安全可靠的云原生数据库，加速更多企业实现数字化转型。【11·11云数据库专场】深度剖析行业痛点，提供全套解决方案，爆款产品低至2折，ECS+MySQL组合购还可享折上9折！更多惊喜猛戳→https://activity.huaweicloud.com/dbs_Promotion/index.html

UNIONUNION指令的目的是将两个SQL语句的结果合并起来，从这个角度来看，UNION跟JOIN有些许类似。但UNION的一个限制是两个SQL语句所产生的结果列需要是保持一致。另外，UNION执行过程中会对结果进行去重处理，最终结果返回的是不同的值(类似SELECTDISTINCT)。UNION ALLUNION ALL这个指令的目的也是要将两个SQL语句的结果合并在一起。UNION ALL和UNION的处理方式基本一致，所需的限制也是相同，不同之处在于UNION ALL不会对结果进行去重操作，只会将每一个符合条件的结果都列出来，无论结果值有无重复。INTERSECT同样和UNION指令类似，INTERSECT也是对两个SQL语句所产生的结果做处理的。不同的地方是，UNION在处理逻辑上是一个OR的关系(如果这个值存在于第一句或是第二句，它就会被选出)，而INTERSECT的处理逻辑则是AND的关系(这个值要存在于第一句和第二句才会被选出)。简而言之，UNION是并集，而INTERSECT是交集。MINUSMINUS指令同样是运用在两个SQL语句上。它先找出第一个SQL语句所产生的结果，然后看这些结果有没有在第二个SQL语句的结果中，如果有的话，那这一个结果就被去除，而不会在最后的结果中出现，如果没有则会在最终结果显示。第二个SQL语句所产生的结果不管是不是在第一个SQL的结果中都不会在最终结果中显示。MINUS指令即相当于SQL1与SQL2的差集。上面四种关联的语法均相同，如下格式：[SQL 语句 1]UNION | UNION ALL | INTERSECT | MINUS[SQL 语句 2]共同的限制点都是SQL 语句 1与SQL 语句 2所返回的查询结果列需保持一致。

 摘要：全密态数据库，专门处理密文数据的数据库系统，数据以加密形态存储在数据库服务器中，数据库支持对密文数据的检索与计算。1、云数据库安全现状及问题伴随着云基础设施的快速增长和成熟，与之对应的云数据库服务也层出不穷。一方面，受益于云服务的便捷性传统企业加速业务上云，通过充分发挥云数据库特有的轻松部署、高可靠、低成本等优势降低企业运营成本，加速企业应用创新；另一方面，以苹果iCloud服务为代表的存储服务和云计算服务为移动消费者带来应用便捷性，利用云侧的数据库服务存储海量消费者的个人数据。云数据库俨然已成为数据库业务未来重要的增长点，绝大多数的传统数据库服务厂商正在加速提供更优质的云数据库服务。但无论是传统的线下数据库服务，还是日益增长的云数据库服务，数据库的核心任务都是帮助用户存储和管理数据，在复杂多样的环境下，保证数据不丢失、隐私不泄露、数据不被篡改以及服务不中断。这就要求数据库具备多层次的安全防御机制，用来抵抗来自内部和外部的恶意攻击行为。事实上，经过数据库的长期发展，已经构建了体系化的安全能力，比如通过数据库防火墙的入侵防御以及基于AI的攻击识别及智能防御，做到“攻不破”；通过在数据库服务端实现强认证机制，达到攻击者“进不来”；通过完善的权限管理模型、对象访问控制及校验机制做到恶意用户“拿不走”；通过数据加密存储机制或数据静态脱敏及动态脱敏机制实现对关键数据的保护，确保数据在被非法窃取后攻击者“看不懂”；通过多副本备份，融合区块链思想实现类账本系统能力，做到“改不了”；通过系统内部细粒度审计机制，记录用户操作行为，达到攻击行为“赖不掉”。除了传统数据库厂商本身在提升自己的能力外，许多专业化的评估测试机构也在帮助数据库厂商挖掘产品缺陷，加速完善数据库安全能力的构建，并出具专业化评估报告，作为第三方背书让用户“信得过”。这些成熟的安全技术手段，构建了数据库纵深防御的安全体系，保障数据库在应用中的安全。一个完整的防御架构如图1所示。图1：传统数据库多层级安全防御架构虽然数据库安全功能越做越强，但这些安全技术手段都是针对传统数据库所面临的威胁构建的。作为面向开放市场的云数据库服务，其所面临的风险相较于传统数据库更加多样化，更加复杂化，无论是应用程序漏洞、系统配置错误，还是恶意管理员都可能对数据安全与隐私保护造成巨大风险。云数据库，其部署网络由“私有环境”向“开放环境”转变，系统运维管理角色被拆分为业务管理员和运维管理员。业务管理员拥有业务管理的权限，属于企业业务方，而运维管理员属于云服务提供商。数据库运维管理员虽然被定义成系统运维管理，其实际依旧享有对数据的完全使用权限，通过运维管理权限或提权来访问数据甚至篡改数据；再者由于开放式的环境和网络边界的模糊化，用户数据在整个业务流程中被更充分的暴露给攻击者，无论是传输、存储、运维还是运行态，都有可能遭受来自攻击者的攻击。因此对于云数据库场景，如何解决第三方可信问题，如何更加可靠的保护数据安全相比传统数据库面临着更大挑战，其中数据安全、隐私不泄露是整个云数据库面临的首要安全挑战。当前云数据库数据安全隐私保护是针对数据所处阶段来制定保护措施的，如在数据传输阶段使用安全传输协议SSL/TLS，在数据持久化存储阶段使用透明存储加密，在返回结果阶段使用RLS(Row Level Security)或者数据脱敏策略。这些传统技术手段可以解决单点风险，但不成体系，且对处于运行或者运维状态下的数据则缺少有效的保护。面对越来越复杂的云环境，我们需要一种能够彻底解决数据全生命周期隐私保护的系统性解决方案。事实上，近年来学术界以及工业界陆续提出了许多创新思路：数据离开客户端时，在用户侧对数据进行加密，且不影响服务端的检索与计算，从而实现敏感数据保护，此时即便数据库管理员也无法接触到用户侧的密钥，进而无法获取明文数据。这一思路被称为全密态数据库解决方案，或全加密数据库解决方案。2、全密态数据库与数据全生命周期保护全密态数据库，顾名思义与大家所理解的流数据库、图数据库一样，就是专门处理密文数据的数据库系统。数据以加密形态存储在数据库服务器中，数据库支持对密文数据的检索与计算，而与查询任务相关的词法解析、语法解析、执行计划生成、事务ACID、数据存储都继承原有数据库能力。在全密态数据库机制下，一个用户体验良好的业务数据流图如下图1所示。假定数据列c1已以密文形态存放在数据库服务端，用户发起查询任务指令。用户发起的查询任务无需进行特殊化改造，对于查询中涉及的与敏感数据c1相关联的参数，在客户端按照与数据相同的加密策略(加密算法，加密密钥等)完成加密，如图1中关联参数“123”被加密成“0xfe31da05”。参数加密完成后整个查询任务被变更成一个加密的查询任务并通过安全传输通道发到数据库服务端，由数据库服务端完成基于密文的查询检索。检索得到的结果仍然为密文，并最终返回客户端进行解密。图2：全密态数据库核心业务数据流根据该业务数据流可以看出，全密态数据库的核心思想是：用户自己持有数据加解密密钥且数据加解密过程仅在客户侧完成，数据以密文形态存在于数据库服务侧的整个生命周期过程中，并在数据库服务端完成查询运算。由于整个业务数据流在数据处理过程中都是以密文形态存在，通过全密态数据库，可以实现：(1)保护数据在云上全生命周期的隐私安全，无论数据处于何种状态，攻击者都无法从数据库服务端获取有效信息；(2)帮助云服务提供商获取第三方信任，无论是企业服务场景下的业务管理员、运维管理员，还是消费者云业务下的应用开发者，用户通过将密钥掌握在自己手上，使得高权限用户无法获取数据有效信息；(3)使能合作伙伴，通过全密态数据库可以让合作伙伴借助全密态能力更好的遵守个人隐私保护方面的法律法规。3、全密态数据库核心思路与挑战正如全密态数据库定义所描述的那样，全密态数据库的核心任务是保护数据全生命周期安全并实现基于密文数据的检索计算。在加密算法足够安全的情况下，外部攻击者及内部管理员均无法获取有效的数据信息。对于用户来说，从已有数据库服务切换成全密态数据库或者直接将应用部署于全密态数据库，需要解决三个主要的问题：(1)如何保障密态计算机制的安全性，全密态数据库从原理上可以有效保障数据安全，但这要求密文数据检索及运算的算法在机理和工程上要达到该原理要求；(2)如何进行业务的无缝迁移或者轻量化迁移，全密态数据库最显著的特征是数据存储信息的变更，那与加密数据相关的各类参数都要同步进行变更，否则会因为计算数据形态的不对等导致查询紊乱；(3)如何避免服务切换所带来的性能损耗，本质上需要将加密算法实现和工程实现所产生的性能回退控制在一个合理的范围内，避免因为不合理的数据加解密和数据存储膨胀带来性能急速下降。只有解决这三个关键问题，才能真正的推动全密态数据库落地。目前，全密态数据库在学术界和工业界均有研究和尝试，主要聚焦于两种解决方案：(1)密码学解决方案，或称为纯软解决方案，通过设计满足密文查询属性的密码学算法来保证查询的正确性，如已知常见的OPE(Order Preserving Encryption)算法，数据加密后仍保留顺序属性;(2)硬件方案，通过可信执行环境(TEE, Trusted Execution Environment)来处理REE(Rich Execution Environment，REE与TEE相对应)环境中的密文数据运算，图3展示了ARM架构下的TEE与REE的对应关系。无论是密码学解决方案还是现有的硬件方案都有他们各自的优缺点。图3：REE与TEE逻辑关系图密码学方案的核心思路是整个运算过程都是在密文状态，通过基于数学理论的算法来直接对密文数据进行检索与计算。该方案需要解决在用户不感知的条件下，实现密文数据的安全、高效检索与计算，当前的主要挑战在两个方面：一方面学术界当前主要的密码学算法，大部分都是基于功能实现及安全能力的考虑，对于内外存储、网络吞吐、计算消耗等性能指标都会有不同的劣化，甚至有些性能完全脱离了实际场景，因此如何能在数据密文状态下实现检索和计算，并且满足性能要求，是密码学方案的最大挑战；另一方面，通常一种数学算法只能解决部分业务场景，如何将多种密码学算法融合，以实现数据库查询和计算的主要功能，也是密码学方案的一大挑战。硬件方案的核心思路是将存放于REE侧的加密数据传递给TEE侧，并在TEE侧完成数据解密和计算任务(见图3)，依赖TEE的“隔离性”或“对REE侧应用的不可见性”实现数据计算过程的安全保护。一方面，受限于TEE空间的大小（如SGX v1仅提供128MB可用空间、基于ARM TrustZone方案一般也仅提供几十MB空间），难以处理大量数据和复杂操作，这就要求TEE内仅关注关键敏感数据的查询操作，降低攻击面；另一方面由于REE与TEE运行切换和数据交互带来额外的开销，因此需要解决整个运算过程中的REE与TEE的计算资源分配与高效调度问题，也是硬件方案面临的一大挑战。4、GaussDB(openGauss)全密态数据库解决方案4.1 开创性自适应架构打造首款支持软模式密态计算全密态数据库中的软件方案和硬件方案目前均已取得了很多进展，特别的，工业界已开始在逐步采用硬件方案。借助诸如Intel SGX等安全硬件的TEE空间，对数据计算空间进行物理或逻辑隔离，实现数据对REE的“不可见”。但硬件方案目前存在两个较大的缺陷：首先由于数据在TEE内部均为明文存在，因此数据的安全性完全依赖于硬件本身的安全性。目前针对硬件的攻击方式如侧信道攻击等越来越多，但是一般硬件设备更新迭代周期较长，一旦出现漏洞无法及时更新修补，将直接导致用户数据长时间暴露在风险之下。其次用户在使用该特性时，密钥需要离开客户端环境发送给TEE使用，而该传输过程的安全直接依赖于硬件设备厂商的证书签名，恶意的硬件设备厂商人员完全有能力攻击并窃取用户的数据及密钥，因此硬件方案，也需要用户在使用过程中，持续信任硬件设备厂商。全密态数据库的软件方案目前在学术界发展较快，通过一系列数学算法在密文空间直接对密文进行查询运算，保障数据隐私不泄露。软件方案可以不依赖于硬件能力，也不需要在服务侧获取密钥对数据进行解密，但当前也存在着在第三章节提到的巨大挑战。图4：GaussDB全密态数据库架构在华为全连接大会上，华为正式发布基于GaussDB的全密态数据库解决方案，该方案结合软件模式与硬件模式各自的优缺点，推出融合策略，实现硬件模式和软件模式的自由切换，该方案支持全场景应用，包括公有云、混合云以及终端智慧业务，更为重要的是对终端用户透明无感知。在硬件模式下，GaussDB首先支持多硬件平台能力，如Intel CPU的SGX能力，以及业内首创的华为自主研发鲲鹏ARM TrustZone能力。其次GaussDB实现了最小粒度的隔离级别，使得攻击面最小化，并且通过一系列的密钥安全保障机制，如多层密钥管理体系、可信传输通道、会话级密钥管理机制等，实现了硬件环境中的数据及密钥安全，从而降低因硬件安全问题而导致的用户数据及密钥泄露风险。由于硬件模式依赖于硬件及其生产厂商的安全和信誉，且用户在实际使用过程中需要依赖特性硬件环境，GaussDB还开创性的支持了软件模式的密态查询能力，通过对多种密码学算法的深度性能优化，构建出不同的密态查询引擎，以完成不同的检索和计算功能，实现数据等值查询、范围查询、保序查询、表达式计算等特性。特别的，通过引入确定性加密机制，实现了数据的增删改查、表字段关联、等值检索等基本操作；基于GS-OPE算法的密文索引技术，实现了数据密态保序查询、表达式大小比较等常规操作；通过Range-Identify算法，实现数据密态范围查询。GaussDB 全密态数据库解决方案创新性的解决了多个技术难点，实现了对用户无感知、数据加密无泄漏等核心竞争力。4.2 全自动加密驱动实现用户数据库操作无感知要实现在客户端进行加解密，无疑需要在客户端进行大量维护管理，包括数据密钥管理，敏感数据加密，解析和修改SQL语句等。如果仅仅提供数据加密工具，由用户来对数据进行显式加密，一方面会增加用户的开发成本，另一方面用户也容易因数据加密不到位而造成数据泄露。GaussDB将这一系列的复杂操作，全部封装在客户端加密驱动中，实现了完全自动化的敏感信息加密替换，同时在数据库中存储了所有加密相关的元信息，使得数据库可以很好的识别和处理对应的加密数据。如图5所示，由于SQL语句中与敏感信息相关的参数也被加密处理，使得发送至数据库服务侧的查询任务(图中ciphertext query)也不会泄露用户查询意图，减少客户端的复杂安全管理及操作难度，实现用户应用开发无感知。另外，GaussDB提供一系列的配置接口，满足用户对加密字段、加密算法、密钥安全存储等不同场景的需要。GaussDB全密态数据库的透明性使得用户在任务迁移时将获得极大的便捷性。图5：全自动客户端加密驱动4.3 利用算子级隔离显著降低安全风险当密文查询进入数据库内核之后，就需要依赖现有的查询处理模块来完成数据运算。对数据库这种高度复杂的系统，在硬件模式下，如何将敏感数据的检索、计算等核心功能解耦隔离，放在安全环境中独立运行，从而最小化敏感数据计算面临的安全风险，一直是GaussDB的一个重大难题。图6：主流硬件隔离方案当前业界主要有三种TEE隔离计算方案：数据库级隔离、模块级隔离、算子级隔离。这三种方案从攻击面和工程实现维度来看，有显著的差异。数据库级隔离，是在TEE中完整的建立一个特殊的数据库引擎，将敏感数据的查询请求直接发送给该数据库进行全部的解析和执行处理。该方案的架构比较清晰，实现简单，安全性和可靠性直接依赖于TEE中数据库的能力。然而，由于TEE中数据库引擎的代码规模较大，因此数据库实例需要消耗更多的TEE侧资源，且一旦由于潜在代码缺陷导致在执行过程出现严重错误，将导致出现TEE环境崩溃等严重后果。模块级隔离，是将SQL执行器放到TEE中，实现对语句的执行过程进行保护。执行器是数据库查询语句的查询任务执行模块，与数据库级隔离相比，这种方式减小了TEE中的代码规模，其安全性主要依赖于执行模块的安全能力。但该方式下仍有大量与敏感数据计算无关的操作将在TEE中运行，而这些操作都可能接触到明文数据，故而容易引入错误或者无意泄露敏感数据，留下安全攻击隐患。算子级隔离。算子是机密数据计算的最小、最核心功能单元，如数据排序算子、表达式计算等。通过将密文算子放在TEE中执行，可以针对性的对敏感数据进行重点保护，排除非敏感数据操作带来的潜在风险，具有最小规模的代码实现。但是其难度和挑战并存：首先，数据库的复杂性决定了将敏感数据的单一算子执行过程进行解耦存在较大的挑战性，传统的pipeline执行流程意味着单个算子执行过程的连续性，针对算子执行过程中的核心计算流程进行解耦就需要进行定向梳理；其次单个查询语句通常涉及多个算子运算，整个查询运算流程需要根据算子运算需求多次切换到TEE侧环境，对性能造成影响。为了追求极致的安全，GaussDB选择了算子级隔离策略。为了解决算子级隔离的两大问题，GaussDB全密态数据库通过精心设计，成功实现了最小粒度的敏感数据检索和计算模块。同时，从多个层面对REE与TEE之间的world switch的性能和数据传输方式进行深度优化，将性能影响降到最低。从而在显著减小安全风险的同时，也有力地保障了数据库系统的高效运行。4.4 高强度密钥体系保障密钥安全整个全密态数据库解决方案中除数据本身具有敏感性质外，最为敏感的信息就是数据加解密密钥，一旦密钥泄露，将给用户数据带来严重风险。特别是在硬件模式下，密钥需离开用户侧，传输到云侧可信硬件环境中，其安全保护至关重要。GaussDB通过实现三层密钥体系，让各层密钥各司其职，真正做到密钥高强度的安全保护。图7：GaussDB高强度密钥体系第一层为数据密钥，做到了字段级别，即针对不同的字段将采用不同的密钥，同时对相同字段不同数据采用不同的盐值，以实现不同字段之间的加密隔离，即使某一列数据的加密密钥被泄露，也不会影响到其他数据安全，提升整体数据的安全性。第二层为用户密钥，对不同用户将使用不同的密钥，以实现用户之间的加密隔离，而且用户密钥永远不会离开用户可信环境；使得包括管理员在内的其他用户，即便窃取了数据的访问权限，也无法解密最终数据。第三层为设备密钥，即对不同的密钥存储设备或工具，使用不同的密钥进行保护，实现设备间的加密隔离，大大增加了攻击用户密钥存储设备或工具破解密钥的难度。不仅如此，由于在硬件模式下，需要将字段级密钥传输给硬件TEE环境使用。GaussDB在该场景下进行了更高强度的保护措施：首先，通过ECCDH协议安全协商和TEE内置证书签名校验，构建用户侧与TEE环境之间的可信通道，保证密钥安全可信的加密传输，防止中间人攻击；其次，密钥不会以任何形式离开TEE环境，只在会话期间存在，结束立刻释放，最小化数据密钥生命周期，防止因代码漏洞或异常情况引起的密钥泄露。5、全密态数据库的未来全密态数据库技术理念抛开了传统的多点技术单点解决数据风险的问题，通过系统化思维建立了一套能够覆盖数据全生命周期的安全保护机制。这套机制使得用户在无感知的情况下就解决了数据的安全隐私保护，对于攻击者和管理者来说都无法获取有效信息。全密态数据库是数据库安全隐私保护的高级防御手段，但全密态数据库在当前仍存在一定的局限性，仍需要突破算法安全性和性能损耗等相关问题。全密态数据库在实际应用中建议仅针对敏感数据进行使用，通过借助于数据库本身提供的多方位数据保护机制，为不同等级的数据提供不同层级的安全机制，从而构建全方位的数据安全保护机制。未来GaussDB会将该能力逐步开源到openGauss，与社区共同推进和完善全密态数据库解决方案，一起打造数据库安全生态。

 摘要：那些会导致执行效率低下的SQL语句及其执行方式，我们称之为SQL中的“坏味道”。◆ 什么是SQL中的坏味道SQL语言是关系型数据库（RDB）的标准语言，其作用是将使用者的意图翻译成数据库能够理解的语言来执行。人类之间进行交流时，同样的意思用不同的措辞会产生不同的效果。类似地，人类与数据库交流信息时，同样的操作用不同的SQL语句来表达，也会导致不同的效率。而有时同样的SQL语句，数据库采用不同的方式来执行，效率也会不同。那些会导致执行效率低下的SQL语句及其执行方式，我们称之为SQL中的“坏味道”。下面这个简单的例子，可以说明什么是SQL中的坏味道。图1-a 用union合并集合在上面的查询语句中，由于使用了union来合并两个结果集，在合并后需要排序和去重，增加了开销。实际上符合dept_id = 1和dept_id > 2的结果间不会有重叠，所以完全可以用union all来合并，如下图所示。图1-b 用union all合并集合而更高效的做法是用or条件，在扫描的时候直接过滤出所需的结果，不但节省了运算，也节省了保存中间结果所需的内存开销，如下图所示。图1-c 用or条件来过滤结果可见完成同样的操作，用不同的SQL语句，效率却大相径庭。前两条SQL语句都不同程度地存在着“坏味道”。对于这种简单的例子，用户可以很容易发现问题并选出最佳方案。但对于一些复杂的SQL语句，其性能缺陷可能很隐蔽，需要深入分析才有可能挖掘出来。这对数据库的使用者提出了很高的要求。即便是资深的数据库专家，有时也很难找出性能劣化的原因。GaussDB在执行SQL语句时，会对其性能表现进行分析和记录，通过视图和函数等手段呈现给用户。本文将简要介绍如何利用GaussDB提供的这些“第一手”数据，分析和定位SQL语句中存在的性能问题，识别和消除SQL中的“坏味道”。◆ 识别SQL坏味道之自诊断视图GaussDB在执行SQL时，会对执行计划以及执行过程中的资源消耗进行记录和分析，如果发现异常情况还会记录告警信息，用于对原因进行“自诊断”。用户可以通过下面的视图查询这些信息：• gs_wlm_session_info• pgxc_wlm_session_info• gs_wlm_session_history• pgxc_wlm_session_history其中gs_wlm_session_info是基本表，其余3个都是视图。gs_开头的用于查看当前CN节点上收集的信息，pgxc_开头的则包含集群中所有CN收集的信息。各表格和视图的定义基本相同，如下表所示。表1 自诊断表格&函数字段定义其中的query字段就是执行的SQL语句。通过分析每个query对应的各字段，例如执行时间，内存，IO，下盘量和倾斜率等等，可以发现疑似有问题的SQL语句，然后结合query_plan（执行计划）字段，进一步地加以分析。特别地，对于一些在执行过程中发现的异常情况，warning字段还会以human-readable的形式给出告警信息。目前能够提供的自诊断信息如下：◇多列/单列统计信息未收集优化器依赖于表的统计信息来生成合理的执行计划。如果没有及时对表中各列收集统计信息，可能会影响优化器的判断，从而生成较差的执行计划。如果生成计划时发现某个表的单列或多列统计信息未收集，warning字段会给出如下告警信息：Statistic Not Collect:schemaname.tablename(column name list)此外，如果表格的统计信息已收集过（执行过analyze），但是距离上次analyze时间较远，表格内容发生了很大变化，可能使优化器依赖的统计信息不准，无法生成最优的查询计划。针对这种情况，可以用pg_total_autovac_tuples系统函数查询表格中自从上次分析以来发生变化的元组的数量。如果数量较大，最好执行一下analyze以使优化器获得最新的统计信息。◇SQL未下推执行计划中的算子，如果能下推到DN节点执行，则只能在CN上执行。因为CN的数量远小于DN，大量操作堆积在CN上执行，会影响整体性能。如果遇到不能下推的函数或语法，warning字段会给出如下告警信息：SQL is not plan-shipping, reason : %s◇Hash连接大表做内表如果发现在进行Hash连接时使用了大表作为内表，会给出如下告警信息：PlanNode[%d] Large Table is INNER in HashJoin \"%s\"目前“大表”的标准是平均每个DN上的行数大于100，000，并且内表行数是外表行数的10倍以上。◇大表等值连接使用NestLoop如果发现对大表做等值连接时使用了NestLoop方式，会给出如下告警信息：PlanNode[%d] Large Table with Equal-Condition use Nestloop\"%s\"目前大表等值连接的判断标准是内表和外表中行数最大者大于DN的数量乘以100，000。◇数据倾斜数据在DN之间分布不均匀，可导致数据较多的节点成为性能瓶颈。如果发现数据倾斜严重，会给出如下告警信息：PlanNode[%d] DataSkew:\"%s\", min_dn_tuples:%.0f, max_dn_tuples:%.0f目前数据倾斜的判断标准是DN中行数最多者是最少者的10倍以上，且最多者大于100,000。◇代价估算不准确GaussDB在执行SQL语句过程中会统计实际付出的代价，并与之前估计的代价比较。如果优化器对代价的估算与实际的偏差很大，则很可能生成一个非最优化的计划。如果发现代价估计不准确，会给出如下告警信息："PlanNode[%d] Inaccurate Estimation-Rows: \"%s\" A-Rows:%.0f, E-Rows:%.0f目前的代价由计划节点返回行数来衡量，如果平均每个DN上实际/估计返回行数大于100,000，并且二者相差10倍以上，则认定为代价估算不准。◇Broadcast量过大Broadcast主要适合小表。对于大表来说，通常采用Hash+重分布（Redistribute）的方式效率更高。如果发现计划中有大表被广播的环节，会给出如下告警信息：PlanNode[%d] Large Table in Broadcast \"%s\"目前对大表广播的认定标准为平均广播到每个DN上的数据行数大于100,000。◇索引设置不合理如果对索引的使用不合理，比如应该采用索引扫描的地方却采用了顺序扫描，或者应该采用顺序扫描的地方却采用了索引扫描，可能会导致性能低下。索引扫描的价值在于减少数据读取量，因此认为索引扫描过滤掉的行数越多越好。如果采用索引扫描，但输出行数/扫描总行数>1/1000，并且输出行数>10000（对于行存表）或>100（对于列存表），则会给出如下告警信息：PlanNode[%d] Indexscan is not properly used:\"%s\", output:%.0f, filtered:%.0f, rate:%.5f顺序扫描适用于过滤的行数占总行数比例不大的情形。如果采用顺序扫描，但输出行数/扫描总行数<=1/1000，并且输出行数<=10000（对于行存表）或<=100（对于列存表），则会给出如下告警信息：PlanNode[%d] Indexscan is ought to be used:\"%s\", output:%.0f, filtered:%.0f, rate:%.5f◇下盘量过大或过早下盘SQL语句执行过程中，因为内存不足等原因，可能需要将中间结果的全部或一部分转储的磁盘上。下盘可能导致性能低下，应该尽量避免。如果监测到下盘量过大或过早下盘等情况，会给出如下告警信息：• Spill file size large than 256MB• Broadcast size large than 100MB• Early spill• Spill times is greater than 3• Spill on memory adaptive• Hash table conflict下盘可能是因为缓冲区设置得过小，也可能是因为表的连接顺序或连接方式不合理等原因，要结合具体的SQL进行分析。可以通过改写SQL语句，或者HINT指定连接方式等手段来解决。使用自诊断视图功能，需要将以下变量设成合适的值：▲ use_workload_manager（设成on，默认为on）▲ enable_resource_check（设成on，默认为on）▲ resource_track_level（如果设成query，则收集query级别的信息，如果设成operator，则收集所有信息，如果设成none，则以用户默认的log级别为准）▲ resource_track_cost（设成合适的正整数。为了不影响性能，只有执行代价大于resource_track_cost语句才会被收集。该值越大，收集的语句越少，对性能影响越小；反之越小，收集的语句越多，对性能的影响越大。）执行完一条代价大于resource_track_cost后，诊断信息会存放在内存hash表中，可通过pgxc_wlm_session_history或gs_wlm_session_history视图查看。视图中记录的有效期是3分钟，过期的记录会被系统清理。如果设置enable_resource_record=on，视图中的记录每隔3分钟会被转储到gs_wlm_session_info表中，因此3分钟之前的历史记录可以通过gs_wlm_session_info表或pgxc_wlm_session_info视图查看。◆ 发现正在运行的SQL的坏味道上一节提到的自诊断视图可以显示已完成SQL的信息。如果要查看正在运行的SQL的情况，可以使用下面的视图：• gs_wlm_session_statistics• pgxc_wlm_session_statistics类似地，gs_开头的用于查看当前CN节点上收集的信息，pgxc_开头的则包含集群中所有CN收集的信息。两个视图的定义与上一节的自诊断视图基本相同，使用方法也基本一致。 通过观察其中的字段，可以发现正在运行的SQL中存在的性能问题。例如，通过“select queryid, duration from gs_wlm_session_statistics order by duration desc limit 10;”可以查询当前运行的SQL中，已经执行时间最长的10个SQL。如果时间过长，可能有必要分析一下原因。图2-a 通过gs_wlm_session_statistics视图发现可能hang住SQL查到queryid后，可以通过query_plan字段查看该SQL的执行计划，分析其中可能存在的性能瓶颈和异常点。图2-b 通过gs_wlm_session_statistics视图查看当前SQL的执行计划再下一步，可以结合等待视图等其他手段定位性能劣化的原因。图2-c 通过gs_wlm_session_statistics视图结合等待视图定位性能问题另外，活动视图pg_stat_activity也能提供一些当前执行SQL的信息。◆ Top SQL——利用统计信息发现SQL坏味道除了针对逐条SQL进行分析，还可以利用统计信息发现SQL中的坏味道。另一篇文章“Unique SQL特性原理与应用”中提到的Unique SQL特性，能够针对执行计划相同的一类SQL进行了性能统计。与自诊断视图不同的是，如果同一个SQL被多次执行，或者多个SQL语句的结构相同，只有条件中的常量值不同。这些SQL在Unique SQL视图中会合并为一条记录。因此使用Unique SQL视图能更容易看出那些类型的SQL语句存在性能问题。利用这一特性，可以找出某一指标或者某一资源占用量最高/最差的那些SQL类型。这样的SQL被称为“Top SQL”。例如，查找占用CPU时间最长的SQL语句，可以用如下SQL：select unique_sql_id,query,cpu_time from pgxc_instr_unique_sql order by cpu_time desc limit 10。Unique SQL的使用方式详见https://bbs.huaweicloud.com/blogs/197299。◆ 结论发现SQL中的坏味道是性能调优的前提。GaussDB对数据库的运行状况进行了SQL级别的监控和记录。这些打点记录的数据可以帮助用户发现可能存在的异常情况，“嗅”出潜在的坏味道。从这些数据和提示信息出发，结合其他视图和工具，可以定位出坏味道的来源，进而有针对性地进行优化

带业务均衡集群过程中可能会出现长时间切换不成功的问题造成集群不可用，集群均衡的原理以及碰到该问题如何进行恢复，详细见博文介绍。https://bbs.huaweicloud.com/blogs/203410