SQL 靠边站、GQL 来了：已成为 ISO/IEC 国际标准数据库语言项目

　　作者：Alastair GreenFollow 是 Neo4j 的查询语言标准和研究负责人。

　　面向属性图的标准查询语言

　　GQL 是官方标准。今年 6 月，隶属 ISO/IEC 联合技术委员会1（负责制定 IT 标准）的全球诸多国家性标准机构开始就 GQL 项目提案进行表决。上周初投票结束，该提案获得了通过，七个国家派出专家开展这个为期四年的项目。

　　GQL 的全称是“图形查询语言”。这种新语言将由监管 SQL 标准的同一个国际工作组开发和维护。GQL 高度依赖现有的语言。　　

　　主要灵感源自 Cypher（现在实现的版本有十多个，包括六款商业产品）、Oracle 的 PGQL 和 SQL 本身，以及用于只读属性图查询的 SQL 新扩展。Tigergraph 的 GSQL 虽然来自风格上与其他标准机构不一样的起点，但它是另一个值得注意的贡献，其开发者已对 GQL 项目表示出了坚定承诺。

　　自 SQL 项目启动以来已有三十多年，它最初是一项 ANSI 标准：GQL 是 SQL 之后的第一个 ISO/IEC 国际标准数据库语言项目。十个国家投票支持这个新项目：中国、韩国、瑞典、美国、德国、英国、荷兰、丹麦、哈萨克斯坦、加拿大和芬兰。五个国家因缺乏判断或评论该提案的专长而弃权。

　　只有日本投了反对票。日本给出的评论饶有意思。他们提出了两个理由：外界的现有语言已经取得所需的结果；具体来说，SQL/属性图查询（PGQ）扩展与 SQL 标准的其余部分一起就能满足需求。

　　我想谈谈为什么 GQL 的拥护者提议与 SQL 共存的一种新标准语言是对的。

　　为什么我们需要一种专门针对图形的查询语言？

　　我在 2018 年 5 月提出了 GQL 宣言（GQL Manifesto）。该倡议的直接原因是：a）SQL/PGQ 仅限于只读查询，b）它无法投射新图形，c）它只能访问基于生成 SQL 表的图形化视图的图形。

　　但许多供应商、研究人员和用户都一致认为，可以使用非关系型“图形原生”存储和运行时模型（比如 Neo4j 领先行业的产品或新的 Redis Labs 图形产品）来开发图形数据库。他们绝对需要一种 Cypher 之类的语言可以支持数据的插入和维护，而不仅仅是数据查询。而 SQL 不太可能成为以图形为中心的可“基于图形生成”的语言所需的那种合适的模型。基于图形生成是指获取作为查询输入的图形，因而输出图形，就像 SQL 可以读表，并生成实为新表的结果集。

　　GQL 和 SQL 如何协同工作？

　　支持 GQL 项目的许多公司和国家性标准机构并不将 GQL 和 SQL 视为竞争对手，而是视为可以通过共同基础和互操作性来相辅相成的语言。我这里所说的基础是指核心数据类型和形成表达式的方法，以及共同的概念（比如目录中保存的模式对象以及用户/角色关联的会话。）

　　不妨进一步了解这两种语言将如何协同操作。

　　SQL/PGQ 查询实际上是包裹着一段“proto-GQL”的 SQL 子查询。我在下面演示的一个示例查询来自关于 SQL/PGQ 的非常出色的资料（http://wiki.ldbcouncil.org/download/attachments/106233859/ldbc_tuc_2019_sql-pgq.pdf?version=1&modificationDate=1562342465000&api=v2）；今年 SIGMOD 大会接近尾声时，Oracle 的同仁 Oskar van Rest 为 7 月份在阿姆斯特丹召开的链接数据库基准委员会（LDBC）会议制作了该资料。

　　以关键字 MATCH 开头的红色部分是模式匹配查询的一个片段，它与用 Cypher 或 PGQL 编写的查询极其类似（这些语言在很多方面非常相似）。你可能注意到，IS 用于引入标签（如在 Creator IS Person 中），用于引入主机参数或变量。但是你也可以在标签表达式中使用冒号（如果 SQL 引擎的解析器足够智能），那样与之前存在的“输入”属性图查询语言的相似性会变得更明显。

