图数据库_图数据库成为主流

原文： 《Graph Databases Go Mainstream》 作者： Kurt Cagle Former Contributor COGNITIVE WORLD Contributor Group Futurist, Technologist, Information Architect, Blogger

原文发表在:

 https://www.forbes.com/sites/cognitiveworld/2019/07/18/graph-databases-go-mainstream/#32d93bd0179d

翻译：唐行方 图片：GETTY 排版：王图图  

图技术正在成为主流，而知识库则处于领先地位。

现在看来，每十年都会流行一种新的数据库形式。 在 20 世纪 90 年代，关系型数据库成为了主要的数据环境，因其易用性和表格式的排列方式很自然地满足了不断增长的数据网络需求。 而在 21 世纪的头十年里，虽然关系型数据库依然保持强大， XML 数据库也出现了，并且 NoSQL ，即数据库不需要以纯粹的表格形式进行结构化的想法开始流行起来。 在本世纪的 10 年代，随着 Hadoop 作为一个数据平台的迅速崛起和最终的衰落， JSON 数据库得到了广泛的关注。 有鉴于此，可以做出判断： 图形数据库将成为 21 世纪 20 年代的热门数据库。 自从数据库发展的早期以来，图形数据库一直以某种形式出现，但它们通常比关系型数据库更慢，更复杂，并且在适用性上更受限制。它们也主要被用作学术数据库，因为这类数据库最早的使用案例之一是建立逻辑分析系统，而且由于它与学术的联系，图形数据库多年来一直在商业领域受到忽视。 然而，到了2014年年中，几项关键性的进展汇集到一起，使图形数据库在几项计算机领域里的重大发展中拔得头筹。Neo4J作为一个早期的且仍在被大量使用的图形数据库，已经开始获得足够的成熟度和渗透性并开始用于某些类型的数学图形处理。硬件(通过云计算)也已经变得足够快，让许多早期的关键性能挑战可以被克服。一种图查询语言(SPARQL)的第二个版本的出现解决了早期版本带来的许多问题，包括引入了更新功能，这意味着出现了动态添加内容的一致机制。像MongoDB和CouchDB这样的JSON数据存储的出现使得人们更加关注索引式的非传统型数据库的挑战，这反过来又导致了连接处理(它对于任何数据库都是核心要求之一，但对于图形数据库尤为重要)的显著优化。

同样重要的是，已经有几家公司开始试验图形数据库以解决在企业层面上开始变得棘手的这些问题——企业元数据管理、主数据管理、自然语言处理、知识导航和其它相关问题，而搜索技术本身已经触底。讽刺的是，机器学习(通常使用数据聚类方法进行文本分析)最近越来越成为帮助构建图形数据库的另一种机制。从某种程度上来说，最新的图形数据库现在正在将机器学习算法和工具整合进其核心套件中去。

图数据库提供了一种通过类进行组织的方法，支持Web，并且在管理元数据方面优于传统的关系或NoSQL数据存储。 理解图

最后，图形数据库正越来越多地利用一个最新的技术发展——功能日益强大和复杂的图形处理单元(GPU)，这些专用的多核计算机致力于创建复杂的三维图形。这些GPU的工作原理是将网格分解成数百万乃至数十亿个三角形。通过为组成这些网格的节点和边分配属性，GPU可以计算颜色、光照、边的硬度与柔软度、位移和其他许多属性。由于它们采用了流水线结构，这种计算的速度非常快。

事实证明，图形数据库与图形处理中使用的网格差别不大(事实上它们几乎相同)，特别是从为节点和边分配属性的角度来看：每个节点代表一个概念，每条边代表一个关系。这意味着，特别是从2010年末开始，图形数据库供应商越来越多地利用GPU来沿这些图形遍历和比较节点值，有效地利用了GPU为power graph数据库提供的大规模并行能力。虽然更传统的CPU会被继续使用，但GPU上的图形数据库很可能在21世纪20年代占据主导地位。

目前，图形数据库分为两大类：属性图和语义图。它们有一个关键不同：语义图将边视为标识关系的全局命名对象，而属性图则将边视为基于周围节点的唯一对象。这意味着可以将文本属性(如日期或字符串)分配给属性图中的关系。一种在语义图中类似的操作，称作具体化，将会给节点和边一起赋予一个标识符，但目前SPARQL还没有本质上支持这种功能。

