图数据库由于其优于关系模型的优势而备受关注（参见此处的讨论）。然而，当不同的技术公司涌入这个领域，亚马逊，微软，甲骨文，IBM等时，当项目想要开始使用图数据库时，评估不同供应商的产品变得越来越具有挑战性。
在这篇文章中，我将分享我的见解，以评估从对不同图数据库进行基准测试而获得的心得。您可以在此处下载基准报告。
- 装载能力。如果您计划使用图数据库处理实际问题，这是好的和坏的图数据库的个（也是重要的！）标准。我建议尝试一个高于10亿边和5000万-1亿个顶点的公共数据集。检查加载工作，包括加载语言/ API支持，加载速度（大应在1小时内完成），增量/批量加载支持等。可以在此处找到不同图数据库供应商的一些加载脚本。如果你已经完成了这个小的需求加载，并且结果令人满意，那么接下来要尝试的是找到一个具有10个以上顶点类型和边缘类型的图，每个图都有一些不同的类型属性/属性。你能轻松装载吗？它是否支持复杂的属性类型，例如map，set和list？怎么样加载JSON文件？所有这些问题都是处理现实生活图数据的实际障碍。
- 是否支持实时更新。通过实时更新，这意味着更新可以在对数据库进行查询处理的同时进行。数据库更新可以是新顶点/边的插入/删除，现有顶点/边的属性的upsert等。图数据库提供并发控制，使得不同的操作可以以交错方式发生，但是终结果是一致的，就像所有操作都按顺序执行一样。请注意，图计算平台与图数据库不同。由于HDFS的设计限制，大多数基于HDFS的图平台（例如Giraph，GraphX）不支持实时更新。
- 磁盘存储采用原生图格式或非原生图格式。许多图数据库都是非原生的，这意味着它们将图数据存储在磁盘上的关系模型，RDF三元组或键值对中。在内存中，它们提供中间层API来模拟图遍历。原生图数据库以图模型格式 - 顶点和边存储图数据。此类供应商中受欢迎的是TigerGraph，Neo4j。原生图存储格式的优点在于它本身可以免费获得图模型的好处，因为图模型是一个自然索引，每个查询只触及索引后的相关数据。
- 查询语言表达能力。图语言可以是图灵完全图灵完整性 - 维基百科，意味着用户可以使用它来编写任何算法，从而从数据中提取值。目前，还没有标准的图查询语言，并且市场上的许多产品具有不同的表现力。TigerGraph的GSQL是一种用户友好且高度表达的查询语言，它更像是一种PL / SQL - 维基百科风格语言，用户可以使用它来声明性地编写任何图算法。另一种声明性语言是来自Neo4j的Cypher，然而，很难用它来编写精细控制图分析算法。第三个是Gremlin https：//arxiv.org/pdf/1508.03843 ......，高度表达，学习曲线不低，复杂度高。我不建议。简单的查询可以，稍微复杂的， 如多次反复遍历，就会显现出使用的问题。用户必须阅读每个手册，并询问不同的查询，以测试和欣赏每个语言的表达能力，学习曲线和设计理念等。关系数据库专家可以阅读本指南，了解和评估图查询语言。
- 支持计算和/或存储的横向扩展和/或纵向扩展。一些图数据库可以在存储上水平扩展（横向扩展），这意味着将机器加倍，存储可以加倍。但是，计算速度不会提高2倍。一些图数据库也可以在计算上扩展。如果他们这样做，他们必须有一个 MPP建筑。纵向扩展意味着在单个机器上，图计算引擎可以探索多核并行化计算，并在添加更多核时实现加速。在你对这个项目勾选之前，请注意，永远不要忘记加载工作。如果机器加倍会导致装载工作量增加一倍或三倍，则不能将其视为合格的横向扩展数据库。TigerGraph拥有可以横向扩展和扩展的MPP架构。亚马逊海王星无法横向扩展，它可以拥有主数据库的副本以提高吞吐量。Janus Graph和ArangoDB可以横向扩展存储，但不能在同一查询上横向扩展计算。由于其单一服务器架构，Neo4j无法扩展计算或存储。
- 支持OLTP，OLAP或HTAP 混合事务/分析处理（HTAP） - 维基百科。一些图平台纯粹用于离线大规模处理，即OLAP Online分析处理 - 维基百科样式，如PageRank - 维基百科，渐变下降，弱连接组件等。一些图数据库支持点遍历查询（例如返回给定人的3 -step neighbors）这是更多的OLTP风格。一个很好的衡量标准是看他们是否每秒谈论QPS 查询 - 维基百科，如果是的话，他们很可能支持OLTP。有些人可以同时支持HTAP。尝试使用简单的连通分量和页面排名算法，看看它们是否能在合理的时间内完成10亿个边缘图。
- 是否支持多图。这是企业安全性和并发性要求，其中不同部门希望同时对同一服务器/集群上的不同图/子图进行独占或包含访问。至于这篇文章，的供应商支持原生多图来自TigerGraph，它允许不同的图共享子图，这对于不同的功能单元来说很重要。Neo4j允许您为当前使用附加不同的图存储文件，但不允许同时使用具有相同服务器实例的多个图。默认情况下，亚马逊海王星有1个内置图表，不允许用户拥有自己的图表。
- 模式或非模式。一些图数据库供应商声称他们不需要预定义的模式。其他图数据库供应商需要预定义的模式，如传统的关系数据库，并支持模式的在线演变。在我看来，预定义的模式对于企业实时应用程序非常重要，因为使用模式，您实际上迫使开发人员/架构师有一个设计时间来考虑放入什么以及如何组织预先设置的图。从数据实例中分离元数据是一种众所周知的技术，可以在数据库系统中获得更好的性能。不幸的是，当前的图数据库市场过分强调元素类型的爆炸性数量，因此，提倡无模式作为应对这一挑战的优势，
- 有机图数据库还是附加图界面。这个很重要。作为一个数据库构建者，我个人不同意一刀切的说法。我遵循工艺并相信提供佳的专业数据库，以实现佳性能和用户体验。在当前的市场中，太多的供应商通过在现有核心的基础上为新的市场趋势添加新接口来扩展他们的产品，这些核心初是为另一个市场开发和构建的。这种摆动很难在数据管理软件领域提供好的产品，并导致在所需企业中采用正确技术的摩擦。说实话，一个简单的测试是对十亿边图的三跳查询。如果它们不是为图数据管理而设计的，那么很难实时获得3跳查询。这是一个12跳查询示例。
- 是否支持实时深层链接分析查询。在今天的大多数图数据库中，查询响应时间从3跳开始显着降低。一个简单的测试，看它是否是一个图数据库是测试他们的3跳路径邻居计数查询。对于十亿边图，给定一个输入顶点，图数据库能否找到所有具有到输入顶点的k-hop路径的邻居顶点，并返回总计数？这个简单的测试是区分好的和坏的图数据库的一个很好的标准。在我们即将推出的新基准测试中，我将揭示5个媒体流行图数据库的性能，只有一个可以完成这个简单的测试。所有其他人都失败了。这是因为从种子顶点开始，该顶点的邻居对于远离种子的每个额外跳跃而言指数变大。
- 是否支持内置图可视化。使用图数据库的一个很好的优点是面向对象的思想。与传统的关系数据库不同，从建模到查询结果的所有内容都是表格格式，图数据库优雅地将现实世界的对象映射到顶点和边缘，如果返回的结果可视化，人眼可以很容易地理解查询结果。顶点边图。这是一个例子。
总而言之，图数据库很热，并且随处可见。在开始图数据库世界的冒险之前，建议购买者或从业者多了解！这并不意味着很难找到合适的数据库。本文中的标准包含一些简单且可实现的步骤，供读者尝试并了解真相。
