图数据库项目DGraph的前世此生

本文由云+社区发表

做者：ManishRai Jain

做者：ManishRai Jain Dgraph Labs创始人

版权声明：本文由腾讯云数据库产品团队整理，页面原始内容来自于db weekly英文官网，若转载请注明出处。翻译目的在于传递更多全球最新数据库领域相关信息，并不意味着腾讯云数据库产品团队赞同其观点或证明其内容的真实性。若是其余媒体、网站或其余任何形式的法律实体和我的使用，必须通过著做权人合法书面受权并自负所有法律责任。不得擅自使用腾讯云数据库团队的名义进行转载，或盗用腾讯云数据库团队名义发布信息。

---

每当我向别人介绍本身，并解释咱们在Dgraph Labs所建设的内容时，我常常被人问到是否在Facebook工做过，或者我如今所作的尝试是否受到FaceBook的启发。不少人都知道FaceBook为社交图数据库所作的努力，是由于他们发布了不少关于图数据库基础设施的文章。

来自谷歌的Word仅限于提供知识图谱，但在这个项目以前，几乎没有人认为内部基础架构就能够实现这个服务。Google提供专门的系统来提供知识图谱服务。事实上，在谷歌工做的时候，我和个人团队对图数据库服务系统下了很大的赌注。远在2010年，我本身就至少作了两个比较激进的尝试去研究新的图数据库理论，来看看咱们能够创造什么。

Google须要构建一个新的图数据库服务系统，不只能够处理知识图谱数据中的复杂关系，还能够处理全部访问结构化数据的搜索服务（OneBoxes）。该服务系统要具有遍历全部数据的能力，还要具有足够高的吞吐量和足够低的延时，这样就能够应用于海量的网络搜索查询。当时几乎没有可用的系统或者数据库能同时知足上面三个要求。

如今我已经回答了谷歌为何要构建图数据服务系统，剩下的篇幅我会向大家介绍，咱们是如何一步一步，构建一个符合要求的图数据库系统来服务知识图谱和搜索引擎的。

我是怎么知道这些的？

先容许我快速的自我介绍一下，2006年到2013年，我在谷歌工做。最开始是做为一个实习生，后面在Web Search Infrastructure组做为一个软件工程师工做。2010年，Google收购了Metaweb，个人团队刚刚推出了Caffeine。我想作一些不同凡响的事情，并开始与Metaweb人合做，穿梭在旧金山和山景之间。我当时的目标是弄清楚如何使用知识图谱来改进网络搜索。

在我致力于研发图数据库以前，Google有一些项目。值得注意的是，Google在纽约办公室建立了一个名为Squared的项目，而且有一些关于知识卡片的讨论。这些是我的和小团队的零星努力。但那时候尚未造成一个既定的决策链，这也最终使我离开了谷歌。这个咱们稍后再谈。

Metaweb故事

如上所述，谷歌在2010年收购了Metaweb。Metaweb使用多种技术构建了一个高质量的知识图谱，包括爬取和解析维基百科，以及使用相似维基百科的众包策略经过Freebase运做。全部这些都是由他们内部构建的图形数据库驱动的，这个数据库名为Graphd ，一个图数据库程序（现已经GitHub上发布）。

Graphd有一些很是典型的属性。像守护进程同样，它在一台服务器上运行，全部数据都在内存中。整个Freebase网站都用了Graphd。收购完成后，谷歌面临的挑战之一就是继续运行Freebase。

Google构建了SSTable，而后是Bigtable，它们能够横向扩展到数百或数千台机器，共同服务于数PB的数据。并且它们使用Borg（一个集群管理工具，K8s的前身）分配机器，使用Stubby（gRPC出来）进行通讯，经过Borg名称服务解析IP地址（BNS，baked into K8s），并将数据存储在Google文件系统（GFS，相似Hadoop FS）。进程可能会死亡，机器可能会崩溃，但系统仍是会一直保持运行。

正是基于这个环境，Graphd得以发扬光大，服务于在单个服务器上运行整个网站的数据库的想法与Google（包括我本身）最初的想法千差万别。Graphd须要64GB或更多内存才能运行。若是你在嘲笑这内存，请注意时间点，这是在2010年。大多数Google服务器的最大容量为32GB。事实上，Google必须购买具备足够大RAM的特殊机器来支持Graphd。

GraphD的替代者

关于如何移动和重写GraphD以分布式方式工做的想法被提出，可是他们不是存储键值对的数据库，人们只须要获取一大块数据，将其移动到另外一个服务上，当访问对应的key，就能够提供服务了。图数据库须要保证有效的链接和遍历，这就须要咱们使用特定的方式构建软件。

