揭密首个面向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举办在加强，使其对全部查询前提可以举办提醒和补全。

（编辑：湖南网）

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