IOGP: An Incremental Online Graph Partitioning Algorithm for Distributed Graph Databases（2017）

IOGP: An Incremental Online Graph Partitioning Algorithm for Distributed Graph Databases

IOGP：一种分布式图数据库增量在线图分区算法

研究对象：考虑在线事务处理 (OLTP) 工作负载，生成平衡的分区，增加访问图的高度顶点的并行性
研究目的：目标是优化图数据库中OLTP操作的性能，例如：割边数最少 ，遍历图完成时间最短。
研究方法：混合割+增量重划分（Fennel启发式）。先是确定散列函数分配（边割），再是边达到一定规模，重划分，以及边规模达到分割阈值，点割。
平衡目标：割边最小+分区平衡
缺陷：虽然是混合割，但其平衡目标还是割边最小和分区平衡，没有实现混合割的双目标：割边最小+副本最少，因为在文中没有考虑维护副本同步的成本，由于其研究的目标应用领域，规避了这个问题。

摘要

  图在诸如查询社交网络中的关系或管理科学计算中生成的丰富元数据等许多应用和领域中变得越来越重要。许多这些用例需要高性能的分布式图数据库，以便为来自客户端的持续更新提供服务，并同时回答有关当前图的复杂查询。图数据库中的这些操作，也称为在线事务处理(OLTP)操作，对图分区算法有特定的设计和实现要求。在本研究中，我们认为在图划分过程中有必要考虑连通性和顶点度的变化。基于这一思想，我们设计了一种增量在线图划分(IOGP)算法，该算法对顶点度的增量变化做出相应的响应。IOGP有助于实现更好的局部性，生成平衡的分区，并增加访问图的高度顶点的并行性。在真实图和合成图上，与最先进的图分区算法相比，IOGP的查询性能提高了2倍，开销不到10%。

引言

  图在许多应用和领域中变得越来越重要，例如查询社交网络中的关系或管理科学计算中生成的丰富元数据[2,8,21,38]。这些图通常很大，因此很难放入一台机器中。更重要的是，即使某些图可能适合单个服务器，但它们通常会被多个客户端同时访问，需要分布式图数据库来避免性能瓶颈。例如，我们之前的工作利用属性图来统一建模和管理高性能计算（HPC）平台中生成的丰富元数据[6-8]。正如[8]中所示的示例，丰富的元数据图可能不是特别大（包含数百万个顶点和边），但仍然需要分布式图数据库来有效地服务于数千个客户端发出的高度并发的图突变和查询。事实上，针对此类任务已经出现了大量的分布式图数据库系统，例如 DEX [10]、Titan [32] 和 OrientDB [23]。
  与关系数据库类似，分布式图数据库旨在提供持续更新，同时回答来自许多客户端的任意查询。它们与另一组重要的系统不同，即图形处理引擎，如 Pregel [20]、GraphX [37] 和 X-Stream [27]，它们专注于在整个图形上快速执行单独的分析工作负载。在许多情况下，现有的研究并没有明确区分它们，因为图数据库和图处理引擎之间的界限是模糊的。例如，大多数图数据库都可以通过定义复杂的图遍历来提供图计算；许多图计算引擎支持动态图的分析查询。然而，就其设计的使用场景而言，存在显着差异。具体来说，图形数据库专为在线事务处理 (OLTP) 工作负载（例如 INSERT、UPDATE、GET 和 TRAVEL）而设计。这些操作通常由多个客户端同时发出，并预计立即完成。它们通常只对图表的一小部分进行操作。另一方面，图处理引擎是为在线分析处理（OLAP）工作负载而设计的，例如在整个图上运行 PageRank [24] 或查找社交图的社区结构 [11]。这些工作负载通常会偶尔发出一次，并在图表中进行足够的更改。它们通常对整个图进行操作，并且需要很长时间才能完成。这些差异导致了完全不同的性能要求，也从根本上影响了图分区的设计考虑。在本研究中，我们重点研究分布式图数据库的图分区算法。
  第一个区别是图分区中可接受的时间成本。由于图处理引擎在整个图上运行分析工作负载通常需要很长时间，因此它们可以花更多时间进行分区以加速后续计算。但是，图数据库的情况并非如此，因为每个事务通常都很短。他们必须快速完成并立即生效。分布式图数据库的图划分算法必须迅速做出每个事务的在线决策，而图处理引擎的图划分算法则不需要。
  第二个区别是划分图所需的知识。在大多数图处理引擎中，当分区开始时，图的大部分内容已经是已知的。事实上，许多图划分算法严重依赖这些知识（例如，顶点度及其连通性）来提供优化的划分。最著名的例子包括 METIS [16] 和 Chaco [14]。尽管最近的一些研究（例如，LDG [22, 30]，Fennel [33]）可以在不知道整个图的情况下进行分区，但一些局部图信息仍然是必要的。例如，当插入一个顶点时，当时它的大部分连接边应该是已知的。然而，在分布式图数据库中，顶点及其连接的边通常是从多个客户端独立并发地插入的。当分区发生时，通常全局图结构和局部图结构都是未知的。图划分算法应该能够在图知识有限的情况下工作，在这种情况下，现有的划分算法可能根本不适用或无效。
  第三个区别是划分质量的衡量。图处理引擎主要在整个图上运行分析任务，因此它们针对最佳整体吞吐量进行了优化。大多数现有的图划分算法都是为这样的目标而设计的，可以将其表述为 k 路划分问题：1）尽量减少跨分区的“边割”，以降低通信成本； 2）最大化分区的“平​​衡”以避免潜在的落后者。然而，这些指标并不一定能为分布式图数据库生成良好的分区。例如，如果一个图由 k 个大小相等的不连通子图组成，那么其最佳的 k 分区应该是将每个子图放置在一个服务器上，以实现最小化的“切割”和最佳的“平衡”。然而，从图数据库的角度来看，如果这些子图中的任何一个包含高度顶点，则由于单机的吞吐量瓶颈，从这些顶点开始的图遍历将明显变慢。图分区算法应考虑单个 OLTP 操作的指标，而不是整体吞吐量。
  在本文中，我们介绍了一种新的图分区解决方案，即增量在线图分区（IOGP），专为分布式图数据库设计。它在为单独的 OLTP 操作提供服务的同时，立即做出针对每个事务的在线分区决策。它根据对图的了解不断增加，分多个阶段增量调整分区。这种方法在处理图变更和图遍历等 OLTP 工作负载时实现了优化的性能，相比现有最先进的做法。本文的贡献有三个方面：

