跨越鸿沟——图数据库查询语言的八个先决条件

前奏

去年12月，我在Quora上发表了一篇关于图数据库利弊的文章。在那里，我分享了市场上两个普遍存在的问题:图数据库应用开发人才匮乏，以及非标准化图查询语言减慢了需要它的企业的采用步伐。

解决这两个问题的方法是提供一种简单而强大的标准图数据库查询语言。

市场上有许多图数据库语言，包括Neo4j的Cypher、Apache TinkerPop Gremlin和TigerGraph的GSQL等等。在讨论哪种图数据库语言是好的，或者将每个图数据库语言的佳方面融合到一个新的、统一的选项之前，让我们后退一步，问一个更基本的问题: 图数据库查询语言的先决条件是什么?

图数据库查询语言的先决条件

乍一看，这是个很难回答的问题! 基于许多用户的反馈，和我18年多的数据管理职业生涯的经验，我将尝试用刨析一系列相关的子问题来回答这个问题。

首先，为什么世界关注图数据模型?

英特尔在1972年4月1日推出了8008处理器。随后，1975年台个人电脑问世。在那个时代，越来越多的企业信息被数字化。当时市场的一个紧迫需求是使用数据管理应用程序来帮助记账，并生成业务通信的报告。由于内存是稀有资源，基于磁盘的关系数据库应运而生，它利用规范化理论减少数据冗余，提高数据完整性。关系模型(或表格模型)满足了硬件约束和市场需求，因此在接下来的30年里蓬勃发展。那时，QUEL和SQL是两种相互竞争的关系查询语言。这两种语言都具有很强的表达能力，易于使用，满足了市场需求。随着市场的发展，SQL终取得了胜利，并被业界广泛采用。

时间过得飞快。数据量快速持续增长，硬件继续发展。市场需要可伸缩的软件来管理不断增长的数据。自2000年以来，许多大型并行处理(MPP)数据库供应商通过解决这一需求而取得了进展——包括Teradata、Greenplum、Netezza、Vertica、AsterData、亚马逊Redshift等。这些MPP数据库仍然遵循关系模型，但使用MPP解决可伸缩性问题。MPP数据库的成功可以归因于SQL。由于SQL的声明性，用SQL编写的应用程序是独立于数据的，因此可以轻松地移植到单节点或多节点的RDBMS系统。

现代社会见证了数据的泛滥和相互关联的数据。互联数据的独特性和威力已经被大型互联网公司的出现所证明，这些公司包括谷歌(搜索引擎)、Facebook(社交网络)、LinkedIn(职场社交网络)和Twitter(在线新闻和社交图)。如今，Instagram、WhatsApp和微信，微博等移动通讯工具，以及Paypal、微信支付和支付宝等移动支付提供商，每一秒都能产生海量的网络形互联数据。当人、机器、汽车、移动设备等产生了大量相互关联的数据时，我们真的正处于网络时代! 管理图数据的迫切需求已经出现。

在数据管理的历史上，关系模型次“尴尬”，因为关系数据库不能有效地连接多个表，以遍历互连数据中的多个链接。通常，关系模型数据库盲目地扫描参与表的所有或大部分，并使用join谓词查找数据记录连接。虽说索引(加速随机记录查找的辅助数据结构)可以有所帮助。然而,有经验的数据库管理员将很乐意告诉你, 索引是一个关系表的一小部分复制,如果数据随时都在变化,保持更新的表和索引同步并不牺牲查询性能是一个很大的挑战（如果不是不可行）。

更重要的是，我们甚至无法编写SQL查询来发现和预测隐藏在许多表中的关系——当我们事先不确定可能涉及哪些类型的关系时，我们不能通过加入表来“连接这些点”。

图模型提供了以下有益的特性:

• 互连数据的自然和经济存储模型
• 用于管理不断增长的对象类型的自然模型
• 知识/推理/学习的自然计算模型-链接和结合观察点

为什么图模型需要一种新的查询语言?

正如到目前为止所讨论的，图模型非常适合今天的互连数据。然而，因为它是新的，而且以图为导向的思维是不同的，所以开发人员需要花费一些精力来学习和使用它。今天的大多数计算机教科书都把图轮单独拿出来，专门介绍图算法，其中有关于图模型和图算法的课程，这些课程都围绕着解析图问题的理论复杂性和优雅性。编写图算法是另一回事，教科书使用Java或c++等通用编程语言。此外，教科书中的大多数图算法通常假设所有的图数据都可以存储在内存中，而不考虑分布式计算。因此，对于现实世界的图问题，特别是对于大型图数据集，开发人员往往缺乏实用的训练和工具。