　　PGQ 查询的其他部分（黑色和绿色）将此 proto-GQL 联合到 SQL SELECT 语句中。表格结果通过 COLUMNS 子句流出到常规 SQL 查询中。它们仅仅对与图形查询交互的 SQL 引擎而言值得关注。GQL 本身不会参与这种 SQL“外来函数接口”。

　　SQL/PGQ：GQL 火箭的第一级

　　模式匹配只读子语言（上面 Oskar 的示例查询中标以红色）注定要成为完整 CRUD GQL 的一个组成部分。它好比是“GQL 火箭的第一级”。这种紧密的连接是 GQL 项目提案文件的一部分。

　　因此，GQL 的其中一项工作是规范诸多方面，比如属性图数据模型、标签的使用以及查询谓词（query predicate）的属性：我们获得了一种标准的方法来处理已经可以用现有语言来处理的事情。我们希望由多种类似语言变成一种标准语言。

　　但我们还希望将供应商正竭力开发的工业创新成果纳入到定义清晰的属性图数据库这个产品类别?6?7。SQL/PGQ 领域有值得关注的新动向，比如常规路径查询、嵌套路径和路径宏命令，所有这些都增强了流行的模式匹配范式的功能。GQL 会添加还没有被所有供应商实施，但起码被至少一家供应商实施的其他创新。

　　这就引出了 SQL/PGQ 无力实现、而且不太可能实现的功能。

　　SQL 生成表，而 GQL 生成图

　　SQL 这种语言在一个关键方面与 Cypher 大不相同。Cypher（和 PGQ 的图形子语言）让用户可以探索其数据图的结构，无需事先知道将返回哪些类型的数据。它们让你可以进行真正的图查询，这方面值得关注的不仅仅是值，还有数据子集的形状，在与图模式匹配的元素值方面予以定义。换句话说，图查询描述了针对一个或多个输入图计算的子图或投射图。

　　然而，SQL/PGQ、Cypher 和 PGQL 只允许你从图中提取一个表。这是必须保留的重要特性，因为否则就不可能获取存储在图元素上的实际数据值。但是将结果仅限于表意味着你无法轻松创建图转换链，也无法针对多个输入图执行集合操作。你也无法生成和存储快照图，无法定义图投射视图。

　　GQL 将建立在 openCypher Morpheus 的基础上（后者将 Cypher 引入到 Apache Spark），并结合来自 LDBC 的G-CORE 的灵感，为用户提供了一种组合图查询语言，支持所有那些功能。这将使 GQL 在概念上等同于 SQL。

　　我认为 SQL 标准社区在这里做出了一个正确的决定：让 SQL（一种围绕表构建的语言）可以在 SQL 用户想要从图中查找和投射表时可以引用 GQL，但在用户想要从图中查找和投射图时可以使用 GQL。这意味着我们可以生成图、将图编入目录，这些图不仅仅是基于表的视图，还有离散的复杂数据对象。

　　这涉及 SQL 并非天然适合的其他图功能。

　　CRUD 的图模式

　　插入、更新和删除图（以及路径和元素）的 DML 语句与用于匹配和提取数据的 DQL 密切相关。因此，最好在这两种操作中使用一套共享的以模式为中心的词汇表。这意味着 GQL 是适合将“CUD”添加到 PGQ 的“R”的（单一）环境。

　　你可以更新图视图下的表以获得同样的效果（前提是你使用配备图的 SQL 引擎），但这使你无法享用图数据模型的简单性和强大功能。这就像通过针对所有基本表编写更新来写入到 SQL 视图：有可能做到但弄巧成拙。

　　SQL 引用 GQL

　　由于除了 SQL/PGQ 中完成的工作外，GQL 还添加了数据修改，我们开发了一种“可引用性更强”的 GQL。如果 SQL 用户想要将数据从表格数据库推送到存储在数据库目录中的图对象，那么合乎自然的做法是引用更多的 GQL，在 SQL GRAPH_MODIFY 函数里面执行专门针对图的那项工作。

　　当我们 Neo4j 早在 2017 年在关于 PGQ 的标准讨论中首次提出“SQL 引用 Cypher”供讨论时，得到的评论是“Cypher 不是一项可引用的国际标准”。这促使我们直奔 GQL。它将是一种官方的国际标准，可以被 SQL 引用。当然，随着时间的推移，我们可能希望让 GQL 可以为表操作引用 SQL！

