采用spark将计算好的数据写入高斯数据库，提示invalid input syntax for type oid:"xxxxx"。导致部分数据无法写入oid这个是系统表中对数据库资源的标志吧，sql中没有修改这个字段。这个异常具体怎么回事，有大神能够帮忙解释一下吗？

GaussDB(for Influx)支持哪些hint查询

云计算时代，云数据库的需求和技术也在不断的发展，华为云数据库GaussDB是华为自主创新研发的分布式关系型数据库。该产品具备企业级复杂事务混合负载能力，同时支持分布式事务，同城跨AZ部署，数据0丢失，支持1000+的扩展能力，PB级海量存储。同时拥有云上高可用，高可靠，高安全，弹性伸缩，一键部署，快速备份恢复，监控告警等关键能力，能为企业提供功能全面，稳定可靠，扩展性强，性能优越的企业级数据库服务。为了让各位开发者0距离体验GaussDB、GaussDB(for MySQL)等产品，特举办《与数据库同行的日子》有奖征文活动，提供一个沙箱实践和一个实操手册，以便大家可以更好地学习和使用华为云数据库产品。☞参与规则第一步：体验GaussDB、GaussDB（for MySQL）等产品点我进行沙箱实验- GaussDB数据库应用程序开发实验点我获取现网实操- GaussDB(for MySQL)场景化综合应用实验（见文末底部附件）点我前往产品免费体验区-云数据库第二步：围绕如下主题之一发表文章① 产品体验：体验GaussDB、GaussDB(for MySQL)等产品，撰写产品体验反馈，如体验感受，使用后建议，操作使用方法等内容。② 最佳实践：分享在使用华为云GaussDB、GaussDB(for MySQL)等产品过程中，解决痛点问题或者完成应用开发实践的案例，进行性能优化、预测性维护、风险排查、NL2SQL等的实践内容。③ 技术攻坚：分享在数据库技术攻坚过程中遇见的技术和理论的难题、解决方向、以及成功的解决方案等内容。④ 人物图鉴：分享与数据库相关的身份在生活和工作中的故事，内容用到的技术手段、收获的感受、困惑和奇思妙想等，比如“数据库应用开发的一天”。☞格式要求1、标题必须以【华为云GaussDB：与数据库同行的日子】结尾，例如华为云GaussDB性能优化【华为云GaussDB：与数据库同行的日子】2、文章需打上【云数据库GaussDB】/【云数据库GaussDB（for MySQL）】/【云数据库GaussDB（for Redis）】/【云数据库GaussDB（for Influx）】/【云数据库GaussDB（for Cassandra）】的标签（至少包含一个） 3、文章末尾需加上活动名称及链接地址，如：我正在参加【有奖征文 第28期】华为云GaussDB：与数据库同行的日子！ 链接：4、建议投稿内容字数不少于500字（不含代码段），语句通顺、文章逻辑清晰、排版整洁、代码规范，尽量图文并茂（有技术架构图或者分析图等做支撑）。5、文章保证原创首次发布，如发现投稿内容为转载、复制、抄袭、恶意拼接、灌水等侵权作弊行为，均视为无效并取消参与资格。6、文章须符合征文主题及平台内容规范，不得出现违规负面内容。详见华为云开发者平台内容互动使用协议。7、 参加征文活动的文章作者拥有著作权，华为云拥有使用权、修改权等。点此立即发表博文· 以上奖品均为实体奖品，具体视出库情况而定。☞评分规则专家评分依据 ：文章篇幅、经验含金量、排版美观度、阅读量、点赞、收藏等指标综合评分。其他说明： 1、一二三等奖不能叠加。 2、参与奖不与一二三等奖叠加。 3、本期征文的一二三等奖对应四个主题方向分别设置1名、2名和7名。 4、有奖征文投稿数量不计入月度激励活动（即社区明星评选）文章数量。☞你将获得什么？我们会把收到的优质内容汇编成册，并注明原作者，积累行业口碑，开放给圈内开发者下载查阅，提供实践参考。对于贡献优质内容的作者，我们还将送出各项大礼！同时，在华为云站内外10+个技术社区醒目位置进行推荐，给与百万级流量资源。优质作者更可获得长期约稿和更多内容合作机会。☞问题咨询如果有任何问题，可扫描下方二维码咨询。添加微信时请备注：有奖征文+华为云博客昵称！如果大家在征文中遇到有关华为云产品体验方面的问题建议，请到【云声平台】提出您的宝贵建议，标题以【云驻计划-定向征文】开头，还有机会赢取额外奖励。快来华为云社区博客，一起遨游技术海洋吧！ 点击立即体验☞部分奖品展示定制保温杯 定制保温杯 游戏机礼盒 定制双肩包 手机支架 定制折叠雨伞 定制连帽卫衣 定制笔记本 定制笔记本

产品文档-基于模板创建流水线 章节  表6 params  alias代码仓别名 建议说明下别名不允许-字符，可以是大小写字母数