对于任何采用图模型的企业来说，重要的问题是，他们在哪里找到合格的开发人员来有效地编写图数据库应用程序?

解决方案? 使用声明式图查询语言，降低学习和实现图应用程序的门槛! 就像SQL和QUEL显著降低了管理关系数据的门槛一样，一个设计良好、用户友好的、高表达的图查询语言可以显著地缩短用自然语言提出的现实问题和轻松构建基于图的解决方案之间的差距。

图查询语言的先决条件是什么?

基于多年与有前瞻性的客户合作的实战经验，我总结出了以下关键需求，所有这些都可以作为我们问题的答案: 图查询语言的先决条件是什么?

1. 基于模式，并具有动态模式更改能力
如上所述,关系数据库的SQL编程的成功很大程度上归功于数据独立性,用户使用一个逻辑层数据模式,独立于底层存储机制。 逻辑层数据模式的变化将对现有应用程序透明(所以他们不会被破坏)。有了数据独立性，下一级的所有更改对上一级都是透明的。在预设定的模式(数据模型)上编写的应用程序可以移植到任何理解该模式的数据管理软件和硬件。同样，图模型和图查询语言应该包含数据独立性。更准确地说，图查询语言应该支持逻辑图模式的定义。由于数据模型在现实世界中随时间变化，因此语言和系统也应该支持动态模式更改。

2. 图遍历的控制能力
SQL语言是纯粹声明性的，这意味着用户可以提出问题，而不必担心数据库软件如何处理查询。这点解放了用户，他们不必绞尽脑汁编写高性能算法来执行任务。同样的方式也可以应用于设计优雅的图查询语言。对于简单的查询，它可以是声明性的，比如模式匹配查询。例:下面的示例查询查找所有年龄大于23岁客户，他们购买了Peter购买的苹果生产的产品。

3. 图遍历的精细控制能力

除了查询之外，我们还看到客户对编写复杂的迭代图挖掘算法和遍历算法的大量需求，他们希望遍历图数据、添加标记和运行时属性，并进行迭代更新，直到计算出终的查询结果。例如，考虑协作过滤推荐、PageRank、社区检测、标签传播、基于相似性的排名算法等。根据我们为世界上财富100强大公司提供服务的经验，客户初找图数据库公司来设计和执行SQL无法解决的复杂算法。因此，对图查询和图模型的元素——顶点和边——的精细控制是标准图查询语言必须拥有的。例如，考虑一个PageRank查询。或者,GNN深度学习 [1806.01261] Relational inductive biases, deep learning, and graph networks

4. 内置并行语义以保证高性能

图算法是昂贵的，因为每一跳都可能以指数形式增加数据的复杂性。让我们考虑: 如何从一个顶点开始, 个跳可以产生n个邻居,图上的下一跳的直接邻居可以产生n²更多的邻居,等等。因此，图中的每个遍历步骤都应该具有内置的并行处理语义，以确保高性能。

5. 具有表达能力很强的加载数据能力

世界是一个图。将数据竖井加载到一个中央图模式需要一种表达灵活的模式映射加载语言。否则，即使将几个数据源集成到图模式中也是一项艰巨的任务。全面的图语言需要包含易于使用的加载功能子语言，以帮助快速加载复杂的异构数据。这是图查询语言和相关系统的高优先级要求之一。

6. 数据安全性和隐私

企业客户热衷于促进自己与图数据的协作。一方面，他们想要一个图模型，可以在多个部门之间甚至在合作伙伴之间共享选定的数据部分。同时，他们也希望保持某些敏感数据的隐私性，并根据他们的业务需求，仅由特定的角色、部门和合作伙伴访问。对于大型企业来说，在现实世界中成功的图查询语言需要支持一个具有基于角色的安全模型的多图。

7. 支持查询调用查询(并支持递归)

对于实现生成业务价值的基于图的解决方案来说，这是一个不太明显的需求。通常，我们的客户希望对图中的所有顶点进行相同的查询，即所谓的批处理。例如，对于产品推荐问题，他们希望为每个客户找到推荐。在一个图查询中编写这样的批处理查询要比编写单个客户推荐查询困难得多，因为数据结构和算法流要复杂得多。为了解决这个问题，出现了查询调用查询需求。在主查询中，对于每个顶点我们都调用单个客户的推荐查询。同样的模式也可以应用到其他复杂的图批处理中，分治可以使图查询逻辑更简单，资源更可伸缩。这还允许用户以更模块化的方式编写和组织查询。