• 提出第一个（据我们所知）分布式图数据库增量（多阶段）在线图分区算法。
• 设计并实现所提出的算法，以有限的资源立即合并新的顶点和边。
• 对来自不同领域的多个图数据集所提出的划分算法进行广泛的评估。
    请注意，尽管许多图处理系统倾向于将大型图容纳到单个服务器中，以避免通过划分图而引入的网络通信（例如，G-store 将万亿边图压缩为 2 TB 并使用一台服务器进行处理） [18]），图大小并不是划分图和部署分布式图数据库的唯一根本原因。在许多情况下，从多个/许多客户端发出的高度并发的工作负载需要分布式图数据库来为应用程序提供高质量的服务，即使存储的图不是那么大。

相关工作

  众所周知，图划分问题是NP-hard问题[13]。事实上，即使是最简单的二分划分问题也是 NP 困难的[12]。因此，当前广泛使用的算法都是启发式方法。其中，一个重要的类别称为多级方案。例子包括 METIS [16]、Chaco [14]、PMRSB [1] 和 Scotch [25]。他们首先将图粗化，并将其大致切割成小块，然后改进划分，最后将这些小块投影回更精细的图。这些算法可以并行化以提高性能，例如ParMetis[17]和Pt-Scotch[4]。虽然该方案中的算法能够有效地处理大型图，但它不是为动态图设计的，因为动态图的顶点和边是不断变化的。要将多级方案应用于动态图，通常需要在一批更改后重新分区图[28]。然而，这种重新分区是重量级的（在大型图中很容易花费数小时[31]），并且倾向于处理一批更改而不是图数据库上的事务工作负载。相反，在本文中，我们关注的是轻量级在线分区，它在更改流进入数据库时进行分区。
  近年来，人们提出了几种轻量级算法。它们在对数据执行单遍迭代时对图进行分区。它们通常使用一些启发式方法来决定在哪里分配当前顶点(及其所有连接的边)，利用关于顶点的局部图结构。典型的例子包括线性确定性贪婪(LDG)[30]和Fennel[33]。然而，正如我们在前一节中所描述的，在图数据库的情况下，即使是这样的本地信息在执行分区时也可能不可用。这种策略的另一个主要缺点是每个顶点只分配一次，即使它以后可能会得到新的边。这些新的更改可能会破坏以前的分区。尽管一些扩展[22,34]可以在几次传递或迭代中划分图，但它们在图数据库用例中仍然受到影响，其中顶点和边是连续且独立插入的。
  最近的一些工作已经介绍了大规模动态图的在线划分算法，这与本研究中提出的IOGP算法有关。Vaquero等[35]在处理工作负载运行时对动态图进行分区。它通过在类似pregel的图批计算框架的每个超级步骤中迁移所有顶点来连续更新现有分区。这为处理图形更改带来了巨大的成本和长时间的延迟，这对于批处理是可以接受的，但不适合我们的情况。Leopard[15]为大规模、不断变化的图提供了分区算法和紧密集成的复制算法。它借鉴了Fennel等单通道流方法的技术，并通过精心设计的复制策略对其进行了改进。Leopard的限制是，它是专门为只读图形计算设计的，以利用复制机制。因此，不仅图数据库工作负载不适合它，而且许多图分析任务也不支持它，比如寻找单个源最短路径的分析。与那些算法相比，IOGP 的设计旨在在 OLTP 工作负载（如访问给定顶点或从中遍历的工作负载）上实现更好的性能。

建模和分析

图数据库模型

  在本研究中，我们将分布式图数据库描述为以下特征:1)支持有向图;2)支持双向遍历，即一个顶点既可以访问其传入边，也可以访问其传出边;3)支持具有可查询属性的顶点和边。事实上，这些特征在现有的分布式图数据库中很常见。
  图1显示了分布式图数据库的典型架构。在这种体系结构中，每个物理服务器在其本地存储引擎中存储整个图的一部分或分区。服务器可以通过高速网络相互通信，客户端与驱动程序库链接以与服务器通信。由于每个顶点都需要访问其传入边和传出边以实现双向遍历，因此存储引擎将保留两个边列表，如图1所示。每个服务器都包含一个OLTP执行引擎，用于处理来自客户机的请求。客户机和服务器中的图分区组件协作交付分区。基于这个通用模型，我们将分析OLTP操作性能的关键因素，这将导致下一节中描述的IOGP的设计和实现。