1.背景华为云GaussDB(for Influx) 集群版时序数据库构建了高可靠、高可用、高性能、高可扩展性、免运维等特性，使得客户不用担心数据库层面的问题，更多专注于其自身应用的开发设计，成为很多客户的业务首选。相对于MySQL等传统数据库，“新”的时序数据库在设计和使用方面有比较大的差异，数据模型和使用方式对于大多数开发者来说比较陌生，需要更多的实例进行测试、调试。在非生产环境中，例如开发、测试场景下，对性能、可靠性没有诉求，成本成为首要的考虑因素；如果选择自己搭建环境用于开发、测试，虽然解决了成本问题，但是维护麻烦、操作复杂，遇到问题不能及时处理，也非常影响开发测试效率。因此，针对性能、可靠性要求不高、成本敏感的使用场景，GaussDB(for Influx)推出了单机版方案。该方案可用于开发、测试等场景，既能享受到服务化带来的便利，也可以明显地降低使用成本。2.GaussDB(for Influx)单机版极致成本很多客户在使用数据库时，觉得在不考虑高可用性、性能和扩展性的测试、开发场景下，完全可以自己购买ECS搭建一套数据库，这样虽然麻烦，但是可以降低使用成本，毕竟云数据库也是基于ECS建立的，“面包”肯定是比 “面粉”贵吧。GaussDB(for Influx)团队结合多方实践使用经验，综合考虑成本、稳定性和可运维性等各种因素，单机版方案选择了1:2的超高性价比规格，同时支持4种不同的规格以满足不同场景的需求，下表是单机版支持的规格类型和对应的费用：规格单机版（元/月）自建ECS（元/月）4U8G486.94898U16G973.895016U32G1947.6171232U64G3895.23396注：费用对比只是针对计算资源，存储资源根据数据量大小按需购买可以看到GaussDB(for Influx)单机版价格做到和自建基本持平，在4U8G的规格下，甚至比自建购买ECS还便宜。GaussDB(for Influx)单机版在做到了“面粉”和“面包”价格基本持平的同时，提供了自建不具备的许多服务化能力。3. GaussDB(for Influx)单机版能力优势3.1 云服务即开即用，免运维数据库虽然是基础软件，但是它的搭建也需要一系列基础服务作为支撑。客户在购买云上ECS后，通常需要自行选择合适的数据库版本，按照当前的ECS规格修改合适的配置参数，实现基本的高可用能力。在完成上述工作后，还需要搭建监控系统保障基础运维。相比之下，使用云数据库的客户完全不用担心上述复杂的工作，可专心聚焦于自身业务的实现和优化，如下图所示：特别是在批量、频繁的创建和删除环境时，上述的手动操作会特别繁琐、耗时且容易出错。数据库创建完成后，后续的运维也是极具考验经验的工作，如果是对不熟悉的数据库，一个简单的问题就可能会阻塞开发、测试，最终可能影响项目的整体进度。反观云数据库的操作就非常简单、方便。只要在页面上简单点击选择就可以购买创建，选择相应的存储大小、填写密码即可，极大提升了操作效率。最主要的是，在遇到问题时云数据库背后有经验丰富的运维团队来保障，常见问题可以达到分钟级恢复。除了在使用和部署上的方便之外，云数据库内核针对不合理的业务使用做了很多的规范限制，使得客户在业务开发、测试阶段就可以发现问题，并及时优化和调整，保障正式业务的稳定。3.2 限制不合理查询GaussDB(for Influx)在数据库内核层面做了很多限制和规范，对于不合理的使用不允许执行，并给出优化建议，遵循这些规范可有效提升业务运行的稳定性。禁止不带时间范围的查询执行时序数据有很强的时间属性，数据库的内部组织也是严格按照时间属性的，这是相对于其他数据库很大的区别。如果不带时间范围的查询，就会导致数据库查询全部数据，大概率会导致数据库发生OOM问题，影响业务稳定性。禁止执行select * from语句查询大多数真实业务场景是需要指定具体的查询字段的，只是由于开发习惯等各种原因而使用了select * from进行查询。这种写法有两个潜在的问题：1.返回结果可能不确定，GaussDB(for Influx)是schemaless模式的，可以随时添加和减少tag，field，这样随着业务的变化select*返回的结果可能会出现不一致，容易导致业务在解析返回结果时发生异常；2 select* 返回了所有字段的值，但是实际上有用的只有某几个字段，这样有大量数据传输是无效的，浪费了网络带宽，也浪费计算、内存等资源。因此在开发规范中我们不建议使用这种方式查询，在内核中也会对这种查询进行拦截。查看慢日志能力云服务的慢日志能力，使得在业务开发阶段能及时发现慢查询，及时进行优化调整。限制每条查询涉及的时间线和field数量如果一条查询涉及的时间线或者field数量太多，说明这个查询可能会查询太多的数据，数据库会把这些数据都加载到内存中，很容易导致OOM，影响业务稳定性。而涉及的太多时间线或者field，大多数场景下是因为我们所写的查询语句不合理导致的，需要进一步优化。4.总结GaussDB(for Influx)是一款基于计算存储分离架构，兼容InfluxDB生态的云原生时序数据库，此次推出的单机版模式，在保留云数据库优势的同时做到和自建ECS价格基本持平，满足业务对可用性、可靠性要求不高场景下对低成本的诉求。

目前ps ux | grep gauss命令显示 结果：root       34723  0.0  0.0  21992  2228 pts/1    S+   15:01   0:00 grep --color=auto gauss但是不知道它安装目录放哪里了，gs_ctl query报找不到命令..........gsql也找不到命令.......

新应用驱动的数据库(5G、车、终端云)从数据库诞生开始,新的应用领域就不断为数据库带来新诉求,例如巨大的数据量、更短的数据处理时间、更高的可靠性、新的数据类型,而数据库也在满足这些新的诉求的同时得到不断的发展与更新。一、 及其相关应用对数据库系统带来的挑战与机遇从历史上看,通信技术对数据库发展起到了至关重要的作用：1980—1990年,TCP/IP网络协议出现,大中型企业内部开始规模部署局域网,甚至通过卫星技术将地域上分散的局域网互联互通,这推动了企业IT系统从主机时代走向客户端/服务端(Client/Server,C/S)时代。Oracle数据库抓住C/S架构下数据库系统需要应对更高并发、更多客户端连接的挑战,加大C/S架构数据库研发,在数据库市场上取得了决定性胜利,市场份额甚至接近当时企业IT 霸主IBM 的DB2数据库。上分散的局域网互联互通,这推动了企业IT系统从主机时代走向客户端/服务端(Client/Server,C/S)时代。Oracle数据库抓住C/S架构下数据库系统需要应对更高并发、更多客户端连接的挑战,加大C/S架构数据库研发,在数据库市场上取得了决定性胜利,市场份额甚至接近当时企业IT 霸主IBM 的DB2数据库。1990—2000年,互联网和万维网普及,对运营电子商务和在线购物公司的数据库系统提出更为艰巨的挑战,单一服务器无法满足运营公司对处理能力、数据容量等的诉求,且在线业务对服务的持续可用性也提出了更高的要求。Oracle公司抓住市场机会,推出了Oracle RAC集群数据库,在这一时期最终成为数据库市场的老大。2000年至今,移动互联网和智能手机兴起,用户从过去固定时间和地点接入互联网,到随时随地进行网络社交活动、在线支付和购物,即使集群数据库系统也无法满足性能、扩展性和服务可用性的诉求,必须从过去垂直扩展Scale-up(通过升级硬件配置提升性能)走向横向扩展Scale-out(通过增加新的服务器硬件提升系统整体性能)。分布式数据库系统从研究走入商用,这一时期的典型代表是谷歌公司于2012年发表的论文中阐述的Google Spanner分布式数据库系统。维基百科对5G(5th generation mobile networks or 5th generation wireless systems,第五代移动通信技术)的定义: 是最新一代蜂窝移动通信技术,是4G(LTEA、WiMAX-A)系统后的延伸。5G 的性能目标是具有高数据传输速率、减少延迟、节省能源、降低成本、提高系统容量和连接大规模设备。5G作为最新移动通信技术,其高带宽(吉比特每秒级)、极低延迟(毫秒级)的特征使其主要潜在应用于AR(Augmented Reality,增强现实)/VR(Virtual Reality,虚拟现实)、云游戏、实时视频通信、无人机、工业互联网等。这将对数据库系统带来新的挑战,体现在:终端设备到云端网络延迟通常上百毫秒,不利于充分利用5G 的低延迟特性,考虑在终端设备与云端之间部署中小型计算中心,这种部署称为边缘计算。如何将计算和数据在终端-边缘-云之间进行高效的协同,是新型数据库系统的研究方向。5G网络下,视频和计算机视觉相关应用将成为杀手级应用,如何解决图像的实时查询和分析等问题,也会成为新型数据库系统的热点话题。二、自动驾驶汽车对数据库系统带来的挑战与机遇根据维基百科对自动驾驶汽车的定义: 自动驾驶汽车能通过雷达、光学雷达、GPS(Global Positioning System,全球定位系统)及计算机视觉等技术感测其环境。先进的控制系统能将感测资料转换成适当的导航道路以及障碍与相关标志。根据定义,自动驾驶汽车能透过感测输入的资料,更新其地图信息,让交通工具可以持续追踪其位置。当前业界研发自动驾驶需要采集大量数据,包含来自车载传感器的各类时序数据(上百种)、激光雷达的点云(Point Cloud)数据、毫米波雷达数据、GPS定位数据、车载摄像头的视频数据等。自动驾驶汽车会产生海量数据,厂商会采集并在云端存储某些车辆数据,用于研发。典型数据量如下:600GB/h-radar;140GB/h-lidar;3.2TB/h-camera;40GB/h-sonar;6GB/h-CANbus。厂商一般在云端需要存储和管理数十PB(1PB=1000000GB)甚至更多数据量,如何高效地存储、管理和查询这些海量、异构、多模的数据,是当前自动驾驶领域面临的严峻挑战。三、终端云对数据库系统带来的挑战与机遇智能手机厂家为了给用户提供优良的体验,一般都构筑终端云服务,为用户提供云存储备份(如相册、短信、通讯录等),这极大方便了用户更换手机,即使用户手机丢失,但手机中数据无损。同时,如何保证用户数据隐私和安全是一个重大的技术挑战。2016年欧盟专门为数据隐私和安全提出新的法案《通用数据保护条例》(General Data Protection Regulation,GDPR,欧盟法规编号为(EU) 2016/679),是在欧盟法律中对所有欧盟个人关于数据保护和隐私的规范,涉及了欧洲境外的个人资料出口。GDPR主要目标为取回公民以及居民对于个人资料的控制,以及为了国际商务而简化在欧盟内的统一规范。当前数据库缺乏原生对用户数据隐私和安全的保障机制,这对终端云数据库提出新的挑战,例如:数据主体(Data Subject)有被遗忘权(Right to be Forgotten),即可以要求控制资料的一方,删除所有个人资料的任何连接、副本或复制品。数据库系统如何保证数据主体所产生的数据按照要求,正确、一致、稳妥地进行删除,这涉及数据主体所产生数据在不同子系统中流转的跟踪、所产生数据副本的管控与追溯、存储介质的擦除等难题。GDPR要求执行安全防护(Security Safeguards Principle),即个人资料应受到合理的安全保护,以防止丢失或未经授权的访问、破坏、使用、修改或披露数据等风险。这对数据库系统提出数据需要在存储、传输和计算中均保证安全、可信,不因为被攻击而产生数据泄露等难题。

