• [技术干货] 揭秘618大促背后的黑科技:为何几百万人同时下单的秒杀,为什么越来越容易抢到了?
    【摘要】 几百万人同时下单,你抢到的概率为何越来越大?电商企业又是如何掌握大促期间上亿的销售数据?      把心仪的商品加入购物车,点击结算,付款,商品页面的销量+1,库存量-1,如果只有几十个人下单,系统轻松应付,但是当这个数量变为百万、千万,就是另一番情形了。电商企业在大促期间面临流量访问压力:网站的访问用户激增让单服务器超负荷运行,从而导致网站访问卡顿或失败,严重影响用户体验,弹性负载均衡服务可以轻松解决这个难题。弹性负载均衡:哪里压力大往哪里搬      弹性负载均衡(Elastic Load Balance,简称ELB)是将访问流量根据转发策略分发到后端多台服务器的流量分发控制服务,华为云的ELB就可以通过流量分发扩展应用系统对外的服务能力,并通过消除单点故障提升应用系统的可用性。      面对不同的电商业务需求,ELB可以灵活处理。举个例子,对于业务量访问较大的业务,可以通过ELB设置相应的转发规则,将访问量均匀的分到多个后端云服务器处理;对于存在潮汐效应的业务,可以随时在ELB上添加和移除后端云服务器,比如在大促第一波高潮前增加服务器,到了中期再移除,最后收尾的时候重新加上。      这样既能保证大促期间,商品页面不会因为过多访问而阻塞,也能控制成本的开支。但运营人员如何知道什么时候添加/减少服务器,什么时候为ELB设置转发规则,就得对整个促销的节奏以及自家产品数据有基本的预判。      所以,大促期间,除了访问流量压力,更让人头疼的则是数据的实时分析管理能力。数据仓库:有货没货,卖了多少单,系统门清      通常情况下,电商数据主要分两块:第1类是面向交易的订单、商品、活动、发货等数据;第2类是平台运行的实时日志及用户在平台上活动产生的行为数据。      如果企业无法应对大规模在线交易及“实时分析”的业务要求,这“618”这样的大促中就无法掌握主动权。      举个例子,某运动服饰类电商企业原有系统采用传统解决方案,交易和BI相互独立。交易平台采用分布式中间件+单机版数据库搭建。由于该方案不具备数据的强一致性能力,在同一时刻系统中数据可能是不完整、不准确的,比如一分前已经销售了100单,但库存没有变化,最后为销售对单带来极大困难。为保证数据的最终一致性,交易系统数据需要通过ETL工具时隔数小时后同步到BI系统,无法做到实时分析,销售及运营主管无法实时掌握经营情况。      为了解决这个问题,他们后来采用了华为云混合负载数据仓库DWS。DWS采用“一库两用”的设计理念,一套数据仓库集群既可以支持超高并发、低时延的业务交易请求,同时可支撑复杂的海量数据分析和BI应用,减少开发和运维成本。相比于原系统,BI系统时效性大大提高,且数据分析性能提升3倍。      做到数据实时一致的同时,DWS也确保了对单数据的准确,以及运营报表的“零”时延。      DWS小规模可支持万级TPS的写入能力,横向扩展后可达百万至千万级TPS,支撑该电商企业平稳度过 “双十一”、“双十二”。而且由于它原生具备分布式事务ACID特性,具有数据的强一致性保证,在任何时刻均可保证交易系统数据的准确性、完整性,确保对单数据无误。再加上DWS的高可用架构设计,提供自动化数据备份功能,可靠性达到小数点后的11个9,保障业务数据不丢失。数据可视化:销售有没有破纪录,就看它了      当我们把不同系统模块数据整合到数仓中,让它进一步清洗、整合、规则处理,实现实时、完整以及准确的数据后,还需要通过数据可视化平台推送到产品及运营人员进行可视分析。      华为商城之前就将电商大数据应用由TIDB+Spark集群搬迁到基于华为云以DWS数据库为核心的数仓平台中。      在数据的实时集成方面,华为云提供了基于Flink、Spark两种流计算引擎的CS流计算服务。随着Flink社区的活跃及FlinkSQL对应用开发者极大的门槛降低,通过SQL的形式即可实现流计算。      华为云将通用的消息中间件封装成对应数据输入的source算子,逻辑层用SQL作为表示,各种数据存储平台作为sink算子封装。如果用原生Flink API的方式,开发及发布一个简短的输入输出任务,起码2小时才可以完工,但现在一站式的流计算平台10分钟即可完成。 而且进行语法校验后,绝大多数问题都可以在这个环节规避,发布之后,就能通过数据可视界面,查看其输入输出的数据信息进行校验监控。      BI数据可视模块选择的是华为云DLV服务,以大屏场景为主。华为商城某次大促活动需要临时加一个指挥大屏看数据,2个开发人员加了2小时班,一个做前台,一个处理数据逻辑,很快完成了0.1版本并发布,之后再持续迭代优化效果。图:某企业经营数据看板      核心数仓装备之外,DAYU数据开发套件平台可极大提升发布效率,DAYU以数据调度平台为核心作为扩展,融合了数据监控、元数据库管理、数据服务发布,这些服务华为商城大数据平台都有逐步使用。      简单介绍下其中开发人员最常用的DLF(调度平台),以一个数据API发布来说,开发人员先在DLF上开启一个Job,拖入三个任务:CDM(将TIDB任务集成到DWS)、2个DWS SQL(一个做DWR层规则处理,一个做数据DWD结果呈现),然后将结果表数据通过DAYU的DLG服务进行API发布,其他领域即可进行调用。      电商企业上云后,解决了基础设施的难题,得以把更多的精力聚焦在业务逻辑开发上,不用再考虑服务负载均衡,容灾等等,也降低了运维的负担和人力成本。对于消费者来说,大促期间的抢购体验更好,流量高峰期下单也能抢到心仪的商品。最后      电商在争夺消费者的战争中,技术的进步至关重要。从消费需求的产生,到购买行为的深入,从供应链到平台交易数据的分析管理,从直播带货的低时延到业务数据的安全,云计算、AI、大数据等技术的迭代,一步步改变在线购物的模式,也定义了新的商业模式。      曾经,AR/VR技术在内容呈现和消费者互动上提供了新的可能性,随着5G技术的成熟,以及经历前期高投入和试错后,模拟真实场景的VR购物,或许会让足不出户边逛边买成为一种常态化的购物模式。      在消费者的另一端——智慧物流侧,IoT、边缘计算、机器视觉、无人驾驶,这些技术已经在改变传统的物流仓储和运送体系,从自动化立体仓储、自动输送、自动分拣到机器人作业,规整统一的自动化操作提高了运作效率。      618是消费者购物狂欢的节日,它对电商企业也是一次大考,创新高的业绩背后考验他们的技术实力。换个角度看,618在拉动内需的同时,也拉紧了技术创新、产业升级背后的那根绳子。转载来自:华为云社区原文链接:https://bbs.huaweicloud.com/blogs/279700
  • [行业资讯] 聚力创新,华为云联合数据库领域合作伙伴共同发布四大解决方案
     5月18日,在华为中国生态大会2021“驱动数据创新,共建GaussDB生态”分论坛现场,华为云数据库CTO庄乾锋分享了GaussDB的全栈能力和生态合作计划,并联合行业合作伙伴共同发布了四大解决方案:迪思杰大型数据库高性能复制平台和GaussDB联合解决方案、帆软自助大数据分析平台FineBI和GaussDB联合解决方案、用友YonBIP和GaussDB联合解决方案、长亮银行分布式核心业务系统与华为云GaussDB联合解决方案,为企业数字化转型进一步注入了新动力。 驱动数据创新,共建GaussDB生态 庄乾锋表示,云数据库将加速成为市场主流,会有越来越多的政企核心业务与数据上云。数据库是专家密集型行业,需要软硬件全栈协同提升竞争力。华为云GaussDB坚持长期战略投入,布局全球7大研究所,汇聚了1000+数据库专业人才,同时立足华为云原生全栈能力,整合华为公司多元领域经验,软硬协同,打造了稳定可靠、极致性能的数据库服务。 数据库产业呼唤开放的生态,客户不希望从传统封闭生态再走向另一个封闭生态。华为云GaussDB以市场为导向,遵循“一套架构、两个生态”的理念,基于统一的计算存储分离架构,支持华为自有openGauss生态和主流开源数据库生态(如MySQL、MongoDB、Redis、InfluxDB等),实现生态兼容、层次解耦、数据融合等能力。新品金融级分布式云数据库GaussDB更是具备应对海量并发事务处理与复杂查询混合负载的能力,在和金融客户的联创考验中,证明了其出色的金融级高可用商用能力。 华为云与数据库领域合作伙伴重磅发布四大解决方案 本次论坛,华为云联合迪思杰、帆软、用友、长亮等合作伙伴共同发布了四大解决方案。方案一:迪思杰大型数据库高性能复制平台和GaussDB联合解决方案 迪思杰(北京)数据管理技术有限公司(简称DSG)总经理韩宏坤介绍道,DSG与华为云GaussDB联合打造的解决方案,通过DSG 高性能数据实时异构复制平台与华为云数据库平台合作互补,满足各种企业级数据交换场景;DSG基于数据库日志的企业级复制技术,与GaussDB开放生态、高性能等优势互补,实现数据的实时同步和满足信创需求;DSG数据采集、数据集成、数据**一体化对接GaussDB,实现了智能数据资产探测、迁移与治理一体化能力。此外,DSG与华为在数据复制和迁移领域展开了重要合作,在智慧东莞、海关总署、太平洋保险等合作项目中取得亮眼成绩。方案二:帆软自助大数据分析平台FineBI和GaussDB联合解决方案 帆软软件有限公司售前总监贺道友分享到,帆软基于华为云GaussDB数据库,联合创建了集收集、分析、管理为一体的数据平台解决方案,该方案实现了业务数据分析可视化,数据处理高效迅速,加速数据使能,充分发挥了数据价值,实现了跨部门协同沟通,提升了企业沟通效率。基于该联合方案,帆软助力正邦集团构建从数据接入到数据分析的“端到端”智能数据系统,让数据精准到业务流程每一步;实现数据统一分析、管理效果显著,节约了50%数据处理时间;同时降低开发、运维投入,成本下降50%。方案三:用友YonBIP和GaussDB联合解决方案 用友网络科技股份有限公司平台与数据智能事业部区域总监&技术专家阎翼介绍到, 为了推进企业基于数字化的商业创新,加速企业数字化转型,用友推出了YonBIP商业创新平台。YonBIP平台完成了用友云服务与华为Docker、K8s、GaussDB等基础服务的深度适配,联合打造了云原生解决方案、全栈国产化方案以及“华为云+用友企业云服务”最佳方案等系列方案。尤其在亿级数据量性能验证过程中,YonBIP平台基于GaussDB在亿级数据量下的性能测试结果优于其他云数据库,其响应更快,资源占用更少,非常适用于大数据量、高并发、高负载等企业复杂场景。方案四:长亮银行分布式核心业务系统与华为云GaussDB联合解决方案 深圳市长亮科技股份有限公司解决方案总监张杰介绍到,长亮积极携手华为投身到鲲鹏生态整体体系建设和鲲鹏生态全面融合工作中,有力保障了银行核心业务系统数据安全,为银行核心系统业务发展保驾护航。长亮分布式核心系统基于GaussDB数据库等华为云基础服务能力,构建了强有力的竞争优势。尤其在某国有大行核心系统建设过程中,华为云GaussDB数据库高度匹配长亮分布式核心系统,完成了各项性能指标的验证,获得了优异的成绩,符合客户方预期。 数据库生态建设是一个长期艰巨的过程,华为云GaussDB会始终坚持生态开放,联合更多伙伴携手共建良好数据库生态,持续助力企业智能化升级,共赢产业新机遇。
  • [其他] 【咨询】活跃视图中,一条sql的query_start没变,query_id一直变化是怎么回事
    现网处理问题过程中,遇到这样一种场景,查询活跃视图,有一条语句的query_start时间很早,query_id后台一直在变化,gstack抓取堆栈为:问题原因:该堆栈是语句分片的堆栈,在客户端输入多个连续语句,中间分号隔开,这种情况下,需要对传入的整个字符串进行分片,每个语句逐条执行,逐条执行时每个语句对应的query_id不同。因此,出现该问题的原因是客户输入的字符串长度太长,和客户确认后,该字符串大小为250M,包含上千万条语句,因此整个过程执行时间较长。这种情况是正常现象,等语句正常执行完即可。不过不建议一次传入的语句过多,过多会导致语句分片的时间开销增多,性能变差。
  • [实践系列] 处理执行sql文件时,某个sql语句报错,需要继续执行其余sql,直至所有sql执行完毕。
    可以对sql文件中报错的sql语句处利用匿名块,对报错sql语句捕获异常处理例如DECLARE   declarationsBEGIN    sql语句EXCEPTION    WHEN others  THEN         RAISE NOTICE 'sql exec error';END;
  • [开发应用] 【GaussDB A产品】【sql脚本执行功能】脚本文件中的某个语句sql语句报错,怎样才能不退出继续执行其余的sql语句
    【功能模块】sql脚本文件执行【操作步骤&问题现象】在使用命令 gsql -d  postgres -p port - f filed 执行某个sql文件时,里面的某个sql执行报错,此时会退出脚本文件的执行,但是怎样才能继续执行其余的sql语句,直至所有sql语句执行完毕oracle处理这种问题的办法是在执行sql语句前面加‘whenever sqlerror continue none ;’我想了一个办法,是利用匿名块来捕捉异常,还有其他办法么?类似于oracle这种处理方法
  • [其他] 【OS】 集群CPU高的一个案例
    问题描述集群中所有节点的CPU都非常高,接近90%左右,系统响应慢,集群中有10个节点。问题分析当出现CPU高的时候,通过以下几个SQL,抓取一下当前系统的并发和正在执行的语句:select coorname,  usename, datname, enqueue , count(*) from pgxc_stat_activity  where  usename <> 'omm' and state = 'active' group by coorname, usename, datname, enqueue ;select coorname, usename, client_addr, sysdate - query_start as dur, enqueue, query_id, replace(query, chr(10), ' ') from pgxc_stat_activity where usename!= 'omm' and state = 'active' order by coorname, dur desc;select sysdate - query_start as dur, waiting, enqueue, state, a.query_id, replace(substr(query, 0, 10), chr(10), ' '), node_name,thread_name,tid,lwtid,ptid,tlevel,smpid,wait_status,wait_event  from pgxc_stat_activity a, pgxc_thread_wait_status b  where state = 'active' and  a.query_id = b.query_id and a.query_id <> 0  order by a.query_id, 1 desc;通过第三条语句中等待视图的信息可以看到,单个语句执行计划达到了839层,执行的语句非常复杂,对应到系统中会有800多个stream线程并发来执行这个一个SQL语句,同时分析到该类型的语句并发执行的有20左右,因此会导致集群CPU飙升。解决方案1. 根据业务场景进行优化SQL。降低SQL复杂度。2. 推荐多租户方案,对单个租户的CPU使用率进行管控。
  • [互动交流] 使用DLI SQL报错count,请问下原因
    SQL 如下:SELECT http_method, count(http_method) FROM apigateway WHERE service_id = 'ecs' DISTRIBUTE BY http_method
  • [实践系列] GaussDB(DWS) 【低效SQL分析案例】
    SQL:select      t.ebeln  as ebeln    ,t.ebelp  as ebelp    ,t.werks  as werks    ,t.mwskz  as mwskz    ,t.txz01  as txz01    ,t.matnr  as matnr    ,t.matkl  as matkl    ,t.meins  as meins    ,t.menge  as menge    ,t.menge  as cmenge    ,t.netpr  as netpr    ,case when t.menge = 0 then t.netpr else round(t.brtwr/t.menge/decode(t.peinh,0,1,t.peinh),2) end as netprtax    ,t.netwr  as netwr    ,t.brtwr  as brtwrtax    ,t.brtwr-t.netwr  as tax    ,t.netwr  as cnetwr    ,t.brtwr  as brtwr    ,t.brtwr-t.netwr  as bghsk    ,t.retpo  as retpo    ,t.elikz  as elikz    ,t.banfn  as banfn    ,t.bnfpo  as bnfpo    , t.zdgdhxm  as zqgdhxm    ,t.konnr  as konnr    ,t.ktpnr  as ktpnr    ,t.zhtbh  as zhtbh    ,t.zhxm  as zhxm    ,t21_1.zqgdh  as zpr_id     ,t2.frgke  as frgke    ,t2.ekgrp  as ekgrp    ,t2.ekorg  as ekorg    ,t2.bstyp  as bstyp    ,t2.bsart  as bsart    ,case when t2.bedat = '00000000' then '' else cast( t2.bedat as date) end    as bedat    ,t2.ernam  as ernam    ,t2.lifnr  as lifnr    ,t2.waers  as waers    ,t2.zhtbglx  as zhtbglx    ,t2.verkf  as verkf    ,t2.telf1  as telf1    ,t4.budat  as budat    ,t5.menge  as fpyzsl    ,t25.bcqkje as wrbtr           ,t5.menge  as fpjysl    ,t8.eindt  as eindt    ,t8.wemng  as wemng    ,t9.pspsppnr  as ps_psp_pnr    ,t.menge-t8.wemng  as wzcgddsl    ,t10.name1  as name1    ,t11.maktx  as maktx    ,t12.prart  as prart    ,t12.post1  as wbspost1    ,t12.posid  as posid    ,t13.pspid  as pspid    ,t13.post1  as propost1    ,t14.eknam  as eknam    ,t15.text1  as text1    ,t16.batxt  as batxt    ,t17.pratx  as pratx    ,''              as kbetr           ,t19.vtext      as vtext       ,t20.ZGLIFNR          as gwven      ,case when t2.ZRETURN_DATUM = '00000000' then '' when  t2.ZRETURN_DATUM =' ' then '' else cast( t2.ZRETURN_DATUM as date) end as wzdat     ,t23.bidinteger  as zbnum    ,t21_1.zzbjhbh  as zzbjhbh     ,t.lgort  as lgort    ,t.infnr  as infnr    ,t.ktmng  as ktmng    ,t.bprme  as bprme    ,t.bpumz  as bpumz    ,t.bpumn  as bpumn    ,t.umrez  as umrez    ,t.umren  as umren    ,t.peinh  as peinh    ,case when t.agdat = '00000000' then '' when  t.agdat =' ' then '' else cast( t.agdat as date) end     as agdat    ,t27.bwtar  as bwtar     ,t.bwtty  as bwtty    ,t.pstyp  as pstyp    ,t.knttp  as knttp    ,t.wepos  as wepos    ,t.weunb  as weunb    ,t.repos  as repos    ,t.webre  as webre    ,case when t.abdat = '00000000' then '' when  t.abdat=' ' then '' else cast( t.abdat as date) end as     abdat    ,t.zwert  as zwert    ,t.bstyp  as bstyp_ekpo    ,t.sobkz  as sobkz    ,t.fistl  as fistl    ,t.fipos  as fipos    ,t.bonba  as bonba    ,t.zbbh  as zbbh    ,t.bhzb  as bhzb    ,case when t.zjcdj=' 'then ''   else t.zjcdj end as zjcdj    ,case when t.zjccj=' 'then ''  else t.zjccj end as zjccj    ,case when t.zjcfxjj=' 'then ''  else t.zjcfxjj end    as zjcfxjj    ,case when t.zjcfxzj=' 'then ''  else t.zjcfxzj end     as zjcfxzj    ,t.mandt  as mandt_ekpo    ,t.idnlf  as idnlf    ,t.webaz  as webaz    ,t.spinf  as spinf    ,t.kzvbr  as kzvbr    ,t.abmng  as abmng    ,case when t.prdat = '00000000' then '' when  t.prdat =' ' then '' else cast(t.prdat as date) end               as prdat    ,t.effwr  as effwr    ,t.xoblr  as xoblr    ,t.arsnr  as arsnr    ,t.arsps  as arsps    ,t.brgew  as brgew    ,t.volum  as volum    ,t.packno  as packno    ,t.uebpo  as uebpo    ,case when t.lewed = '00000000' then '' when  t.lewed =' ' then ''else cast(t.lewed as date) end               as lewed    ,t.anzpu  as anzpu    ,t2.bukrs  as bukrs    ,t2.statu  as statu    ,t2.zterm  as zterm    ,case when t2.kdatb = '00000000' then '' when  t2.kdatb =' ' then '' else cast( t2.kdatb as date) end    as kdatb    ,case when t2.kdate = '00000000' then '' when  t2.kdate =' ' then '' else cast( t2.kdate as date) end    as kdate    ,case when t2.bwbdt = '00000000' then '' when  t2.bwbdt =' ' then '' else cast( t2.bwbdt as date) end    as bwbdt    ,t2.konnr  as konnr_ekko    ,t2.reswk  as reswk    ,t2.lifre  as lifre    ,t2.frggr  as frggr    ,t2.frgsx  as frgsx    ,t2.frgzu  as frgzu    ,t2.frgrl  as frgrl    ,t2.procstat  as procstat    ,t2.rlwrt  as rlwrt    ,t2.ebeln  as ebeln_ekko    ,t21_1.zsczt  as zsczt     ,t2.zhtbh  as zhtbh_ekko    ,'' as zjcjzj        ,'' as zjcczj      ,t21_1.zqgdh  as zpr_id_ekko     ,t2.mandt  as mandt    ,t2.bsakz  as bsakz    ,t2.pincr  as pincr    ,t2.lponr  as lponr    ,t2.spras   as spras    ,t2.zbd1t  as zbd1t    ,t2.zbd2t  as zbd2t    ,t2.zbd3t  as zbd3t    ,t2.zbd1p  as zbd1p    ,t2.zbd2p  as zbd2p    ,case when t2.angdt = '00000000' then '' when  t2.angdt =' ' then ''else cast( t2.angdt as date) end    as angdt    ,case when t2.bnddt = '00000000' then '' when  t2.bnddt =' ' then ''else cast( t2.bnddt as date) end    as bnddt    ,case when t2.gwldt = '00000000' then '' when  t2.gwldt =' ' then ''else cast( t2.gwldt as date) end    as gwldt    ,case when t2.ihran = '00000000' then '' when  t2.ihran =' ' then ''else cast( t2.ihran as date) end    as ihran    ,t2.weakt  as weakt    ,t2.stako  as stako    ,t2.lands  as lands    ,t2.stceg_l  as stceg_l    ,t2.memory  as memory    ,case when t2.eq_eindt = '00000000' then '' when  t2.eq_eindt =' ' then ''else cast( t2.eq_eindt as date) end   as eq_eindt    ,t2.key_id  as key_id    ,t2.otb_value  as otb_value    ,t2.otb_res_value  as otb_res_value    ,t2.otb_spec_value  as otb_spec_value    ,sysdate  as cqsj    ,''            as aut_strategy      ,t21_1.ZPUR_MODE  as aut_mode     ,t21_1.zjhdd  as zjhdd    ,t21_1.zjsgfid  as zjsgfid     ,t.zdgdhxm                 as zggdhxm      ,t.swidsl  as swidsl     ,''                   as wznum      ,''                   as wzuse      ,''                 as zzprp10      ,''                  as zebeln      ,''                  as zebelp     ,t.meins                  as csdw     ,t.menge                 as cssl     ,t21_1.zqgdh  as zqgdh    ,t2.zjfbh  as htbh     ,t.loekz  as loekzfrom erp_sapsr3.ekpo t       left join erp_sapsr3.ekko t2 on t.ebeln = t2.ebeln and t2.mandt = '800'     left join (                select ebeln,ebelp,vgabe,min(budat) as budat from sg_dwd_mat.dwd_mat_purchaseorderhistory where vgabe = '1' group by ebeln,ebelp,vgabe         ) t4 on t.ebeln = t4.ebeln and t.ebelp = t4.ebelp     left join sg_dwd_mat.dwd_mat_purchaseorderhistory t5 on t.ebeln = t5.ebeln and t.ebelp = t5.ebelp and t5.vgabe = '1' and t5.bewtp in ('t','a','q')     left join sg_dwd_mat.dwd_mat_plaagreplaline t8 on t.ebeln = t8.ebeln and t.ebelp = t8.ebelp and t8.mandt = '800'     left join sg_dwd_mat.dwd_mat_purorderaccassign t9 on t.ebeln = t9.ebeln and t.ebelp = t9.ebelp     left join erp_sapsr3.lfa1 t10 on  t2.lifnr = t10.lifnr  and t10.mandt='800'                        left join sg_dwd_mat.dwd_mat_matdes t11 on t.matnr = t11.matnr and t11.spras = '1' and t11.mandt = '800'              left join un_erp_sapsr3.un01_03_erp_cd_prps t12 on  t9.pspsppnr = t12.pspnr and t12.mandt = '800'     left join un_erp_sapsr3.un01_03_erp_cd_proj t13 on    t12.psphi = t13.pspnr and t13.mandt = '800'        left join sg_dwd_mat.dwd_mat_purgroup t14 on  t2.ekgrp = t14.ekgrp     left join un_erp_sapsr3.un01_03_erp_cd_t052u t15 on  t2.zterm = t15.zterm and t15.spras = '1' and t15.mandt = '800'       left join un_erp_sapsr3.un01_03_erp_cd_t161t t16 on  t2.bstyp = t16.bstyp and t2.bsart = t16.bsart and t16.spras = '1' and t16.mandt = '800'      left join un_erp_sapsr3.un01_03_erp_cd_tcj1t t17 on    t12.prart = t17.prart and t17.langu = '1' and t17.mandt = '800'      left join erp_sapsr3.tvzbt t19 on  t2.zterm = t19.zterm  and t19.mandt = '800'  and t19.spras = '1'      left join erp_sapsr3.zvendor_add_on t20 on  t2.lifnr = t20.lifnr and t20.mandt = '800'       left join un_erp_sapsr3.un01_03_erp_cd_ekpo t21 on t.ebeln = t21.ebeln and t.ebelp = t21.ebelp and t21.mandt = '800'     left join erp_sapsr3.eban t21_1 on t21.banfn = t21_1.banfn and t21.bnfpo = t21_1.bnfpo and t21_1.mandt = '800' and t.banfn <> ' '     left join un_erp_sapsr3.un01_03_erp_cd_ekko t22 on t.ebeln = t22.ebeln and t22.mandt = '800'     left join (                 select distinct * from sg_dwd_mat.dwd_mat_purchaserequisition where length(banfn) > 1              ) t23 on t.ebeln = t23.ebeln and t.ebelp = t23.ebelp     left join  erp_sapsr3.zfi22t_zjjh t25  on  t25.mandt='800' and t25.fkxz='A' and t25.ebeln=t.ebeln     left join  erp_sapsr3.ekbe t27 on t27.mandt='800' and t27.ebeln=t2.ebelnwhere t.banfn <> ' ' and t.mandt = '800' and t.ebeln not like '6%' and t.ebeln not like '7%';执行计划:分析:1)计划中49层-->19层算子,t表一直作为主表进行关联操作,当与与t14表进行关联时,结果集翻2倍+,从599万涨到1364万t表的的值在关联的t14表中过程中,关联字段ekgrp出现大量重复数据,导致结果集翻倍。2)计划中,5层到4层算子 join后结果集从1364万增加到51亿+,增长将近500倍,性能劣化严重。经验证,t表与t14的的结果集1364万与t27关联字段存在大量重复值,导致结果集增加到51亿+,增长将近500倍3)93层到91层算子,t27表因统计信息不准,预估scan结果集为300行,因此执行计划走的BROADCAST,会把结果集分发到每个DN用于下一层的HASH计算,但实际scan的结果集为1700w+,造成对大表广播,大量的文件传输,消耗IO资源,导致性能劣化。优化建议:1.对SQL相关表更新统计信息,保证SQL执行时,优化器有准确的统计信息作为参考,生成高效的执行计划。2.关联过程中存在大量关联字段重复数据,导致结果集膨胀,说明业务数据质量不高,请结合业务提前清晰重复数据。
  • [互动交流] 如何用IDEA 上的database 连接数据湖,在IDEA 读取到schema信息,或直接执行SQL
    【功能模块】【操作步骤&问题现象】1、2、【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [运维管理] 【gaussdb A】有sql缓冲池命中率的概念吗
    有sql缓冲池命中率的概念吗有的话命中率怎么查看呢
  • [运维管理] 【Gaussdb 200 6.5.1产品】系统用户OMM下有大量的SQL在执行,没有DML的操作的时候状态为IDLE
    【功能模块】Gaussdb 200 6.5.1产品【操作步骤&问题现象】1、系统用户OMM下有大量的SQL在执行,没有DML的操作的时候状态为IDLE,当有INERT入库的时候,这些OMME下的SQL状态为ACTIVE,用户想了解这些系统用户OMM调用的SQL,这些SQL主要是在做哪些操作,为什么会有这系统任务,如下图:
  • [运维管理] 【Gaussdb A 8.0】PG_STAT_ACTIVITY视图中的query字段不能显示较大的SQL内容
    你好,对于 PG_STAT_ACTIVITY视图中的query字段,在SQL * FORM PG_STAT_ACTIVITY; 查询的query显示SQL不全,请问对于比较大的SQL为什么 显示不全,有什么解决办法,或调整相关参数能解决吗!(
  • [实践系列] GaussDB(DWS)【用SQL方式查询所有带主键的表的主键字段方法】
    SQL:select n.nspname as schemaname ,c.relname as tablename,rtrim(ltrim(pg_get_constraintdef(p.oid),'PRIMARY KEY ('),')') as column_pk from pg_class c inner join pg_namespace n on c.relnamespace=n.oid inner join pg_constraint p on c.oid=p.conrelid where p.contype='p';eg:
  • [实践系列] GaussDB(DWS)【通过SQL方式查询分区表的的分区字段方法】
    查询SQL如下:select a.attname from pg_class c left join pg_namespace n on c.relnamespace=n.oid left join pg_partition p on c.oid=p.parentid left join pg_attribute a on p.partkey[0]=a.attnum and  a.attrelid=c.oid  where   p.parttype='r'and n.nspname ='schemaname'and c.relname ='tablename';备注:查询时请替换SQL中红色内容替换为schema名及表名eg:select * from dba_tab_partitions where table_name='a_rcvbl_entry';
  • [技术干货] SQL
    结构化查询语言(Structured Query Language)简称SQL,是一种数据库查询语言。作用:用于存取数据、查询、更新和管理关系数据库系统。
总条数:865 到第 页
上滑加载中