前言在日常数据库的使用中，难免会遇到一些内存问题。此次博文主要向大家分享一些华为云数仓GaussDB(DWS)内存的基本框架以及基本视图的使用，以便遇到内存问题后可以有一个基本的判断。注意，本篇博文基于华为云数仓GaussDB(DWS) 8.0版本，其他版本细节上或许稍有不同。内存常用视图1.   PV_TOTAL_MEMORY_DETAIL视图该视图会展示当前数据库节点的内存使用信息，单位为MB。视图中个字段的含义：nodename：节点名称，memorytype：内存类型，memorymbytes：对应内存类型的大小。常用的内存类型有以下几种：max_process_memory：取自GUC参数max_process_memory的配置，表示一个数据库节点最大可使用的物理内存。process_used_memory：取自/proc/pid/statm(第二个值) * pagesize，pid替换为当前节点所在的进程号。表示当前节点所处进程已使用的内存。max_dynamic_memory：由下面公式计算而来，表示Gaussdb内核所能使用的最大内存。max_dynamic_memory = max_process_memory- max_cstore_memory - udf_reserved_memory - max_shared_memory ;dynamic_used_memory：GaussDB内核已使用内存，由GaussDB内存管理在申请内存时统计而来。dynamic_peak_memory：GaussDB内核使用内存峰值，由GaussDB内存管理在申请内存时统计而来。dynamic_used_shrctx：GaussDB内核已使用线程间共享内存上下文内存大小，由GaussDB内存管理在申请内存时统计而来。dynamic_peak_shrctx：GaussDB内核已使用线程间共享内存上下文内存峰值，由GaussDB内存管理在申请内存时统计而来。max_shared_memory：进程间最大共享内存大小shared_used_memory：进程间已使用共享内存大小，由/proc/pid/statm(第三个值) * pagesize值统计而来。max_cstore_memory：列存允许的最大使用内存，由GUC参数cstore_buffers配置。cstore_used_memory：列存已使用内存，一般包含列存或HDFS使用过程中所消耗的内存。other_used_memory：通常表示除去GaussDB内核使用的内存以外的内存使用，通常是三方库使用所消耗的内存，例如LLVM，Kerberos等。postgres=# select * from  PV_TOTAL_MEMORY_DETAIL;    nodename   |       memorytype        | memorymbytes --------------+-------------------------+--------------  coordinator1 | max_process_memory      |        12288  coordinator1 | process_used_memory     |          240  coordinator1 | max_dynamic_memory      |        11564  coordinator1 | dynamic_used_memory     |          229  coordinator1 | dynamic_peak_memory     |          234  coordinator1 | dynamic_used_shrctx     |            1  coordinator1 | dynamic_peak_shrctx     |            1  coordinator1 | max_shared_memory       |          211  coordinator1 | shared_used_memory      |          139  coordinator1 | max_cstore_memory       |          512  coordinator1 | cstore_used_memory      |            0  coordinator1 | max_sctpcomm_memory     |            0  coordinator1 | sctpcomm_used_memory    |            0  coordinator1 | sctpcomm_peak_memory    |            0  coordinator1 | other_used_memory       |            0  coordinator1 | gpu_max_dynamic_memory  |            0  coordinator1 | gpu_dynamic_used_memory |            0  coordinator1 | gpu_dynamic_peak_memory |            0  coordinator1 | pooler_conn_memory      |            0  coordinator1 | pooler_freeconn_memory  |            0  coordinator1 | storage_compress_memory |            0  coordinator1 | udf_reserved_memory     |            0 (22 rows)2. PV_SESSION_MEMORY_DETAIL视图华为云数仓GaussDB(DWS)的内存管理框架沿用了之前的内存上下文的思路。在PV_SESSION_MEMORY_DETAIL的视图中，将会统计各线程的内存上下文维度统计的内存使用情况。视图中个字段的含义如下：Sessid：表示Session ID，由线程启动时间+线程标识拼接而来。Sesstype：线程名称Contextname：内存上下文名称。Level：内存上下文层级。Parent：父内存上下文名称。Totalsize：当前内存上下文内存大小Freesize：当前内存上下文已释放内存大小Usedsize：当前内存上下文已使用大小。postgres=# select * from PV_SESSION_MEMORY_DETAIL order by totalsize desc;            sessid           |        sesstype         |         contextname          | level |            parent            | totalsize | freesize | usedsize ----------------------------+-------------------------+------------------------------+-------+------------------------------+-----------+----------+----------  0.140169093357952          | postmaster              | Postmaster                   |     1 | TopMemoryContext             |  26566912 |    23912 | 26543000  0.140169093357952          | postmaster              | gs_signal                    |     1 | TopMemoryContext             |   4272464 |  2050224 |  2222240  1594694378.140168361137920 | WLMCollectWorker        | CacheMemoryContext           |     1 | TopMemoryContext             |   1455032 |   268488 |  1186544  1594694378.140168296134400 | WLMarbiter              | CacheMemoryContext           |     1 | TopMemoryContext             |   1455032 |   266696 |  1188336  1594694378.140168465999616 | JobScheduler            | CacheMemoryContext           |     1 | TopMemoryContext             |   1455032 |   239584 |  1215448  1594708276.140168270964480 | postgres                | CacheMemoryContext           |     1 | TopMemoryContext             |   1455032 |   316392 |  1138640  1594694438.140168207001344 | postgres                | CacheMemoryContext           |     1 | TopMemoryContext             |   1455032 |   329944 |  1125088  1594694378.140168344356608 | WLMmonitor              | CacheMemoryContext           |     1 | TopMemoryContext             |   1455032 |   269528 |  1185504  1594708276.140168270964480 | postgres                | TempSmallContextGroup        |     0 |                              |    550592 |   160320 |      114  1594694438.140168207001344 | postgres                | TempSmallContextGroup        |     0 |                              |    530816 |   148256 |      107  1594708276.140168270964480 | postgres                | SRF multi-call context       |     5 | FunctionScan_140168270964480 |    496704 |     8032 |   488672  1594694378.140168465999616 | JobScheduler            | TempSmallContextGroup        |     0 |                              |    489152 |   120672 |      102  1594694378.140168361137920 | WLMCollectWorker        | TempSmallContextGroup        |     0 |                              |    477184 |   118168 |       98  1594694378.140168344356608 | WLMmonitor              | TempSmallContextGroup        |     0 |                              |    477184 |   118280 |       98  1594694378.140168296134400 | WLMarbiter              | TempSmallContextGroup        |     0 |                              |    477184 |   118136 |       98  1594694438.140168207001344 | postgres                | TopMemoryContext             |     0 |                              |    460808 |    24728 |   436080  1594708276.140168270964480 | postgres                | TopMemoryContext             |     0 |                              |    452616 |     5352 |   447264  1594694378.140168361137920 | WLMCollectWorker        | TopMemoryContext             |     0 |                              |    411528 |     3272 |   408256  1594694378.140168296134400 | WLMarbiter              | TopMemoryContext             |     0 |                              |    411528 |     3032 |   408496  1594694378.140168344356608 | WLMmonitor              | TopMemoryContext             |     0 |                              |    411528 |     3272 |   408256  1594694378.140168465999616 | JobScheduler            | TopMemoryContext             |     0 |                              |    255240 |    10552 |   244688  0.140169093357952          | postmaster              | TopMemoryContext             |     0 |                              |    140680 |     7856 |   132824  1594694438.140168207001344 | postgres                | VecFuncHash                  |     1 | TopMemoryContext             |    122272 |    20928 |   101344  1594708276.140168270964480 | postgres                | VecFuncHash                  |     1 | TopMemoryContext             |    122272 |    20928 |   101344  1594694378.140168539399936 | CheckPointer thread     | TopMemoryContext             |     0 |                              |    116104 |     5944 |   110160  1594694378.140168482780928 | WalWriter thread        | TopMemoryContext             |     0 |                              |    107848 |     7224 |   100624  1594694378.140168505317120 | BackgroundWriter thread | TopMemoryContext             |     0 |                              |    107848 |     7144 |   100704  1594694378.140168394700544 | TwoPhaseCleaner thread  | TopMemoryContext             |     0 |                              |    107848 |     8280 |    99568  1594694378.140168377919232 | FaultMonitor thread     | TopMemoryContext             |     0 |                              |    107848 |     8280 |    99568  1594694378.140168442930944 | PgstatCollector         | TopMemoryContext             |     0 |                              |    107848 |     6696 |   101152  1594694378.140168482780928 | WalWriter thread        | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  1594694378.140168465999616 | JobScheduler            | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  1594694378.140168505317120 | BackgroundWriter thread | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  0.140169093357952          | postmaster              | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  1594694378.140168296134400 | WLMarbiter              | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  1594694438.140168207001344 | postgres                | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  1594694378.140168377919232 | FaultMonitor thread     | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  1594694378.140168539399936 | CheckPointer thread     | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  1594694378.140168442930944 | PgstatCollector         | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    80656  1594694378.140168361137920 | WLMCollectWorker        | Timezones                    |     1 | TopMemoryContext             |     83488 |     2832 |    806563. PG_SHARED_MEMORY_DETAIL视图华为云数仓GaussDB(DWS)除了通用内存上下文以外，还包含共享内存上下文类型用于线程间共享数据。由于共享内存上下文是属于一个进程的，故该视图相比PV_SESSION_MEMORY_DETAIL，不存在sessid，其他的字段含义相同。postgres=# select * from PG_SHARED_MEMORY_DETAIL order by totalsize desc;               contextname               | level |                 parent                 | totalsize | freesize | usedsize ----------------------------------------+-------+----------------------------------------+-----------+----------+----------  Workload manager memory context        |     1 | ProcessMemory                          |   1056832 |     6080 |  1050752  PoolerAgentContext                     |     2 | PoolerMemoryContext                    |     57344 |    36000 |    21344  PoolerCoreContext                      |     2 | PoolerMemoryContext                    |     57344 |    30544 |    26800  ProcessMemory                          |     0 |                                        |     57344 |    28304 |    29040  wlm iostat info hash table             |     2 | Workload manager memory context        |     24576 |    10832 |    13744  WaitCountGlobalContext                 |     1 | ProcessMemory                          |     24576 |     9984 |    14592  wlm user info hash table               |     2 | Workload manager memory context        |     24576 |    10832 |    13744  OBS connector cache                    |     1 | ProcessMemory                          |     24576 |    15056 |     9520  Resource pool hash table               |     2 | Workload manager memory context        |     17984 |     2704 |    15280  Dummy server cache                     |     1 | ProcessMemory                          |      8192 |     2832 |     5360  Node Pool                              |     3 | PoolerCoreContext                      |      8192 |      768 |     7424  dywlm register hash table              |     2 | Workload manager memory context        |      8192 |     2704 |     5488  node group hash table                  |     2 | Workload manager memory context        |      8192 |     2832 |     5360  sql count lookup hash                  |     2 | WaitCountGlobalContext                 |      8192 |     8000 |      192  wlm session info hash table            |     2 | Workload manager memory context        |      8192 |     2704 |     5488  wlm collector hash table               |     2 | Workload manager memory context        |      8192 |     2704 |     5488  DFS connector cache                    |     1 | ProcessMemory                          |      8192 |      768 |     7424  PoolerMemoryContext                    |     1 | ProcessMemory                          |      8192 |     5456 |     2736  operator collector hash table          |     3 | Operator resource track memory context |      8192 |      640 |     7552  operator running hash table            |     3 | Operator resource track memory context |      8192 |      640 |     7552  Query resource track memory context    |     2 | Workload manager memory context        |      8192 |     8144 |       48  bad block stat global hash table       |     2 | bad block stat global memory context   |      8192 |     2704 |     5488  global info hash table                 |     2 | Workload manager memory context        |      8192 |     2832 |     5360  StreamInfoContext                      |     1 | ProcessMemory                          |         0 |        0 |        0  Operator resource track memory context |     2 | Workload manager memory context        |         0 |        0 |        0  bad block stat global memory context   |     1 | ProcessMemory                          |         0 |        0 |        0  ProcSubXidCacheContext                 |     1 | ProcessMemory                          |         0 |        0 |        0 (27 rows)内存相关数据收集通过前面讲述的几个内存视图，我们可以对华为云数仓GaussDB(DWS)内存有一个整体的理解。下面将分享几个内存相关数据收集的功能。注意： 鉴于论坛中的问题多是release版本，故debug版本的各种内存相关功能将不再此次介绍以免混淆。同时收集数据就会带来一些消耗，避免长期大规模的使用下面的方案，仅用作问题诊断数据分析使用。 1.   pv_session_memctx_detail函数       通过上面的视图介绍我们了解到了PV_SESSION_MEMORY_DETAIL视图的作用。我们可以通过pv_session_memctx_detail打印出该线程内存上下文的详细信息。注意第一个参数表示线程ID，我们根据上线的介绍得知sessid的后半部分就是线程ID。第二个参数表示需要打印内存上下文的名称，在release为空才可以生效即由TopMemoryContext开始递归打印内存上下文信息。Release版本不包含chunk的详细信息。例如：select * from pv_session_memctx_detail(140168207001344,'');生成的文件默认在/tmp/dumpmem下，文件中三列分别表示内存上下文名称，总大小，剩余大小。文件内容样例：140168207001344_1594695418.logTopMemoryContext, 460808, 24728 Record information cache, 24576, 14928 TableSpace cache, 8192, 2304 set params hash table, 8192, 2832 VecFuncHash, 122272, 20928 MaskPasswordCtx, 8192, 8144 RowDescriptionContext, 8192, 7104 MessageContext, 8192, 7104 Operator class cache, 8192, 768 smgr relation table, 24576, 8880 tokenize file cxt, 0, 0 hba parser context, 3072, 480 TransactionAbortContext, 32768, 32720 bad block stat thread hash table, 8192, 1664 bad block thread memory context, 0, 0 Portal hash, 8192, 768 PortalMemory, 8192, 8144 Partcache by OID, 8192, 2832 Relcache by OID, 24576, 11904 CacheMemoryContext, 1455032, 329944 pg_index_indrelid_index, 3776, 280 pg_toast_2618_index, 5824, 1760 pg_prepared_xacts, 31744, 3488 pg_db_role_setting_databaseid_rol_index, 5824, 1808 pg_opclass_am_name_nsp_index, 5824, 1768 pg_directory_name_index, 3776, 328 pg_foreign_data_wrapper_name_index, 3776, 328 pg_enum_oid_index, 3776, 328 pg_class_relname_nsp_index, 5824, 1760 pg_foreign_server_oid_index, 3776, 328 pg_statistic_relid_kind_att_inh_index, 5184, 760 pg_cast_source_target_index, 5824, 1808 pg_language_name_index, 3776, 328 pg_collation_oid_index, 3776, 328 pg_amop_fam_strat_index, 5184, 760 pg_index_indexrelid_index, 3776, 280 pg_ts_template_tmplname_index, 5824, 1808 pg_ts_config_map_index, 5824, 1768 pg_partition_partoid_index, 5824, 17682.   memory_tracking_mode参数     除了上面的内存上下文数据统计，我们还可以通过memory_tracking_mode设置内存信息统计的模式，共支持四种模式：    none：不启动内存统计功能。    normal：仅做内存实时统计，不生成文件。    executor：生成统计文件，包含执行层使用过的所有已分配内存的上下文信息。当为executor模式时，将在GaussDB进程(取决于在哪个数据节点最终执行了该算子)的pg_log目录下生成cvs格式文件，命名方式为：memory_track_<DN名称>_query_<queryid>.csv。作业执行时，执行器postgres线程和所有stream线程执行的算子信息，都将输入该文件。其中各字段分别为：输出顺序号、线程内分配内存上下文的顺序号、当前内存上下文的名称、父内存上下文的输出顺序号、父内存上下文的名称、内存上下文树形层次级别号、当前内存上下文使用的内存峰值、当前内存上下文及其所有子内存上下文使用的内存峰值、当前线程所在query的plannodeid。    fullexec：生成文件包含执行层申请过的所有内存上下文信息。当设置为fullexec模式时，输出信息和executor模式相同，但可能增加部分内存上下文分配信息，因为所有申请内存（无论是否申请成功）相关的信息都会被打印出来。由于仅记录内存申请信息，故记录中内存上下文使用的峰值均为0。csv文件内容样例：memory_track_datanode1_query_72339069014639220.csv0, 0, ExecutorState, 0, (null), 0, 8K, 656K, 4 1, 4, CStoreScan_139944754403072, 0, ExecutorState, 1, 272K, 625K, 4 2, 9, cstore scan per scan memory context, 1, CStoreScan_139944754403072, 2, 24K, 24K, 4 3, 8, cstore scan memory context, 1, CStoreScan_139944754403072, 2, 328K, 328K, 4 4, 2, VecToRow_139944754403072, 0, ExecutorState, 1, 23K, 23K, 4 0, 0, ExecutorState, 0, (null), 0, 8K, 144K, 0 1, 13, Stream_72339069014639220_4, 0, ExecutorState, 1, 72K, 72K, 0 2, 10, Sort_72339069014639220_3, 0, ExecutorState, 1, 8K, 40K, 0 3, 16, TupleSort, 2, Sort_72339069014639220_3, 2, 32K, 32K, 0 4, 2, Agg_72339069014639220_2, 0, ExecutorState, 1, 24K, 24K, 0一些诊断方案：1.   内存膨胀       在release版本调试工具以及信息比较受限，基本都是先通过前面介绍的三种视图初步定位大致功能。首先查看PV_TOTAL_MEMORY_DETAIL视图确定是哪一块内存出现了膨胀或者泄露。若是other_used_memory则要考虑三方仓的场景。若是dynamic_used_memory较大，则要查PV_SESSION_MEMORY_DETAIL视图，查看哪个线程，哪个内存上下文占用内存过多。根据这些信息推断出大致问题场景。2.   内存不足在内核发现内存不足的时候会有memory is temporarily unavailable的日志提示。首先观察日志，若日志里是reaching the database memory limitation则说明内核使用内存到达了max_dynamic_memory，则需要根据PV_SESSION_MEMORY_DETAIL视图分析是那个内存上下文占用内存较多，分析出业务场景。若日志里是reaching the OS memory limitation，则表示是操作系统分配内存失败导致，需要看操作系统参数配置以及内存硬件等情况。小结：       生产环境出现内存问题一般会比较棘手，而且release版本内存检测工具以及数据信息使用都比较受限，遇到问题需要通过上述的方案以及手段快速定位出出现内存问题的相关业务场景。有了业务场景，后面通过debug版本使用ASAN地址消毒技术以及Jemalloc Profiling便可以较快的定位出来。原文链接：https://bbs.huaweicloud.com/blogs/184725【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