1.   背景随着5G和IOT的快速发展，面对爆发式增长的时序数据，如何才能挖掘数据中的潜在价值，为客户的业务运行、商业决策提供精确的指导？在统计学中，直方图作为一种经典的分析工具，可以直观地描述数据分布特征，应用场景极其广泛，例如：在网络监控数据方面，通过直方图可以捕捉异常数据的分布区间，便于网络的自诊断与修复；在时序数据分析方面，通过直方图可以表示数据的分布特征，便于时序数据的特征提取；作为代价评估模型的输入从而指导数据库内部的查询优化；本文带您了解直方图在不同产品中的实现，以及GaussDB(for Influx)中直方图的使用方法。2.   直方图的实现方式时序及分析性数据库大部分都支持了直方图算子，但各个数据库中的直方图实现上也有一定差异，其中几种比较典型的直方图实现有：Druid：Druid-histogram拓展中提供了近似直方图（approximate histogram aggregator）和固定桶直方图（fixed buckets histogram）聚合器。其中近似直方图根据论文《A Streaming Parallel Decision Tree Algorithm》实现，较适用于随机分布的数据。ClickHouse：ClickHouse提供了自适应直方图，查询的结果为近似值。与Druid类似，其实现参考了论文《A Streaming Parallel Decision Tree Algorithm》。当新数据输入到直方图时，直方图中桶的边界会被调整，通常情况下，桶的宽度并不相等。 ElasticSearch：ElasticSearch中支持了HDR Histogram(High Dynamic Range Histogram)，HDR Histogram是一种替代实现，在计算网络延迟的百分位数表现良好。同时，当值的范围并不清楚时，官方并不建议使用HDR Histogram，因为此时内存占用会很高。InfluxDB v2.0：InfluxDB同样提供了直方图的实现，与其它直方图略有不同。InfluxDB2.0可以设置直方图的桶的生成方式，linearBins()可以将数据按照线性分割，即桶宽相等，logarithmicBins()则可以将数据按照指数分割，即桶宽呈指数形式增长。GaussDB(for Influx)：GaussDB(for Influx)支持两种直方图类型查询，一种确定桶数的等高直方图，另一种确定桶边界的定界直方图。等高直方图指每个桶的高度接近的直方图，而定界直方图指设定桶的上下边界值的直方图。定界直方图支持用户的自定义，更方便用户根据业务特点提取数据的关键分布特征。支持四种数据类型，包括整数、浮点数、字符串与布尔类型，可满足各行各业的数据分析需求。 3.   GaussDB(for Influx)直方图使用本章节通过实际的数据样例介绍GaussDB(for Influx)直方图的使用。3.1 数据样例示例采用的数据如下：mst是表名，包含4个field(每个field对应一种数据类型)与2个tag，元数据如下：> show field keys name: mst fieldKey fieldType -------- --------- address string age integer alive boolean height float > show tag keys name: mst tagKey ------ country name原始数据如下：> select * from mst name: mst time address age alive country height name ---- ------- --- ----- ------- ------ ---- 1629129600000000000 shenzhen 12 true china 70 azhu 1629129601000000000 shanghai 20 false american 80 alan 1629129602000000000 beijin 3 true germany 90 alang 1629129603000000000 guangzhou 30 false japan 121 ahui 1629129604000000000 chengdu 35 true ca** 138 aqiu 1629129605000000000 wuhan 48 china 149 agang 1629129606000000000 52 true american 153 agan 1629129607000000000 anhui 28 false germany alin 1629129608000000000 xian true japan 179 ali 1629129609000000000 hangzhou 60 false ca** 180 1629129610000000000 nanjin 102 true 191 ahuang 1629129611000000000 zhengzhou 123 false china 203 ayin3.2 等高直方图查询语法：SELECT HISTOGRAM( [ * | <field_key> | /<regular_expression>/ ] , <N> ) [WINTO_clause] FROM_clause [WHERE_clause] [GROUP_BY_clause] [ORDER_BY_clause] [LIMIT_clause] [OFFSET_clause] [SLIMIT_clause] [SOFFSET_clause]HISTOGRAM(field_key, N)计算指定指标field在各区间的统计值，其中N是要求的。HISTOGRAM(/regular_expression/, N)计算满足正则匹配的field在各区间的统计值。HISTOGRAM(*, N)计算整数与浮点数数据类型的field在各区间的统计值。查询示例1. 查询field_key为age且桶数为5的等高直方图。> select histogram(age, 5) from mst where time >= 1629129600000000000 and time <= 1629129611000000000 name: mst time histogram value ---- --------- ----- 0 20 3 0 30 2 0 48 2 0 60 2 0 9223372036854775807 22. 查询field_key满足正则匹配为/hei/(符合要求的只有height)且桶数为5的等高直方图。# 浮点数类型 > select histogram(/hei/, 5) from mst where time >= 1629129600000000000 and time <= 1629129611000000000 name: mst time histogram_height value ---- ---------------- ----- 0 90 3 0 138 2 0 153 2 0 180 2 0 1.7976931348623157e+308 23. 支持field为字符串类型的address与布尔类型的alive的等高直方图查询。> select histogram(address, 5) from mst where time >= 1629129600000000000 and time <= 1629129611000000000 name: mst time histogram value ---- --------- ----- 1629129600000000000 chengdu 3 1629129600000000000 hangzhou 2 1629129600000000000 shanghai 2 1629129600000000000 wuhan 2 1629129600000000000 zhengzhou 2 > select histogram(alive, 3) from mst where time >= 1629129600000000000 and time <= 1629129611000000000 name: mst time histogram value ---- --------- ----- 1629129600000000000 false 5 1629129600000000000 true 6下图分别表示上述查询的各等高直方图3.3 定界直方图查询语法：SELECT HISTOGRAM( [ * | <field_key> | /<regular_expression>/ ] , ‘specifyBins’, boundary1, boundary2,...,boundaryN) [WINTO_clause] FROM_clause [WHERE_clause] [GROUP_BY_clause] [ORDER_BY_clause] [LIMIT_clause] [OFFSET_clause] [SLIMIT_clause] [SOFFSET_clause]HISTOGRAM(field_key, ‘specifyBins’,  boundary1, boundary2,...,boundaryN)计算指定指标field在指定区间的统计值，specifyBins为定界直方图标志，boundaryN表示指定的各边界值，可以是整数、浮点数、字符串与布尔四种数据类型。HISTOGRAM(/regular_expression/, ‘specifyBins’,  boundary1, boundary2,...,boundaryN)计算满足正则匹配的field在指定区间的统计值。HISTOGRAM(*, ‘specifyBins’,  boundary1, boundary2,...,boundaryN)计算整数与浮点数数据类型的field指定区间的统计值。查询示例：1. 查询field_key为age且指定区间[0, 10), [10, 20), [20, 30), [30, 40), [40, 50)的定界直方图。# 整数类型 > select histogram(age, 'specifyBins', 10,20,30,40,50) from mst name: mst time histogram value ---- --------- ----- 0 10 1 0 20 2 0 30 2 0 40 1 0 50 12. 查询field_key满足正则匹配为/eight/(符合要求的只有height)且指定区间[0, 160), [160, 170), [170, 180), [180, 190), [190, 200)的定界直方图。# 浮点数类型 > select histogram(/eight/, 'specifyBins', 160.0, 170.0, 180.0, 190.0, 200.0) from mst name: mst time histogram value ---- --------- ----- 0 160 7 0 170 0 0 180 2 0 190 0 0 200 13. 支持field为字符串类型的address与布尔类型的alive的定界直方图查询。# 字符串类型 > select histogram(address, 'specifyBins', 'anhui', 'beijin', 'chengdu') from mst name: mst time histogram value ---- --------- ----- 0 anhui 1 0 beijin 1 0 chengdu 1 # 布尔类型 > select histogram(alive, 'specifyBins', false, true) from mst name: mst time histogram value ---- --------- ----- 0 false 5 0 true 6下图分别表示上述查询的各定界直方图。总结直方图作为一种经典的统计分析工具，由于其构建简单高效且能有效地描述数据分布特征，因此它的应用场景极其广泛，特别是在分析型数据库中。GaussDB(for Influx)中不仅支持了两种类型的直方图查询能力(等高与定界直方图)，而且支持了四种数据类型(整数、浮点数、字符串与布尔型)，能够帮助用户快速构建业务的数据分析能力，助力用户商业成功。另外，GaussDB(for Influx)还在集群化、冷热分级存储、查询、高可用方面也做了深度优化，能更好地满足时序应用的各种场景。结束本文作者：华为云数据库创新Lab & 华为云时空数据库团队 欢迎加入我们！ 云数据库创新Lab（成都、北京）简历投递邮箱：xiangyu9@huawei.com 华为云时空数据库团队（西安、深圳）简历投递邮箱：yujiandong@huawei.com

