|  首页  |  资讯  |  评测  |  活动  |  学院  |  访谈  |  专题  |  杂志  |  产服  |  
您现在的位置:硅谷网> 资讯> 软件>

ZStack 2.6:揭密首个面向IaaS的查询语言:(ZQL)

2018-08-14 17:15 作者:佚名 来源:硅谷网 HV: 编辑:何睿 【搜索试试

为了简化UI工作并为运维人员提供一种更加灵活的资源查询方式,ZStack在2.6版本中推出了首个面向IaaS的查询语言 —— ZStack Query Language,简称ZQL。

背景

IaaS管理着海量的数据中心资源,如何对这些资源进行灵活快速的查询是运维人员面临的一个难题。在以往的IaaS软件中,往往只对单个资源的某些字段提供有限的API查询支持,例如可以通过虚拟机的IP字段查询,这不足够也不灵活。运维人员在做复杂查询时往往得绕开IaaS软件直接查询其后端数据库,这既要求运维人员要了解IaaS资源的内部关系,又带来了数据库误操作的风险。

从ZStack正式发布的第一个版本ZStack0.6开始,我们就致力在API层面提供跟数据库级别的查询功能,ZStack的每个资源都包含一个Query API,能够通过资源的自身字段以及资源的关联资源字段进行查询。例如

QueryVmInstance name~=web-vm state=Running

这里查询所有名字包含web-vm字符串,正在运行中的VM。又例如

QueryVmInstance vmNics.eip.vip.ip='22.22.22.22'

EIP是虚拟机的关联资源,这里查询网卡绑定了EIP为22.22.22.22的虚拟机。

Query API功能强大:

用户可以通过count参数返回满足查询条件资源数量,类似SQL的count();

通过fields参数指定要返回的字段,类似SQL的uuid,name from;

通过sortBy、sortDirection参数指定排序的字段和方向,类似SQL的order by;

通过start、limit参数实现分页查询,类似SQL的limit和offset。

Query API除了使用方便外,定义也很简单。程序员在ZStack中增加了一种新资源后,只需要在代码中定义如下class:

@AutoQuery(replyClass = APIQueryVmInstanceReply.class, inventoryClass = VmInstanceInve
ntory.class)public class APIQueryVmInstanceMsg extends APIQueryMessage {

}

不需要写任何实现,对应资源就具有了Query API。

ZStack内部包含一个Query Service负责处理所有资源的Query API,将他们翻译成相应的SQL语句,在查询条件中包含关联资源条件时会生成对应的Join子句。

基于Query API, ZStack0.6版本就包含了超过400万个单项查询条件,组合查询条件数为400万的阶乘。极大的方便了运维和复杂UI的设计。但Query API仍然包含一些缺陷:

查询条件之间只能是AND逻辑,无法执行OR逻辑,条件之间也无法加括号实现复杂逻辑组合

不支持类似SQL中的sub query子句

单个API只能查询一种资源,查询多种资源时需要调用多个API

不支持跟监控系统的查询语言整合

随着ZStack UI的场景越来越丰富,Query API的限制使得UI端的工作越来越多,很多场景需要多次调用Query API进行数据组合。例如在监控Top 5页面(用于检测系统中CPU、内存、磁盘、网络等资源使用率最高5个资源的页面),需要先采用Query API将虚拟机、物理机等资源信息查询回来,再调用监控系统ZWatch的API查询对应的监控数据。

Query API在未来的ZStack版本中会一直保留并维护,其后端实现已经从原来的Query Service替换成ZQL。

ZStack Query Language

使用过著名issue管理系统JIRA的开发者都知道JIRA在进行高级搜索的时候提供一种查询语言JQL (JIRA Query Language),能够使用一种类似SQL的DSL(Domain Specific Language)对JIRA中ticket的各个字段进行高效的查询。ZQL跟JQL类似,也是一种类似SQL的DSL,先来看一个例子:

query vminstance where name='webvm' or vmnics.ip='192.168.0.10' or (vmnics.eip = '172.20.100.100' (cpuNum >= 8 or clusterUuid in ('fe13b725c80e45709f0414c266a80239','73ca1ca7603d454f8fa7f3bb57097f80')))