单点访问性能

  图数据库中的单点OLTP操作通常包括INSERT、UPDATE和GET。它们的性能很大程度上取决于客户端是否知道顶点或边的位置:知道了准确的位置，客户端可以直接向服务器发送请求，从而节省了查询位置的额外成本。在许多情况下，这可以将延迟减少一半，并使吞吐量增加一倍。为了实现这种“一跳”机制，客户机和服务器需要共享关于当前分区的相同知识。一个被广泛采用的解决方案是使用确定性哈希函数，可以很容易地共享，来划分图。许多现有的分布式图形数据库(如OrientDB和Titan)都在使用这种策略。虽然它的缺点很明显:确定性哈希不学习顶点连接的亲和性，导致局域性差，但它的单跳优势仍然值得考虑，以获得更好的OLTP单点访问性能。在本研究中，提出的IOGP算法通过保持客户端和服务器对大多数图的位置达成一致来最大化一跳访问的机会。

图遍历的性能

  有效地支持图遍历是图数据库的一个独特特性，也是图数据库与其他存储系统(如关系数据库或键值存储[36])之间的关键区别。图2(a)显示了一个示例图和从顶点u开始的遍历。一次遍历通常由多个步骤组成，每个步骤都包含对顶点及其并行邻居的访问，就像步骤S1中对v,w的访问一样。

  图分区是将图的顶点和边放入不同的部分，存储在不同的服务器上。如图2(b)所示，图的划分一般有两种方式，即边切和点切。切边倾向于把源顶点和它连接的边放在一起。由于目标顶点可能被放置在不同的服务器上，它们的中间边看起来就像被切割了一样。例如，u和它的邻居是这样放置的，e0被切割在两个分区之间。另一方面，顶点切割倾向于将源顶点及其边缘分开放置，因此顶点看起来就像被切割了一样。例如，如图所示，v被分割成两个分区，因为它的边e1和e2是分开存储的。
  事实上，不管是边切还是点切，只要两个相连的顶点没有存储在一起，就会引入一个“切”。对于遍历，这样的“切断”仅仅意味着服务器之间额外的网络通信。因此，所有的图划分算法都力求最小化这些切割，以实现顶点之间更好的局部化。在本研究中，该算法利用启发式方法动态调整顶点位置，增强了顶点之间的局部性。
  此外，即使在相同的位置，点割和边割也会导致不同的性能。例如，如果一个顶点u有超过一百万条连接的边，这在现实世界的幂律图中是很有可能的，那么切边就会把所有的边和u存储在一起。这将导致在访问u时加载边的时间很长。相比之下，点割可以将这些边缘分配到多个服务器中，以分摊工作负载并提供更好的性能。另一方面，如果一个顶点u有少量的边，将它们分割到多个服务器会引入额外的网络通信，从而降低并行性的好处。在这种情况下，由于幂律图中的大多数顶点都有少量的边，因此切边显然是更好的选择。在本研究中，提出的IOGP算法在划分时考虑了顶点的度，并选择了更好的划分图的方法。

算法概述

  IOGP的目标是优化图数据库中OLTP操作的性能。前几节中的性能分析对其设计和实现进行了启发和合理化。具体来说，IOGP首先利用确定性散列来快速放置新顶点。默认情况下，该策略允许对大多数图顶点进行一跳访问。当插入更多顶点的边时，IOGP将调整顶点的位置，以利用关于顶点连接的不断增加的知识来实现更好的局域性。在此步骤之前，图仍然按照边切分区进行分区。然而，一旦一个顶点有太多的边，IOGP将应用顶点切割来增加并行度，进一步提高遍历性能。通过这种方式，IOGP能够在服务连续OLTP操作的同时生成高质量的分区。我们将IOGP分为三个阶段，分别是直接分配阶段、顶点重分配阶段和点割阶段，并在下面进行详细介绍。

直接分配阶段

  IOGP默认运行在直接分配阶段。在这个阶段，它使用确定性散列函数将一个新顶点放置到服务器中。所有客户端和服务器共享相同的功能，以确保一次访问。在边切割之后，IOGP将新边与它们的关联顶点放置在一起。注意，边u→v将同时存储在u的出边列表和v的入边列表中，以实现双向图遍历。
  确定性哈希的问题在于它不考虑顶点的局部亲和性。当一个顶点没有很多边时，这个问题并不严重，但是随着顶点的增长，这个问题就会出现。IOGP 在了解更多有关顶点连接性之后，解决了顶点重新分配阶段的问题。另外，如果顶点的边太多，边切割可能会产生热点，IOGP在点割阶段采用顶点切割来解决这个问题。

顶点重分配阶段

  在直接分配阶段，顶点没有足够的连接信息，因此随机散列是一个很好的选择。但是，随着插入的边越来越多，获得的连通性信息也越来越多。我们希望利用这些知识将顶点重新分配给更好的分区。目标很简单:将一个顶点移动到存储其大部分邻居的分区，同时保持所有分区的平衡，以避免出现滞后。
  为了确定哪个分区是最佳选择，IOGP 利用 Fennel 启发式评分 [33]，如公式 1 所示。这里，Pi 指的是第 i 个分区中的顶点，v 指的是要分配的顶点，N(v) 指的是 v 的邻居集合。 α 和 γ 是可调参数。