这种情况很可能会随着SPARQL的下一个版本(它可能会在21世纪20年代初正式出现，同时还会对变量谓词路径进行一些更改)而改变。这实际上意味着，在未来几年内，属性和语义图数据库将合并为一个类别。除此之外，你还可以看到图形数据库与NoSQL数据库的合并(以JSON或XML风格，或者在某些情况下两者兼而有之)。

图形数据库本质上比传统的关系数据库系统更灵活，因为它可以将数据库的元数据视为数据本身，并以完全相同的方式访问。实际上，你可以用图轻松地表示关系数据库，因为关系表/列/行/键结构本身就是一种图形式。虽然直到最近，这种灵活性还是以牺牲性能为代价的，但是随着GPU的发展，这种性能差距已经基本消失了。

越来越多的系统也在启用关系垫片隐藏表格和图形数据库之间差异的细节，以便使它们可以使用现有的工具集(例如用于数据分析或可视化的工具集)。但随着完整图功能的标准化，新的利用这种标准化以同时满足灵活性和高性能的工具将出现。这意味着到2030年，图形数据库有可能取代现有的关系型数据库的市场。

图形数据库市场正在发展，合并期可能即将到来。 市场状况 大约十年前，曾经有过四个商业的和几个开源的图形数据库，它们共同服务于一个与关系型数据库市场相比很小的市场。我个人还记得，当时在几次语义图形数据库会议的贸易展台上，供应商的数量超过了参展者。现在已经不是这样了，供应商图形数据库专家在过去的几年里如雨后春笋般涌现，以至于可以对不同供应商的种类进行一番讨论。

---

坚定者

这一组包括那些在2008-2012年语义图数据库核冬天中幸存下来的供应商。它们往往拥有最长的追踪记录，但也倾向于关注诸如推理和SPIN之类的功能，这些功能在很大程度上早于SPARQL的第二个版本，尽管它们完全支持该版本。这些产品包括TopQuadrant的Top Braid、Cambridge Semantic的Anzo、OntoText的GraphDB和Franz的Allegrograph等。所有这些都是很好的产品，尤其是Top Braid，它在SHACL(一种数据模式语言)上的工作继续在这个领域保持创新。它们还倾向于拥有更广泛的数据管理策略，使它们成为能够在企业层面上实现传统语义的好产品。

混血儿

这一组包括那些将三重存储(图形数据库)与其他集成数据库系统(如JSON或XML)或搜索引擎相结合的供应商。在许多方面，这些都是过渡性的系统，它们对现有的索引技术进行了重新利用(或在其基础上建设)，并在2012年至2017年左右的时间段内大部分转移到图空间中。这其中包括MARKLogic，它提供对JSON和XML文档和语义的支持，以及StGART，它是在JSON基础上构建的，但采用了复杂的索引技术。混血儿系统在混合数据系统中工作得很好，但它们的价格也往往高于其它图形数据库。

少壮派

一般来说，这一群体仅仅在几年前才真正成为一股力量，其中包括了Pool Party、BlazeGraph(以及它的最新化身Amazon Neptune)、Tiger Graph和Data World。我也把Neo4J放在这一类，尽管它已经存在一段时间了。在大多数情况下，这些产品将重点放在作为属性图形数据库的图形数据库上，并且在某些情况下已经放弃了诸如推理之类的特性，随着SPARQL的广泛采用，这些特性变得越来越无关紧要。

支持者

这一群体包括像SmartLogic(或最近收购的Capsenta)这样的公司，它们通常是建立在多个三重存储之上(并与之合作)。它们通常为数据建模、文档实体扩展、高速摄取和集成可视化提供支持。有明显迹象表明，随着市场变得更加拥挤，支持者们可能会与某个特定的供应商建立战略合作伙伴关系，或者干脆与之合并(我怀疑MarkLogic和SmartLogic正特别朝着这个方向发展)。

---

棒球运动员同时也是投手、是MVP、是一个人。知识库对于处理现实世界的复杂性非常有用。

最大的增长领域—知识库

有许多因素都表明，图形数据库在未来十年将获得相当大的吸引力。首先就是知识库的兴起，它可以被看作是数据的百科全书。

举个例子，考虑一个梦幻棒球联盟。在这个例子中，我们通常需要追踪许多不同类别的事物，例如球员、位置、球队、赛季。随着类别数量的增加，创建接口以查看每个类中的各种项目的能力下降，而这些程序的复杂性则在上升。传统的数据库程序在这时会不堪重负，因为它们通常只试图提供所涉及数据空间的一部分的特定视图。

