图数据库可扩展性指南，设计分布式数据库系统，图数据库查询优化。在许多企业场景中，拥有一个分布式和可扩展的图数据库系统是非常受欢迎的。一方面，这在很大程度上受到大数据处理框架的持续兴起和流行的影响，包括但不限于Hadoop、Spark和NoSQL数据库；另一方面，随着越来越多的数据在做分析，针对一个实例将所有数据打包到一张图中变得越来越难，拥有一个真正分布式和水平可扩展的图数据库是必须具备的。不要被误导设计和实施可扩展的图形数据库系统从来都不是一项简单的任务。无数企业，尤其是互联网巨头，都在探索让图数据处理可扩展的方法。尽管如此，大多数解决方案要么限于其专有和狭窄的用例，要么通过硬件加速以垂直方式提供可扩展性，这再次证明大型机架构计算机在90年代确定性地被PC架构计算机取代，主要是因为垂直可扩展性是通常被认为不如水平可扩展性，可扩展性差。分布式数据库通过加入廉价的PC来实现可扩展性（存储和计算），并尝试按需存储数据，一劳永逸已经成为常态。但是，这样做无法在不牺牲图系统上更多查询性能的情况下实现同等的可扩展性。为什么图形（数据库）系统的可扩展性如此难以（获得）？主要原因是图系统是高维的；这与传统的SQL或NoSQL系统形成鲜明对比，传统的SQL或NoSQL系统主要以表为中心，本质上是基于列和行的存储（以及更简单的KV存储），并且已被证明通过水平可扩展设计相对容易实现。一个看似简单直观的图查询可能会导致大量图数据的深度遍历和渗透，否则往往会导致典型的BSP（BulkySynchronousProcessing）系统在其众多的分布式实例之间进行大量的交换，从而导致在显着（和无法忍受的）延迟。另一方面，大多数现有的图形系统更愿意在提供可扩展性（存储）的同时牺牲性能（计算）。这将使此类系统对于许多现实世界的业务场景不切实际且无用。更准确的描述此类系统的方式是，它们可能能够存储大量数据（跨许多实例），但无法提供足够的图计算能力——换句话说，这些系统在查询越界数据时无法返回结果元素（节点和边）。本文旨在揭开图数据库的可扩展性挑战的神秘面纱，同时关注性能问题。简而言之，您将更好、更流畅地了解任何图形数据库系统的可扩展性和性能，并对选择您未来的图形系统更有信心。关于图数据库的可扩展性，市场上有很多声音；一些供应商声称他们具有无限的可扩展性，而另一些供应商则声称他们是第一个企业级可扩展图形数据库。你应该信任或跟随谁？唯一的出路是让自己充分了解图形数据库系统的可扩展性，这样您就可以自己验证它而不会被所有营销炒作所误导。诚然，图数据库可扩展性有很多术语；有些可能非常令人困惑，仅举几例：HA、RAFT或分布式共识、HTAP、联合、结构、分片、分区等。您真的能分辨出所有这些术语之间的区别吗？我们会解开它们。3分布式图系统架构设计学院首先要了解从单机（图数据库）实例到全分布式、可水平扩展的图数据库实例集群的演进路径。图1：分布式（图形）系统的演变。分布式系统可能有多种形式，而这种丰富的多样性会导致混乱。一些供应商误导性地（讽刺地）声称他们的数据库系统均匀分布在单个底层硬件实例上，而其他供应商则声称他们的分片图数据库集群可以处理数万个图数据集，而实际上，最重要的是，集群不能甚至不能处理迭代遍历整个数据集的典型多跳图形查询或图形算法。简而言之，可扩展图数据库架构设计只有三种流派，如表所示：表1：分布式图系统三种流派的比较。PAH架构的第一个思路被认为是主从模型的自然延伸，我们称之为分布式共识集群，通常三个实例组成一个图数据库集群。在同一个集群中拥有三个或奇数个实例的唯一原因是为了更容易投票选出集群的领导者。如您所见，此集群设计模型的许多变体都是可能的；例如，Neo4j的企业版v4.x支持原始的RAFT协议，只有一个实例处理工作负载，而另外两个从主实例被动同步数据——当然，这是让RAFT协议成为工作。一种更实用的处理工作负载的方法是扩充RAFT协议以允许所有实例以负载均衡的方式工作。例如，让领导实例处理读写操作，而其他实例至少处理读取类型的查询，以确保整个集群的数据一致性。这种分布式图系统设计中更复杂的方法是允许HTAP（HybridTransactionalandAnalyticalProcessing），这意味着不同的角色将分布在集群实例中；Leader会处理TP操作，而Follower会处理AP操作，再细分为图算法等角色。使用分布式共识的图形系统的优点和缺点包括：硬件占用空间小（且更便宜）。良好的数据一致性（更容易实现）。复杂和深度查询的最佳性能。可扩展性有限（取决于垂直可扩展性）。难以处理具有超过100亿个节点和边的单个图。下面显示的是Ultipa的新HTAP架构，具有以下主要特性：高密度并行图计算。多层存储加速（存储非常接近计算）。动态剪枝（通过动态剪枝机制加速图遍历）。超线性性能（即当CPU核数等计算资源翻倍时，性能提升可达一倍以上）。图2：UltipaGraph的HTAP架构图。请注意，此HTAP架构适用于小于10B节点+边的图形数据大小。因为很多计算加速都是通过内存计算完成的，如果每十亿个节点和边消耗大约100GB的DRAM，那么单个实例可能需要1TB的DRAM来处理一个数百亿个节点和边的图。这种设计的好处是架构可以满足大多数真实场景的需求。即使对于G-SIB（全球系统重要性银行），一个典型的欺诈检测、资产负债管理或流动性风险管理用例也会消耗大约10亿条数据；一个合理大小的虚拟机或PC服务器可以容纳这样的数据规模可以通过HTAP非常有效地设置。这种设计的缺点是缺乏水平（和无限）的可扩展性。这一挑战在分布式图形系统设计的第二和第三学派中得到解决（见表1）。下面两张图说明了HTAP架构的性能优势。需要注意两点：线性性能提升：一个3实例UltipaHTAP集群可以达到独立实例吞吐量的约300%。收益主要体现在元数据查询、路由/k-hop查询、图算法等AP类操作上，而没有体现在元数据插入或删除等TP类操作上，因为这些操作主要是同步之前的master实例。更好的性能=更低的延迟和更高的吞吐量（TPS或QPS）。图3：HTAP架构的性能优势。图4：Ultipa和Neo4j的TPS比较。网格架构在第二种流派中，这种分布式和可扩展的图形系统设计也有相当多的命名变体（有些误导）。仅举几例：代理、名称服务器、MapReduce、网格或联合。忽略命名差异；二级和一级之间的主要区别在于名称服务器充当客户端和服务器端之间的代理。当充当代理服务器时，名称服务器仅用于路由查询和转发数据。最重要的是，除了运行图形算法外，名称服务器还具有从底层实例聚合数据的能力。此外，在联合模式下，可以针对多个底层实例运行查询（查询联合）；然而，对于图形算法，联邦表现不佳（由于数据迁移，如map-reduce的工作方式）。请注意，第二个学派与第三个学派在一个方面有所不同：数据在功能上是分区的，但在这个设计学派中没有分片。对于图数据集，功能分区是图数据的逻辑划分，例如按时间序列（水平分区）或按业务逻辑（垂直分区）。另一方面，分片被设计成自动化的、业务逻辑或时间序列无关的。分片通常考虑基于网络存储的数据分区位置；它利用各种冗余数据和特殊的数据分布来提高性能，例如一方面切割节点和边缘，另一方面复制部分切割数据以获得更好的访问性能。事实上，sharding非常复杂且难以理解。根据定义，自动分片旨在处理不可预测的数据分布，将人为干预降至最低或零，并且忽略业务逻辑，但当面临与特定数据分布纠缠在一起的业务挑战时，这种忽略可能会带来很大问题。大问题。让我们用一个具体的例子来说明这一点。假设您有12个月的信用卡交易数据。在人工分区模式下，你自然地将数据网络划分为12个图集，一个图集包含每个3个实例的集群上一个月的交易量，这个逻辑由数据库管理员预定义。它强调通过数据库的元数据对数据进行分区，而忽略了不同图集之间的连通性。它对业务友好，不会减慢数据迁移速度，并且具有良好的查询性能。另一方面，在自动分片模式下，图系统决定如何划分（切割）数据集，分片逻辑对数据库管理员是透明的。但是开发人员很难立即弄清楚数据存储在哪里，仅仅因为自动分片涉及较少的人为干预就声称自动分片比功能分区更智能是不明智的。你觉得这里有什么问题吗？随着人工智能的不断发展，这正是我们正在经历的，我们允许机器代表我们做出决定，而且它并不总是智能的！（在另一篇文章中，我们将讨论全球从人工智能向增强智能转变的话题，以及为什么图技术在战略上定位于推动这一转变。）在Graph-5中，我们展示了学院的网格架构；在Graph-2的HTAP架构之上添加的两个额外组件是名称服务器和元服务器。基本上所有查询都通过名称服务器代理，名称服务器与元服务器一起工作以确保网格的弹性；服务器集群实例在很大程度上与原始HTAP实例相同（如图2所示）。图5：具有名称服务器和元服务器的网格架构。参考表1，网格架构设计的优缺点可以总结如下：保留了典型HTAP架构的所有优点/优势。可扩展性是在不改变性能的情况下实现的（与HTAP架构相比）。可扩展性有限——服务器集群在DBA/管理员干预下进行分区。引入名称服务器/元服务器，使集群管理更加复杂。名称服务器对于确保业务逻辑在服务器集群中分布执行并在返回给客户端之前具有简单的合并和聚合功能至关重要且复杂。可能需要业务逻辑配合分区和查询。分片架构现在，我们可以迎来具有无限可扩展性的分布式图系统设计的第三个流派——分片（见表1）。从表面上看，分片系统的水平可扩展性也像第二种设计一样利用名称服务器和元服务器，但有一个主要区别：分片服务器是真正共享的。名称服务器不直接了解业务逻辑（就像第二所学校）。间接地，它可以通过自动统计粗略判断业务逻辑的类别。这个解耦很重要，在secondclass是不可能优雅实现的。分片架构有一些变化；有的叫fabric（其实更像中学的grid架构），有的叫map-reduce，但还是要深入核心的数据处理逻辑才能揭开答案。Sharding架构中的数据处理逻辑只有两种：Type1：数据主要在名称服务器（或代理服务器）上处理Type2：数据在分片或分区服务器以及名称服务器上处理。类型1是典型的，正如您在大多数map-reduce系统（例如Hadoop）中看到的那样；数据分布在高度分布式的实例中。然而，在它们可以在那里被处理之前，它们需要被提升并转移到名称服务器。类型2的不同之处在于，分片服务器具有在数据被聚合并在名称服务器上进行二次处理之前在本地处理数据的能力（这称为：Computingnearstorageorwithstorageordata-centriccomputingApposition）。可以想象，类型1更容易实现，因为它是许多大数据框架的成熟设计；但是，类型2通过更复杂的集群设计和查询优化提供更好的性能。type-2中的分片服务器提供计算能力，这是type-1中没有的。下图显示了类型2分片设计：图6：具有名称服务器和元服务器的分片架构。Sharding从传统的SQL或NoSQL大数据框架设计的角度来看并不是什么新鲜事。然而，图形数据的分片可能是潘多拉魔盒，原因如下：多个分片将提高I/O性能，尤其是数据摄取速度。但是多个分片将显着增加任何跨越多个分片的图查询的周转时间，例如路径查询、k-hop查询和大多数图算法（延迟增加可能是指数级的！）。图查询计划和优化可能非常复杂，如今大多数供应商都做得很浅，并且有大量机会可以即时加深查询优化：级联（启发式与成本）分区修剪（实际上是分片修剪）索引选择统计（智能估计）)下推（使计算尽可能接近存储）等等。在Graph-7中，我们捕获了一些关于UltipaHTAP集群和UltipaShard集群的初步发现；如您所见，数据摄取速度快四倍（超线性），但其他一切往往慢五倍或更多（PageRank慢10倍，LPA慢16倍，等等）图7：关于HTAP和分片之间性能差异的初步发现架构。敬请期待有很多机会可以不断提高分片架构的性能。Ultipa的团队已经意识到，在水平可扩展的系统上拥有真正先进的集群管理机制和更深入的查询优化，是实现无限扩展和令人满意的性能的关键。最后，分布式图系统架构的第三个流派说明了设计复杂且功能强大的图系统所涉及的多样性和复杂性。当然，考虑到成本、主观偏好、设计理念、业务逻辑、复杂度容忍度、可服务性等诸多因素，很难说一种架构就一定比另一种更好——画出一个架构演进的方向是明智的从长远来看，显然是从第一所学校到第二所学校，最后到第三所学校。然而，大多数客户场景都能满足前两种思想流派，人类智能（DBA干预）对于帮助实现性能和可扩展性的平衡仍然至关重要，尤其是在第二种和第三种设计流派中。国王公式：图增强智能=人类智能+机器图算力