max ⁡ { ∣ N ( v ) ∩ P i ∣ − α γ 2 ( ∣ P i ∣ ) γ − 1 } \max \{ |N(v) \cap Pi| - \alpha \frac{\gamma }{2}{(|Pi|)^{\gamma - 1}}\} max{∣N(v)∩Pi∣−α2γ​(∣Pi∣)γ−1}

此启发式将顶点 v 作为输入并计算每个分区的分数。然后，IOGP 将 v 放置在得分最高的分区中。|N(v) ∩ Pi |是分区 Pi 中 v 的邻居数量。随着分区中邻居数量的增加，分区的分数也会增加。为了确保平衡分区，启发式包含基于分区 (|Pi |) 中顶点和边的数量的惩罚。随着数量的增加，分数会降低。
  在 Fennel 中，这样的启发式分数是通过扫描每个分区中顶点的所有邻居来简单计算的。时间成本是可以接受的，因为 Fennel 不是为服务 OLTP 操作而设计的。然而，在我们关注的案例中，这样的计算会消耗太多时间。为了解决这个问题，在本研究中，我们提出了一种新的策略，通过连续维护边计数器来计算它。更多细节将在第 5 节中介绍。

点割阶段

  在幂律图中，顶点的度数可能非常大。正如我们所讨论的，边割可能会导致性能显着下降。在 IOGP 中，我们引入了点割阶段来处理它。具体来说，我们建议将高度顶点的边分割到多个服务器中以分摊负载。在通用图数据库模型中，每个顶点都包含传入边和传出边。我们将它们放在一起考虑，因为遍历可能会在两个方向上发生。
  IOGP 定义了一个阈值 MAX EDGES 来决定何时分割顶点。如果顶点度数超过此数字，IOGP 将切割并分割其所有边。分割非常简单：IOGP 将传出边与其目标顶点放置在一起，并将传入边与其源顶点放置在一起。图 3 显示了使用三个存储服务器进行拆分的示例。在此示例中，需要分割 u 的边以卸载其负载。最初，所有边(从1到6)与u一起存储在服务器1上。分割后，它们根据目标顶点的位置分配到所有三个服务器上。请注意，顶点 u 没有移动。服务器2和3上的只是Id索引（图中阴影图案所示）。

  在此阶段，局部性不会改变，因为边被移动到其源顶点或目标顶点，而不会改变局部性。然而，这将显着提高访问高度顶点的性能，因为这些操作可以跨多个服务器并行执行。此外，可以将对该顶点的并发边变更分配到多个服务器上，以获得更好的性能。

算法设计与实现

  上一节我们简单描述了IOGP的三个阶段。然而，它在分布式图数据库中的实现并不简单。仍然存在许多实施挑战和各种设计权衡。在本节中，我们将介绍更多设计和实现细节。

IOGP数据结构

  IOGP引入了一系列数据结构来实现高效的在线图划分。这些数据结构主要是计数器，记录了每个分区中顶点的状态。它们存储在内存中以便快速访问。如果出现故障，可以通过对现有数据库的完整扫描来重建它们。

• 在当前存储顶点 v 的服务器上，有一个split(v)，指示其边是否被分割。
• 在原来或当前分别存储顶点 v 的两台服务器上，都有一个 loc(v) 记录其准确位置。它仅在 IOGP
  重新分配顶点时存在，充当图数据库的位置服务。
• 每个顶点v最多有四个边缘计数器来增量地维护其连接信息。这些计数器可以存储在多个服务器上。

1. alo(v)/ali(v) 存储 v 的实际本地出/入边的数量。它们计算出/入边，其目标/源顶点也存储在本地服务器中，即本地邻居。它们只存在于实际存储 v 的服务器中。
2. plo(v)/pli(v) 存储了顶点 v 的潜在本地出边数目和入边数目。这两个计数器存在于不存储 v 的服务器中。这两个计数器存在于不存储 v 的服务器上。如果 v 已被移回本地服务器，则它们计算 v 的本地邻居数。

• 每个服务器还维护一个尺寸计数器，指示其顶点和边的数量。
    总的来说，这些数据结构都很小。每台服务器只有一个尺寸计数器。对于每个顶点 v，split(v) 和 loc(v) 仅存在于一台或两台服务器上，因此也具有良好的扩展性。但是，边计数器可能存在于所有服务器上：一台服务器存储 alo、ali，所有其他服务器存储 plo、pli。如果每个计数器占用 2 个字节，则每个服务器上的每个顶点总共占用 4 个字节。如果整个图数据库存储超过 10 亿个顶点，这可能会导致问题，在最坏的情况下将消耗每台服务器超过 4GB 的内存。然而，实际情况比这种最坏的情况要好得多，原因有二：1）进入点割阶段的顶点不再需要边计数器，2) plo(v),pli(v) 潜在计数器仅存在于存储 v 邻居的服务器中。这些显着减少了现实世界幂律图中的内存消耗。在评估部分，我们展示了有关这些计数器的内存占用的更多详细信息。