“你们的数据库性能怎么样？” “能不能满足我们的业务？” “和其他数据库对比性能有优势么？” ...... 客户在使用数据库时常有这样的担心和疑问。 本文从测试方案、测试工具、测试场景、测试结果等方面详细介绍了GaussDB(for Influx)和开源InfluxDB集群在X86架构下的性能测试情况。测试结果显示，GaussDB(for Influx)较企业版InfluxDB集群能提供更高的写入性能、更低的访问延迟以及更高的数据压缩率。 01 测试方案1.1 资源配置服务端配置产品名称规格存储架构GaussDB(for Influx)4U16G 2节点100G集群架构开源企业版InfluxDB4U16G 3节点100G集群架构1.2 测试工具测试工具为开源性能工具TS-benchMark。02 测试设计2.1  测试模型本次测试采用风力发电数据模型，每个风场50个设备，每个设备50个传感器，1个风场1个线程，通过load数据的线程数来控制时间线的大小，通过收集时间的长短来控制数据量。模型每条数据大小约为24字节，具体的类型如下：Timestamp | farm | device |sensor | value2.2  测试数据量测试数据分为两个场景，大数据量和小数据量，具体数据量如下：场景时间线数据量小数据量50004亿大数据量250万GaussDB(for Influx) 150亿 企业版InfluxDB 47亿注：企业版InfluxDB在插入到47亿数据时OOM，以下性能对比都基于此数据量。2.3  测试场景2.3.1  数据写入场景batch_size(每个批次写入的数据量) 固定为50，线程数分别从1、2、4、8、16、32、64、128、256、512 递增；线程数（客户端并发请求的连接数）固定为8， batch_size分别从50、100、150、200、250、300 递增。2.3.2  数据查询场景单线程进行不同语句的查询，并统计其时延信息。第一类查询：所有TAG查询select * from sensor where f='f1' and d='d2' and s='s1' and time>=1514768400000000000 and time<=1514772000000000000第二类查询：TAG+ VALUE查询select * from sensor where f='f1' and s='d2' and value>=3.0 and time>=1514768400000000000 and time<1514854800000000000第三类查询：聚合查询select mean(value) from sensor where f='f1' and s='s1' and time>=1514768400000000000 and time<=1514854800000000000 group by f,d,s,time(1h)第四类查询：或条件查询select * from sensor where f='f1' and (s='s1' or s='s2' or s='s3' or s='s4' or s='s5') and time>=1514768400000000000 and time<=1514769150000000000第五类查询：单个TAG查询select * from sensor where f='f1' and time>=1514768400000000000 and time<=151476915000000000003 测试结果分析3.1  写入吞性能比对在小数据量场景下，GaussDB(for Influx)的写入性能是企业版InfluxDB的13倍左右，在大数据量的场景下可以达到1.8倍左右。3.2 查询性能对比1） 第一类查询（所有TAG查询）：无论是大数据量还是小数据量场景下，GaussDB(for Influx)的吞吐量是开源InfluxDB企业版的2倍左右。2） 第二类查询（TAG + VALUE查询）：在小数据量场景下，开源InfluxDB企业版性能高于GaussDB(for Influx)，GaussDB(for Influx)在大数据量和小数据量场景下性能基本持平。3）第三类查询（聚合查询）：GaussDB(for Influx)查询性能明显优于开源InfluxDB企业版，在小数据量场景下是开源版本的14倍，大数据量下也是开源版本的8倍左右。4）第四类查询（或条件查询）：GaussDB(for Influx)查询性能在两种场景下比较稳定，开源企业版InfluxDB在两种场景下差异较大；GaussDB(for Influx)在小数据量场景下表现优于开源版，在大数据量场景下低于开源版。5）第五类查询（单个TAG查询）：GaussDB(for Influx)查询性能在两种场景下比较稳定，在大数据量场景下低于开源版。3.3  数据压缩率对比在250万时间线场景下，GaussDB(for Influx)导入了151亿条数据，导入前数据大小为337.5G，导入后为49.8G，压缩率为6.8；开源企业版导入了47亿条数据，导入前105G，导入后21.3G，压缩率为4.9。GaussDB(for Influx)压缩率是开源企业版的1.4倍左右。Influx引擎采用LSM tree架构，随着后台compaction的进行，压缩率会进一步提升，当前数据对比是数据刚导入时的结果。04 总结在GaussDB(for Influx)2节点对比开源版3节点场景下，GaussDB(for Influx)给客户带来了更高的写入能力、更稳定的查询能力、更高的压缩率。GaussDB(for Influx)写入能力在小数据量场景下是开源企业版的13倍，在大数据量场景下是开源企业版的1.8倍；查询能力在两种场景下表现稳定，在大部分查询场景下优于开源企业版；在压缩率方面，同样数据模型下，高出开源版本40%。除了以上优势外，GaussDB(for Influx)还在集群化、冷热分级存储、高可用方面也做了深度优化，能更好地满足时序应用的各种场景。05 结束本文作者：华为云数据库创新Lab & 华为云时空数据库团队欢迎加入我们！云数据库创新Lab（成都、北京）简历投递邮箱：xiangyu9@huawei.com华为云时空数据库团队（西安、深圳）简历投递邮箱：yujiandong@huawei.com

