共计 5086 个字符，预计需要花费 13 分钟才能阅读完成。
明天，我试着简要综述几类不同的图数据库的分布式与切图的设计，心愿能够帮忙大家理解不同我的项目、产品的设计差别。如果有了解不对的中央，欢送留言探讨。
什么是分布式系统
一般来说，分布式系统是一组计算机程序的汇合，这些程序利用跨多个独立节点的资源来实现独特的指标；这里的独立节点，硬件上大多是指商用服务器（Commodity Servers）而不是大型主机（Mainframe）；这里的跨节点协同，硬件上大多是基于以太网设施或者更高端的 RMDA 设施。
为什么咱们须要分布式系统？
应用分布式技术的次要目标，实质上是用软件技术 + 便宜硬件来换取低廉硬件设施（比方主机）的老本；特地是在大多数公有机房环境——而不是私有云端或者超算条件下，此时洽购老本是商业决策的重要依据。
除了升高硬件老本外，分布式技术带来的另一个益处是其“扩展性”，通过在原有商用服务器的数量根底上，减少几台服务器，再联合分布式软件的调度和散发能力，使得新退出的这几台服务器也再额定提供更多的服务；
相比于每次扩容都要 1 比 1 洽购更多的等数量服务器，或者购买更高配置的服务器；分布式技术这一方面使得采购计划能够按需扩容，升高了一次性的大额资本收入；另一方面也使得业务容量能够更加容易布局。
分布式系统的根底问题
在分布式技术中，因为数据的存储和计算须要跨多个独立节点来实现，因而不得不波及到一系列根底技术。在本文中咱们只探讨两个：一是提供数据（和服务）的拷贝或者正本的问题；二是对于那些宏大数据的存储和计算该如何散发到各个独立节点上实现？
一、数据的正本问题
因为是商用服务器，其硬件上的可靠性和可维护性远远低于主机，网线松动、硬盘损坏、电源故障在大型机房中简直每小时都在产生，是常态；解决屏蔽这些硬件问题是分布式软件系统要解决的根本问题。一个罕用的形式是为数据（和其服务）提供更多的拷贝或者正本，这些正本存在于多台商用服务器上。当一些正本产生故障时，由失常的正本持续提供服务；并且当拜访压力减少时，还能够减少更多的副原本加强服务能力。此外，还须要通过肯定的技术手段来保障这些正本的“一致性”，也就是每个服务器上各个正本的数据是一样的。
当然，在图数据库中，正本问题也存在；其解决形式和大多数大数据、RDBMS 会较为相似。
二、是数据的切分问题
单台服务器的硬盘、内存、CPU 都是无限的，TB、PB 级别的数据通过肯定的方法散发到各个服务器上，这称为”切片”。当一些申请要拜访多个切片时，分布式系统要可能将这些申请拆散散发到各个正确的分片上，并将各分片的返回从新“拼装”成残缺的后果。
图数据中的切分问题：切图
在图数据库中，这个散发过程被形象的称为“切图”：就是把一个大图切成很多的小图，把对于这些小图的存储或者计算再搁置在不同的服务器上。相比大数据、RDBMS 的大多数计划，值得一些特地的阐明。
咱们先思考一个动态的（不会发生变化的）图构造，比方“CiteSeer 数据集”，这外面记录了 3,312 篇论文，以及这些论文之间的援用关系；这是一个很小规模的数据集，因而工程上，咱们能够根本置信对于这个数据集的解决是能够交给单个服务器。
再对于 twitter2010 这个数据集，其中有 1,271 万个顶点和 2.3 亿条边，对于明天（2023 年）的支流服务器来说，绝对能够轻松解决；但对于 10 年前的服务器来说，可能就须要选购十分低廉的高端服务器才行。
但对于 WDC 数据集(Web Data Commons)，其中有 17 亿个顶点和 640 亿条边，这样规模的计算这对于以后单台支流服务器来说也相当艰难了。
另一方面，因为人类社会数据产生的速度快于摩尔定律，而数据之间的交互与关系又指数级高于数据产生的速度；“切图”仿佛是一个不可避免的问题；但这听下来仿佛和各种支流分布式技术外面的数据分片和散列的形式没啥区别。毕竟那么多大数据系统，不都要“切”吗
等等——图真的那么好”切”吗？
遗憾的是，并不是。图畛域外面，”切图”是一个在技术、产品和工程上须要认真衡量的问题。
切图面临的三个问题
第一个问题，切在哪里 ？在大数据或者 RDBMS 中，咱们依据记录或者字段来进行 行切 row-based 或者 列切 column-based，也能够依据 ID 规定进行切分；这些在语义和技术都比拟直观。可是图的特点是它的强连通性，一个点通过一些边，关联上了另外一些点，这些点又通过它们的邻边关联上了更多的点，就像全世界的 Web 网页，简直都通过超链接关联在一起，那对于图来说，切在哪里才是语义上直观与天然的。(如果用 RDBMS 的术语，相当于有大量的外键状况下，如何切分)。当然，也存在一些人造语义上的图切片形式，例如在新冠疫情下，各种毒株在中国的传染链条和国外的链条曾经人造是两个不同的网络结构。但此时，引入了第二个问题。
第二个问题，如何保障切了之后，各分片的负载是大抵平衡的？人造造成的图合乎幂率定律——20% 的多数节点连贯了 80% 的其余节点，这些多数节点也称为“超级节点”或者“浓密点”。这意味着多数超级节点关联了大多数其余的平平无奇的节点。因而能够预计含有超级节点的分片（服务器）的负载和热点会远远大于其余不含超级节点的分片。
图解：互联网上网站通过超链接造成的关联网络可视成果，其中的超级网站（节点）清晰可见
第三个问题，当图网络逐步演变增长，图的散布和连通性也逐步产生了扭转，原有的切分办法逐步生效，该如何评估和进行重散布。下图是人类大脑 860 亿个神经元之间的连贯可视图，随着学习、锤炼、睡眠、苍老，神经元连贯甚至在周级别就会产生显著的变动；原先失去的切片形式可能齐全跟不上变动。
当然还有其余很多要思考的问题细节，本文也尽量避免引入太多的技术术语。
遗憾的是，尽管有这些问题（当然其实还有更多），在技术角度并没有一个通用的最优计划，各个产品针对其重点不得不进行取舍，上面是一些举例。
不同图数据库的切图形式
1.“分布式”但不”切图”
这种思路的典型做法是 Neo4j 3.5 尽管采纳了分布式的架构，但不进行图切分。
采纳分布式的目标，是为了保障写入的多正本一致性和读负载能力。也就是说每个服务器中都保留了”全量”的图数据，因而图数据不能大于单机的内存和硬盘容量；而通过减少写正本，能够保障写入过程中单机生效问题；通过减少读正本，能够提供更多的读申请能力（不能进步写申请的能力）。
能够看到对于后面的三个问题，这种计划在产品层面间接防止。然而实践上，这样的计划称为“分布式”并没有什么问题。
多说一句，因为是单机，数据库意义上的 ACID 在技术上较为简单。
Neo4j 3.5 的因果集群架构
https://medium.com/neo4j/querying-neo4j-clusters-7d6fde75b5b4
2. 分布式，由用户来”切图”
这个典型的代表是 Neo4j 4.x Fabric。依据业务状况，用户指定将每个局部的子图放在一个 (组) 服务器上，例如在一个集群内，E 号产品的图放在 E 号服务器上，N 号产品的图放在 N 号服务器上。当然，为了服务自身的可用性，这些服务器还能够采纳上文中 Causal Cluster 的计划。
在这个过程中，不论是查问还是写入，都须要用户指定要拜访哪个服务。Fabric 辅助用户代理路由。这个计划和 RDBMS 的分表十分相似，用户在应用过程中本人指定要应用那个分区或者分表，“切分”这个动作，用户是有着齐全的掌控。
能够看到对于后面的三个问题，这种计划在产品层面齐全交给了用户来决定。当然，这样的计划也能够称为“分布式”。
多说一句，尽管能够保障 E 服务器外部的 ACID。但因为存在肯定数量的边”横跨”两个服务器，技术上不保障这些”横跨”边操作的 ACID。
Neo4j Fabric 架构
https://neo4j.com/developer/neo4j-fabric-sharding/
3. 非对等分布式，”切图”，粗颗粒度的正本
在这种计划中，既有多正本，也有“切图”，这两个过程也都须要大量用户的染指。
Tigergraph 的切图计划，可拜访视频查看：https://www.youtube.com/watch?v=pxtVJSpERgk
在 TigerGraph 的计划中，点和边（在编码后），会扩散到多个分片上。
下面的三个问题，第 1 和 2 能够通过编码局部的技巧来局部缓解，并将局部查问或者计算的决策（单机还是分布式模型）交给用户决定来实现衡量。
TigerGraph 的单机查问模式和并行计算模式
多说一句，这样一组分片必须要残缺并截然不同的复制多份（因而扩容颗粒度是整个图，而不是某个分片）。绝对扩容时的单次收入较大。
4. 全对等分布式，”切图”，细颗粒度的正本
还有一些计划的架构设计目标中，绝对把图的扩展性 / 弹性排在整个零碎设计最高的优先级。其假如是数据产生的速度快于摩尔定律，而数据之间的交互与关系又指数级高于数据产生的速度。因而，必须要可能解决这样爆炸增长的数据，并疾速提供服务。
在这种架构中，通常的显著特点是把存储层和计算层物理上离开，各自实现细颗粒度的扩容能力；
数据分片由存储层负责，通常用 hash 或者一致性 hash 的计划进行切分，依据点的 ID 或者主键进行散列。（答复第一个问题）
NebulaGraph 的架构图如上，援用自论文：Wu, Min, et al. “Nebula Graph: An open source distributed graph database.” arXiv preprint arXiv:2206.07278 (2022).
图援用自：Li C, Chen H, Zhang S, et al. ByteGraph: A High-Performance Distributed Graph Database in ByteDance[J].
为了解决超级节点和负载平衡（第二个问题），再引入一层数据结构 B+tree，将大的超级节点拆分成更多小的处理单元，并工程上实现线程间的负载切换，和独立扩容计算层。对于第三个问题，通过引入细颗粒度的切片，独自实现局部切片的扩容
当然，这种计划也能够称为“分布式”。
以上四种计划，在产品和技术层面做了不同的衡量，各种偏重以适宜各自的用户业务场景。但它们都能够称为“分布式”。
扩大浏览
图的切分问题：在单机上如何进行切图，曾经失去了大量的钻研。这里举荐工具 METIS（http://glaros.dtc.umn.edu/gkhome/metis/metis/overview）在分布式环境的切图是一个比 (fei) 较(chang)艰难的问题。这里举荐一些业界的探讨：
- https://dgraph.io/blog/post/db-sharding/
- https://hal.inria.fr/hal-01401338/document
- https://docs.janusgraph.org/advanced-topics/partitioning/
对于“伪分布式”(Pseudo-Distrubuted Mode)
一般来说，这是用单服务器上的运行模仿在多个服务器的运行；特地适宜于学习或者调试。
对于图畛域的综述
- Sahu, S., Mhedhbi, A., Salihoglu, S., Lin, J., ¨Ozsu, M.T.: The ubiquity of large graphs and surprising challenges of graph processing: extended survey. VLDB J. 29(2-3), 595–618 (2020)
- Sakr, S., Bonifati, A., Voigt, H., Iosup, A., Ammar, K., Angles, R., Yoneki: The future is big graphs: a community view on graph processing systems. Communications of the ACM 64(9), 62–71 (2021)
Disclaimer
1. 以上提到的技术计划，是作者的了解和分享，如有谬误欢送指出，并没有商业竞争目标。
2. 为了升高读者了解难度, 做了很大水平的简化，并不示意原计划是如此简略。
谢谢你读完本文 (///▽///)
NebulaGraph Desktop，Windows 和 macOS 用户装置图数据库的绿色通道，10s 拉起搞定海量数据的图服务。通道传送门：http://c.nxw.so/6TWJ0
想看 nebula-br 源码的小伙伴能够返回 GitHub 浏览、应用、(^з^)-☆ star 它 -> GitHub；和其余的 NebulaGraph 用户一起交换图数据库技术和利用技能，留下「你的名片」一起游玩呢~