直接分配阶段实施

  在直接分配阶段，IOGP默认使用确定性哈希函数放置顶点。请注意，为了支持双向遍历，插入像 e(u →v) 这样的边将导致两次插入：一个作为 u 的出边，另一个作为 v 的入边。
  IOGP 维护用于顶点重新分配的边计数器。最初，我们将所有计数器设置为 0。一旦插入新边 (u →v)，就会发出两次插入。在存储源顶点（su）的服务器上，成功插入该边作为u的出边后，IOGP将检查目标顶点 v 是否也存储在本地。通过检查 v 的哈希值和本地内存中 loc(v) 的存在性，可以立即完成此检查。如果是，则该边对于其源顶点和目标顶点都是局部的，因此它将 alo(u) 加 1，因为这表明实际局部性的存在。如果不是，它会增加 pli (v)，这意味着仅为 v 引入潜在局部性。需要注意的是，这个pli是针对顶点v计算的，也就是说以后只要将 v 移回这个服务器，就可以得到实际的位置。类似地，在存储目标顶点（sv）的服务器上，计数器也会相应更新。
  IOGP 在提供顶点和边插入服务时更新边计数器。实际局部边（alo，ali）和潜在局部边（plo，pli）用于顶点重新分配阶段，以计算顶点效率的最佳划分。

顶点重新分配阶段实现

  在顶点重新分配阶段，IOGP尝试将顶点重新分配给不同的服务器以增强局部性。重新分配顶点的首要任务是计算最佳分区。根据4.2节的描述，IOGP利用边计数器来有效地计算最佳位置，而不是扫描数据库来获取 |N(v)∩Pi |。

  图 4 显示了一个具有 5 个顶点和边的示例图，该图被划分为三个服务器。我们还展示了他们的边计数器。这里，带有彩色图案的实心圆圈表示该服务器中实际存在的顶点；虚线圆圈表示顶点不存在，仅存在边。如图所示，每条边实际上被存储两次。例如，e(u → x)作为u的出边存储在server1中，同时作为x的入边存储在server2中。
  在这个例子中，只有边 e(u →v) 表示实际位置，这意味着我们在 server1 上有 alo(u) = 1 和 ali (v) = 1。其他三个边仅表示潜在的位置。相关边计数器如图4所示。这些值在直接分配阶段得到有效维护。
  当 IOGP 重新分配一个顶点（例如 u）时，它将比较将 u 移动到另一台服务器是否会增加或减少根据公式 1 计算出的分数。具体来说，将 u 移出 s1 肯定会减少服务器 s1 上的局部性数量 2*(alo(u)s1 + ali (u)s1 )。我们将它加倍，因为局部性的减少来自顶点u及其本地连接的顶点。同时，将 u 移至另一个服务器 sj 会将其局部性增加 2 ∗ (plo(u)sj + pli (u)sj )。还应计算每台服务器上的分区大小。IOGP将选择从以下等式中获得最大正值的分区si：

  该方程是通过选择参数 α = 1 和 γ = 2 从方程 1 导出的。这些参数在现有研究中也被广泛使用[15]。如果我们以图 4 为例，顶点 u 将被重新分配给 s2，因为它的 ra 分数为 1。

维护IOGP数据结构

  算法 1 显示了 IOGP 如何在重新分配顶点时维护内存中的数据结构。当顶点 u 移动时，原始服务器中的 loc(u) 将更新到新位置。任何进一步的重新分配也会更新原始服务器中的 loc(u)。这充当图形数据库的分布式位置服务。新的客户端需要请求存储 u 的原始服务器通过查询 loc(u) 来检索其当前位置。客户端可以缓存该位置以供将来请求。此外，参与此重新分配的服务器将相应地更新其大小计数器。
  在更新边计数器方面，首先更新顶点u的计数器：1）在原服务器su中，u的实际地点将变成潜在地点；2）在目标服务器sk上，u的潜在位置将变成实际位置。除了更新u之外，更重要的是更新与u相连的顶点。它们的实际局部性会因为顶点 u 移出或移入而改变。例如，在原始服务器（su）中，对于所有u的传入边，如果它们的源顶点（src）也存储在本地服务器中，我们需要将它们的实际传出局部性（alo（src））减少1，因为它们的目的顶点 u 不再位于本地服务器中。这对于传出边也是必需的。目标服务器 sk 执行类似的更新，但它会增加局部性。更重要的是，每次重新分配顶点 u 时，其邻居的边计数器也需要更新。这些更新实际上很快（在内存中迭代 u 的传入和传出边）并且与实际数据移动重叠（第 5.5 节中描述）。

顶点重新分配的时序

  重新分配顶点的时机对于平衡划分质量和开销至关重要。对于所提出的在线 IOGP 算法尤其如此。我们观察到，当一个顶点有更多的边时，它的连接性变得更稳定，因此需要更少的重新分配。这个理由相当简单。例如，当一个顶点只有一条边时，一条新边可能会显着改变其局部性。但是，如果一个顶点已经有 1K 条边，很可能新边不会产生显着差异。这一观察和基本原理导致了我们在 IOGP 中的设计：1）推迟顶点重新分配，直到其连接稳定；2) 减少顶点重新分配频率，同时插入更多边。具体来说，我们考虑直到顶点包含超过 REASSIGN THRESH 连接边（传入边和传出边）为止，可以进行顶点重新分配尝试。重新分配后，只有在插入相似数量的新边后，我们才会检查另一次重新分配的可能性。假设 k=REASSIGN THRSH，我们在到达 [k, 2 * k, 4 * k, ., $2^i$ * k, …] 边时检查顶点重新分配。这显着减少了顶点的重新分配次数。例如，如果 REASSIGN THRSH=10，则对于具有 10,240 条边的顶点，最大移动次数仅为 10。REASSIGN THRSH 的选择和影响将在评估部分讨论。