在这些想法中，其中一个是使用名为MindMeld（IIRC）的项目。该项目能够经过网络硬件能够更快地访问来自另外一台服务器的内存。据推算，这种访问方式正常的RPC更快，足以快速复制内存数据库所需的伪复制直接内存访问。这个想法并无走得太远。

另外一个真正被采纳的想法是构建一个真正的图数据库服务系统。不只能够取代Graphd for Freebase，还能够为未来的全部知识图谱工做服务。这被命名为Dgraph，一个分布式的图数据库服务系统，一个升级版的Graphd。

不用感到疑惑，答案是确定的。在Google内部，Dgraph Labs这家公司和开源项目Dgraph，就是这样被命名的。

对于本博文的大部份内容，当我提到Dgraph时，我指的是Google内部的项目，而不是咱们构建的开源项目。固然开源项目后面也会有更多介绍。

Cerebro的故事：一个知识图谱引擎

一个无心中造就的图数据库服务系统

虽然那时是我已经意识到Dgraph在努力取代Graphd的路上，但我当时的目标是改进网络搜索的体验。我在Metaweb找到了一位研发工程师DH，他同时也是Cubed的创始人。

正如我前面提到的，Google纽约的一些工程师已经创建了Google Squared。DH创建了一个相似的项目Cubed。虽然Squared这个项目最终烂尾了，但Cubed很是使人印象深入。我开始考虑如何在Google上构建它。Google提供了一些小特性，帮助我更轻松的搞定整个构建过程。

第一个特性是搜索，谷歌提供了一种方法，能够高度准确地判断哪些词是连在一块儿理解的。例如，当看到像[tom hanks movies]这样的短语时，它能够告诉你[tom]和[hanks]应该连起来。一样，看到[san francisco weather]就知道[san]和[francisco]连在一块儿表达一个意思。对于人类而言，这些都是显而易见的事情，然而对于机器来讲，作到这一点很难。

第二个特性是理解语法，当一个相似于[books by french authors]的搜索请求产生时，机器能够理解为[french authors]写的[books]（即法国籍做者写的书）。但这个短语还能够被理解为写[french books]的[authors]，即写法国书籍的做者。我使用斯坦福的词性（POS）标记器来更好地理解语法并构建一棵语法树。

第三个特性是理解实体，[french]一词能够表明不少实体。它能够表明国家（地区），国籍（指法国人），菜肴（指法式食物）或法语。这里我可使用另外一个项目来获取单词或短语能够对应的实体列表。

第四部分是了解实体之间的关系。如今我已经知道如何将单词链接成到短语，短语应该被以什么样的形式组织（即语法），以及它们能够对应的实体，我须要一种方法来找到这些实体之间的关系以建立机器解释。例如，一个查询说[books by french authors]，而后POS告诉咱们它表明[french authors]写的[books]。咱们有[french]的几个实体，[authors]的几个实体，接下来算法须要肯定它们的链接方式。他们能够经过出生地联系起来，即出生在法国的做者（但多是英文写做），或者是法国国民的做者，或者说或写法语（但可能与法国这个国家无关）的做者，或者仅仅是喜欢法国美食的做家。

基于搜索索引的图数据库系统

为了肯定实体是否须要以及如何链接，我须要一个图数据库系统。Graphd从未扩展到整个Google级别，而我擅长的是网络搜索。知识图谱元数据以三元组格式化，即每一个事实由三个部分表示，主题S（实体），谓词P（关系）和对象O（另外一个实体）。查询必须来自[S P]→[O]，来自[P O]→[S]，有时来自[S O]→[P]。

我使用了Google的搜索索引系统，为每一个三元组分配了一个Id，并构建了三个索引，分别为S，P和O.另外，索引容许附件，因此我附上了每一个实体的类型信息（即演员，书，人等等）。

我创建了这个图数据服务系统，但知道它存在链接深度问题（以下所述），而且不适合任何复杂的图数据查询。事实上，当Metaweb团队的某我的让我开放该系统给其余团队访问时，我坚持拒绝了。

为了肯定实体间的关系，我会遍历查询实体间的全部可能性。好比，[french]和[author]之间会产生的全部关系，从中选一部分结果出来，在判断[book]和这些结果之间产生的任何联系，以此类推不断推演。这会致使同一个短语会产生多个解释，好比[tom hanks movies]这个短语，它会产生如[汤姆汉克斯执导的电影]、[汤姆汉克斯主演的电影]、[汤姆汉克斯制做的电影]这样的解释，并自动过滤像[电影命名汤姆汉克斯]的解释。