华为云GaussDB(for Influx)时序数据库面向工业物联网海量时序数据场景提供数据安全、高性能、低存储成本、免运维等能力，受到越来越多企业的关注；同时，即开即用、使用简单、类SQL查询语句、无需设计schema、适合业务快速迭代等特点，也越来越得到开发者的认可。 但是随着业务规模不断增加，也会遇到诸如时间线暴涨、查询时延高、Tag和Field同名导致查询数据时有时无等问题，其根本原因是，在使用过程中没有良好的数据模型设计。本期将从GaussDB(for Influx)数据模型谈起，分享GaussDB(for Influx)数据建模的最佳方法，避免一些使用过程中的常见问题。 01 数据模型与关键概念Database与MySQL中Database概念相同。创建命令：CREATE DATABASE “mydb”。用户权限、数据保留策略都以Database为粒度设置。比如赋予用户对“mydb”数据库只读权限：GRANT read ON mydb TO username。Measurement与MySQL中Table概念类似。所不同的是，GaussDB(for Influx)属于Schemaless，Measurement不需要提前创建，也不需要设计表中的字段和类型。写入数据时自动创建Measurement，字段可以任意新增和减少，但要求相同字段的数据类型必须一致。Retention Policy（RP）数据保留策略，是关系型数据库中不存在的概念，专为时序场景设计，意为指定数据在数据库中的最长保存时间，过期数据会自动被清理。Tag数据源标识，只支持string类型Field采集指标，支持string，float，int，bool类型Line Protocol（数据模型）如图所示，写数据到GaussDB(for Influx)，单条数据由measurement、Tag_key、Tag_value、Field_key、Field_value、timestamp 6部分组成。<Tag_key= Tag_value>可以1个或多个，<Field_key=Field_value>可以1个或多个，每条数据必须要携带时间戳。 Point（点）Point通常包含measurement+Tags+Field+timestamp 4个部分。例如，如下数据包含2个Point。 <monitorInfo，area=“葡萄花”，，device=“钻机A” pressure=1.8，level=35 1650443961100400200> Point1： <monitorInfo，area=“葡萄花”，device=“钻机A”，pressure=1.8 1650443961100400200> Point2： <monitorInfo，area=“葡萄花”，device=“钻机A”，level=35 1650443961100400200>即，一条数据包含多少Field Key，则可以简单认为存在多少Point。在GaussDB(for Influx)中，可以一条数据包含一个Point，也可以包含多个Point。Series（时间线）在GaussDB(for Influx)里，我们将一个指标+一组Tag组合称为一条时间线。在一条时间线下面，连续时间点的采样数据则为时序数据。比如有数据：monitorInfo，area=”葡萄花”，device=”钻机A”，pressure=1.8，1650443961100400200 monitorInfo，area=”葡萄花”，device=”钻机B”，pressure=1.6，1650443961100400200 monitorInfo，area=”榆树林”，device=”钻机B”，pressure=1.7，1650443961100400200 monitorInfo，area=”榆树林”，device=”钻机A”，pressure=1.5，1650443961100400200表示4条时间线，分别是：葡萄花油田的钻机A上的压力传感器(pressure)葡萄花油田的钻机B上的压力传感器(pressure)榆树林油田的钻机B上的压力传感器(pressure)榆树林油田的钻机A上的压力传感器(pressure)02 数据建模之最佳实践通常，数据建模是为了让查询更简单、更高效。对于大多数使用情形，我们建议使用以下设计准则：1、合理设计Tag 和FieldTag只支持字符串类型，数值和布尔类型数据应该被设计为Field；将常用查询条件和分组条件设计为Tag；因为Tag会创建索引，而Field则没有索引。比如在业务中，经常会查询某一台机器的平均CPU利用率：SELECT mean(cpu) FROM monitor WHERE host=“192.168.1.1” AND time > now() – 1h或者查询风电场每台风力发电机每小时的平均发电量：SELECT mean(elect) FROM monitor WHERE farm_id=“737f738a-bd63” AND time > now() – 24h GROUP BY time(1h)，device_id则应该将上述查询语句中的 host、farm_id、device_id 设置为Tag，前提是字符串类型才能被设为Tag。time属于内置关键字，不能作为Tag_key和Field_key；使用InfluxQL函数（Max、Min、Count等）的字段，作为Field存储。2、 遵守Tag_Key 和Field_Key的命名约定不使用保留关键字作为Tag和Field的key（名称）；Tag和Field不使用相同名称，否则会出现不可预料的问题；Tag和Field名称尽量简短清晰，可以节约Index内存空间，同时会让查询更加高效；避免一个Tag中包含多层意思，比如machine = “192.168.2.1-Ubuntu”，包含ip地址和操作系统名称，建议拆分为两个Tag：host和os；建议将变化小的数据设置为Tag，比如进程名称可以设为Tag，而进程号则建议设置为Field。3、避免超过节点规格所能承受的时间线数量GaussDB(for Influx)规格与时间线数量对应关系如下： 时间线过度超过限制，会引起性能急剧下降，可能会影响业务运行，需要考虑对节点扩容。4、避免一张表中存在过多Tag或者 Field 建议一张表存放同一类业务数据，比如物流车辆监测数据。过多业务数据放置到同一张表，会造成Tag和Field数量激增，直接影响查询效率。Field太多时，每个Field的计算都会单独计算，当执行模糊查询时可能会导致查询超时。 5、避免同一个Retention policy存储多用户数据 不同业务数据的过期时间不尽相同，应根据业务具体需求分别存储在不同的RP中，否则过期数据不能及时删除，依然占据存储空间，增加了数据存储成本，影响了查询效率。 6、避免同一个Database存储多用户数据 由于当前GaussDB(for Influx)的权限控制粒度是DB级别，同一个Database保存多用户数据，容易导致数据被其他用户访问和修改。建议不同用户使用单独Database，并且只对单一用户授予访问权限。 03 总结在制造、能源、农业、电力等工业物联网行业中，大部分数字化信息系统是构建在MySQL等关系型数据库基础上。但随着企业业务和规模的进一步扩大，数据量迅速增长，MySQL等关系型数据库面临并发数、存储成本、查询性能、扩展性、维护等诸多问题，正逐渐被时序数据库所替代。 GaussDB(for Influx)摒弃关系型数据库范式化繁复的设计规则，支持Schemaless设计，业务能按照简单、高效的方式建模。面对业务变化快、接入设备多样化严重的工业物联网场景，GaussDB(for Influx)数据建模表现更加灵活，无需更改业务即可兼容不同设备，更适用于工业物联网场景。 04 结束本文作者：华为云数据库创新Lab & 华为云时空数据库团队欢迎加入我们！云数据库创新Lab（成都、北京）简历投递邮箱：xiangyu9@huawei.com华为云时空数据库团队（西安、深圳）简历投递邮箱：yujiandong@huawei.com