GaussDB(DWS)架构简介    近期刚刚接触GaussDB(DWS)，它是一个shared nothing的分布式架构，下图是一个简化的GaussDB(DWS)架构图。    其中各组件的功能如下：CN(Coordinator Node)为对外服务和协调节点，负责接受客户端连接以及对用户SQL命令解析下发，并收集DN节点执行的结果进行汇总，将结果展现给客户端。DN(Datanode)为内部数据节点，承载内部数据存储及计算单元的功能。GTM(Global Transaction Manager)负责集群全局事务控制，其与Datanode均有本地主备双机功能。分布式执行框架    对应于分布式架构，GaussDB(DWS)提供了分布式执行框架，这也是GaussDB(DWS)中最核心的技术，旨在充分利用DN的资源，尽量将计算下推到DN进行，避免CN成为瓶颈，以提升查询效率和系统扩展性。    分布式执行框架的技术特点如下：CN负责查询请求的解析、基于代价进行优化以及向DN进行任务下发，并收集DN节点执行的结果进行汇总DN上运行执行计划进程，基于本节点存储的数据执行任务执行过程中每个算子都是接收下级算子的数据输入，并向上级算子输出数据。是一个生产者—消费者的流水线工作模型  针对分布式框架，GaussDB(DWS)增加了支撑分布式计划的Stream算子。Stream算子有三种类型：Gather Stream（N:1）：每个源节点都将其数据发送给目标节点            Redistribute Stream（N:N）：每个源节点将其数据根据连接条件计算Hash值，根据重新计算的Hash值进行分布，发给对应的目标节点    Broadcast Stream（1:N）：有一个源节点将其数据发给N个目标节点      下面通过tpch中的Q1和Q2为例，使用explain查看这两个SQL的执行计划来认识一下这几个算子。查看执行计划查看与Gather Stream和Redistribute Stream算子相关的执行计划  以tpch的Q1为例说明，Q1的SQL语句如下SET explain_perf_mode=pretty; --以Oracle-like风格打印执行计划，便于查看EXPLAINSELECT          l_returnflag,          l_linestatus,          SUM(l_quantity) as sum_qty,          SUM (l_extendedprice) as sum_base_price,          SUM (l_extendedprice * (1 - l_discount)) as sum_disc_price,          SUM (l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,          AVG(l_quantity) as avg_qty,          AVG (l_extendedprice) as avg_price,          AVG (l_discount) as avg_disc,          COUNT(*) as count_orderFROM          row_engine.lineitemWHERE          l_shipdate <= DATE '1998-12-01' - INTERVAL '3 day'GROUP BY          l_returnflag,          l_linestatusORDER BY          l_returnflag,          l_linestatus;      执行结果如下： id |                 operation                  | E-rows  | E-memory | E-width |  E-costs   ----+--------------------------------------------+---------+----------+---------+-----------   1 | ->  Streaming (type: GATHER)               |       5 |          |     257 | 146811.70   2 |    ->  Sort                                |       5 | 16MB     |     257 | 146811.20   3 |       ->  HashAggregate                    |       6 | 16MB     |     257 | 146811.19   4 |          ->  Streaming(type: REDISTRIBUTE) |      18 | 2MB      |     257 | 146810.87   5 |             ->  HashAggregate              |      18 | 16MB     |     257 | 146809.83   6 |                ->  Seq Scan on lineitem    | 6001622 | 1MB      |      25 | 66788.09(6 rows)                   Predicate Information (identified by plan id)                    ------------------------------------------------------------------------------------    3 --HashAggregate          Skew Agg Optimized by Statistic   6 --Seq Scan on lineitem          Filter: (l_shipdate <= '1998-11-28 00:00:00'::timestamp without time zone)(4 rows)    ====== Query Summary =====    ---------------------------------  System available mem: 9252864KB  Query Max mem: 9473228KB  Query estimated mem: 3123KB(3 rows)    为了便于说明，我在执行计划的每一行的行首加了一个序号。下面对这个计划进行一下说明：从第2行的Sort算子开始直到第6行，是CN下发到在DN上执行的部分；第1行是在CN上执行执行顺序首先从id为6的行开始，对lineitem表执行seqscanid为5的行，对下层扫描得到的数据根据GROUP BY分组键执行hashaggregate操作id为4的行，是一个Redistribute Stream算子，它将在DN上的local数据执行agg后结果，重分布给其他DNid为3的行，各DN收到其他DN上的数据，重新做aggid为2的行，对下层的agg结果进行排序id为1的行，是一个Gather Stream算子，CN节点收到DN返回的结果，汇集后将最终结果展示给客户端    在这个执行计划中，我们看到了两个和Stream算子相关的节点：Gather Stream，用于CN收集DN的结果Redistribute Stream，用于将DN上的数据重分布给其他DN做HashAgg。    这里有两个问题：Q1查询是一个单表查询，为什么需要在DN之间重分布数据呢？tpch的Q1是对lineitem表的单表查询，进行分组聚集计算。因为lineitem表是按照l_orderkey列作为分布列，将数据分布到各DN的。而聚集操作分组键是l_returnflag和l_linestatus，而不 是分布键l_orderkey，所以，属于同一个分组的数据分布在不同的DN上，这就需要各DN重新按照分组键作为分布键，将数据分发给其他DN，使得各DN上拥有相同分组键的数据完成聚集操作。从以上的计划中，可以看到在DN上先做了hashagg，再又重分发给其他DN，再次做hashagg，如下图中的右侧。为什么不是先把数据重分布发给其他DN后，做一次hashagg即可，如下图的左侧       这两个计划的区别在于：如果scan后数据量非常大，而聚集后数据量比较小的情况，就适合用第二个计划，可以减少DN之间的数据流动，降低网络开销。从上面Q1的执行计划中，可以明显看到，Seq Scan on lineitem对应的E-rows为6001622，即seqscan后的数据估计有6001622行，重分布之前HashAggregate的的结果数据估计只有18行，数据量大大减少。根据代价估算，重分布前做一次hashagg的代价，比直接重分布scan的结果的代价要小很多，故选择了重分布前先做一次hashagg。查看与Gather Stream和Broadcast Stream算子相关的执行计划    以tpch的Q2为例说明，Q2的SQL语句如下SET explain_perf_mode=pretty; --以Oracle-like风格打印执行计划，便于查看EXPLAIN     SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment    FROM row_engine.part, row_engine.supplier, row_engine.partsupp, row_engine.nation, row_engine.region    WHERE p_partkey = ps_partkey AND s_suppkey = ps_suppkey AND p_size = 15 AND p_type LIKE 'SMALL%' AND s_nationkey = n_nationkey AND n_regionkey = r_regionkey AND r_name = 'EUROPE ' AND ps_supplycost = ( SELECT MIN(ps_supplycost) FROM row_engine.partsupp, row_engine.supplier, row_engine.nation, row_engine.region WHERE p_partkey = ps_partkey AND s_suppkey = ps_suppkey AND s_nationkey = n_nationkey AND n_regionkey = r_regionkey AND r_name = 'EUROPE ' )ORDER BY s_acctbal DESC, n_name, s_name, p_partkeyLIMIT 100;   执行结果如下： id |                                            operation                                             | E-rows | E-memory | E-width | E-costs      ----+--------------------------------------------------------------------------------------------------+--------+----------+---------+----------   1 | ->  Limit                                                                                        |      3 |          |     192 | 23979.08   2 |    ->  Streaming (type: GATHER)                                                                  |      3 |          |     192 | 23979.08   3 |       ->  Limit                                                                                  |      3 | 1MB      |     192 | 23978.89   4 |          ->  Sort                                                                                |      3 | 16MB     |     192 | 23978.89   5 |             ->  Nested Loop (6,10)                                                               |      3 | 1MB      |     192 | 23978.88   6 |                ->  Nested Loop (7,9)                                                             |      5 | 1MB      |      30 | 2.48   7 |                   ->  Streaming(type: BROADCAST)                                                 |      3 | 2MB      |       4 | 1.30   8 |                      ->  Seq Scan on region                                                      |      1 | 1MB      |       4 | 1.02   9 |                   ->  Seq Scan on nation                                                         |     25 | 1MB      |      34 | 1.08   10 |                ->  Materialize                                                                   |      3 | 16MB     |     170 | 23976.35   11 |                   ->  Streaming(type: REDISTRIBUTE)                                              |      3 | 2MB      |     170 | 23976.34   12 |                      ->  Nested Loop (13,14)                                                     |      3 | 1MB      |     170 | 23976.14   13 |                         ->  Seq Scan on supplier                                                 |  10000 | 1MB      |     144 | 108.33   14 |                         ->  Materialize                                                          |      3 | 16MB     |      34 | 23767.83   15 |                            ->  Streaming(type: REDISTRIBUTE)                                     |      3 | 2MB      |      34 | 23767.82   16 |                               ->  Hash Join (17,21)                                              |      3 | 1MB      |      34 | 23767.71   17 |                                  ->  Hash Join (18,19)                                           |   2538 | 1MB      |      44 | 11916.85   18 |                                     ->  Seq Scan on partsupp                                     | 800000 | 1MB      |      14 | 8532.67   19 |                                     ->  Hash                                                     |    651 | 16MB     |      30 | 2373.01   20 |                                        ->  Seq Scan on part                                      |    651 | 1MB      |      30 | 2373.01   21 |                                  ->  Hash                                                        |    507 | 16MB     |      36 | 11841.97   22 |                                     ->  Subquery Scan on subquery                                |    507 | 1MB      |      36 | 11841.97   23 |                                        ->  HashAggregate                                         |    507 | 16MB     |      42 | 11840.28   24 |                                           ->  Streaming(type: REDISTRIBUTE)                      |    507 | 2MB      |      10 | 11837.75   25 |                                              ->  Hash Join (26,31)                               |    507 | 1MB      |      10 | 11833.54   26 |                                                 ->  Streaming(type: REDISTRIBUTE)                |   2538 | 2MB      |      14 | 11687.60   27 |                                                    ->  Hash Semi Join (28, 29)                   |   2538 | 1MB      |      14 | 11617.80   28 |                                                       ->  Seq Scan on partsupp                   | 800000 | 1MB      |      14 | 8532.67   29 |                                                       ->  Hash                                   |    651 | 16MB     |       4 | 2373.01   30 |                                                          ->  Seq Scan on part                    |    651 | 1MB      |       4 | 2373.01   31 |                                                 ->  Hash                                         |   2001 | 16MB     |       4 | 126.89   32 |                                                    ->  Hash Join (33,34)                         |   2000 | 1MB      |       4 | 126.89   33 |                                                       ->  Seq Scan on supplier                   |  10000 | 1MB      |       8 | 108.33   34 |                                                       ->  Hash                                   |     15 | 16MB     |       4 | 2.97   35 |                                                          ->  Streaming(type: BROADCAST)          |     15 | 2MB      |       4 | 2.97   36 |                                                             ->  Hash Join (37,38)                |      5 | 1MB      |       4 | 2.43   37 |                                                                ->  Seq Scan on nation            |     25 | 1MB      |       8 | 1.08   38 |                                                                ->  Hash                          |      3 | 16MB     |       4 | 1.30   39 |                                                                   ->  Streaming(type: BROADCAST) |      3 | 2MB      |       4 | 1.30   40 |                                                                      ->  Seq Scan on region      |      1 | 1MB      |       4 | 1.02(40 rows)    在这个计划中我们看到对region表的扫描结果使用Broadcast方式广播给其他DN节点，然后在各DN上和nation表做Nestloop连接。    那么什么时候用Broadcast Stream，什么时候用Redistribute Stream呢？    一般来说，Broadcast Stream比较适用于表要广播的表数据量比较小的情况，从上面的计划可以看到Streaming(type: BROADCAST)对应的E-rows 为3，即要广播的数据仅有3条。但是对于小表作为外连接的NonNullable-side时，是不适合用Broadcast Stream的。因为小表全表广播到所有DN后，和Nullable-side的表的数据进行外连接，因为Nullable-side的表在DN上存储的只是集群中该表的部分数据，而NonNullable-side表是所有数据，导致外连接的结果中Nullable-side的NULL行数增加。DN的结果再发给CN进行汇总后，会使整个结果的数据中结果增多。原文链接：https://bbs.huaweicloud.com/blogs/176347【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 GaussDB(DWS)引入了内存自适应控制的技术，在SQL语句复杂、处理数据量大的AP场景下，能够对运行的作业进行内存级的管控，避免高并发场景下内存不足产生的各种问题。1. 技术背景在SQL语句复杂、处理数据量大的AP场景下，单个查询对内存的需求越来越大，多个语句的并发很容易将系统的内存吃满，造成内存不足的问题。为了应对这种问题，GaussDB(DWS)引入了内存自适应控制的技术，在上述场景下能够对运行的作业进行内存级的管控，避免高并发场景下内存不足产生的各种问题。2. GaussDB(DWS)的静态内存管理机制及缺陷GaussDB(DWS)的执行引擎继承自PG，对于优化器生成的执行计划树，总体采取执行算子+流水线的处理方式，如下图所示。对于NestLoop算子节点，需要首先从左树的IndexScan算子节点获取元组，然后到右子树的IndexScan算子节点进行连接，匹配元组后进行输出。流水线的执行方式使得对于NestLoop, IndexScan类的一般算子，同时只有一定数量的元组处于内存中，对于行引擎每个算子仅占用一条元组的空间，对于列引擎占用一个batch（最多1000条元组）的空间，占用的空间较小，基本可以忽略不计。但是，GaussDB(DWS)中也有一些需要将所有数据收集后进行处理的算子，在执行时需要使用较多的内存，通常我们称这类算子为物化算子。GaussDB(DWS)中主要存在如下不同种类的物化算子：（1） HashJoin：Hash连接操作符，主要思想是计算左右两表连接列的hash值，通过hash值比较减少元组比较的次数，需要将一个表建立hash表，另一个表进行hash值比较操作，建立hash表需要在内存中进行。（2） HashAgg：Hash聚集操作符，主要思想同HashJoin类似，通过hash值比较减少元组去重比较的次数，需要将不同值的元组保存的内存中。（3） Sort：排序操作符，需要获取所有元组后进行排序操作，待排序元组均存在于内存中。（4） Materialize：物化操作符，通常在需要重复扫描时使用，通过将结果存储在内存中，保证重复扫描时的效率。同时，GaussDB也提供下盘的机制，当上述操作符需要使用的内存太大时，可以将部分或全部的数据下盘处理，提高内存的使用效率，但相应的查询性能也会受到影响。PG使用 work_mem参数来控制算子可使用内存的阈值，当使用内存超过阈值时，就需要做下盘处理。GaussDB(DWS)的静态内存管理机制也延续了PG的处理机制，使用work_mem来控制单算子的内存使用上限。GaussDB(DWS)的静态内存管理存在较大弊端，需要调优人员能够根据数据量、语句复杂程度和系统的内存大小设置合理的work_mem，既避免work_mem设置太大导致系统资源不够用，还要考虑到数据规模，保证大部分算子不下盘。通常情况下，这个是很难做到的，有以下几点原因：（1） 通常情况下，复杂语句的执行计划中包含多个复杂算子，每个算子的内存使用上限是work_mem，我们没有办法计算一个语句要使用多少内存，因此也就不容易设置一个最优的work_mem参数，保证尽可能不下盘，同时内存又够用。并发场景更无法设置了。（2） work_mem只是每个算子内存使用的上限，并不是预分配；如果数据量没有那么大的话，实际内存使用是达不到work_mem的。因此也会影响work_mem的设置。（3） 每个语句的场景不一样，有的语句包含多个物化算子，而另外的语句只有一个物化算子，而这个算子对内存的需求会比较大，因此无法全局统一地进行设置。3.  GaussDB(DWS)的内存自适应技术介绍针对静态内存管理机制的弊端，我们设计了内存自适应控制技术，目的有两个：（1） 去除静态内存管理对work_mem的依赖。可以由SQL引擎优化器模块自动估算每个算子所需的内存。（2） 避免大并发场景下内存不足现象的发生。资源管理模块根据SQL引擎优化器对于每个查询内存的估算值，对每个查询进行调度，如果超过系统可用内存，则进行排队。     如上图所示，动态资源管理与内存自适应技术的组件图如上图所示。我们从多个CN中选择一个CN，命名为CCN（Central CN），进行语句队列的管理。对于每个查询SQL，CN在生成完执行计划后，为每个物化算子分配合适的内存，同时计算整个语句内存使用量，并将语句及对应的内存使用量发给CCN。CCN维护系统可用的内存值，对于新来的语句，如果语句内存使用量小于可用内存值，则允许其下发到DN执行，否则挂起，等到有语句结束释放内存后再次将其唤醒，是否可以下发。     为了达到上述目的，SQL引擎实现了内存自适应控制技术，步骤如下：（1）对于每个SQL，生成计划前首先从资源管理模块获取系统当前的最大可用内存（Query Max Mem）和当前可用内存（System Available Mem）。最大可用内存通常为每个DN的最大可用内存去除系统预分配内存，例如：数据缓存等，表示语句可用的最大内存，如果语句使用内存超过该值，必须下盘。当前可用内存用于表示当前系统的繁忙程度，如果当前可用内存比较小，倾向于选择耗费内存少的计划。（2）依据当前可用内存生成计划，同时根据SQL引擎优化器计划生成过程中的cost估算值估算每个物化算子的内存使用量，以及流水线场景下整个查询使用的内存总量估算值。如果该值大于当前可用内存，则尝试将整个查询的内存使用量调到当前可用内存以下，此时会造成部分算子下盘。（3）将语句及估算的语句内存发送到CCN，如果当前可用内存小于语句估算内存，则估算语句的内存进一步减少是否对查询性能造成较大的影响，如果根据cost评估影响不大，则进一步减少算子的内存使用，使语句内存使用满足当前可用内存，将语句下发执行，否则则进入排队状态。（4）由于每个算子的内存使用量是基于cost评估获得，可能存在一定的误差。因此，在SQL语句执行时，支持内存的动态调整，包括：执行算子内存的自动扩展和提前下盘。当算子达到估算的内存值上限，但系统还有宽裕的内存时，会进行算子内存的扩展，继续保持不下盘的状态。当系统已用内存达到80%或更高时，如果算子已有最小内存保证，则会触发提前下盘逻辑，保证不会由于内存不足而报错。4.  GaussDB(DWS)内存自适应的使用和参数控制通过开启use_workload_manager和enable_dynamic_workload两个参数开启GaussDB(DWS)的内存自适应控制机制。使用内存自适应机制时，打印SQL语句的explain performance执行计划运行信息时，会包含以下额外的信息辅助定位问题：（1） 在最下方的Query Summary一栏中，会显示出System available mem、Query max mem和Query estimated mem，分别表示：系统当前可用内存、语句可用最大内存（系统可用最大内存），语句估算内存使用量，均为单DN的衡量值。下图表示当前语句的语句最大可用内存和系统当前可用内存均为22G，语句估算内存使用为1.6G。                                        （2） 在Memory Information一栏，会显示CN和每个DN的内存使用峰值，如下图所示，语句实际内存使用，单DN使用16GB，CN使用76MB。                       （3） 在Memory Information一栏下方每个算子对应的位置，会显示每个算子单DN的内存峰值，同时会显示每个DN上内存使用的自动扩展和提前下盘情况，例如下图，可以看出第15号HashJoin算子，每个SMP线程的内存使用均为3.8GB，估算内存是860MB，经历了五次内存自动扩展，在第五次扩展后，系统内存告急，算子未用到第五次扩展后的峰值即提前下盘。               （4） 在explain performance最顶层的表格中，汇总了每个算子的估算内存和实际使用内存的情况，见下图的E-memory和Peak Memory两列所示。与上面信息对应，第15号算子单SMP线程的peak memory，最大值为3766MB，最小值为3753MB，估算内存值（单DN4个SMP线程）为860MB。     可以看出，上面例子由于cost估算不准导致内存估算值较小，实际场景也会出现内存估算值较大的场景，会导致CCN预留内存较多，阻塞其它作业的执行。因此，可以使用参数query_mem来控制语句最大可用内存上限（单DN），相当于代替了Query max mem。此参数默认为0，表示未开启。当此值大于32MB（最小语句内存分配值）时，表示开启，此时使用work_mem控制系统当前可用内存进行估算，相当于代替了System available mem进行估算。此时，CCN会使用query_mem值进行语句内存估算值的预留和排队，提高并发场景下的内存使用效率。5. 总结    内存自适应控制技术是GaussDB(DWS)的资源管理结合SQL引擎所做的一次尝试，当然还存在一些不足，比如：cost估算对内存的评估影响较大，部分场景存在失真需要进行参数控制；系统中内存使用情况比较复杂，还存在部分内存不在管控范围内需要增强。欢迎各位在实用过程中，将遇到的各种问题及时反馈，也帮助我们更好的改进！原文链接：https://bbs.huaweicloud.com/blogs/176326【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

1.问题背景某局点出现如下业务场景：从存量清单表中，根据条码，合同号等条件，查询明细数据，表总数据量有3亿。一次业务请求包含10个并发的查询语句，需要1秒内返回结果集。但是多次优化之后并发性能依旧长达4s左右。2.   硬件配置硬件配置信息：集群 6个数据节点：每个节点都是RH5885服务器，配置1T内存、 144个CPU core、SSD 存储空间3.   历史优化对于这个业务场景需求，客户做了多种性能优化尝试，优化动作主要分为如下三个阶段l  第一版本：调试分布键分析业务数据特性，并测试验证选择最合适的分布键，既能保障数据不倾斜，又能利用分布键做为条件过滤数据调整后单个查询响应从平均9秒降到4~5秒l  第二版本：添加PCK&限制结果集接口上线后，发现业务中会有几个高频条件字段，同时有些查询返回结果集过大，有几十万记录，不符合前端查询响应要求，所以添加了限制，单次最大只能返回1万条记录；同时对合同号添加了PCK调整后单个查询响应从平均5秒降到2秒l  第三版本：使用SMP，以资源换性能从系统监控发现资源使用率低，建议使用SMP，通过提高CPU资源使用率的方式提升查询性能。根据现网CPU配置推荐设置query_dop=8调整后单个查询响应从2秒降到了400MS版本上线后，生产使用发现查询性能劣化到3~4秒，但是把SQL提取之后单独运行时性能达到400ms。分析平台日志发现下日志中会每10个请求发起时间点很接近，然后再找到下游调用方了解，才确认是会每此业务请求包含10个类似SQL语句的并发调用。后续测试确认并发查询时性能下降，导致性能不达标。4.   优化分析4.1. SQL语句分析业务SQL是如下简单的单表查询语句，SQL语句未发现明显的不下推、不能提升子查询等明显低效性能点。需要进一步获取performance信息分析性能瓶颈。4.2. 性能瓶颈分析执行并发查询，获取performance信息，典型信息如下，详细信息见附件 发现耗时主要有两个1)  数据收集（GATHER和LOCAL GATHER），这个算子主要是从相关线程收集数据，这个算子耗时一般分为两个场景 数据量大，导致数据收集耗时特别长CN申请线程，DN上创建STREAM线程等计算相关线程初始化耗时长2)   数据扫描(Scan)耗时长分析Scan算子，发现顺序扫描（Cstore Scan）时，RoughCheck（根据稀疏索引排除查询不相关的数据）时排除掉的元组为0，即稀疏索引没有预过滤掉任何CU根据上述分析可以看到当前查询性能主要损耗在计算相关线程初始化上，但是如果把SMP去掉（设置query_dop为1），底层数据扫描耗时会变长，同样导致性能不达标。和相关维护和业务人员也确认了这点4.3. 性能优化4.3.1. 优化思路找到性能瓶颈点之后就可以针对性进行性能优化，我们把优化的重点放在Scan性能的提升上，期待在不设置SMP时通过Scan性能的大幅提升来优化性能。根据表扫描信息分析，我们发现，表扫描的filter条件可以过滤掉376029639条记录，输出149条记录，可以过滤掉99.99996037%的元组，效果非常明显。 分析表的扫描条件，通过测试验证发现过滤效果最明显的条件为POSITION(','||a.ItemNo||',' in ','||'0835TXWY'||',') > 0，过滤效果在99.99%以上，其它表达式基本没有起到过滤效果进一步分析RoughCheck，发现RoughCheck排除掉的元组为0，稀疏索引没有任何过滤效果 通常来讲，这类过滤效果非常明显的filter是典型的构建PCK和索引场景，但是这个filter条件为函数表达式，导致此filter条件即没有办法构建PCK又没办法构建索引。因此我们尝试跟业务人员沟通，看能够改写POSITION约束，使其支持索引和PCK4.3.2. 业务分析跟客户业务人员进一步沟通position函数的业务含义，发现1.  position函数的第二个参数如果个合同号通过’,’连接起来的子串2.  函数功能是查询能跟匹配到第二个参数中任一合同号的记录第二个参数通过如下的方式从客户端输入这样写的原因是从在客户界面上操作的方便性以及常规的操作习惯上来讲，在外部输入时不会在合同号上引号，在SQL拼接时不能把此约束条件写成itemno in ('0AFR2C', ‘0A672C’, ’0A902C', '0AY72C'')这类索引支持的表达式4.3.3. 最终优化方案在了解这些原因之后，我们和业务人员沟通，采取以下优化手段1)   在业务层在接受客户界面输入的合同号之后，内部在拼接SQL之前，进行数据预处理，把函数的逻辑转化为itemno in ('0AFR2C', ‘0A672C’, ’0A902C', '0AY72C'')式的in约束2)  在itemno上建PCK以及索引，通过PCK和索引的双重优化来提升性能采取这两个措施之后，标准并发测试场景下，SQL查询性能提升到90ms，端到端的性能从4s提升到300ms5.   优化总结5.1.       关于列存点查性能通常场景下，列存表的点差性能比行存表的点查性能要差，但是在如下场景下列存表的索引查询性能也非常好1）宽表的少量列查询列存是按照列存储的，宽表的少量列查询时，列存表只需要读取少量查询相关列即可，这可能会导致列存表扫描的数据量小于行存表的数据量，体现列存表扫描的性能优势2）索引列上局部聚簇通过在索引列上做PCK，通过PCK的聚簇效果减小扫描的CU个数，导致列存表扫描的数据量小于行存表的数据量。注：行存表有全局聚簇的手段，详见产品文档的CLUSTER命令5.2.       关于优化思路SQL语句优一些建议：1)  梳理性能问题业务，找出执行性能差的SQL语句2)  分析业务流程，确认SQL全生命周期的耗时分布，如果数据库执行时间长，那么进入下一步3)  分析是否存在不下推场景。如果存在，通过改写SQL消除不下推因素，如果SQL语句可以下推，进入下一步4)  通过performance找性能瓶颈点：根据performance显示的算子耗时，查询耗时最长的算子，这个算子就是导致执行耗时时间比较长的最基本因素5)  针对性能瓶颈点，给出优化思路和方案优化不要局限在SQL语句本身，要和具体硬件配置和业务背景相结合。名词解释1. 【CU】列存的基本存储单元，同时也是列存表扫描时基本的读取单元。列存表读取数据时会把全部CU的数据读上来，而不能读取CU中的一部分数据。2. 【PCK】Partial Cluster Key（局部聚簇）的简称，是列存表的一种局部聚簇技术，该技术可以在批量数据导入时，把数据按照PCK指定的列(单列或多列)进行局部排序，实现不同值区间的数据存储到不同的CU上。这种局部聚簇结合列存表CU的内置min/max稀疏索引，可以大幅提升表在PCK列上简单filter的过滤效果使用PCK需要注意的几点1)  只有列存表支持PCK2)  一个表只能定义一个PCK3)  PCK列上的fliter要满足以下约束 简单的<、>、≤、≥、=表达式 一侧是PCK列，而不能是列相关表达式、函数另一侧是常量表达式计算时，PCK列不需要进行隐士类型转换4)  上个步骤的filter条件要可以过滤掉较多的元组，减轻Scan以及相关投影计算量5)  表数据是批量数据入库，且单次入库数据不小于DN的个数*6w * 5条记录；如果单次入库记录数不满足上述约束，建议把表建成分区表，定期对增强数据所在分区进行VACUUM FULL操作增强聚簇效果6)  通过ALTER语法增加PCK时，只有后续新增数据才会有局部聚簇效果。可以通过VACUUM FULL全表让已有数据恢复聚簇3. 【SMP】SMP特性通过算子并行(可以理解为把一个线程的任务拆分为多个线程并行执行)来提升性能，本质上是一种以资源换取时间的方式，在合适的场景以及资源充足的情况下，能够起到较好的性能提升效果；但是如果在不合适的场景下，或者资源不足的情况下，反而可能引起性能的劣化。GaussDB A中可以通过参数query_dop设置算子并行度4. 【RoughCheck】粗过滤检查，列存表扫描的特殊的优化手段。在列存表简单filter条件（单列 op 常量， op为>、<、=、≤、≥）过滤时，通过判断CU的内置min/max跟filter条件进行快速比较，如果此CU内是不满足filter条件，那么直接跳过此CU的扫描。GaussDB A的列存表通过PCK +RoughCheck+Latter Read(先读取filter条件列进行过滤、再读取非filter条件列数据) 组合技术，可以典型场景下节省大量的数据扫描，提升查询性能原文链接：https://bbs.huaweicloud.com/blogs/175458【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【功能模块】请问FusionInsight Manager能监控数据仓库（DWS）集群资源情况吗【操作步骤&问题现象】1、我想监控GaussDWS集群资源的使用情况，请问FusionInsight Manager能做到吗2、该如何安装使用FusionInsight Manager呢？【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】多租户【操作步骤&问题现象】创建租户关联用户过程如下：用户u02去压测（50个并发）运行如下SQL：ta.tb表的相关信息如下：查看用户u02的资源限制情况：怎么让着used_memory的值接近total_memory:452，这样可以呈现出对u02用户限制了内存使用，到了452M之后不会再增加了??