对于每一个可能解释，图数据库系统将生成结果列表，包含图中的有效实体，而且还将返回其类型（存在于附件中）。使用起来很是强大，由于结果的类型容许过滤，排序或进一步扩展等功能。好比对于电影搜索结果，您能够按照发行年份，电影的长度（短片，长片），语言，获奖等等对电影进行分类。

这个项目看起来很常智能，咱们（DH做为知识图谱专家也参与了一部分）将它命名为Cerebro，以后X战警电影里出现了同名机器（脑波触发器）。

Cerebro的运行常常会揭示一我的们最初没有探索过的很是有趣的事实。当运行像[美国总统]那样的查询时，Cerebro会明白总统是人类，而人类有身高。所以，它容许你按身高对总统进行分类，并代表亚伯拉罕林肯是美国最高的总统。它还能够容许人们按国籍查询总统，在这种状况下，它同时显示了美国和英国总统的名单，由于美国有一位英国国籍总统：乔治华盛顿。 （免责声明：基于当时KG状态的结果，不能保证这些结果的正确性。）

超连接 vs 知识图谱

Cerebro是有机会真正理解用户查询的含义的。利用图数据库的中的数据库，咱们能够生成查询的机器解释，生成结果列表并理解结果以支持进一步探索。如前面介绍的，您能够对结果启动特定的过滤和排序操做，也能够进行对链接进行遍从来显示数据的链接关系。从[美国总统]到[他们去的学校]，或者[他们所生的孩子]。 DH在另外一个他称为Parallax的项目中证实了从一个结果列表跳转到另外一个结果列表的能力。

Cerebro使人很是印象深入，Metaweb的领导层也支持它。即便是服务于其中的一部分的，Cerebro也具备使人满意的高性能和功能，我称之为知识引擎（从搜索引擎升级）。可是谷歌的领导没有知识图谱相关领域的。个人经理对此也并不感兴趣，在跟他沟通以后，我得到了将其展现给一位很是高级的搜索部门领导的机会。

然而展现以后的回应使人沮丧。对于[法国做者的书籍]的演示，该领导向我展现了谷歌查询的搜索结果，其中显示了十个相关的超连接，他认为谷歌能够作一样的事情。此外，他们不想从网站上取走大量信息，也许会侵犯搜索者的隐私。

若是你也认为这个高管说的有道理，不妨再想想：当Google进行网络搜索时，它并不能真正理解查询。它会在正确的相对位置，页面的等级中查找正确的关键字，以及作诸如此类的事。它是一个很是复杂和极其复杂的系统，但它并不能真正理解查询或结果。用户须要自行从结果中读取，解析和提取他们须要的信息，并进一步搜索以将完整的结果列表放在一块儿。

例如，对于[法国做者的书籍]，首先须要将一个详尽的列表放在一块儿，内容多大单个网页可能都放不下。而后按出版年份对这些书籍进行排序，或者按出版社等进行过滤，全部这些操做都须要大量的连接跟踪，进一步搜索和人工聚合结果。 Cerebro有能力将全部用户过滤信息的步骤省除，让人机交互简单而完美。

然而，这是当时典型的知识图谱方法。Google的管理层不肯定知识图谱的效用，也不肯定搜索引擎应该如何跟知识图谱结合起来。这个经过向用户提供网页连接而得到巨大成功的组织，难以轻易消化这种接近更知识的新方式。

在与Google管理层对峙了一年后，我几乎丧失了继续的信心。此时谷歌上海办公室的一位经理向我伸出手，我于2011年6月将项目交给了他。他组建了一个由15名工程师组成的团队。我在上海呆了一个星期，将我建造和学到的东西转移给工程师。 DH也参与其中，他在这里长期指导团队。

链接深度问题

我为Cerebro构建的图数据库服务系统存在一个链接深度问题。当须要查询的先前部分的结果集来执行其后续部分时，一个链接就被创建了。典型的链接将涉及一些SELECT操做，即来自通用数据集的某些结果中的过滤器，而后使用这些结果来过滤数据集的另外一部分。我将以一个例子来讲明。

好比说，你想知道 [people in SF who eat sushi]（住在旧金山且吃寿司的人）。数据被人们分红两类：住在SF的人和吃寿司的人这两类信息。

以上查询是单级链接。若是数据库外部的应用程序正在执行此操做，它将执行一个查询来执行第一步。而后执行多个查询（每一个结果一个查询），找出每一个人吃什么，只挑选吃寿司的人。

第二步是出现扇出问题。若是第一步有一百万个结果（全部旧金山人口），那么第二步须要将每一个结果放入查询中，检索他们的饮食习惯，而后经过过滤器过滤出符合条件的人。