知识库采用与传统不同的方法，一种通常被称为上下文无关的设计，在这种方法中，系统中的每个对象都被视为图中的一个节点。在知识库中，每个节点都有一个最小的属性集，这些属性允许它显示在图中。我喜欢在这里用纸牌来比喻，就像在棒球纸牌上，问题中的牌可能是投手、接球手、球队、击球手等等，但所有卡片都需要有标题、图片和一些其他基本属性，这样卡片才能被打印出来。

对于那些熟悉这个术语的人来说，上下文无关的方法在概念上类似于网络对REST所采用的方法，因为被请求或被发布的数据通常并不扮演重要的角色，只需要数据和进程遵循某些基本协议即可。但是，细节确实很重要，并且通常以一种难以用纯层次结构管理的方式重叠。譬如说，在棒球联盟例子中，数据通常是以层次形式组织的，在一个特定的赛季中，一支球队有一些球员，其中每个都有一定的作用(投球手，接球手，游击手，等等)。

当你开始考虑赛季间的交易和类似的行动时，情况会变得更复杂，因为与投球手相关的属性(每场投球数、三振数等)不同于与击球手相关的属性(赢得的跑垒次数，保送次数等)。但以上又只有在国家联盟成立，因为美国联盟允许投球手击球，而全国联盟不允许。对这种逻辑进行建模会给典型的数据库带来很大的限制，但这却实际上是知识库的优势所在，因为在知识库中，属性本身就是可以作为数据访问的资源，而且属性本身也可以包含元数据。

这种能力使得通过导航而不是通过熟悉查询语言来有效地构建查询成为可能。此外，你还可以创建额外的过滤器(通常称为语义约束)，它允许你查找2018赛季西雅图水手队投手的所有球员并按每场比赛的平均投球数排序。这无需了解数据库表或数据结构，通常甚至不需要你写一行代码。

这种灵活性还扩展到创建数据服务的能力。例如，有了知识库，就可以将上述查询直接转换为URL，该URL将以机器可读(JSON或XML)格式返回一个数据提要，以其他应用程序可以使用的格式提供当前数据，而不必让程序员编写新的数据API。

知识库在整合企业数据的同时让企业继续构建内部和面向公众的应用程序这方面可能会获得长足的发展。更新的技术也使得提供属性级别的安全性成为可能，在这种情况下，给定的用户只有在具有相关访问级别的情况下才能查看或浏览特定的属性。

机器学习系统也使对于知识库摄取的自动分类变得更容易，而且随着ML+语义的好处被更好地证明，这只会随着时间的推移变得更加普遍。其它应用程序，包括推理分析系统、风险检测和缓解、最小路径分析和其它所有具有语义组件的应用程序，都将很可能在成功的知识库基础上搭载。它们需要某种程度上不同的数据组织，但是随着数据联合也变得越来越普遍，这比起革命性的变化来说不如说是一个进化性的变化。

最后一点需要注意的是，最近语义图领域中最令人兴奋的领域之一是与属性图技术的统一，在这种技术中，声称(事实陈述)本身就被视为资源。RDF的早期工作支持这一点，但是由于性能原因，(大多数现存的)知识图所使用的SPARQL查询语言规范既没有实现它，也没有实现变量属性路径。

我预计来自W3C的SPARQL2.0提议(它拥有语义技术的大部分核心专利)可能会出现，但最早可能要到2022年才会成为现实。如果是这样，结果很可能是SPARQL、Gremlin和/或Tinker Pop的某种形式的合成。

总体而言，以知识图谱为主导的语义系统的市场前景是积极和不断增长的。

总结

考虑到以上这些，语义采用的路线图变得越来越清晰。寻找语义数据系统变得更加面向知识库，而不是推理分析，至少一开始，它将同时结合机器学习和自动分类的最新进展。

数据领域的大佬们现在正密切关注着这一领域。随着战略合作伙伴关系导致的彻底合并，顶级玩家开始抢购可行的技术而非在内部构建技术，我预计会出现一波整合浪潮。在未来两年内，这种可能性很高(尤其是在经济低迷的情况下出现不良销售的话)。

与此同时，随着标准的敲定，我希望看到语义和属性数据库的重新合并，这很有可能是由W3C为实现这种统一而采取的一些正式行动所造成的。

---

点击「阅读原文」获取英文原文

免责申明：本文全部内容均来源于网络开放信息整理,如有侵权,请联系删除