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

Posted 2021-05-01 TigerGraph

点击标题下「蓝色微信名」可快速关注

涨姿势

 

【关于图形数据库】

图形数据库是一种非关系型数据库，它应用图形理论存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系。关系型数据库用于存储“关系型”数据的效果并不好，其查询复杂、缓慢、超出预期，而图形数据库的独特设计图模型更适合今天的海量互连数据。

前奏科普篇 by Mingxi:

去年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开发人员能够以最小的时间学习和实现图应用程序。

那么如何解决这八大先决条件呢?

敬请期待 跨越鸿沟——图数据库查询语言的八个先决条件——下篇