分布式系统工程师一般经过广播来解决这个问题。他们将结果分红不少批量任务，使用分片功能进行分割，并将查询任务分配到集群中的每一个服务器。使用分布式会完成链接，但会致使查询延迟问题。

分布式系统中的广播很糟糕。谷歌的Jeff Dean在他的“Achieving Rapid Response Times in Large Online Services” 演讲中最好地解释了这个问题。查询的总延迟老是大于最慢的那台机器的延迟。单个机器上的小问题就会致使延迟，每次查询涉及到海量的机器就会大大增长延迟的可能性。

考虑一个服务器，其50％延迟为1ms，但99％延迟为1s（即百分之99的延迟都小于等于1s）。若是查询仅仅在一个服务器上处理，则只有1％的请求会占用一秒钟以上。但若是查询触及其中的100台服务器，则63％的请求将占用一秒钟以上。

所以，执行一个查询的广播对于查询延迟是不利的。如今考虑是否须要进行两次，三次或更屡次链接。对于实时OLTP场景来讲，会变得太慢，延时超出人们的接受范围。

大多数非原生图数据库都存在这种高扇出的广播问题，包括Janus图，Twitter的FlockDB和Facebook的TAO。

分布式链接是一个难题。现有的单机图形数据库经过将通用数据集保持在一个机器（独立数据库）内，而且在不触及其余服务器的状况下进行全部链接操做，则能够避免这个问题，好比Neo4j。

进入Dgraph：任意深度链接引擎

在结束Cerebro以后，我有了构建图形服务系统的经验，参与了Dgraph项目，并成为该项目的三位技术主管之一。 Dgraph设计中涉及的概念是新颖的，解决了链接深度问题。

Dgraph以一种特殊的方式对图形数据进行分片，其中每一个链接均可以彻底由一台机器执行，回到以前说的概念主题 - 谓词 - 对象（SPO），Dgraph的每一个实例将保存与该实例中的每一个谓词相对应的全部主题和对象。多个谓词将存储在实例上，每一个谓词都以总体存储。

这实际上容许了查询执行任意深度链接，同时避免扇出广播问题。好比查询[people in SF who eat sushi]，会致使数据库内最多进行两次网络调用，不管集群规模大小。第一个调用会找到全部住在旧金山的人。第二个调用会发送这我的名单并与全部吃寿司的人求并集。咱们还能够添加更多约束或扩展，每一个步骤仍然会涉及最多一个网络调用。

这引入了位于单个服务器上的很是大的谓词的问题，可是这个问题能够经过随着大小的增加在两个或更多个实例之间进一步分割谓词来解决。即便这样，整个集群中的单个谓词拆分也只是在最极端状况下的最坏行为，其中全部数据仅对应于一个谓词。在其余状况下，这种经过谓词对数据进行分片的技术表现都很好，能够在实际系统中实现更快的查询延迟。

分片技术并非Dgraph的惟一创新。Dgraph为全部对象分配了整数ID，并对其进行排序并存储在发布列表结构中，以便快速对这些发布列表求进行交叉计算。这些创新将在链接期间加快过滤速度，还能够用来查找公共引用等。这些想法里涉及到了Google的Web服务系统。

经过Plasma项目统一全部OneBox

谷歌的Dgraph不是一个数据库，而是一个服务系统，至关于谷歌的网络搜索服务系统。使用Dgraph还能够对实时更新作出反应。做为实时更新服务系统，它须要一个实时图形索引系统。我在Caffeine项目中积累了不少实时增量索引系统方面的经验。

我发起一个项目，经过图数据索引系统来统一全部Google OneBox，其中包括天气，航班，事件新闻等。你可能不知道OneBox这个词，但你确定已经看过了。 OneBox不一样于其余搜索结果，是一个单独的显示框，在运行某些类型的查询时显示，Google能够在OneBox返回更丰富的信息。想了解一下OneBox，请尝试搜索[weather in sf]。

在发起这个项目以前，每一个OneBox由独立后端运行并由不一样的团队维护。有一组很复杂的结构化数据，但每一个OneBox之间没有共享数据。这样不只在操做上保留了后端的大量的重复工做，并且每一个Box之间缺少知识共享也限制了Google能够响应的查询类型。

举个例子，[events in SF]能够显示旧金山的事件新闻，[weather in SF]能够显示旧金山的天气。但若是[events in SF]这个OneBox了解到天气多雨而且知道用户须要查找的事件是在室内仍是在室外，它就能够根据天气过滤（或至少排序）事件（在暴雨中，可能电影或交响乐等室内活动是最好的选择）。