【摘要】集群类问题目录 => 找你所需1  原理类1.1  通信原理 => https://bbs.huaweicloud.com/blogs/2399711.2  通信视图 => https://bbs.huaweicloud.com/blogs/2475431.3  资源负载管理 => https://bbs.huaweicloud.com/blogs/2399601.4   集群管理CM => https://bbs.huaweicloud.com/blogs/2443551.5  集群管理CM => https://bbs.huaweicloud.com/blogs/2240051.6  CMS通信机制 => https://bbs.huaweicloud.com/blogs/2418531.7   LVS基本原理 => https://bbs.huaweicloud.com/blogs/2386211.8  CPU资源管理 => https://bbs.huaweicloud.com/blogs/2375502  连接类2.1  JDBC连接报错 => https://bbs.huaweicloud.com/blogs/244348Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connectionsInvalid username/password, login deniedNo suitable driver found for XXXXNo pg_hba.conf entry for hostconflictTerminating connection due to administrator command, Session unused timeoutSSL error: Connection resetConnection refused: connectConnections could not be acquired from the underlying database2.2   LVS异常 => https://bbs.huaweicloud.com/blogs/247267 || https://bbs.huaweicloud.com/blogs/244340安装报错安装报写入文件权限不足ipvsadn –Ln显示没有CN信息客户端连接gsql报错客户端连接LVS不轮询客户端通过虚拟IP不能连接CN卸载LVS导致机器重启检测是否virtual_router_id冲突问题机器重启导致浮动IP丢失CN启动异常2.3  连接断开 => https://bbs.huaweicloud.com/blogs/239471 || https://bbs.huaweicloud.com/blogs/205970Too many clients already, active/non_active: xxxx/xxxxAn I/O error occurred while sending to the backend客户端连接CN耗时长Kerberos认证失败集群内部连接报错3  网络类3.1  重传or丢包 => https://bbs.huaweicloud.com/blogs/2352373.2  通信性能 => https://bbs.huaweicloud.com/blogs/248843网卡多队列网络流量通信库内存系统调用4  资源类4.1  资源管理配置 => https://bbs.huaweicloud.com/blogs/244671无效的服务名/内部未知异常/CPU配额不足等oms到主CMS节点的问题创建租户失败，后台日志报错权限不足创建租户失败，日志报错修改资源池失败4.2  内存异常 => https://bbs.huaweicloud.com/forum/thread-110215-1-1.html || https://bbs.huaweicloud.com/forum/thread-82838-1-1.html || https://bbs.huaweicloud.com/forum/thread-85225-1-1.html || https://bbs.huaweicloud.com/forum/thread-94896-1-1.htmlmemory temporarily unavailable4.3  CPU异常 => https://bbs.huaweicloud.com/forum/thread-76364-1-1.html || https://bbs.huaweicloud.com/forum/thread-79937-1-1.html || https://bbs.huaweicloud.com/forum/thread-70297-1-1.html || https://bbs.huaweicloud.com/forum/thread-73291-1-1.htmlCPU使用率超过阈值多租户CPU资源管理5   参数类5.1  通信参数 => https://bbs.huaweicloud.com/blogs/239863tcp_keepalives_idle、tcp_keepalives_interval、tcp_keepalives_countcomm_max_datanode、comm_max_stream、comm_max_receiverenable_stateless_pooler_reuse、comm_cn_dn_logic_conncomm_quota_size、comm_usable_memorynet.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle、net.ipv4.tcp_max_tw_bucketsnet.ipv4.tcp_syn_retries、net.ipv4.tcp_synack_retriesnet.ipv4.tcp_retries、net.ipv4.tcp_retries26  工具类6.1  网络流量/重传/丢包 => gsar.sh6.2  客户端连接状况监控 => clients.py6.3  网络打流 => speed_test_x86.sh/speed_test_arm6.4  网络多队列查询/设置 => get_irq_affinity.sh/set_irq_affinity.sh6.5  网络监控 => network_monitor.py6.6  通用语句监控 => general.sh7  总结未完待续 => 欢迎补充原文链接：https://bbs.huaweicloud.com/blogs/248845【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