点割阶段的实现

  点割阶段是IOGP针对高度顶点的关键优化。它的主要目的是分摊访问高度顶点的负载并提高扫描和遍历等操作的性能。
  如顶点重新分配阶段所述，当一个顶点被分割时，它可能已经被重新分配了多次。但是，一旦顶点进入分割阶段，它就不会再被重新分配。IOGP 将使所有边计数器失效并释放，以减少内存占用。选择这种策略有两个原因。首先，当一个顶点在集群中分割时，从统计上看，它的边将均匀分布，因为它们的邻居通过散列随机分布。因此，重新分配顶点将不再显着增加局部性。其次，移动已分割的顶点也会带来不必要的复杂性。当一个顶点被重新分配并且它的边已经被分割时，算法需要额外的注意，这可能会使边计数器失效。
  对于IOGP数据结构的更新，在点割阶段比较简单。首先，它将split(u)更新为相应的值。其次，它使顶点u的局部边计数器失效并释放出来。随着边的移动，它进一步释放了其他存储服务器中的边计数器。u 的传入和传出边的大小也将相应更新。

异步数据移动

  在启用 IOGP 的图数据库中，引入了两种额外的数据移动：顶点重新分配和点割。在处理 OLTP 请求时同步移动数据可能会导致潜在的性能问题。在 IOGP 中，我们将这些数据移动优化为异步，以避免阻塞 OLTP 操作。
  在点割过程中，一旦 IOGP 需要切割一个顶点，它会在一次事务中更新内存中的 IOGP 数据结构，并将该顶点添加到待分割队列中。一旦此事务成功完成，即使尚未移动数据，我们也开始拒绝不应存储在本地的新边。向错误服务器发出边插入的客户端将被拒绝，并显示一条通知，表明顶点已被分割。客户端根据回复同步其状态并再次请求正确的服务器。重新分配顶点的处理方式类似。确定目标服务器后，它将更新内存中的 IOGP 数据结构，然后在一个事务中将顶点添加到挂起的重新分配队列中。服务器还将停止服务有关该顶点的请求，并通知客户端将来请求目标服务器。对于这两种情况，真正的数据移动操作都是通过后台线程实现的，该线程定期从待处理队列的头中检索顶点 v 并为其处理数据移动。移动数据后，本地副本将被删除。
  这种异步数据移动机制是高效的，但是可能会给读请求带来问题，因为在数据移动发生时，所请求的顶点或边可能处于不确定状态。它们可以在原服务器上（复制尚未开始），也可以在新服务器上（复制和删除已完成），甚至可以在两台服务器上（复制完成但未删除）。为了解决这个问题，客户端需要对正在移动的元素同时发出两个读取请求：一个请求发送到原始服务器，另一个请求发送到新服务器。如果两个请求都得到结果，则来自新服务器的请求获胜。客户端可以根据新服务器的回复获知边移动是否完成，避免将来产生额外的请求。

评估

评估设置

  所有评估都是在 CloudLab APT 集群上进行的 [5]。总共有128台服务器，我们使用了32台服务器作为后端服务器。每台服务器均配备 8 核 Xeon E5-2450 处理器、16GB RAM 和 2 TB 本地硬盘。所有服务器均通过 10GbE 双端口嵌入式 NIC 连接。除非明确说明，我们在实验中使用了全部 32 个服务器。

数据集选择

  我们使用流行的 SNAP 数据集进行现实世界的图评估 [19]。SNAP 是来自各个领域的网络的集合，其中大多数是幂律图。我们展示了评估中使用的这些图表的代表性选择，并在表 1 中概述了它们的属性和比例。
  具体来说，我们选择了从不到 200K 边到近 100M 边的图来表示图数据库所服务的不断增长的图的不同阶段。尽管许多图处理框架能够在单个服务器中处理具有这些大小（即边或顶点的数量）的图，但我们确实认为分布式图数据库在实践中对于这些图仍然是必要的。正如我们之前的工作[6-8]所示，具有数百万个顶点和边的图可能会被数千个客户端同时访问，因此需要图分区和分布式图数据库解决方案。此外，属性图往往具有丰富的可查询属性。它们很容易变得足够大（例如，多个 KB），以生成具有数百万个顶点和边的图，不适合单台机器。

  在本次评估中，我们没有包含非常大的图的另一个原因是，与离线图分区算法或底层存储引擎不同，IOGP等在线算法对图的大小不敏感。相反，他们更专注于图的结构（例如连接性）。因此，在从数据集中的各个域中选择图形时，我们考虑了一组不同的结构。请注意，SNAP 数据集仅包含图形结构。我们在每个顶点和边上附加随机生成的属性，即 128K 字节的键值对。
  我们还使用合成图来评估 IOGP。合成图是使用 RMAT 图生成器 [3] 遵循幂律分布生成的。我们使用以下参数生成具有 10K 个顶点和 1.2M 条边的 RMAT 图：a = 0.45，b = 0.15，c = 0.15，d = 0.25。该图被命名为RMAT-10K-1.2M。