“只存储这些数据一年就要花费200多万？”   面对老板的质疑，小王又重新讲解了一遍评估方案。为了支撑生产分析和系统运维，一个设备就需要几十个检测点数据，所有设备24小时不断采集数据，一天的数据量就会达到TB级，这些数据至少存储2年，再加上高可用的3副本，总的数据量会达到PB级。   小王又展示了当前云厂商存储价格和性能对比的调研结果： 不同存储其性能差异很大。例如NVME盘的吞吐量是SATA盘的7倍，IOPS超过了20倍，当然对应的成本也高出10倍左右。根据测试评估，低成本的存储性能无法满足大量数据的写入和实时业务的监控，只得使用性能高的SSD盘，因此导致存储的成本提高。   成本提高，老板自然不满意。那如何才能既满足性能需求，又能控制成本呢？小王想，“实际上，不是所有的数据处理都需要很高的性能，如果把价值高的数据放在高性能磁盘上满足业务需求，价值低的数据放在低成本磁盘上降低成本，这样不就既能满足需求，又能降低成本了么？”   不过，想法很美好，现实很残酷，要实现这个方案，小王面临着更多的难题： （1）怎么在一套系统中既能使用高性能存储，又能使用低成本存储？ （2）怎么区分高价值数据？ （3）高价值数据变成低价值数据后怎么自动转储？ （4）当前业务改造量要尽量少。 01 GaussDB(for Influx)解决方案企业的数字化转型，数据是基础。为了能实时掌握设备、系统状态，需要采集大量的数据并进行实时处理。这些数据都属于时序数据，带有明显的特点，如时间戳、更新少、数据源唯一等。除了数据本身的特点，在业务应用上还具有如下特点： 随着时间的推移，其被查询和分析的概率越来越低。随着时间的推移，对数据分析的实时性要求越来越低。随着时间的推移，数据的精度要求越来越低。数据只保留一段时间，到期后会删除。如何结合时序数据的特点，实现小王既满足业务性能，又控制成本的美好愿望呢？华为云GaussDB(for Influx)时序数据库的数据分级存储功能完美解决了困扰小王的问题。 1、华为云GaussDB(for Influx)依托云原生能力，实现了计算存储分离的分布式架构，其中存储基于华为分布式存储DFV和对象存储OBS，解决了在一套系统中既能使用高性能存储，又能使用低成本存储的问题，其具体架构如下图： 分布式DFV存储属于高性能存储，热数据放在DFV中确保业务性能要求；OBS存储属于低成本存储，冷数据存储在OBS中，降低客户成本。 2. 提供了冷热数据自动分离的方案，用户在创建保留策略时，可以指定冷热数据的划分时间，系统根据用户的指定，自动将数据分为热数据和冷数据，解决了数据如何划分的问题。 3. 随着时间的推移，热数据转冷，系统会自动将数据转储到冷存储上。 4. 上述过程中只有在创建RP时需要指定冷热数据策略。对于业务侧是不感知的，避免业务的适配和改造。 02 GaussDB(for Influx)冷热存储的使用GaussDB(for Influx)存储分级功能使用十分方便，在购买冷存储后，设置RP策略时指定冷存储的时间即可，系统会根据RP策略，自动将冷数据转储到低成本存储上。业务在访问冷数据时，系统会自动去冷存储上读取，整个过程业务是不感知的，对业务无影响。 2.1 购买冷存储GaussDB(for Influx)支持一键购买冷存储空间，可以在购买实例时选择是否够买冷存储，选择“是”，可以根据业务需求选择冷存储的大小，具体如下图： 也可以在购买实例后，独立购买冷存储。进入实例详情页面，点击创建冷存储空间，如下图： 跳转到如下页面，按照业务需求进行存储空间大小选择： 冷存储空也支持在线扩容，扩容过程中不影响业务。2.2 设置冷数据规则在购买了冷存储空间后，就可以按照业务需求设置冷数据的规则，系统会根据规则，自动划分冷热数据，并将冷数据存储在冷存储空间上。可以通过创建RP来指定冷热数据规则，具体示例如下： //在db名为mydb上创建名为myrp的RP，显示指定WARM DURATION为6d，表示6天前的数据是冷数据。 create retention policy myrp on mydb duration 30d replication 1 warm duration 6d shard duration 3d //在db名为mydb上创建名为myrp的RP，没有指定WARM DURATION，表示没有冷数据。 create retention policy myrp on mydb duration 30d replication 1 shard duration 3d //创建名为mydb的db，并带有名为myrp的RP，显示指定WARM DURATION为3d，表示3天前的数据是冷数据。 create database mydb with duration 6d warm duration 3d name myrp //修改WARM DURATION为7d，表示7天前的数据是冷数据。 alter retention policy myrp on mydb warm duration 7d规则设置完成后，系统会根据指定的规则，自动判断哪些数据属于冷数据，并自动将数据转储到冷存储上。2.3 使用效果验证冷数据规则设置好，插入数据一段时间后，系统会自动判断数据是否转为冷数据，如果已经成为冷数据，系统会自动将数据转储到冷存储上。可以通过show shards命令来查看数据的状态，如下图所示：> show shards name: hsdb id database retention_policy shard_group start_time end_time expiry_time owners tier -- -------- ---------------- ----------- ---------- -------- ----------- ------ ---- 5 hsdb myrp 2 2019-08-12T00:00:00Z 2019-08-19T00:00:00Z 2019-08-19T00:00:00Z 4 cold 6 hsdb myrp 2 2019-08-12T00:00:00Z 2019-08-19T00:00:00Z 2019-08-19T00:00:00Z 5 moving 7 hsdb myrp 2 2019-08-12T00:00:00Z 2019-08-19T00:00:00Z 2019-08-19T00:00:00Z 6 warm 8 hsdb myrp 2 2019-08-12T00:00:00Z2019-08-19T00:00:00Z 2019-08-19T00:00:00Z 7 cold：表示数据为冷数据，已存储在冷存储中； moving：表示数据为冷数据，该数据正在转储到冷存储中； warm：表示数据为热数据。 03 总结在应用了GaussDB(for Influx)的冷热分级存储方案后，存储100T的数据量一年，按照1个月内的数据是热数据，其余是冷数据，其总体的存储成本从250万降至37.5万，可节省85%的存储成本。 GaussDB(for Influx)除了冷热分级存储功能外，在集群化、读写性能、压缩率、高可用方面也做了深度优化，能更好地满足时序应用的各种场景。 04 结束本文作者：华为云数据库创新Lab & 华为云时空数据库团队欢迎加入我们！云数据库创新Lab（成都、北京）简历投递邮箱：xiangyu9@huawei.com华为云时空数据库团队（西安、深圳）简历投递邮箱：yujiandong@huawei.com

