You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Neo4j Fabric is a way to store and retrieve data in multiple databases, whether they are on the same Neo4j DBMS or in multiple DBMSs, using a single Cypher query.
9
-
For more information about Fabric itself, please visit the https://neo4j.com/docs/operations-manual/4.4/fabric/introduction/[Fabric documentation].
10
+
Neo4j composite databases are a way to store and retrieve data in multiple databases, whether they are on the same Neo4j DBMS or in multiple DBMSs, using a single Cypher query.
11
+
For more information about Composite databases/Fabric itself, please visit the
10
12
11
-
A typical Neo4j Fabric setup consists of two components: one or more shards that hold the data and one or more Fabric proxies that coordinate the distributed queries.
12
-
There are two ways of running the Neo4j Graph Data Science library in a Fabric deployment, both of which are covered in this section:
13
+
[.tabbed-example, caption = ]
14
+
====
13
15
14
-
. Running GDS on a Fabric <<fabric-shard, _shard_>>
15
-
. Running GDS on a Fabric <<fabric-proxy, _proxy_>>
NOTE: For simplicity this documentation page further only mentions composite databases which are available from Neo4j 5.0 on. As GDS supports 4.x and 5.x Neo4j versions this documentation can be also applied to Fabric setups using the exact same queries and examples as shown below.
29
+
30
+
A typical Neo4j composite setup consists of two components: one or more shards (constituents) that hold the data and one composite database that coordinates the distributed queries.
31
+
There are two ways of running the Neo4j Graph Data Science library in a composite deployment, both of which are covered in this section:
32
+
33
+
. Running GDS on a Composite <<composite-shard, _shard_>>
34
+
. Running GDS on a Composite <<composite-proxy, _database_>>
35
+
36
+
[[composite-shard]]
18
37
== Running GDS on the Shards
19
38
20
-
In this mode of using GDS in a Fabric environment, the GDS operations are executed on the shards.
21
-
The graph projections and algorithms are then executed on each shard individually, and the results can be combined via the Fabric proxy.
39
+
In this mode of using GDS in a composite environment, the GDS operations are executed on the shards.
40
+
The graph projections and algorithms are then executed on each shard individually, and the results can be combined via the composite database.
22
41
This scenario is useful, if the graph is partitioned into disjoint subgraphs across shards, i.e. there is no logical relationship between nodes on different shards.
23
42
Another use case is to replicate the graph's topology across multiple shards, where some shards act as operational and others as analytical databases.
24
43
25
-
[[fabric-shard-setup]]
44
+
[[composite-shard-setup]]
26
45
=== Setup
27
46
28
47
In this scenario we need to set up the shards to run the Neo4j Graph Data Science library.
29
48
30
49
Every shard that will run the Graph Data Science library should be configured just as a standalone GDS database would be, for more information see xref:installation/index.adoc[Installation].
31
50
32
-
The Fabric proxy nodes do not require any special configuration, i.e., the GDS library plugin does not need to be installed.
33
-
However, the proxy nodes should be configured to handle the amount of data received from the shards.
51
+
The composite database does not require any special configuration, i.e., the GDS library plugin does not need to be installed.
52
+
However, the Composite database should be configured to handle the amount of data received from the shards.
34
53
35
-
[[fabric-shard-examples]]
54
+
[[composite-shard-examples]]
36
55
=== Examples
37
56
38
-
Let's assume we have a Fabric setup with two shards.
57
+
Let's assume we have a composite setup with two shards.
39
58
One shard functions as the operational database and holds a graph with the schema `(Person)-[KNOWS]->(Person)`.
40
59
Every `Person` node also stores an identifying property `id` and the persons `name` and possibly other properties.
41
60
@@ -46,26 +65,26 @@ First we need to project a named graph on the analytical database shard.
Using Fabric, we can now calculate the PageRank score for each Person and join the results with the name of that Person.
76
+
Using the composite database, we can now calculate the PageRank score for each Person and join the results with the name of that Person.
58
77
59
78
[source, cypher, role=noplay]
60
79
----
61
80
CALL {
62
-
USE FABRIC_DB_NAME.ANALYTICS_DB
81
+
USE COMPOSITE_DB_NAME.ANALYTICS_DB
63
82
CALL gds.pagerank.stream('graph', {})
64
83
YIELD nodeId, score AS pageRank
65
84
RETURN gds.util.asNode(nodeId).id AS personId, pageRank
66
85
}
67
86
CALL {
68
-
USE FABRIC_DB_NAME.OPERATIONAL_DB
87
+
USE COMPOSITE_DB_NAME.OPERATIONAL_DB
69
88
WITH personId
70
89
MATCH (p {id: personId})
71
90
RETURN p.name AS name
@@ -78,44 +97,44 @@ The algorithm results are streamed to the proxy, together with the unique node i
78
97
For every row returned by the first subquery, the operational database is then queried for the persons name, again using the unique node id to identify the `Person` node across the shards.
79
98
80
99
81
-
[[fabric-proxy]]
82
-
== Running GDS on the Fabric Proxy
100
+
[[composite-proxy]]
101
+
== Running GDS on the Composite database
83
102
84
-
In this mode of using GDS in a Fabric environment, the GDS operations are executed on the Fabric proxy server.
103
+
In this mode of using GDS in a composite environment, the GDS operations are executed on the Fabric proxy server.
85
104
The graph projections are then using the data stored on the shards to construct the in-memory graph.
86
105
87
-
NOTE: Currently only xref:management-ops/projections/graph-project-cypher-aggregation.adoc[Cypher Aggregation] is supported for projecting in-memory graphs on a Fabric proxy.
106
+
NOTE: Currently only xref:management-ops/projections/graph-project-cypher-aggregation.adoc[Cypher Aggregation] is supported for projecting in-memory graphs on a Composite database.
88
107
89
-
Graph algorithms can then be executed on the Fabric proxy, similar to a single machine setup.
90
-
This scenario is useful, if a graph, that logically represents a single graph, is distributed to different Fabric shards.
108
+
Graph algorithms can then be executed on the composite database, similar to a single machine setup.
109
+
This scenario is useful, if a graph that logically represents a single graph is distributed to different Composite shards.
91
110
92
-
[[fabric-proxy-setup]]
111
+
[[composite-proxy-setup]]
93
112
=== Setup
94
113
95
114
In this scenario we need to set up the proxy to run the Neo4j Graph Data Science library.
96
115
97
-
The dbms that manages the Fabric proxy database needs to have the GDS plugin installed and configured.
116
+
The dbms that manages the composite database needs to have the GDS plugin installed and configured.
98
117
For more information see xref:installation/index.adoc[Installation].
99
118
The proxy node should also be configured to handle the amount of data received from the shards as well as executing graph projections and algorithms.
100
119
101
120
Fabric shards do not need any special configuration, i.e., the GDS library plugin does not need to be installed.
102
121
103
-
[[fabric-proxy-examples]]
122
+
[[composite-proxy-examples]]
104
123
=== Examples
105
124
106
-
Let's assume we have a Fabric setup with two shards.
125
+
Let's assume we have a composite setup with two shards.
107
126
Both shards function as the operational databases and hold graphs with the schema `(Person)-[KNOWS]->(Person)`.
108
127
109
128
We now need to query the shards in order to drive the import process on the proxy node.
110
129
111
130
[source, cypher, role=noplay]
112
131
----
113
132
CALL {
114
-
USE FABRIC_DB_NAME.FABRIC_SHARD_0_NAME
133
+
USE COMPOSITE_DB_NAME.COMPOSITE_SHARD_0_NAME
115
134
MATCH (p:Person) OPTIONAL MATCH (p)-[:KNOWS]->(n:Person)
116
135
RETURN p, n
117
136
UNION
118
-
USE FABRIC_DB_NAME.FABRIC_SHARD_1_NAME
137
+
USE COMPOSITE_DB_NAME.COMPOSITE_SHARD_1_NAME
119
138
MATCH (p:Person) OPTIONAL MATCH (p)-[:KNOWS]->(n:Person)
0 commit comments