在Metaweb团队的帮助下，咱们开始将全部这些数据转换为SPO格式并在一个系统下对其进行索引。我将系统命名为Plasma，一个基于图数据服务系统Dgraph的实时图形索引系统。

管理混乱

像Cerebro同样，Plasma项目资金不足，但仍在继续。最终，当管理层意识到OneBox团队即将迁移到这个项目时，他们须要负责知识图谱的“合适人选”。在那场“权利的游戏”中，我经历了三次管理层变化，但每次都没有对知识图谱有经验的人加入。

在这次管理层洗牌期间，支持Spanner的管理层认为Dgraph过于复杂，Spanner是一个全球分布式的SQL数据库，须要GPS时钟来确保全局一致性。具备讽刺意味的是，这至今仍然使人难以置信。

最终，Dgraph取消了，Plasma幸免于难，但由新的领导和新的团队来负责继续运营，并直接汇报给CEO。新团队对知识图谱缺少了解，他们决定创建一个基于Google现有搜索索引的服务系统（就像我为Cerebro所作的那样）。我建议使用我已经为Cerebro创建的系统，可是被拒绝了。我将Plasma改造为一个爬取并能够扩展知识话题到若干层的系统，这样Google现有的搜索服务能够把结果当成Web文档来处理。他们称之为TS（名称缩写）。

这种改造也意味着新的服务系统将没法进行任何深度链接。在不少公司，我都看到一个关于知识图谱的“决策诅咒”，是由于工程师们一般错误地认为“图数据服务是一个简单的问题，能够经过在另外一个已有系统之上构建一个层来解决”。

几个月以后，2013年5月，我离开谷歌，此时我已经为Dgraph / Plasma工做了两年。

后记

• 几年后，Web搜索基础设施团队被重命名为Web搜索和知识图形基础设施团队，我曾经向其演示Cerebro的领导开始从新领导知识图谱工做，大谈特谈他们打算如何用知识图谱取代超连接，并直接回应尽量多的用户查询。
• 当上海的Cerebro研发团队的即将将项目上线时，该项目从上海直接被拉到了谷歌纽约办公室。最终，它以Knowledge Strip的形式上线。若是你搜索[tom hanks movies]，你会在搜索结果顶部看到它。自首次发布以来，它有一些迭代改进，但仍然不支持Cerebro提供的过滤和排序级别。
• 在Dgraph工做的全部三位技术主管（包括我）最终都离开了谷歌。据我所知，其余两位领导如今正在微软和LinkedIn工做。
• 当我做为高级软件工程师离开谷歌时，我确实得到了两次晋升，目前准备迎接第三次。
• 小道消息，当前版本的TS实际上很是接近Cerebro的图形系统设计，主题，谓词和对象都有一个索引。所以，它将继续受到加入链接深度问题的困扰。
• 此后，Plasma被重写并重命名，但仍然继续充当实时图形索引系统，支持TS。他们一块儿继续托管和提供Google的全部结构化数据，包括知识图谱。
• 从不少地方均可以看出，Google没法进行深度链接。首先，咱们仍然没有看到OneBoxes的各类数据反馈的结合：尽管天气和KG数据随时可用， [cities by most rain in asia] （亚洲下雨最多的城市）都、没有生成城市实体列表（相反，结果是来自网页的引用）; [events in SF]没法根据天气进行过滤; [US presidents]的结果不能进一步分类，过滤或扩展到他们的孩子或他们就读的学校。我怀疑这也是中止使用Freebase的缘由之一。

搜索关注“腾讯云数据库TencentDB"官方微信，最新最热数据库前沿知识和手把手实战教程等你来约，更可在移动端一键管理数据库。

Dgraph：凤凰磐涅

离开谷歌两年后，我决定创建Dgraph。不在Google的日子里，我见证了不少与在内部研发图数据系统时的犹豫不决。图形空间有不少半生不熟的解决方案，特别是不少自定义解决方案，草率的将系统搭建在关系型或NoSQL数据库之上，或者做为多模型数据库的众多功能之一。若是存在一个本地单击解决方案，则会遇到可伸缩性问题。

Dgraph团队花了三年的时间，不只吸取了我本身以前的经验，并且还对系统设计进行了大量的原创型研究，创建了市场上无与伦比的图形数据库。所以，公司具有了强大，可扩展且高性能的解决方案，用来替代那些半生不熟的解决方案。

此文已由腾讯云+社区在各渠道发布

获取更多新鲜技术干货，能够关注咱们腾讯云技术社区-云加社区官方号及知乎机构号