我对图数据库基准测试的兴趣始于我在SIGMOD 2018上与Peter Boncz（LDBC主席）的对话。他向我介绍了他在分析著名的TPC-H关系数据库基准时使用的“阻塞点”概念。他还与我分享了他在设计图数据管理基准LDBC 社交网络基准时采用的阻塞点方法(LDBC-SNB)。那时，为了简单起见，我刚刚完成了使用仅拓扑（没有属性的顶点/边）数据集并依靠 k-hop 查询和众所周知的迭代算法（例如 PageRank 和 Connected Components）来比较六个图数据库比较（这是行业首创，其次是其他图形初创公司和学术界基准报告）。当我在 TigerGraph 与最大的银行、医疗保健、零售和制造企业合作时，我意识到这些基准不符合评估企业级图形数据库的实际要求。我一直在寻找更接近真实客户查询的复杂图形查询模式的图形基准。LDBC-SNB 符合要求！
从那时起，TigerGraph 就采用 LDBC-SNB 作为基准套件来评估我们的发布性能，并且我们使用最大的 LDBC-SNB 数据集（2019 1TB，2020 5TB）继续创造可扩展性方面的世界纪录。
近日，Neo4j的吹捧在100TB的规模运行LDBC-SNB查询（视频这里开始51:48;演示的源代码在这里）。起初，我对此感到很兴奋，因为我们受人尊敬的竞争对手似乎开始关注可扩展性，并意识到大数据集在图用例中的重要性。然而，在查看了演示的实际内容后，我真的很失望。这种所谓的 100TB 演示并不是对 LDBC-SNB 基准的合理使用；这是一种纯粹的营销策略。也就是说，对于解决实际业务问题的现实世界从业者来说，这不是一个有用的演示。
这个博客将讨论为什么基准测试很重要，并展示 Neo4j 的 100TB 演示是如何伪造的。
关于我的背景的一点点。我是ISO GQL标准委员会成员，并积极为 GQL 图查询语言标准做出贡献。我写这篇博文是用我在数据库领域的二十年研究（我在佛罗里达大学的数据库博士项目培训）和行业开发经验（微软、甲骨文、Turn Inc. 和 TigerGraph）。我已尽我最大的努力使这个技术博客能够被可能对数据库世界不熟悉的普通读者所使用。
Neo4 近期 100 TB Demo 总结
简而言之，Neo4j 采用了 LDBC 基准名称和 LDBC-SNB 基准中的图/表模式，生成了自己在现实生活中无用的简化虚拟数据集（实体之间没有真正的相关性，没有现实的边缘或关系度），cherry -从 LDBC-SNB 的 14 个 IC 查询（第 32 页）中挑选了4 个简单的查询，以声称并创造 Neo4j 可以扩展和回答全局查询的错觉，但两者都不是真的。
分布式和可扩展的数据库不需要用户知道或关心系统需要多少台机器或分片。它应该只是透明地工作。
Neo4j 对其系统中的分片数量以及架构的一部分应该有多少分片以及其他部分应该有多少分片感到自豪和兴奋。这仅仅是事实表明 Neo4j 结构产品不是分布式或可扩展的数据库。作为一名数据库专家，有时我很欣赏 Neo4j 如何将其架构在可扩展性方面的致命缺陷转化为技术壮举，并在其产品营销中如此执着。要了解真正的分布式图数据库应该具备什么以及与 Neo4j 的 Fabrics 产品的比较，请参阅本文的高级摘要。
相比之下，TigerGraph 可以完成 Neo4j 在 100 台机器（而不是 Neo4j 演示中的 1000 多台机器）下展示的一切，对我们产品中的用户透明，开箱即用，无需分片规划，甚至在 TigerGraph Cloud 上！请继续关注有关此的单独博客。
有关 Neo4j 演示的更多详细信息：
Neo4j 创建了自己的数据生成器来生成 100TB 的数据。生成虚拟数据很简单。如今，凭借廉价的存储，生成 100 TB 的数据非常简单。Neo4j 生成的数据集既没有数据倾斜（数据不均匀）也没有真实的分布。官方的 LDBC-SNB 数据生成器旨在生成与Facebook 社交网络研究中描述的真实世界分布接近的连接数据（这就是图表的内容）。用于 Neo4j 演示的数据被简化以获得有利的结果，并不代表现实世界的复杂性，查询是从基准中挑选出来的，演示滥用术语“全局查询”来制造营销假象。
Neo4j 的现场演示从 14 个 LDBC-SNB IC 查询中挑选了一个特定查询。此查询仅涉及数万亿个图形元素中的数千个图形元素（节点/实体和边/关系）。它根本不是深层链接分析，它没有以任何有意义的方式证明可扩展性。
相比之下，自 2019 年以来，TigerGraph 采用了严格的基准测试方法，在 TB 规模上实施 LDBC-SNB 基准测试。我们所有的基准测试都采用以下方法：
严格使用 LDBC-SNB 模式和数据生成器来生成原始数据。
在 LDBC-SNB 基准测试中实现所有查询：不挑剔。
在 SF-1 和 SF-100 上与其他商业数据库系统交叉验证了所有结果（因为没有其他产品可以在 SF-1K 规模的大数据集上完成所有查询）。在我们以 TB 规模进行基准测试之前，确保所有查询及其结果都是正确的。
通过这样做，我们希望让我们的客户可以360度全方位地了解我们的产品，并在整个图数据库行业中以身作则，展示权威LDBC图数据库基准的公平使用。我们邀请所有图数据库供应商对基准进行公平使用，以便在健康和客观的环境中培养图数据库的采用。
为什么要进行基准测试？
当 IT 专业人员计划购买技术产品时，他们需要评估多个竞争产品并回答以下问题：“哪种产品最能满足我的需求？”
基准评估基于跨多个维度的明确定义的客观标准来评估替代产品。它允许人们定量比较不同的技术，以便为他们的软件购买做出更客观的选择。
精心设计的图数据库基准测试从以下角度对不同的图数据库进行了公平的 360 度定量比较：
性能：任何数据库管理系统最基本的 KPI 都是性能。您能以多快的速度回答基准查询？你的吞吐量是多少？
可扩展性：另一个关键衡量标准是可扩展性。技术决策需要考虑未来的增长。所以用户关心数据库的大小限制是多少？它可以处理 1TB、10TB、100TB、1PB 等等吗？数据库在多大程度上不再表现良好？这是一个需要提出的重要问题，因为架构限制无法在几天或几个月内修复。需要几年时间！
存储压缩率： 这与TCO（总拥有成本）有关。图数据库供应商的一个关键技术障碍是他们如何在磁盘和内存上紧凑地表示图。给定相同的原始数据，图形存储越小，它可以容纳在内存中的数据就越多。因此，存储访问延迟越低，硬件成本也就越低。
查询语言表达能力：设计良好的图数据库基准测试可以揭示图形数据库语言的表达能力限制。这是评估图数据库的独特维度，因为图数据库可以回答其他数据库查询语言无法回答的高度复杂的查询。有经验的数据库购买者会犹豫购买无法大规模实施完整基准的数据库。
可变性：可变性要求数据库可以同时更新和查询。在现实生活中非常需要可变数据库，因为它允许针对实时数据运行查询。
哪个基准？
五年前，当我开始在 TigerGraph 领导基准测试工作时，我使用了一种简单但严谨的方法：选择一个关系丰富的真实数据集，修复硬件，选择最常用的图查询（k-hop、page rank等），进行交叉验证，然后在不同的比例因子下测试性能。这种方法提供了裸机性能，许多其他图形数据库供应商都遵循了我们的方法，据我们所知，这是业界第一个。但是，由于当时的时间和资源限制，它并不全面。它无法系统地发现和量化图数据库的弱点。我放弃这种简单方法的关键原因是它与现实世界图形数据库用户的使用模式相去甚远。
在 Peter 向我介绍了 LDBC-SNB 基准测试之后，我将其纳入了我随后的基准测试中。为什么？
真实数据特征：与其他数据集不同，这个 LDBC-SNB 基准数据集模拟了现实生活中的社交论坛场景。该模式包含 11 种顶点类型和 15 种边类型。它模拟在 Facebook 等真实社交网络中发现的数据和边缘分布。并且顶点和边具有属性（属性），它们使用来自 DBpedia 的真实数据来确保属性值是真实的和相关的。
覆盖不同阻塞点的代表性图查询：阻塞点是基准测试背后的代表性技术瓶颈，其解决方案将显着提高产品的性能。LDBC-SNB 具有三个查询集——Interactive Complex (IC)、Interactive Short (IS) 和 Business Intelligence (BI)——涵盖 OLTP 和 OLAP 样式的查询模式。所有三个查询集都包含变异查询。
查询语言不可知： 我喜欢的另一个方面是每个查询语义都是用纯英语描述的，并通过绘图进行直观说明。任何数据管理供应商都可以使用他们的 DSL（域特定语言），例如 SQL、Cypher 或GSQL来实现基准查询，从而产生相同的结果。在 ISO 标准GQL于 2023 年或以后推出之前，这是黄金。
数据生成器：数据生成器至关重要。它需要是确定性的，它应该生成具有接近现实生活特征的数据，并且需要扩展以生成大型数据集。LDBC-SNB 数据生成器遵循TPC基准测试的风格，这是业界最负盛名和众所周知的关系数据库基准测试。它可以确定性地生成不同的比例因子（SF）：SF-1（1GB 数据）、SF-10（10GB 数据）、SF-1k（1TB 数据）等等。此外，对于每个确定性生成的数据集，数据生成器可以生成相应的查询参数，从而确保基准查询可以产生非空结果。
信誉卓著的团队，背后有数十年的努力。它背后的工作组由几十年来研究和实践图数据基准设计的知名数据库研究人员组成。查看他们的出版物列表。
Neo4j 在 LDBC-SNB 上的 100TB 演示
有了上面的背景，我们准备看一看 Neo4 使用 LDBC-SNB 模式的 100TB 演示。请注意，我没有使用“基准”这个词，因为 Neo4j 在他们的演示指南中巧妙地阐明了这个演示不是基准。
“数据本身是根据 LDBC 社交网络基准图的规范生成的。
此演示不是基准，但基准数据非常适合评估扩展策略的影响。”
很明显，Neo4j 选择了权威的基准测试 LDBC-SNB 是因为它的声誉。他们想展示他们所谓的结构产品的可扩展性和性能。不幸的是，这不是对 LDBC-SNB 基准的合理使用。为什么？
数据生成过于简单
在演示时，LDBC-SNB 的官方数据生成器无法生成 100TB 的原始数据。Neo4j 发布了他们自己的数据生成方式，没有遵循原始的基准测试哲学。他们划分图形为一个人碎片和1129个论坛碎片（编号是从他们的演示视频），然后分别使用相同的算法和参数生成每个论坛碎片里面的数据。由于图形大小与论坛分片的数量呈线性关系，因此他们很容易将数据大小扩展到 100TB。
下面，我分解了他们的数据生成方法，并展示了随着数据规模的增加，演示查询具有可预测的结果。
如图 1 所示，LDBC-SNB 模式分为两个主要部分——1 Person 分片和 1000+ 论坛分片。Person 分片包含 3B 个具有连续 ID 的人。每个论坛分片包含对个人分片的所有个人 ID 引用（无属性）。
图 2 显示了如何生成连接两个人的边缘 KNOWS。每个人 K 最多直接认识 20 个人。并且这20个人的ID是连续的并且与K相邻。因此，个人K最多认识40个人（朋友和朋友的朋友）。这种方法产生了可预测的数据复杂度：朋友的朋友数量上限为 40。人物节点的朋友在连续的 ID 范围内，从而导致更好的局部性。这导致演示中更好的缓存（因此更好的性能）。相比之下，LDBC-SNB 官方数据生成器模拟的好友数量遵循 Facebook 社交网络研究中描述的幂律分布，在比例因子 1（1GB 数据）下平均会生成 36 个好友和 2845 个好友的好友）。我做了一个实验，在BI数据集上使用LDBC-SNB官方数据生成器进一步验证，并统计了每个人的平均KNOWS边缘数。对于 SF-1，每个人平均有 24.45 个 KNOWS 边；SF-100, 60.91 KNOWS 边缘；和 SF-10K，137.40 KNOWS 边缘。因此，平均 KNOWS 边缘大致增加 log10(m)，其中 m 是比例因子。见下表。
图 3 描述了一个论坛分片的数据生成。每个论坛分片正好包含 10,000 个论坛。每个论坛包含100~800个帖子，平均每个论坛450个帖子。帖子的创建者是从个人分片中随机选择的。每个帖子有0~80条评论，相当于每个帖子平均有40条评论。40条评论的创建者是从个人分片中随机抽取的连续40个人。每个帖子的时间戳是当前时间减去随机 0~100 天，每个评论的时间戳是当前时间减去随机 0~10 天。所有的随机数都是由均匀分布生成的。
Neo4j 的数据生成器重复相同的算法来生成 1000 多个论坛分片。因此，论坛分片几乎完全相同且独立，这是不现实的。该人工图中不包含数据倾斜和实体之间的真正相关性。
相比之下，LDBC-SNB的官方数据生成器是将数据分块生成，完全不考虑分片，更现实一些。
术语具有误导性
Neo4j 的演示误用了“全局查询”的术语。
Neo4j CEO 声称“演示查询是一个深度、复杂的图形全局查询，旨在折磨数据库”， 这是错误的。
数据库基准测试中的“全局查询”是指涉及大部分图形的查询类别（请参阅此处的LDBC-SNB BI 查询中的解释）。基于这个普遍接受的含义，让我们计算演示查询的触摸图元素的数量。
演示查询 IC9 用英文描述为：
“给定一个起始人，找到该人的朋友或朋友的朋友（不包括起始人）创建的（最近的）消息。只考虑在给定 maxDate 之前创建的消息（不包括那一天）。”
让我们看看 Neo4j 如何运行 IC9 演示。
该演示使用以下固定参数（摘自此处）进行 IC9 查询：
description:"LDBCReadInteractive/complex/9",params:{Date0:newneo4j.types.Date(2022,1,14),Person:neo4j.int(1346680336),}不包含更新查询，并且重复执行相同的查询。最初的 IC 查询工作负载设计为事务性的，其中包含更新（插入）查询。无需在演示中加入更新并修复输入参数，Neo4j 就可以使用缓存结果，通过重复执行降低平均运行时间。此外，他们使用连续边生成方法，这样给定一个人的朋友和朋友的朋友是连续的，这是缓存友好的。仔细观察演示会发现在前几次执行后查询速度加快。
对于固定的人，查询最多会找到该人的 40 个朋友和朋友的朋友（查询的第 2 行 -7 行）。然后，结构驱动程序会将 40 个人和截止日期“2022/1/14”发送到所有论坛分片（查询的第 10 行 -15 行）。请注意，截止日期是无用的，因为由于 Neo4j 生成时间戳的方式，所有帖子和评论都将被限定。现在，让我们计算一下这个查询可以在一个论坛分片中接触多少条消息。
给定一个人，他们成为帖子评论的任何创建者的概率是多少？该人将有 40/3B 的机会。这是基于评论的创建者是如何生成的。从图 3 中，评论的创建者是通过随机选择 40 个连续的人生成的。由于人 K 包含在分别从 K-40、K-39 等开始的 40 个大小为 40 的连续人段中。任何随机选择的片段都会使人 K 成为帖子评论组的创建者。
由于论坛分片中有 4,500,000 个帖子，平均而言，给定一个人，他们将成为论坛分片的 4,500,000*(40/3B) = 0.06 条评论的创建者。给定 40 个连续的人（朋友和朋友的朋友），他们可以成为论坛分片中至少 40*0.06=2.4 条评论的创建者。
由于演示中有 1129 个论坛分片，因此，固定输入人员的 IC 9 查询将平均触及 2.4*1129=2709.6 条消息。接触的图元素将是 O(2.4*count_of_shards)，远小于总图元素（顶点和边）。Neo4j 声称演示查询是一个全局查询，因为该查询涉及所有论坛分片。但是，他们的查询涉及每个分片少于 10 个图形元素。因此，它不能称为“旨在折磨数据库的查询”。
事实上，上面的查询来自 LDBC SNB 基准测试中的 Interactive Complex (IC) 工作负载。此类别中的查询仅访问给定节点的邻域。因此，这些查询是本地的，粗略地用运行时 O(log n) 来表征，其中 n 是图元素的数量。例如，在TuGraph的审计结果中，当数据生成器的比例因子从 30 增加到 300 时，吞吐量仅下降了约 10%（从 5436 ops/sec 到 4855 ops/sec）。如果是全局查询，一个预计随着数据大小增加 10 倍，他/她将看到吞吐量减少 10 倍。
此外，使用 LDBC-SNB 基准数据生成器，由于社交网络内部的相关性，IC 9 选择的人员和消息的数量可能会聚集在某些论坛上。Neo4j 数据生成器将接触到的消息均匀地分布在论坛分片中，由此产生的运行时查询模式是不切实际的。
演示查询是从 LDBC-SNB IC 工作负载中挑选出来的
该演示仅使用了 2 个查询（IC9和最近的帖子）。原始 IC 套件有 14 个查询（请参阅此处的第 33 页）。该演示不能解释为 Neo4j 性能的整体视图。基准查询被设计为一个完整的套件，涵盖不同的阻塞点。Cherry-picking 查询会产生一种错觉，违背了基准设计的目的。
例如，下面的 BI 11 查询取自 LDBC-SNB 最新版本，它计算给定国家/地区中所有不同的 Person-triangle。如果在 Neo4j Fabric 数据库上执行此查询，则查询将仅使用 person shard CPU 和内存，1000+ 论坛 shard 上的资源将处于空闲状态。
事实上，这个查询很昂贵，结果的大小是 O(n^1.5) 复杂度，其中 n 是本例中的人数。如果将 Person 节点分配到不同的分片，并使用集群上所有可用的计算能力运行 join 算法，则性能将比将所有人放在一台机器上（分片）要快得多（由于更多的计算资源）。Cherry-picking 基准查询将使观众不会在 Neo4j 的演示设置中看到这个问题。数据库理论的最新进展可以通过“Worst-case Optimal Join Algorithms”在最坏情况数据复杂度方面最优地解决这个问题。
结论
Neo4j 最近的 100TB 演示并不是对 LDBC-SNB 基准的合理使用。数据高度人工化且不真实，查询是从基准中挑选出来的，演示滥用术语“全局查询”来制造营销错觉。
相比之下，自 2019 年以来，TigerGraph 采用了严格的基准测试方法，以在 TB 规模上实施 LDBC-SNB 基准测试。我们所有的基准测试都采用以下原则：
严格使用 LDBC-SNB 模式和数据生成器来生成原始数据。
在 LDBC-SNB 基准测试中实现所有查询：不挑剔。
在 SF-1 和 SF-100 上与其他商业数据库系统交叉验证了所有结果。在我们以 TB 规模进行基准测试之前，确保所有查询及其结果都是正确的。
通过这样做，我们希望让我们的客户360度全方位地了解我们的产品，并在整个图数据库行业中以身作则，展示权威图数据库基准的公平使用。我们邀请所有图数据库供应商对基准进行公平使用，以便在健康和客观的环境中培养图数据库的采用。
激烈的辩论是坦诚交流的基础。我邀请所有数据库从业者与 TigerGraph 团队就客观基准的优点进行对话。我还邀请所有读者阅读图数据库购买者指南，以评估领先的图数据库，包括 Neo4j、Amazon Neptune、DataStax 和 TigerGraph。