"告警了！告警了！"。"什么告警了？"正在睡梦中迷糊的小王突然被运维同事的一个电话叫醒，顿时一脸惊愕。"慢查询！客户报障了！赶紧起来处理啊！"小王赶紧打开便携，远程连上环境查找问题所在，最终发现该慢查询是一条子查询。"不对啊，相同语句昨天还没报慢查询啊？"不过小王很快得出了原因。这条慢查询的问题在于：子查询的内部查询本来可以将数据汇聚后再输出到外部查询，但由于没有做汇聚，因此当数据量大的时候，就会很慢！找到症结所在，小王立马将优化后的sql语句通过运维同事转给客户，该告警终于得以解决。"看来得好好整理下子查询了！"，趁着思路清晰，小王开始整理了起来......01 什么是子查询？子查询是嵌套在另一个查询中的查询，在InfluxQL语法中一般放在from语句中，以增强代码的灵活性。子查询主要有以下几大分类：标量子查询(scalarsubquery)：返回1行1列一个值行子查询(rowsubquery)：返回的结果集是 1 行 N 列列子查询(columnsubquery)：返回的结果集是 N 行 1列表子查询(tablesubquery)：返回的结果集是 N 行 N 列例如在查询语句：select first(sum_f1)/first(sum_f2) from (select sum(f1) as sum_f1 from mst), (select sum(f2) as sum_f2 from mst)使用了两个子查询，分别是从表mst中求得f1和f2两列之和，并将结果sum_f1和sum_f2作为外部查询的源，供外层查询语句使用。GaussDB(for Influx)子查询的一般语法为SELECT_clause FROM (SELECT_statement ) [...]。在处理子查询时的逻辑如下图所示。系统会首先处理子查询语句，子查询的结果被缓存起来，作为外查询的数据源，最终由外层查询处理完成后将结果返回给客户。02 子查询的使用场景子查询用在一次简单查询无法处理的情况下，或者是基于一个查询的数据做进一步的处理，比如想找出每个分组的最小值中最大的三个：SELECT top (v,3) FROM ( SELECT min (value) AS v FROM mst GROUP BY tag1 )子查询为我们带来了很大的灵活性，但是原则上不推荐使用子查询。原因很简单，相比于普通的查询来说，子查询有更深的函数调用和更大的数据量，消耗的资源和时延都会增加。03 案例剖析我们在使用GaussDB(for Influx)开发的过程中，常常会面临一些子查询方面的困扰，例如：1. 什么时候使用子查询？2. 面对一个复杂场景，如何分解成为子查询来解决？3. 写好的子查询是最优的么？可不可以再优化？接下来我们结合一个具体案例来简单分析下如何高效的使用子查询和分析思路。华为云某用户使用GaussDB(for Influx)，每天写入约5.4亿个点，时间线100w+，业务中有时空查询，请求成功率查询，topN查询。以下面脱敏数据作为sample数据做案例分析和实践：案例1 什么时候使用子查询？用户使用了子查询做时空分组并且作为外查询的源，外查询将时空分组的结果做聚合。查询语句为：SELECT SUM(req_nums) FROM( SELECT requestNum AS req_nums FROM req_table WHERE statement=’SUCCESS’ AND time >= 1629129600000000000 AND time<=1629129611000000000 ) WHERE time>=1629129600000000000 AND time<=1629129611000000000 AND req_nums < 50 GROUP BY time(1s), group ORDER BY time ASC产生的问题：用户的使用场景下，可以发现该查询子查询内部仅仅实现了条件过滤和列名更改，因此内部查询等同于SELECT requestNum AS req_nums + 过滤, 非聚合场景的查询由于需要捞出大量原始数据导致查询速度较慢，因此该查询效率达不到用户的要求。解决思路：通过分析查询语句可知，用户的需求是将符合条件（statement=’SUCCESS’ AND requestNum < 50）的数据做一个时空聚合（GROUPBY TAG, time(5m)）,明确了查询目标之后能写出更加清晰高效的查询语句：将所有的过滤条件放在一起，直接做时空聚合。语法改进：SELECT SUM(requestNum) FORM req_table WHERE statement=’SUCCESS’ AND requestNum < 50 AND time>=1629129600000000000 AND time<=1629129611000000000 GROUP BY time(1s), group ORDER BY time ASC案例2 使用子查询解决复杂问题用户的业务场景中需要计算请求成功率，即按照不同的过滤条件对某一列数据进行筛选和计数，最后求出比例。GaussDB(for Influx)不支持case when语句，因此如何根据不同case过滤出同一列的不同数据是一个难点。很多开发者碰到这样的问题时，便没了思路。解决思路：第一步：利用子查询+多表特性，根据过滤条件将同一列数据变为两列：SELECT * FROM (SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000)第二步：对查询出来的数据进行计数：SELECT SUM(success_requestNum) AS total_success_reqNum, SUM(total_requestNum) AS total_requestNum FROM (SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC第三步：写出最终求成功率的查询语句：SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio FROM (SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC案例3 如何优化子查询语句？基于案例2，我们得到了求成功率的方法，查询语句如下：SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio FROM (SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC产生的问题：用户所写查询语句查询时长高于120s不满足业务需求，需要进一步优化。语法改进：根据前面所述的子查询原则和解决方法，应当把聚合查询放到子查询内部来减少数据量加快查询速度，优化后的查询语句如下：SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio FROM (SELECT SUM(requestNum) AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT SUM(requestNum) AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC查询结果一致：优化效果：未优化查询耗时126s，优化后查询耗时2.7s，性能提升47倍。*注意使用SUM(success_requestNum)，SUM(total_requestNum)的目的是为了让数据对齐。直接使用SELECTsuccess_requestNum / total_requestNum，会因为相同时间数据无法对齐而出现结果不正确的情况：SELECT * FROM (SELECT SUM(requestNum) AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT SUM(requestNum) AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC查询的总数据量与查询速度正相关，越大的数据查询量意味着越慢的查询速度，因此无论是书写子查询还是非子查询的查询语句，第一原则是尽量在查询中减少数据量，也就意味着聚合查询（典型减少数据量的查询）应当尽可能放到子查询内部。04 灵活的子查询和高性能GaussDB(for Influx)不但提供灵活的子查询能力，同时还使用了向量化、内存复用等技术不断提升查询的效率，满足了用户海量数据场景下的查询性能需求。向量化查询：GaussDB(for Influx) 使用了SIMD指令集，提高数据处理的并行化程度。与此同时，采用向量化数据模型，一次迭代可以处理一批次的点，极大减少了计算迭代次数，加快了计算速度。内存复用：在查询过程中尽可能减少GC对内存的回收和分配，申请的内存单独管理，解决了查询过程中内存膨胀导致GC频繁降低查询速度的问题。05 总结GaussDB(for Influx)支持子查询功能给我们处理问题带来了很大的灵活性，同时对使用者也有很高的要求，不合理的子查询往往会导致查询时延高，资源消耗大等问题，因此在使用GaussDB(for Influx)子查询时应该注意以下几点：1. 理解子查询适用的业务逻辑，子查询适用于对查询出来的数据做二次（多次）处理的场景；2. 能不使用子查询的场景下尽量避免使用子查询；3. 必须使用子查询的场景尽量将减少数据量的查询放到子查询内部以减少整体的查询数据量从而加快查询速度。06 结束本文作者：华为云数据库创新Lab & 华为云时空数据库团队欢迎加入我们！云数据库创新Lab（成都、北京）简历投递邮箱：xiangyu9@huawei.com华为云时空数据库团队（西安、深圳）简历投递邮箱：yujiandong@huawei.com

今天DTC数据技术嘉年华迎来了完美收官华为云GaussDB大咖们又产出了哪些金句呢？快来一睹为快！

12月23-24日，2021年第十一届DTC数据技术嘉年华将盛大开启，大会采取线上形式，届时，华为云数据库四位技术专家将现身分享GaussDB数据库技术创新、探索实践经验以及未来在技术、生态方向的发展规划。精彩议程抢先知晓，让我们一睹为快！

6月20日，在ACM SIGMOD国际学术会议“中国数据库高峰论坛”，华为云数据库产品部总经理苏光牛发表了《云数据库的创新与发展》主题演讲，分享了华为云GaussDB数据库5大创新技术，坚持生态开放理念，加速千行百业数字化转型。数字化时代下，企业对云数据库提出了更高要求，既希望云数据库能满足海量业务场景下的复杂需求，又希望可以降低使用成本，提升业务效率，保障数据安全。云数据库也成为了产业升级转型和重塑产业格局的关键抓手。苏光牛提到，华为很早就开始重视数据库的投入和发展，从2007年开始研究数据库，到2020年统一数据库品牌GaussDB，华为持续战略投入数据库，并布局全球7大研究所，汇聚了一批海内外数据库领域专业人才，同时布局前沿技术，积极打造行业领先的技术竞争力。华为云数据库产品部总经理苏光牛发表演讲华为云GaussDB聚焦业务新场景，打造了以下5大核心技术竞争力：金融级高可用：华为云GaussDB提供了多种高可用方案，包括AZ内高可用、跨AZ多活、异地跨Region容灾的两地三中心容灾方案，满足金融级监管要求，并且历经银行核心关键业务严苛考验。软硬协同全栈能力：依托华为全产业链优势，垂直整合华为软硬件全栈资源，不断提升竞争力。企业级混合负载：分布式+全并行架构设计，提供事务处理与复杂查询高性能，支持1000+超大分布式集群能力，可以轻松应对海量高并发数据处理和复杂查询场景的考验。全密态数据库安全：华为云GaussDB实现从密钥处理、查询、内存、存储等全方位的安全合规和隐私保护，包括链路安全、存储安全、访问安全，同时对应用实现尽可能的透明，保证客户隐私安全。智能运维与调优：结合AI技术，实现数据库自动优化与调优等功能，让数据库管理变得更加智能高效。数据库呼唤开放的生态，华为也始终坚持开源开放理念，积极构建良好的数据库生态关系。华为云GaussDB目前已支持华为自有openGauss生态与主流开源数据库生态（如MySQL、MongoDB、Redis、InfluxDB、Cassandra等）。华为还将GaussDB部分核心能力开源到openGauss社区，鼓励合作伙伴基于开源openGauss发行属于自己的商业版本。此外，华为持续和高校联合开课，致力于培养数据库人才，繁荣数据库生态。目前，华为云GaussDB已在1000+大客户规模商用，遍布金融、政府、电信、能源、交通、电商等。另外还在SIGMOD、ICDE、VLDB等国际知名学术会议发表累计50+篇创新成果论文，内容涵盖系统架构、事务处理、AI自治、安全等。面向未来，华为云GaussDB将持续打造领先技术和服务，与更多合作伙伴一起共创时代新价值，共赢未来新机遇！