软件平台

  我们在分布式图数据库原型 SimpleGDB [29] 上评估了 IOGP。其核心已在多个研究项目中使用并被证明是高效的[6, 7]。更重要的是，其灵活的设计支持各种图划分算法，并能够在它们之间进行公平的比较。
  SimpleGDB 遵循图 1 所示的通用图形数据库架构。它通过镜像 Dynamo 的方法，使用一致的哈希以去中心化的方式管理多个存储服务器 [9]。这允许图数据库集群的动态增长（或收缩）。每个服务器都运行相同的组件集，包括 OLTP 执行引擎、数据存储引擎和图形分区层。OLTP执行引擎接受来自客户端的请求并为它们提供服务。存储引擎将顶点、边及其属性等图数据组织成键值对，并将它们持久存储在RocksDB中[26]。图分区层被设计为一个插件，允许黑客在不影响其他组件的情况下更改算法，这在很大程度上简化了本研究中提出的评估和公平比较。SimpleGDB的另一个关键特性是它包含一个基于研究[6]构建的服务器端异步图遍历引擎。通过服务器端遍历，我们能够充分利用图分区算法获得的局部性。

评估结果

边割和平衡

  我们首先比较 IOGP 和最先进的图分区算法（METIS、Fennel 和 Hash）之间的 k 路分区指标（即割边率和分区平衡）。由于METIS不能有效地处理OLTP工作负载，因此为了进行比较，我们实际上在最终的图上运行一次METIS，假设所有的顶点和边都已经插入。类似地，为了对Fennel进行公平比较，我们假设图是以一种方式插入的，即一个顶点及其所有边一起插入。它们的插入顺序是随机选择的。哈希和 IOGP 的结果按照与提供的数据集相同的顺序以在线方式进行。

  我们在图 5 和图 6 中绘制了所有图表（在上一小节中描述）的结果。图 5 显示了边切割率，计算为图中边切割数除以边总数。图 6 显示了不平衡率，计算为所有分区与平均分区大小之间的最大差异。由于Fennel、IOGP和Hash实现了高度平衡的分区，因此在所有情况下它们的不平衡率几乎为零。他们的结果在图中看不到。从这些结果中，我们得到了一些观察结果。首先，METIS 在所有测试的算法中实现了最好的局部性但最差的平衡。在web-Google 图中，它会导致边切割率小于 1% 的分区，但不平衡性超过 6%。另一方面，哈希在所有情况下都会导致最差的分区，但同时提供了出色的平衡。其次，IOGP和Fennel介于METIS和Hash之间，不平衡度较小。就切边率而言，在所有测试情况下，IOGP 均优于 Fennel。在许多情况下（例如，email-EuAll 和 wiki-Talk），差异是显而易见的。这些结果证实，即使使用相同的启发式函数，IOGP 也可以获得比 Fennel 等最先进的流分区算法更好的顶点局部性。原因很简单。 Fennel 仅在首次插入时分配顶点一次。但是，IOGP 可能会在连续插入期间多次重新分配顶点，因此有更多机会为顶点选择更好的位置。我们将在下一小节中进行更详细的分析。

IOGP的不断完善

  正如上一小节中报告和讨论的评估所示，由于 IOGP 能够不断细化分区，因此它比 Fennel 具有更好的局部性。在图 7 中，我们详细展示了这是如何发生的。x 轴表示构建图表期间发生的插入次数。 y 轴显示当前切边率。每插入 $10^5$ 次，我们就采集一次样本。我们在此图中显示了前 $2\ast 10^7$ 个插入。结果证实了我们在 IOGP 中利用的两个重要模式：1）最初的插入显著地改变了局部性，2）插入更多边时图变得更稳定。这也是IOGP设计成指数级增加REASSIGN THRSH以减少重新分配频率的原因。

顶点重新分配阈值

  我们在此评估中讨论重新分配阈值（即 REASSIGN THRSH）。具体来说，我们使用不同的重新分配阈值多次构建整个图，并收集每轮的切边率和顶点重新分配的数量。预计较小的 REASSIGN THRSH 会带来更多的开销（即更多的顶点重新分配），并生成更好的分区（即更小的切边比）。事实上，对于不同的图表，REASSIGN THRSH 的最佳值应该不同。在本次评估中，我们测试了各种可能的值，以找到选择该值的潜在规则。具体来说，我们将阈值从 1 迭代到 50，每一步增加 5。所有结果均绘制在图 8 中。

  顶部子图显示，随着 REASSIGN THRSH 变大，切边率增加。更具体地说，一开始增幅很大，之后就趋于平缓。这是因为大多数这些图的平均度都较小（根据表1），并且它们对较小的阈值变化更敏感。一旦阈值变得足够大，它们的比率就会变得更加稳定。在底部子图中，我们显示了使用不同阈值重新分配顶点的次数。正如预期的那样，较大的阈值会减少顶点重新分配的数量。从这些结果中，我们得出结论，REASSIGN THRSH 的最佳选择应该接近图平均度数的一半，以在实现更好的局部性和更少的顶点重新分配之间取得平衡。这是一个经验结果，例如 web-Google 的 6。