一、背景 即时通讯（Instant Messaging，简称IM）是一个实时通信系统，允许两人或多人使用网络实时的传递文字消息、文件、语音与视频。微信、QQ等IM类产品在这个高度信息化的互联网时代已成为生活必备品，IM系统中最核心的部分是消息系统，消息系统中最核心的功能是消息的同步、存储和检索。·   消息同步：将消息完整的、快速的从发送方发送至接收方。消息同步系统最重要的衡量指标是消息传递的实时性、完整性、顺序性以及支撑的消息规模。·   消息存储：即消息的持久化，传统消息系统通常支持消息在接收端的本地存储，数据基本不具备可靠性。现代消息系统支持消息在云端存储，从而实现消息异地查询：账号可在任意客户端登陆查看所有历史消息。·   消息检索：消息一般是文本，所以支持全文检索也是必备的能力之一。传统消息系统通常来说基于本地存储的消息数据来构建索引，支持消息的本地检索。而现代消息系统支持消息的在线存储以及存储过程中构建索引，提供全面的消息检索功能。二、IM系统架构设计       上图为IM系统的应用场景，可用于聊天，游戏、智能客服等诸多行业。不同行业对IM系统的成本、性能、可靠性、时延等指标的需求是不同的，架构设计需要进行平衡。接下来将介绍IM系统架构设计所涉及到的一些基本概念。2.1 传统架构 vs 现代架构 ·   传统架构Ø  先同步后存储。Ø  在线消息同步和离线消息缓存。Ø  服务端不会对消息进行持久化，无法支持消息异地查询。·    现代架构Ø  先存储后同步。Ø  划分消息存储库与消息同步库。消息存储库用于全量保存所有会话消息，主要用于支持消息异地查询。消息同步库，主要用于接收方的多端同步。Ø  提供消息全文检索能力。2.2 读扩散vs 写扩散 《2020微信数据报告》指出，截至2020年9月，微信月活跃用户数为10.825亿，日消息发送次数450亿次，日音视频呼叫成功次数4.1亿次。面临这么多的消息，如何保证消息传递的可靠性、一致性并且有效的降低服务器或者客户端的压力是十分具有技术挑战的。其中，采用何种读写模型对IM系统至关重要，这里介绍两种模型：读扩散和写扩散。        如上图所示，用户B与每个聊天的人(A1,A2,A3)都有一个信箱（一种数据结构的抽象，用于存储消息），B在查看聊天信息时需读取所有有新消息的信箱。IM系统里的读扩散通常是每两个相关联的人就有一个信箱。读扩散的优点：·   写操作(发消息)轻量，不管是单聊还是群聊，只需要往相应的信箱写一次即可。·   每一个信箱天然就是两个人的聊天记录，可以方便查看和搜索聊天记录。读扩散的缺点：·   读操作(读消息)很重，存在读放大效应。如上图，在写扩散中，用户(B1,B2,B3)都只从自己的信箱里读取消息，但写(发消息)的时候，对于单聊跟群聊处理如下：·   单聊：往自己的信箱跟对方的信箱都写一份消息；同时，如果需要查看两个人的聊天历史记录的话还需要再写一份。·   群聊：发信息时需要针对所有群成员的信箱都写一份消息。群聊使用的是写扩散模型，而写扩散很消耗资源，因此微信群有人数上限(目前是500)。写扩散优点：·   读操作很轻量，只需要读取自己的邮箱。·   可以很方便实现消息的多终端同步。写扩散缺点：·   写操作很重，尤其是对于群聊来说。2.3 推模式 vs 拉模式 vs 推拉结合模式      在IM系统中，消息的获取通常有三种模式：·   推模式(Push)：新消息到达时由服务器主动推送给所有客户端；需要客户端和服务器建立长连接，实时性很高，对客户端来说只需要接收处理消息即可；缺点是服务端不知道客户端处理消息的能力，可能会导致数据积压。·   拉模式(Pull)：由前端主动发起拉取消息的请求，为了保证消息的实时性，一般采用推模式，拉模式一般用于获取历史消息；因客户端拉取新消息的时间间隔不好预设，太短可能会导致大量的连接拉取不到数据，太长导致数据接收不及时。·   推拉结合模式：兼顾push和pull两种模式的优点。新消息来临时服务器会先推送一个新消息到达的通知给前端，前端接收到通知后就向服务器拉取消息。三、IM技术挑战 上图为IM系统的总体架构图，Client双方通信会经过Server转发来完成消息传递。其核心为消息存储库和消息同步库。这两种库对存储层的性能有极高的要求。 ·   支撑海量数据存储：对于消息存储库来说，如果需要消息永久存储，则随着时间的积累，数据规模会越来越大，需存储库支持容量无限扩展以应对日益增长的消息数据。 ·   低存储成本：消息数据具有明显的冷热特征，大部分查询集中在热数据，冷数据需要一个低成本的存储方式，否则随着时间的积累，数据量不断膨胀，存储成本会不断上升。 ·   数据生命周期管理：不管是对于消息数据的存储还是同步，数据都需要定义生命周期。存储库是用于在线存储消息数据本身，通常需要设定一个较长周期的保存时间。而同步库  是用于写扩散模式的在线或离线推送，通常设定一个较短的保存时间。 ·   极高的写入吞吐：绝大部分IM类场景，通常是采用写扩散模型，写扩散要求底层存储具备极高的写入吞吐能力，从而应对消息洪峰。·   低延迟的读：消息系统通常应用于在线场景，具备较高的实时性，读取延迟应尽可能低。四、高斯Redis在IM场景中的优势 IM系统的核心是存储层，其性能差异将直接影响IM系统的用户体验。目前存储层可选择的数据库产品有很多，如HBase、开源Redis等等。选择何种数据库，需根据业务规模、成本、性能等指标来进行综合选择。这里介绍一种NoSQL数据库：高斯Redis，在性能和规模上，可以满足IM系统对存储层的严格要求：海量数据存储、低存储成本、生命周期管理、写入吞吐大、读取时延低。4.1高斯Redis简介 高斯Redis是华为云数据库团队自主研发且兼容Redis5.0协议的云原生数据库，采用计算存储分离架构。存储侧使用自研的存储系统，容量无限扩展、强一致、高可靠。计算侧基于 LSM 存储引擎实现，通过将大量的随机写转换为顺序写，从而极大的提升了数据写入性能，同时也通过读缓存、bloom filter 等极大优化了读取性能。下图是高斯Redis在IM场景的优势介绍。4.2基于高斯Redis的IM应用案例：       下图是基于高斯Redis的IM系统模型图，这里我们使用stream作为基本数据结构。Redis stream不仅可以作为消息存储容器，还实现了生产者、消费者等基本模型，具有IM系统的基本功能，如消息订阅，分发、增加消费者等，用户可基于高斯Redis快速构建一套IM系统。创建一个群聊时，在Redis中对应地为该群聊创建一个stream队列。在发送消息时，每个用户都将消息按照时间顺序添加到stream队列中，保证了消息的有序性。stream是一个持久化的队列，可保证信息不丢失。五、总结 高斯Redis通过一系列技术创新实现了读写性能水平扩展，秒级扩容，低成本以及自动备份等功能, 可作为IM系统的存储层，其优异的读写性能和高级特性将会极大助力IM应用.同时，高斯Redis在开源Redis的基础之上，较好平衡了性能和成本，能够广泛应用在智慧医疗、流量削峰、计数器等领域。六、结束本文作者：华为云高斯Redis团队。杭州西安深圳简历投递：yuwenlong4@huawei.com更多技术文章，关注高斯Redis官方博客：https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813七、参考资料1. 《GaussDB(for Redis)官方主页》https://www.huaweicloud.com/product/gaussdbforredis.html2. 《华为云GaussDB(for Redis)与自建开源Redis的成本对比》https://www.modb.pro/db/427393. 《华为云PB级数据库GaussDB(for Redis)揭秘第一期：Redis与存算分离》https://bbs.huaweicloud.com/blogs/2385844. 《华为云PB级数据库GaussDB(for Redis)揭秘第三期：一场由fork引发的超时，让我们重新探讨了Redis的抖动问题》https://bbs.huaweicloud.com/blogs/2456515. 《现代 IM 系统中的消息系统架构—架构篇》https://www.infoq.cn/article/ypb3y2lv-dsftrr5cguv

