【Neo4j Fabric】架构思想

• ​​【Neo4j Fabric】架构思想​​

• ​​一、概述​​
• ​​二、Fabric概念​​

• ​​2.1 Fabric节点数据库​​
• ​​2.2 Fabric图访问模式​​

• ​​三、部署示例​​

• ​​3.1 开发阶段的部署​​
• ​​3.2 没有单点故障的集群部署​​
• ​​3.3 多集群部署​​

• ​​四、总结​​

Here’s the table of contents:

【Neo4j Fabric】架构思想

一、概述

    Neo4j 4.0中引入的Fabric是一种使用一个Cypher查询在多个数据库中存储和检索数据的方法，无论这些数据是在相同的Neo4j DBMS上还是在多个DBMS中。

    Fabric可以实现下面的功能:

• 本地和分布式数据的统一视图，可通过单个客户端连接和用户会话访问
• 提高了读/写操作、数据量和并发性的可伸缩性
• 在正常操作、故障转移或其他基础设施更改期间执行的查询的可预测响应时间【分布式架构下无显著性能损耗】
• 大数据量下的高可用性和无单点故障

    实际上，Fabric为以下方面提供了基础设施和工具:

• ​​数据联邦​​：以不相交图的形式访问分布式数据源中可用数据的能力
• ​​数据分片​​：在多个数据库上分区的公共图的形式访问分布式数据源中可用数据的能力。

    使用Fabric架构，Cypher查询可以在多个联合图和分片图中存储和检索数据

二、Fabric概念

2.1 Fabric节点数据库

    Fabric设置包括Fabric虚拟数据库，它充当联邦或分片图基础结构的入口点。这个数据库是可以执行多图查询的执行上下文。驱动程序和客户端应用程序通过将Fabric执行上下文命名为会话的选定数据库，来访问和使用Fabric节点。更多信息可以查看数据库和执行环境的操作手册。​​Neo4j Driver manuals​​

    Fabric虚拟数据库(执行上下文)不同于普通数据库，因为它不能存储任何数据，只转发存储在其他地方的数据。Fabric虚拟数据库只能在一个独立的Neo4j DBMS上配置，并且​​dbms.mode​​​配置项需要设置为​​SINGLE​​。

2.2 Fabric图访问模式

    在Fabric虚拟数据库中，数据以图的形式组织。数据被客户机应用程序视为本地逻辑结构，其中物理数据存储在一个或多个数据库中。作为Fabric结构访问的数据库可以是本地的，即在相同的Neo4j DBMS中，或者它们可以位于外部Neo4j DBMS中。客户机应用程序也可以从它们各自的Neo4j dbms中的常规连接访问数据库。即Fabric不影响原来的数据远程或者本地读取的方式，且具备强大的组织和聚合图的能力，通过一个配置项就可以将其它数据库中的图集成到自己的数据体系中。

三、部署示例

    Fabric构成了一个非常通用的环境，在各种拓扑中提供没有单点故障的可伸缩性和可用性。用户和开发人员可以在独立DBMS上运行程序，也可以在非常复杂和大规模分布式图数据库集群中运行程序，而不需要对访问Fabric图的查询应用任何更改，就可以实现应用程序的无缝集成。

3.1 开发阶段的部署

    在最简单的部署中，Fabric可以用于单个实例，其中Fabric图与本地数据库相关联。软件开发人员通常使用这种方法来创建将来会部署在多个Neo4j dbms上的应用程序，或者高级用户打算对局部不连接图执行Cypher图网络聚合查询。​​【该架构部署适用于测试阶段】​​

• 单个实例中的Fabric部署

3.2 没有单点故障的集群部署

    在这种部署Fabric中，它保证了对高可用性中不相交图的访问，没有单点故障。如果通过为Fabric数据库创建冗余入口点(即具有相同Fabric配置的两个独立的Neo4j dbms，部署​​两台Fabric虚拟节点​​​)和​​最小三个节点​​​的集群(用于数据存储和检索)来实现可用性。这种方法适用于​​生产环境​​，高级用户可以使用它对不相交图执行Cypher查询。

• 没有单点故障的Fabric部署

3.3 多集群部署

    在这种部署Fabric中，提供了高可伸缩性和可用性，没有单点故障。可以根据预期的工作负载调整不相连的集群的大小，数据库可以位于同一个集群中，也可以托管在自己的集群中以提供​​更高的吞吐量​​​。这种方法适用于数据库可以​​分片​​​、​​联邦​​​或​​两者结合​​的生产环境。

• Fabric部署以实现无单点故障的可伸缩性

四、总结

    在​​3.1​​​到​​3.3​​​节，分别描述了开发测试阶段、基础生产环境、支持分片和联邦生产环境，三种图数据库集群部署方式。
    其中​​​3.2​​​是在生产环境中使用图数据库集群的基础部署架构，该架构至少包含两台Fabric节点、三台CORE节点【或者其中一台为分片节点也可以】，一共包含了五个节点。在机器资源紧缩的情况下，将两台具有Fabric功能的节点，集成部署在CORE节点也是可以用的，因此生产环境下​​最最最精简​​​的部署方式是三台机器。
    在​​​3.3​​​中展示了高级部署方式，这种架构下就可以充分实现​​数据联邦​​​和​​数据分片​​​操作了。通过Fabric节点即可访问不同集群中的数据，集群可能在本地也可能是在远程，甚至会是其它公司的图数据库集群。
    例如，有一个时间序列的超级大图可能包含上千亿的关联数据，这个时候一个集群存储可能会比较吃力了，因此需要多集群的方式来存储；例如可以通过数据建模来设计2021之前的数据存储在A集群，2021年之后的数据存储在B集群，通过Fabric节点并行查询，就可以实现不同集群数据的一次图数据网络聚合；并且这种分布式扩展方式是不会带来性能的下降的。
    总的来说，​​​数据分片​​​也就是​​REPLICA NODE​​​解决了大规模分布式查询的性能问题；​​数据联邦​​​也就是​​多集群存储数据​​​解决了数据规模问题。像大家熟知的​​Elasticsearch​​​就是经典的分布式存储系统，但是ES在一个索引建立大量分片的情况也会有性能问题，规模其实就遇到了瓶颈；ES解决这个问题是通过​​别名索引​​​的方式，即一个索引被拆分成多个，这样的话就可以有效控制每个索引的分片数量不会导致大量数据时性能急剧下降。在我看来，ES这种​​别名索引​​​的设计思想与​​Fabric​​​架构有点异曲同工之妙！虽然完美解决了性能和容量的问题，但是带来了​​数据工程师​​数据建模和ETL的复杂性。