8. 对SQL用户友好

我们发现大多数客户都有SQL开发人员。因此，图查询语言应该尽可能地接近SQL语法和概念，以便SQL开发人员能够以小的时间学习和实现图应用程序。

TIGERGRAPH GSQL如何解决这八大先决条件?

基于5年多的客户反馈，TigerGraph的团队与我们的客户共同开发了一种名为GSQL的图灵完整图数据库查询语言。它包括用于定义图模式的DDL(数据定义语言)命令，用于高性能加载结构化和半结构化数据的加载语言，以及具有隐式并行性的类SQL的图遍历和计算语言。

1. 基于模式，并具有动态模式更改能力

GSQL使用顶点类型和边类型作为模式构建块。图被定义为顶点类型和边类型的集合。一个TigerGraph数据库可能包含多个(可能重叠的)图，每个图都有自己的用户权限和查询集。例如,

此外，GSQL的DDL支持使用类似SQL的语法进行动态模式更改。这是当今管理企业数据的必备条件。使用DDL，所有GSQL查询都是针对逻辑模型编写的。我们的一些客户从一台机器开始，随着他们的数据大小的增长，他们迁移到使用我们的MPP图数据库来扩展性能和存储的多台机器。基于我们的数据独立性查询语言，它们的应用程序对于扩展架构的更改是透明的，并且可以无缝地从单个节点迁移到节点集群。

2. 图遍历的控制能力

GSQL的构建模块是一个具有单跳模式的类SQL块。例如，“查找所有年龄在23岁或以上、购买过iPhone的客户”的表述如下:

GSQL用户可以编写一系列的GSQL构建块来任意步遍历图，每个步骤都是单跳路径模式。换句话说，它是非常的声明式遍历，简单明了。它易于阅读和维护。没有计算机科学学位的客户可以在一两天内掌握它，并开始在他们的领域数据上编写图算法。

3. 图遍历的精细控制能力

GSQL引入了一组内置的累加器，它们作为顶点的运行时属性。这些运行时属性可以附载到并行遍历过程中看到的每个顶点实例，因此用户可以在运行时遍历过程中向顶点添加标记或运行时属性，以收集欺诈检测和个性化推荐等复杂应用程序的证据。GSQL还具有流控制组件，如WHILE循环、FOREACH循环和IF-ELSE/CASE-WHEN分支，以允许复杂的迭代或分支算法。与本地和全局累加器一起，GSQL让用户真正任意掌控他们的图数据。实际上，它是Turing-complete的，这意味着图数据上的任何算法都可以在GSQL中进行编码，因此不需要在图数据库系统和客户端应用程序之间来回交换半成品数据，从而减慢了查询性能。

4. 内置并行语义以保证高性能

在一个查询块中，结合内置累加器类型的一对创新的ACCUM和POST_ACCUM子句编码了顶点集或边集的并行处理，很好的支持了图遍历。这意味着GSQL允许用户非常容易地实现图数据的并行处理。这是图查询语言的一大优点，它鼓励用户进行并行思考，而不必担心实现细节。当然，并不是每个图查询都需要这个强大的特性。PageRank和社区检测类型的算法可以利用这个特性。

5. 具有表达能力很强的加载数据能力

GSQL的加载语言具有高度的表达性和说明性。我们的用户非常喜欢它。我们看到客户在半小时内学习并掌握它，并使用它在一天内将10到100个数据源集成到一个图模型中。

6. 数据安全性和隐私

行业的个多图模型诞生于GSQL中，帮助我们的客户实现数据共享和隐私保护。

7. 支持查询调用查询

GSQL可以在几个地方调用查询:在ACCUM和POST_ACCUM子句中，在语句层，甚至在被调用的查询体本身。这为解决现实的图遍历问题提供了大的灵活性和简单性。查询也可以递归地调用自己。该特性支持分治，极大地简化了查询逻辑，并鼓励编写可组合查询。

8. 对SQL用户友好

GSQL尽可能多地重用SQL语法、语义和关键字。实际上，GSQL可以被看作是单个SQL块的链。

下载终生免费TigerGraph Dev版，花1小时畅游开发者版，开始重新思考图分析（⚠️不是重新思考人生）

要了解更多信息，请参阅我们的白皮书，该白皮书提供了GSQL与另外两种图查询语言Gremlin和Cypher的比较。