如果使用自带的jdbc驱动，如下配置：jdbc:postgresql://host1:port1,host2:port2/database如果使用开源jdbc驱动，需要设置loadBalanceHosts=true，否则是failover的负载管理方式：jdbc:postgresql://host1:port1,host2:port2/database?loadBalanceHosts=true

从Oracle往GaussDB数据库迁移数据，想知道有什么方法或者工具可以实现（不需要具体操作步骤）？需满足以下要求：Oracle上针对表的增删改查可以同步到GaussDB库；Oracle库里表数据量不大，每次的增量数据也不大，但是需要迁移速度快。

【操作步骤&问题现象】1、gaussdb 已添加白名单  安装windos odbc后 用sap data service 连接gauss正常，import表报错，更换成pgodbc报相同错误2、安装相同pg odbc后切换成连接pg数据库正常使用，求专家分析是什么原因3、目前客户sap data service 是4版本【截图信息】

1、该视图PGXC_GET_STAT_ALL_TABLES执行非常慢，其执行计算逻辑是什么？2、select schemaname,relname,n_tup_ins,n_tup_upd,n_tup_del,n_live_tup,n_dead_tup from  PGXC_GET_STAT_ALL_TABLES where schemaname = 'public'和select schemaname,relname,n_tup_ins,n_tup_upd,n_tup_del,n_live_tup,n_dead_tup from  pg_stat_all_tables where schemaname = 'public'这2个sql对同一模式下的表（8张）执行一样的查询操作，pg_stat_all_tables需要不到20s即可完成，而PGXC_GET_STAT_ALL_TABLES则需要十几分钟。这是为啥？3、针对脏数据统计这块有没有可以快速计算出脏页率的sql参考？