点割阈值

  在IOGP中，我们根据顶点的度数来分割顶点，以在点割阶段获得最佳的遍历性能。尽管将边分配到多个服务器可以节省从磁盘加载数据的时间，但它确实会引入额外的网络开销来从远程服务器检索数据。找到平衡磁盘和网络延迟的最佳阈值非常重要。正如我们所描述的，点割阈值与硬件（磁盘速度和网络延迟）、分布式集群的规模和顶点度有关。获得普遍最佳的设置并非易事。在本次评估中，我们的目标是建立选择点割阈值的通用指南。在特定系统上部署 IOGP 之前，需要进行类似的评估以获得最佳设置。

  具体来说，我们在不同的集群规模上(从2到32台服务器)，针对不同程度的不同顶点(从1到$10^3$)进行了一系列评估。每条边附带128KB随机生成的属性。磁盘和网络延迟根据CloudLab APT集群的硬件配置固定。为了比较，我们测量了在不同簇尺度（不同处理器个数）下从这些顶点一步遍历的时间成本。结果如图9所示。x轴显示了不同的比例，在评估中，“k个服务器”表示所有边都分配在所有服务器上。请注意，“1 服务器”的情况意味着没有点割。y 轴显示读取每个顶点及其邻居的时间成本。总共有四种情况。从这些结果中，我们可以得出一些结论。首先，像 v(1) 和 v(10) 这样的低度顶点往往在较小规模的集群中获得更好的遍历性能。另一方面，高度顶点在更大规模的集群中可以获得更好的性能。这也证实了我们之前的分析。其次，每个度数都有其最佳比例。例如，对于一个具有$10^3$条边的顶点，最短时间是在“16个服务器”集群中获得的。对于有100条边的顶点，“4个服务器”集群将是最好的。该指标可以指导部署为特定集群选择最佳MAX EDGES。

IOGP数据结构的内存占用

  正如我们在第5节中所讨论的，IOGP引入了许多内存计数器来促进分区进程。它们的内存占用可能会限制IOGP算法的可伸缩性。在这个评估中，我们检查了构建表1中列出的图期间的最大内存占用。结果如图10所示。x轴显示不同的图形，y轴显示32台服务器上的最大内存消耗(KB)。我们还绘制了“预期”内存占用，这是简单地假设每个顶点v在每个服务器中有两个边缘计数器来计算的。从这些结果中，我们可以很容易地观察到，实际内存消耗远小于上限估计，特别是对于那些大规模的图。这些来自真实图的结果清楚地表明，IOGP在划分大规模图方面是实用的。

单点访问性能

  正如我们所描述的，大多数图数据库使用简单的散列策略来提供在线图分区。散列速度很快，并且最有利于INSERT等单点OLTP操作。其他图划分算法，包括METIS和Fennel，由于它们的离线性质，预计在插入方面的性能会差得多。在本研究中，为了研究IOGP的优势，我们将其插入性能与最佳算法(哈希)进行了比较。同样，评估是在32台服务器的SimpleGDB集群中进行的。图11显示了IOGP和Hash算法的插入速度。性能是从单个客户机生成的。结果表明，哈希总是比IOGP表现得更好，因为有顶点重新分配和点割带来的开销。然而，差别很小，不到10%。

图遍历性能

  在这次评估中，我们进一步比较了IOGP和Hash的遍历性能。图遍历作为图数据库中最重要的OLTP操作，应该获得最好的性能。这是通过重新分配顶点之间较少的边切比率以及在访问拆分的高度顶点时更高的并行性来实现的。在此评估中，所有遍历都从同一组随机选择的顶点开始。他们的平均完成时间用于比较。我们评估了包含 2、4、6 和 8 步的图遍历。
  由于篇幅限制，我们无法展示所有测试图的比较结果。相反，我们根据图 5 所示的切边比率选择了一组代表性图表。具体来说，我们选择了 Fennel 和 IOGP 之间具有最大边缘切割率差异的两个图（即 web-Google 和 RMAT10K-1.2M）以及具有最小边缘切割率差异的两个图（即 soc-LiveJournal1 和 wiki-讲话）。我们排除了 METIS，因为它在流图中无效，以避免不公平的比较。

  结果如图 12 所示。结果表明，在所有情况下，IOGP 都明显优于 Hash 和 Fennel 的遍历性能。当执行更多的遍历步骤时，性能差距也会增加。这些结果证明了 IOGP 对于未来更复杂的图遍历请求的优势和重要性。此外，我们可以观察到，在边切比率更好的图上，IOGP 实现了更多的改进。这一观察回顾了顶点局部性在图划分中的重要性。

结论与未来工作

  在本研究中，受分布式图数据库的 OLTP 性能要求的推动，我们引入了增量在线图分区（IOGP）算法，并描述了其设计和实现细节。IOGP根据图的连续变化在三个阶段之间调整其操作。它运行速度快，获得优化的分区结果，并生成很好地服务于复杂遍历的分区图。我们还介绍了实现细节，包括内存数据结构（例如边计数器），以提供快速的在线图形分区。我们对各个领域的多个图进行了详细而具体的评估，证实了 IOGP 的优势。从这些评估中，我们还能够得出重要的结论，包括选择其关键参数的一般准则。我们相信IOGP作为分布式图数据库的图分区解决方案具有广泛应用的巨大潜力。未来，我们计划研究和开发 IOGP 的容错功能，重点是在需要时有效地重建内存中的数据结构。