在过去的几周中，我们一直是benchmarking memgraph 2.4 和 neo4j 5.1社区版。具有相似功能的图形数据库，但在架构上是完全不同的系统。最有区别的是，neo4j是基于JVM的，而Memgraph是用本机C ++编写的。
为了了解两个数据库的性能限制，我们以不同的组合执行了各种并发的Cypher查询。

如果您喜欢TL; DR，则是：Memgraph大约是比Neo4J快的 大约120倍，同时消耗了四分之一的内存并提供快照隔离，而不是Neo4J的默认值读取。

基准测试为subtle，必须仔细执行。因此，如果您对它的坚果和螺栓感兴趣，请参见完整的benchmark results或直接潜入methodology或继续阅读Memgraph和Neo4J之间的结果摘要。

基准概述

在早期阶段，开发了MGBench来测试和维持Memgraph性能。更改Memgraph的代码后，在CI/CD基础架构上进行性能测试，以确保不降解。由于我们已经建立了完整的测试基础架构，因此我们认为在各种图形数据库上进行性能测试将很有趣。由于其兼容性，Neo4J首先在集成列表中。

基准很难创建和经常有偏见，因此，在更深入研究结果之前，最好了解基准的主要目标和技术细节。基准的主要目的是测量任何数据库的性能，即不需要微调数据库。配置数据库可以引入偏差，我们想进行公平的比较。

运行基准测试，支持螺栓协议所需的测试系统和Cypher查询语言。因此，两个数据库都使用低离心的C ++客户端在螺栓协议上查询，从而稳定并最小化了测量开销。共享的Cypher查询语言可以在两个数据库上执行相同的查询，但是随着MGBENCE的发展和更多的供应商，将添加到基准标准中，此要求将被修改。

可以通过执行三个不同的工作负载来运行性能和内存测试：

• 隔离 - 单一查询的并发执行。
• 混合 - 同时执行单一类型的查询与指定查询组的一定比例的查询混合在一起。
• 现实 - 通过写，阅读，更新和分析组并同时执行查询。

在我们的测试中，所有基准工作负载均在中端HP DL360 G6服务器上执行，并带有2 x Intel Xeon X5650 6C12T @ 2.67GHz和1333 MHz DDR3的144 GB，运行Debian 4.19。

每个工作负载均使用12个并发客户端查询数据库执行。所有结果都是在冷和热跑中获得的。执行热门运行时，数据库在执行任何基准查询并进行测量之前进行了预测。

要获得基准技术细节的完整范围，请查看我们的methodology。它包含诸如执行的查询，基准的限制和未来计划之类的细节。您还可以找到独立验证结果的复制步骤。

结果

整个基准测试执行23个代表性工作负载，每个工作负载由写，读，更新，汇总或分析查询组成。编写，读取，更新和汇总查询非常简单，并且处理节点和边缘属性，而分析查询更为复杂。

密钥值mgbench度量为延迟，吞吐量和内存。在确定要用于特定用例的数据库时，这些测量中的每一个都至关重要。下面显示的结果是通过在冷运行时在一个小数据集上执行查询来获得的。

潜伏

延迟易于测量，因此几乎每个基准都包含在每个基准中。这是一个基本性能指标，代表查询需要多长时间执行以毫秒。查询复杂性提出了查询延迟绝对值的重要因素。因此，执行复杂的分析查询将需要更多的时间，而延迟将更高，而更直接的查询将更快地执行，从而具有较低的延迟。

由于查询缓存，相同查询的延迟可能会有所不同。预计第一次运行相同的查询将导致比第二运行更高的延迟。由于可变延迟，有必要多次执行查询以更好地近似其延迟。我们特别关注第99个百分位数，代表了所有测量值的延迟测量值比延迟测量快。这听起来好像我们正在专注于异常值，但实际上，it is vital to understand the “tail latency” for any system that you will build reliable systems on top of。

任何图形分析工作负载中最有趣的查询之一是扩展或k-hop查询。扩展查询从目标节点开始，然后返回所有已定义的啤酒花数量的连接节点。根据数据集的不同，扩展远离目标的啤酒花可能会导致查询触摸数据集中的大多数节点。扩展查询是数据密集型，并对数据库构成挑战。在MGBENCH中，有1到4的啤酒花的扩展查询。可能最常用的扩展查询是一个单个跳跃的查询。这是一个分析性查询，执行和使用很多相当便宜：

MATCH (s:User {id: $id})-->(n:User) RETURN n.id

如上图所示，执行扩展1查询需要MEMGRAPH 1.09毫秒，而Neo4J则需要27.96毫秒。在此特定查询中， memgraph的速度更快25倍。但这只是一个查询中的一个示例。为了完整地了解延迟性能，以下是在23个不同查询中测量的延迟。

您可以看到，与23个查询中的每一个相比，Memgraph延迟比Neo4J降低了多次。 “方法论”部分可以提供完整的query list。在MEMGRAPH中，延迟范围从1.07毫秒到Q11，扩展4查询，这是MGBench中最具挑战性的范围。 NEO4J的范围从13.73毫秒到3.1秒。较低的查询延迟全部带来了一个很好的开始，但这并不是数据库之间的性能差异的完整图片。

延迟只是最终结果，可以取决于各种事情，例如查询复杂性，数据库工作负载，查询缓存，数据集，查询等。更好地模仿生产环境。