在这个简单例子中,可以看到很多熟悉的SQL元素,例如and/or条件、括号、>=/in操作符等。ZQL可以看作SQL的一个子集外加ZStack根据自身需求进行的增强的查询语言。它的基本结构如下:

QUERY queryTarget (WHERE condition+)? restrictBy? returnWith? groupBy? orderBy? limit? offset? filterBy? namedAs?

query关键词

一条ZQL语句通常以query关键字开头,queryTarget表示要查询的资源或资源字段的集合。前面的例子中vminstance代表虚拟机,例如host代表物理机、zone代表区域,所有可被查询的资源都有自己的名称。如果不希望返回资源的所有字段,只希望获得资源的一个或多个字段,实现类似SQL的uuid,name from ...的功能,可以在资源名后指定字段名,多个字段名用逗号隔离,例如:

query vminstance.uuid,name,cpuNum

该查询返回所有虚拟机的UUID、名称以及CPU数量。

除了query关键字,查询也能以count和sum关键字开头,前者返回满足查询条件资源的总数,后者可以对资源的某个字段进行求和。例如:

vminstance where cpuNum > 8

返回系统中CPU数量超过8核的虚拟机的总数。

sum vminstance.memorySize by name where cpuNum > 8

用虚拟机名字对CPU核数超过8个的虚拟机进行分组,对它们的memorySize字段进行求和。如果系统中有两个10CPU8G的虚拟机都名为webvm,则求和后返回webvm虚拟机总内存使用数为16G。翻译成SQL则为:

sum(memorySize) from vminstance where cpuNum > 8 group by name

WHERE从句

ZQL的WHERE从句跟SQL的WHERE从句类似,支持and/or逻辑操作符、括号组合,条件的比较符支持=,!=,>,>=,<, <=, like, not like, is null, is not null, in, not in,查询条件名为资源的字段名。跟SQL不一样的地方在于,ZQL的查询条件可以是关联资源的字段,例如:

query vminstance where

vmNics.eip.vip.ip='22.22.22.22'

注意where从句前无需写类似SQL的from xx从句,因为query vminstance已经限定了被查询的资源

这里vip跟eip关联,eip跟vmnic关联,vmnic又跟vminstance关联,则我们可以指定vip的IP作为查询条件。这正是ZQL的强大之处,对于多个关联资源的查询,无需调用多次API在应用端组合数据,也无需像SQL一样写复杂的join从句,只需要像编程一样通过点号(.)引用另一个资源即可, ZQL的翻译器会自动将跨资源引用翻译成对应的SQL join从句。

WHERE从句可以包含子查询,类似于SQL的sub query功能,例如:

query vminstance where vmNics.l3NetworkUuid in (query l3network.uuid

where ipRanges.networkCidr='10.1.0.0/24')

这里找出所有CIRD为10.1.0.0/24的三层网络上运行的虚拟机。

上面这个例子也可以用更简单的方法实现:query vminstance where vmNics.l3network.ipRan
ges.networkCidr='10.1.0.0/24',这里只是为了演示子查询功能

GROUP BY、ORDER BY、LIMIT、OFFSET 子句

跟SQL一样,ZQL支持GROUP BY、ORDER BY、LIMIT、OFFSET关键字,以实现分组、排序、分页等功能。

GROUP BY:

通过虚拟机的区域UUID和集群UUID分组,统计各区域中各集群中虚拟机的数量。

vminstance group by zoneUuid,clusterUuid

ORDER BY:

查询所有虚拟机,使用cpuNum字段降序排序。

1.query vminstance order by cpuNum desc

LIMIT、OFFSET:

使用limit和offset实现分页:

query vminstance limit 100 offset 10

多资源查询

对于多个资源的查询,可以通过多条query查询语句实现,语句之间使用分号分隔,例如:

query vminstance where name = 'my-vm';

query host where cpuNum > 10;

query zone;