【操作步骤&问题现象】对于需要经常做VACUUM FULL释放的系统表，是否有影响范围的说明（锁级别或影响什么操作）？这样可以在不影响业务的情况下定期做释放。如PG_ATTRIBUTE;PG_CLASS; PG_CONSTRAINT; PG_DATABASE; PG_PARTITION; PG_PROC;PG_STAT_USER_INDEXES;PG_STAT_USER_TABLES; PG_STATISTIC;PG_STATS;等

GaussDB(DWS)项目实践系列文章汇总，请大家阅读鉴赏，欢迎在评论区交流探讨~序号主题分类标题链接1对接系列【融合对接】DWS和Hadoop互联互通--读取hdfs数据和将数据写入hdfshttps://bbs.huaweicloud.com/forum/thread-113331-1-1.html2对接系列Gauss   DB（DWS）对接系列-BI工具BIP对接https://bbs.huaweicloud.com/forum/thread-109303-1-1.html3对接系列GaussDB(DWS)与Kettle对接指导https://bbs.huaweicloud.com/forum/thread-104549-1-1.html4对接系列GaussDB(DWS)与OGG对接https://bbs.huaweicloud.com/forum/thread-102196-1-1.html5对接系列GAUSSDB(DWS)对接OBIEE指导https://bbs.huaweicloud.com/forum/thread-102193-1-1.html6对接系列JDBC 对接   GaussDB（DWS）的数据库连接问题https://bbs.huaweicloud.com/forum/thread-101725-1-1.html7对接系列DWS的ODBC常用配置https://bbs.huaweicloud.com/forum/thread-85432-1-1.html8对接系列SQL ON   HADOOP外表HIVE分区字段没有数据https://bbs.huaweicloud.com/forum/thread-81760-1-1.html9对接系列s环境下配置odbc数据源https://bbs.huaweicloud.com/forum/thread-74411-1-1.html10对接系列GaussDB(DWS)常见问题之session_timeout设置导致JDBC业务报错https://bbs.huaweicloud.com/forum/thread-72614-1-1.html11对接系列GaussDB(DWS)字符串数据类型与oracle对比https://bbs.huaweicloud.com/forum/thread-70762-1-1.html12对接系列【DWS产品】【JDBC功能】如何在JDBC连接DWS时设置（set）guc参数https://bbs.huaweicloud.com/forum/thread-70729-1-1.html13对接系列使用Navicat连接数据库报错，none   of server&apos;s SASL authentication mechainismhttps://bbs.huaweicloud.com/forum/thread-69095-1-1.html14对接系列使用CopyManager实现数据导入导出https://bbs.huaweicloud.com/forum/thread-68767-1-1.html15对接系列DataStage   通过JDBC驱动向GaussDB 200插入数据报错https://bbs.huaweicloud.com/forum/thread-67415-1-1.html16对接系列主流Web中间件与GaussDB(DWS)   对接介绍https://bbs.huaweicloud.com/forum/thread-64750-1-1.html17迁移系列Gauss   DB（DWS）迁移系列-TD迁移函数之next函数https://bbs.huaweicloud.com/forum/thread-114003-1-1.html18迁移系列GaussDB(DWS)   encode函数base64转码后存在换行https://bbs.huaweicloud.com/forum/thread-113489-1-1.html19迁移系列Gauss   DB（DWS）迁移系列-Teradata迁移PIVOT/UNPIVOT 语法转换对照https://bbs.huaweicloud.com/forum/thread-113049-1-1.html20迁移系列ADB for mysql 【INSERT   [IGNORE] INTO table_name】迁移 DWS 改写方法https://bbs.huaweicloud.com/forum/thread-111391-1-1.html21迁移系列数据仓库，数据脱敏、and，or，in处置方案https://bbs.huaweicloud.com/forum/thread-99866-1-1.html22迁移系列ADB for mysql  【INSERT [IGNORE] INTO table_name】迁移 DWS   改写方法https://bbs.huaweicloud.com/forum/thread-93001-1-1.html23迁移系列GDS实践指南https://bbs.huaweicloud.com/forum/thread-90062-1-1.html24迁移系列查询GDS外表时报错：connect   failedhttps://bbs.huaweicloud.com/forum/thread-85894-1-1.html25迁移系列GaussDB   A使用本地模式外表导出和导入数据https://bbs.huaweicloud.com/forum/thread-84489-1-1.html26迁移系列Roach基于NAS的备份https://bbs.huaweicloud.com/forum/thread-81751-1-1.html27迁移系列Oracle数据通过sqluldr导出然后通过gds导入到GaussDB实例https://bbs.huaweicloud.com/forum/thread-71300-1-1.html28迁移系列ORACLE使用GDS导入因数据中含有单字节，使部分行导入失败https://bbs.huaweicloud.com/forum/thread-71109-1-1.html29迁移系列GDS外表导入导出的那些事。https://bbs.huaweicloud.com/forum/thread-70824-1-1.html30迁移系列gds导入导出text格式https://bbs.huaweicloud.com/forum/thread-70756-1-1.html31迁移系列自己编写的数据一致性校验函数https://bbs.huaweicloud.com/forum/thread-59893-1-1.html32实践系列DWS  SQL 查询的几点建议https://bbs.huaweicloud.com/forum/thread-112506-1-1.html33实践系列DWS 分区表简介https://bbs.huaweicloud.com/forum/thread-112487-1-1.html34实践系列DWS 局部聚簇（Partial   Cluster Key）选取规则https://bbs.huaweicloud.com/forum/thread-112478-1-1.html35实践系列DWS 开发过程中SQL编写建议https://bbs.huaweicloud.com/forum/thread-112471-1-1.html36实践系列DWS   coordinator部署规划推荐规则https://bbs.huaweicloud.com/forum/thread-112461-1-1.html37实践系列【GaussDB（DWS）实践系列】低效SQL的排查和清理https://bbs.huaweicloud.com/forum/thread-111522-1-1.html38实践系列【GaussDB(DWS)实践系列】数据倾斜检查与修改方法https://bbs.huaweicloud.com/forum/thread-111395-1-1.html39实践系列DWS   泰山服务器未做配置加固影响性能的问题https://bbs.huaweicloud.com/forum/thread-110780-1-1.html40实践系列DWS   参数设置不合理导致作业下盘影响性能的问题https://bbs.huaweicloud.com/forum/thread-110776-1-1.html41实践系列DWS   统计信息不准触发nestloop导致查询语句执行缓慢https://bbs.huaweicloud.com/forum/thread-110543-1-1.html42实践系列DWS SQL语句中in常量优化https://bbs.huaweicloud.com/forum/thread-110535-1-1.html43实践系列DWS 语句中not   in触发NestLoop导致SQL执行慢的问题https://bbs.huaweicloud.com/forum/thread-110506-1-1.html44实践系列DWS语句不下推问题分析https://bbs.huaweicloud.com/forum/thread-110436-1-1.html45实践系列DWS   集群出现很多dn报内存不可用问题定位https://bbs.huaweicloud.com/forum/thread-109095-1-1.html46实践系列DWS 以TPCH   Q7为例，简单介绍Hang问题基本定位过程https://bbs.huaweicloud.com/forum/thread-109083-1-1.html47实践系列DWS INSERT语句疑似HANG住问题https://bbs.huaweicloud.com/forum/thread-109080-1-1.html48实践系列DWS DDL   HANG问题，长时间无法返回！https://bbs.huaweicloud.com/forum/thread-109062-1-1.html49实践系列为何时间戳数据写入和查询的值相差8小时https://bbs.huaweicloud.com/forum/thread-109028-1-1.html50实践系列DWS系统性能问题集锦https://bbs.huaweicloud.com/forum/thread-105345-1-1.html51实践系列"最大并发数"   真的能控制住并发   ？https://bbs.huaweicloud.com/forum/thread-105251-1-1.html52实践系列GaussDB的递归https://bbs.huaweicloud.com/forum/thread-101514-1-1.html53实践系列解决表过多导致的   PGXC_GET_STAT_ALL_TABLES 查询慢问题https://bbs.huaweicloud.com/forum/thread-101196-1-1.html54实践系列行转列的一个函数https://bbs.huaweicloud.com/forum/thread-100204-1-1.html55实践系列DWS内存参数调优https://bbs.huaweicloud.com/forum/thread-99652-1-1.html56实践系列DWS 硬件瓶颈点分析https://bbs.huaweicloud.com/forum/thread-99630-1-1.html57实践系列【程序猿的世界没有单身汪，数仓界达芬奇带您手动设计心仪对象】-12.22直播相关答疑FAQhttps://bbs.huaweicloud.com/forum/thread-98119-1-1.html58实践系列常用的日期操作https://bbs.huaweicloud.com/forum/thread-92120-1-1.html59实践系列如何快速识别被阻塞的SQL语句是不是被其他语句持有锁导致的？https://bbs.huaweicloud.com/forum/thread-90184-1-1.html60实践系列查看表及索引大小https://bbs.huaweicloud.com/forum/thread-87142-1-1.html61实践系列DWS   服务器选型很重要！！！！！！！！！！！！！！！https://bbs.huaweicloud.com/forum/thread-86286-1-1.html62实践系列DWS分页排序https://bbs.huaweicloud.com/forum/thread-81754-1-1.html63实践系列一种获取表结构的方法https://bbs.huaweicloud.com/forum/thread-81612-1-1.html64实践系列表空间提取 -   schema维度提取表大小及倾斜率https://bbs.huaweicloud.com/forum/thread-81495-1-1.html65实践系列终止运行时间过长的sql   session的方法https://bbs.huaweicloud.com/forum/thread-81492-1-1.html66实践系列记一次单表查询慢的定位过程https://bbs.huaweicloud.com/forum/thread-81113-1-1.html67实践系列行存表和Btree索引的应用实现语句的秒级返回https://bbs.huaweicloud.com/forum/thread-76279-1-1.html68实践系列DataStudio工具如何设置保存登录密码？https://bbs.huaweicloud.com/forum/thread-76084-1-1.html69实践系列数据库开发技巧之数据库表长度限制https://bbs.huaweicloud.com/forum/thread-76019-1-1.html70实践系列WITH 中用多个CTEhttps://bbs.huaweicloud.com/forum/thread-75517-1-1.html71实践系列GaussDB(DWS)角色赋予角色后关系字典查询https://bbs.huaweicloud.com/forum/thread-75276-1-1.html72实践系列DWS for GaussDB   生成随机字符串的方法https://bbs.huaweicloud.com/forum/thread-74944-1-1.html73实践系列DWS for GaussDB   生成随机字符串的方法https://bbs.huaweicloud.com/forum/thread-74942-1-1.html74实践系列DWS for GaussDB 中in   与join 在遇到重复数据时的区别https://bbs.huaweicloud.com/forum/thread-74913-1-1.html75实践系列upsert语句怎么改写？https://bbs.huaweicloud.com/forum/thread-73699-1-1.html76实践系列GaussDB多值入参场景实现方法https://bbs.huaweicloud.com/forum/thread-71314-1-1.html77实践系列GaussDB(DWS)多行转一行(列转行)聚合函数listagghttps://bbs.huaweicloud.com/forum/thread-71153-1-1.html78实践系列使用latin1存储了汉字，怎么按照汉字做匹配运算？https://bbs.huaweicloud.com/forum/thread-70943-1-1.html79实践系列存储过程中获取当前schemahttps://bbs.huaweicloud.com/forum/thread-70770-1-1.html80其他【openGauss   1.0.0】【创建表】报错目前不支持分布式功能https://bbs.huaweicloud.com/forum/thread-112260-1-1.html81其他查看数据库设置的参数https://bbs.huaweicloud.com/forum/thread-102611-1-1.html82其他GaussDB for DWS生产应急指导https://bbs.huaweicloud.com/forum/thread-102389-1-1.html83其他为什么高斯DB(DWS)列存表不适合小量   insert 及update操作https://bbs.huaweicloud.com/forum/thread-100112-1-1.html84其他【GaussDB A   6.5.1】【copy】copy导数时空值的处理https://bbs.huaweicloud.com/forum/thread-98570-1-1.html85其他GaussDB 与netezza   个别语法区别https://bbs.huaweicloud.com/forum/thread-93271-1-1.html86其他GasussDB(DWS)   结果集不稳定问题集锦https://bbs.huaweicloud.com/forum/thread-93116-1-1.html87其他DWS日志介绍、典型故障与应急处理https://bbs.huaweicloud.com/forum/thread-91731-1-1.html88其他SQL查询最佳实践https://bbs.huaweicloud.com/forum/thread-91308-1-1.html89其他DWS例行运维https://bbs.huaweicloud.com/forum/thread-91307-1-1.html90其他为什么DWS上自定义的job不生效？https://bbs.huaweicloud.com/forum/thread-91072-1-1.html91其他DWS技术指标分享https://bbs.huaweicloud.com/forum/thread-90061-1-1.html92其他【CDM产品】【数据迁移功能】CDM在执行调度抽取全量数据的时候经常READ   out ，但是单独手工执行调度是成功的https://bbs.huaweicloud.com/forum/thread-87316-1-1.html93其他安装gsql客户端https://bbs.huaweicloud.com/forum/thread-85798-1-1.html94其他物理服务器cpu核数的理解https://bbs.huaweicloud.com/forum/thread-81732-1-1.html95其他记一次集群响应速度慢的问题分析过程https://bbs.huaweicloud.com/forum/thread-77794-1-1.html96其他gaussdb   inode耗尽的现象原因及处理方式https://bbs.huaweicloud.com/forum/thread-75708-1-1.html97其他GaussDB(DWS)提取指定日期一个月第几个星期等信息https://bbs.huaweicloud.com/forum/thread-71934-1-1.html98其他GaussDB(DWS)中从字典表中批量查看表中字段有哪些定义索引与约束https://bbs.huaweicloud.com/forum/thread-70898-1-1.html99其他Migration   Tool支持MySQL业务SQL迁移https://bbs.huaweicloud.com/forum/thread-14216-1-1.html【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

pivot/unpivot是teredata中用来做行列转换的操作，常用于报表展示场景。GaussDB(DWS)当前并不支持 pivot/unpivot 操作，本文尝试从业务改写的方式，在GaussDB(DWS)中实现类似的功能， 具体参见链接