揭密首个面向IaaS的查询语言：ZStack Query Language（ZQL）

当资源特别多时，时序数据库查询性能可能成为多条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{metricName='CPUAllUsedUtilization', offsetAheadOfCurrentTime=60, threshold>90})

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

智能CLI

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

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!