吞吐量

吞吐量表示您可以执行多少查询，每个固定时间范围，以每秒查询（QPS）表示。为了测量隔离工作负载上的吞吐量，23个查询中的每个查询都隔离执行，并同时执行固定的次数，并除以总执行持续时间。执行的查询数取决于查询延迟。如果延迟较低，则执行更多查询。如果延迟很高，则执行较少的查询。在这种情况下，执行查询的数量等于10秒的单线程工作负载的近似值。

更多的吞吐量意味着数据库可以处理更多的工作负载。让我们看一下前面提到的扩展1查询的结果：

memgraph的同时吞吐量在扩展1时每秒的查询为32,028个查询，而neo4j可以处理每秒280个查询，这意味着 memgraph在此查询上比neo4j 快114倍。但同样，这仅是一个查询的吞吐量。让我们看一下孤立的工作量中的所有23个查询：

您可以在上面的条形图上看到，Memgraph在23个查询中的每个查询中的吞吐量都明显更高。由于对于某些查询，吞吐量的差异很大，因此最好专注于每个查询的绝对数字。 Memgraph的最坏情况和NEO4J的最佳情况是Q4，其中 memgraph的速度比Neo4J 快5.1倍。

数据库延迟和吞吐量可能会受到结果缓存的显着影响。连续几次执行相同的查询可以产生浅表延迟和吞吐量。在生产环境中，数据库不断执行写和读取查询。写入数据库可以触发缓存的无效。写作可以成为数据库的瓶颈，并使延迟和吞吐量恶化。

在写入数据库时​​测量吞吐量将产生更准确的结果，以反映混合工作负载时反映现实的缓存行为。为了模拟该方案，混合工作负载执行了固定数量的查询，这些查询与一定百分比的写入查询同时读取，更新，汇总或分析数据。

现在执行之前执行的扩展1查询与30％的写查询混合在一起：

您可以看到，Memgraph在混合工作量中保持了其性能，并且吞吐量高132倍执行混合工作量的工作量比Neo4J。这是混合工作量的完整吞吐量结果：

总混合工作量没有影响整体备忘录的表现，它在21个查询中的每个查询中仍表现出色。未测试用于创建混合工作负载的两个写入查询，因为它不会混合工作量。

孤立的工作负载和混合工作负载都瞥见了数据库可能的生产性能，而先前的测量结果都可能存在局限性。 现实的工作负载是数据库性能最具挑战性的测试。生产中的大多数数据库都执行了各种复杂性，顺序和类型不同的查询。现实的工作负载包括在数据库上同时进行写作，阅读，更新和进行分析工作。工作量由每个操作的百分比定义。每个工作负载均为每个供应商生成非随机性，并且在每个运行中都是相同的。
目前，有4个现实的工作负载分布：

• W1- 20％的分析，40％阅读，10％更新和30％的写作
• W2-70％阅读和30％写作
• W3- 50％阅读和50％写作
• W4- 30％阅读和70％的写作

查看每个工作负载的吞吐量结果：

memgraph在混合工作负载上表现良好，W1上的吞吐量高102倍，W2上高122倍，W3高125倍，W4上高121倍。总体而言，MEMGRAPH大约比Neo4J快<强> 。

内存使用情况

数据库的性能是定义哪个数据库适合哪些用例的众多因素之一。但是，内存使用是真正可以选择数据库的因素之一，因为它会显着影响成本对性比率。 MGBENCH中的内存使用量计算为每个查询或工作负载执行的 peak res （居民大小）内存。结果包括启动数据库，执行查询或工作量以及停止数据库。在停止过程之前，从过程PID中提取峰值RES作为VMHVM（峰值居民套件大小）提取。峰值内存使用定义了给定查询或工作量的最坏情况，而RAM足迹平均较低。
由于MEMGRAPH是一个内存图数据库，因此必须将一些成本附加到该性能上。好吧，这是事情变得有趣的地方。查看现实工作负载的内存使用情况：

您可以看到， memgraph使用了大约四分之一的neo4j内存。由于NEO4J是基于JVM的，因此它为JVM开销支付了价格。

一致性

虽然超出了本博客文章的范围，以涵盖the implications of database isolation levels以及较弱的隔离级别如何阻止广泛的应用程序正确地在其顶部正确构建，但高级的情况是Memgraph支持Snapshot apthot selimation，盒子，默认情况下，Neo4J提供了更弱的读取隔离级别。 NEO4J确实支持可选的手动锁定，但这并不能默认保护所有查询。通常，对于大多数工程师来说，通过要求他们在应用程序负责构建和操作的应用程序上实施自己的数据库锁定协议来推理交易并发控制的微妙之处。

实际上，这意味着可以正确实施更广泛的应用程序，而无需工程师了解高度微妙的并发控制语义。现代数据库生态系统包括许多系统的示例，这些系统的性能非常出色，而不会放弃更强的隔离水平的正确性保证，而Memgraph表明，根本没有必要放弃快照隔离的好处，同时为我们的工作量实现出色的表现，我们专门研究。将来我们打算推动我们的正确性保证。

结论

正如基准测试所示，Memgraph的同时工作负载比NEO4J 更快地执行的幅度，这对于运行任何实时分析至关重要。