　　属性图模式　　

　　这引出了 SQL 不适合的另一项主要功能。图的类型是其节点的类型，加上边缘的类型以及它们可以连接的节点的类型。特定类型的节点和关系存储数据值：特定类型的标签和属性（内容）。

　　SQL 没有这个进化的概念：按照类型组合和参数化表示复杂类型。而表示图类型的最自然方式是显示它编码的数据关系的模式。使用元素内容（标签和属性）的“记录类型”定义的属性图形类型应运而生，模式用于将那些内容类型组合到节点和关系（包括方向）。

　　下图是一项 Neo4j 提案，尚未得到一直在为 GQL 项目做准备的工作组的同意，但它肯定会让人想到 ASCII 码绘图中简洁、富有表现力的图案如何有助于记录和直观显示图及其类型。

　　顺便说一下，GQL 很可能规范无向关系的模式、查询和修改（PGQL 和 Tigergraph 的 GSQL 中已经存在的一项功能）。更宽泛说，GQL 让我们有机会获得比 SQL 更现代化的语言，拥有更结构化的类型系统、干净地组合作为过程查看的查询，拥有参数（允许参数化视图）以及前向（线性）和嵌套过程组合。

　　“全图”（Omnigraph）

　　我最后阐述 GQL 有别于 SQL 的最值得关注的地方之一。在G-CORE 研究语言中，你可以将两个图结合起来，然后添加新元素（节点和关系），构成第三个图。作者着眼于“在现有图上构建”。G-CORE（比如 Cypher for Apache Spark）只针对不可变数据进行操作，因此这种方法中的第三个图实际上是前两个图的副本加上任何新数据。

　　但数据库是可变存储系统。在 Neo4j 中，我们开始将这种“两个图加新数据”设计模式的可变存储系统称为全图（omnigraph）。它是视图和基本图的组合，在 SQL 中没有相对应的，因为 SQL 并不构造拥有任何显式关系的数据，只有值调控的链接（外来键）。

　　GQL 视图如同 SQL 视图，让你可以查看源自基本表上函数的数据。该视图的任何更新都将写入到基本表。GQL 基本图（如同 SQL 基表表）让你可以直接存储和读取数据。但是 GQL“全图”将是这样一个图：一些数据通过其他图（包括其他视图）的视图得出的，一些数据是新的、是相应图所特有的（基本数据）。这就有可能在预先存在的图中的元素之间添加关系，但是这些关系仅存在于“叠加”全图中。

　　这种安排好比 SQL 中基本表和派生表的命名组合，由于外来键和链接表关系形成的内在图被组合在一起。我们认为，称之为图更合乎自然，使用图形查询语言来定义和查询它更自然。

　　WG3 将在坦桑尼亚阿鲁沙开会

　　GQL 项目的工作将于本月晚些时候在坦桑尼亚阿鲁沙召开的 SQL/GQL 标准委员会 ISO/IEC JTC 1 SC 32/WG3 的下一次会议上全面开始。

　　现阶段无法表明第一个可实施版本的 GQL 何时问世，但很有可能在 2020 年下半年之前制定某个相当完整的草案。

　　GQL 社区 10 月 9 日发布更新

　　10 月 9 日周三将举行 GQL 社区更新互联网大会，由 LDBC 主席 Peter Boncz 和 WG3 召集人 Keith Hare 共同主持。

　　这次会议将讨论不同的主题和工作流程，包括针对属性图模式和现有语言分析的两个 LDBC“特别任务组”安排的社区工作。此前，LDBC 的理事会已决定为支持 GQL 的社区工作充当组织中心，充分发挥 LDBC 与 WG3 的正式联络机制。

　　已设想使用正式的指称语义来协助提高 GQL 规范的质量和准确性，并依托在爱丁堡和华沙开展的类似工作，为 Cypher 的一部分（包括值得关注的 Cypher.PL 可执行语义项目，用 Prolog 编写）定义正式语义。随着时间的推移，也很有可能会开始开发用于语法工具和一致性测试的开源软件，以支持官方规范，就像 openCypher 项目那样。

　　定义属性图数据管理这个类别

　　GQL 有望成为属性图的关键性标准：在这个世纪，数据管理领域最激动人心、最强大的产品类别之一已在业界扎稳了脚跟。