则一次调用即可返回三种资源的查询结果。由于返回的结果是一个map的JSON结构,为了方便获得对应语句的查询结果,可以使用named as关键字对查询语句命名,例如:

query vminstance where name = 'my-vm' named as 'vm';

query host where cpuNum > 10 named as 'host';

query zone named as 'zone';

则在返回的JSON map中,可以通过vm、host、zone作为key获得对应语句的查询结果。

合并监控查询 (return with从句)

在ZStack中使用了两种数据库:关系数据库存放元数据,时序数据库存放监控数据。由于不同数据库查询方式不一样,在ZQL之前,用户要查询一个资源的监控数据,需要先通过Query API获得该资源的元数据,再通过ZWatch的查询API获得其监控数据。例如要查询一个名为webvm虚拟机的CPU使用率监控数据,要执行如下API:

QueryVmInstance fields=uuid name=webvm

GetMetricData namespace=ZStack/VM metricName=CPUUsedUtilization labels=VMUuid=Q
ueryVmInstance返回的UUID offsetAheadOfCurrentTime=60

ZQL通过return with子句解决这个问题。return with是一种插件机制,它允许子系统 通过插件将自身的查询条件注入ZQL中,ZQL会先执行关系数据库查询,将满足条件资源的原数据查询出来后,再将资源的主键(primary key)作为输入条件调用实现return with子句的插件,最后将插件的查询结果一并返回给ZQL的调用者。

上述查询虚拟机监控数据的需求可以通过一条ZQL语句实现:

query vminstance.hostUuid,uuid where name = 'webvm' return with (zwatch{resultName='webv
m-cpu',metricName='CPUAllUsedUtilization',offsetAheadOfCurrentTime=60})

返回:

{

"results": [

{

"inventories": [

{

"hostUuid": "f8271f58468b4281a212a43e530b5535",

"uuid": "05781209d24341ac84fc055ae71820ac"

}

],

"returnWith": {

"webvm-cpu": [

{

"labels": {

"VMUuid": "05781209d24341ac84fc055ae71820ac"

},

"time": 1533280402,

"value": 0.8

},

{

"labels": {

"VMUuid": "05781209d24341ac84fc055ae71820ac"

},

"time": 1533280462,

"value": 0.8

}

]

}

}

],

"success": true

}

这里我们用一条ZQL语句中即返回了我们感兴趣的元数据字段:uuid和hostUuid,也返回了该虚拟机的监控数据。细心的读者已经注意到我们在ZWatch查询字段中指定了参数resultName='webvm-cpu',并且在返回的JSON map中监控数据的key也是webvm-cpu。跟named as关键字一样,这是为了执行多条ZWatch查询子句时方便检索返回结果准备的。 ZStack UI使用非常复杂的ZQL查询语句,例如在TOP 5页面,一条ZQL查询包含多达13个ZWatch查询:

ZQLQuery zql="query vmInstance.uuid,name where zoneUuid='89e148fb667c404dbc5309a2e956fa
28' hypervisorType='KVM' type='UserVm' state='Running' return with (zwatch{resultName='CPUAllUse
dUtilization',metricName='CPUAllUsedUtilization',offsetAheadOfCu

上例是在ZStack CLI中执行时的例子,使用\对引号转义

当资源特别多时,时序数据库查询性能可能成为多条ZWatch查询的性能瓶颈,故return with会通过并发的方式执行插件,默认并发度为10。例如上述例子中的13条ZWatch查询会在10个线程中并发执行。用户可以通过全局配置zql.returnWith.concurrency更改并发度,例如

UpdateGlobalConfig category=query name=zql.returnWith.concurrency value=15

限制查询 (restrict by从句)

ZStack的企业管理模块包含一个功能,可以对管理绑定某个区域,使得该管理员只能管理该区域内的资源,这就要求我们的ZQL对该管理员的查询请求只返回与其绑定区区中的资源。

对于虚拟机这样的资源,其元数据本身就带zoneUuid字段用于标识所在区域。但对于eip这样的资源,其元数据并无任何字段表示区域属性,区域属性是由其所在的三层网络或绑定的虚拟机确定的。例如要查询某个区域内的eip,可以使用:

# 通过与虚拟机的绑定关系查询

query eip where vmNic.vmInstance.zoneUuid = '52fdad0a2c0d4131a6c0fc6c1b7141a6'

# 通过所在三层网络确定

query eip where vip.l3Network.zoneUuid = '52fdad0a2c0d4131a6c0fc6c1b7141a6'

无论那种方式,都需要调用者了解知道eip跟zone之间的关联关系,这对API的使用者提出了非常苛刻的要求。ZQL通过restrict by从句解决这个问题。跟return with从句类似,restrict by也是个插件框架,它允许其它服务通过插件解读restrict by从句中指定的条件,向生成的SQL中注入额外条件。例如上面的eip例子通过restrict by从句可以写成:

query eip restrict by (zone.uuid='52fdad0a2c0d4131a6c0fc6c1b7141a6')

这里调用者无需知道eip跟zone之间的逻辑关系,restrict by的路径插件会自动计算两者的逻辑关系,并生成对应的SQL join从句。这里eip既可以通过所在三层网络,也可以通过绑定的虚拟机确定和区域的关系,插件会自动计算路径权重,使用权重最高的路径生成SQL语句。

对于eip这个例子,插件会选取通过三层网络的关系生成SQL语句。因为eip可能没有跟虚拟机绑定,但其一定处于某个三层网络,故三层网络这条路径的权重更高。

restrict by支持多个条件,通过逗号分隔,多个条件之间是AND关系。

除了给ZQL调用者使用外,restrict by插件在ZStack内部也被其它服务广泛使用。例如账号系统会通过插件在普通账户调用ZQL的时候注入跟账号关联的SQL语句,使得普通账号只能查询到属于该账号的资源;又例如SNS服务会通过插件注入语句让ZQL只能查询到非系统类型的接收端。

未来

ZQL为ZStack提供了一种类似SQL的IaaS查询语言,并且能够通过return with插件框架跟其它非关系数据库系统进行查询整合。在未来的版本中我们还会继续丰富其功能,目前有两个方向:

filter by从句

虽然return with的ZWatch插件能让我们在查询资源元数据的同时查询其监控数据,但还不能将监控数据作为元数据的查询条件,例如无法通过一条ZQL实现查询某个集群中所有CPU使用率超过90%的虚拟机。这在未来版本中会通过filter by从句实现,例如:

query vminstance where clusterUuid = '33e26bd547d149fbb190436cc9aca824' filter by (zwatch{met
ricName='CPUAllUsedUtilization', offsetAheadOfCurrentTime=60, threshold>90})

同样,filter by从句会实现成类似return with的插件框架,用于整合非关系数据库的查询条件。

智能CLI

ZQL有大量的从句,每个ZStack又有大量的可查询字段,目前ZStack CLI可以对Query API的可查询字段进行补全,但ZQL还暂时无法补全。未来版本中,我们会对CLI进行在增强,使其对所有查询条件可以进行提示和补全。

欢迎大家在ZStack官网下载页面

http://www.zstack.io/product_downloads/

进行免费的下载安装和试用。

【对“ZStack 2.6:揭密首个面向IaaS的查询语言:(ZQL)”发布评论】

版权及免责声明:
① 本网站部分投稿来源于“网友”,涉及投资、理财、消费等内容,请亲们反复甄别,切勿轻信。本网站部分由赞助商提供的内容属于【广告】性质,仅供阅读,不构成具体实施建议,请谨慎对待。据此操作,风险自担。
② 内容来源注明“硅谷网”及其相关称谓的文字、图片和音视频,版权均属本网站所有,任何媒体、网站或个人需经本网站许可方可复制或转载,并在使用时必须注明来源【硅谷网】或对应来源,违者本网站将依法追究责任。
③ 注明来源为各大报纸、杂志、网站及其他媒体的文章,文章原作者享有著作权,本网站转载其他媒体稿件是为传播更多的信息,并不代表赞同其观点和对其真实性负责,本网站不承担此类稿件侵权行为的连带责任。
④ 本网站不对非自身发布内容的真实性、合法性、准确性作担保。若硅谷网因为自身和转载内容,涉及到侵权、违法等问题,请有关单位或个人速与本网站取得联系(联系电话:01057255600),我们将第一时间核实处理。
广告
相关
·HPE推出业界首个基于Kubernetes的企业级容器平台
·自如与万华战略合作,是长租行业首个大规模引入
·把博物馆带回家 全国首个5G智慧博物馆APP正式上
·首个Android 10稳定版来了 Redmi K20 Pro率先适
·企业微信通过SOC2Type2审计,为企业数据安全保驾
·对庄推出行业首个专属顾问服务体系,成为行业新
·混合云时代的Iaas和容器:IaaS向下、容器向上
·北斗导航定位芯片产业迎来首个“开放创芯平台”
头条
“魔搜”软件开发者张某被判刑1年2个月缓刑1年10个月 “魔搜”软件开发者张某被判刑1年2个月缓刑1
一个取名魔搜的软件篡改消费者在电商平台的购物浏览记录,企图通过数据造假制造爆款。……
·“魔搜”软件开发者张某被判刑1年2个月缓刑1
·45款应用程序遭谷歌下架 猎豹移动股价惨跌16.
·腾讯会议一星好评,如何占得线上视频会议市场
·高仿APP捞钱套路:蹭官方、发广告、索取隐私
·报告称APP的支出和使用率在2019年达到创纪录
图文
“远程办公”战线拉长,如何确保“私有化”办公?
“远程办公”战线拉长,如何确保“私有化”
友盟+智能认证:用户增长始于头,体验提升只需1.3秒
友盟+智能认证:用户增长始于头,体验提升
知米背单词APP那些不为人知的小细节(图)
知米背单词APP那些不为人知的小细节(图)
Realme引入广告什么情况 Realme广告怎么设置关闭?
Realme引入广告什么情况 Realme广告怎么设
最新
·“远程办公”战线拉长,如何确保“私有化”办公?
·友盟+智能认证:用户增长始于头,体验提升只需1.3
·“魔搜”软件开发者张某被判刑1年2个月缓刑1年10
·字节跳动称旗下办公产品飞书被微信全面封禁
·疫情下的危机,如何通过“信源豆豆”实现企业安全
热点
·群控、云控时代即将终结,智控时代已到来
·106短信群发平台APP,致力于成为领域内佼佼者
·DT小听App:防偷拍,还是用这款国产app(图)
·软件技术行业发展变化非常快,软件人才要按需
·嗨学网一级消防可靠吗?新手妈妈亲生经历告诉
旧闻
·微软发布2013年首批补丁 暂未修复IE漏洞
·漂亮有创意的思维导图怎么画?办公也有小技巧
·喜推人工智能名片:看懂客户心,销售才能更欢
·社会“抢票软件”存隐患随时有可能被屏蔽
·全国多地上线电子社保卡 微信10秒即可申领
广告
硅谷影像
“远程办公”战线拉长,如何确保“私有化”办公?
“远程办公”战线拉长,如何确保“私有化”办公?
友盟+智能认证:用户增长始于头,体验提升只需1.3秒
友盟+智能认证:用户增长始于头,体验提升只需1.3
“魔搜”软件开发者张某被判刑1年2个月缓刑1年10个月
“魔搜”软件开发者张某被判刑1年2个月缓刑1年10
打响“科技防疫战” 中软国际解放号在行动
打响“科技防疫战” 中软国际解放号在行动
钉钉5.0新增在线办公室、圈子,满足用户个性化需求
钉钉5.0新增在线办公室、圈子,满足用户个性化需
钉钉5.0产品见面会 彩蛋Real如我曝光号召无压力分享
钉钉5.0产品见面会 彩蛋Real如我曝光号召无压力分
关于我们·About | 联系我们·contact | 加入我们·Join | 关注我们·Invest | Site Map | Tags | RSS Map
电脑版·PC版 移动版·MD版 网站热线:(+86)010-57255600
Copyright © 2007-2020 硅谷网. 版权所有. All Rights Reserved. <京ICP备12003855号-2>