Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -4,60 +4,35 @@
[[composite-databases-concepts]]
= Concepts

A Composite database is a special type of database.
A composite database is a special type of database.
Composite databases are the means to access this partitioned data or graphs with a single Cypher query.

Composite databases *do not store data* independently.
They contain _database aliases_ that target the local or remote databases (the so-called _constituents_) that constitute the fabric setup.
They contain _database aliases_ that target the local or remote databases (the so-called _constituents_).
Local database aliases target databases within the same DBMS, while remote database aliases target databases from another Neo4j DBMS.
For more information, see xref:database-administration/aliases/manage-aliases-composite-databases.adoc[].

Composite databases are managed using Cypher administrative commands.
Therefore, you can create them as any other database in Neo4j standalone and cluster deployments without needing to deploy a dedicated proxy server (as with Fabric in Neo4j 4).
For a detailed example of how to create a Composite database and add database aliases to it, see xref:database-administration/composite-databases/querying-composite-databases.adoc[Set up and query composite databases].

Composite databases cannot guarantee compatibility between constituents from different major versions of Neo4j.
Therefore, all constituents should belong to the same major version.
If a new feature is introduced, its availability will be limited to the intersection of features available for all constituents.

The following table summarizes the similarities and differences between Composite databases in Neo4j 5 and Fabric in Neo4j 4:

.Composite database Neo4j 5 vs. Fabric Neo4j 4
[cols="<24s,38,38",frame="topbot",options="header"]
|===
| | Composite database (Neo4j 5) | Fabric (Neo4j 4)

| Data access
2+| Gives access to graphs found on other databases (local or remote).

| Data storage
2+| Does not store data independently.

| Deployment
| Both standalone and cluster deployments.
| Both standalone and cluster deployments. However, in a cluster deployment, the _fabric_ proxy must be deployed on a dedicated machine.

| Configuration
| Managed using Cypher commands. Composite databases are created with the `CREATE COMPOSITE DATABASE` command and database aliases are added with `CREATE ALIAS ..`.
| Managed through configuration settings. The Neo4j DBMSs that host the same _fabric_ database must have the same configuration settings. The configuration must be always kept in sync.

| Sharding an existing database
2+| With the help of the `neo4j-admin copy` command.

| Security credentials
| Composite databases use the same user credentials as the database aliases.
| The Neo4j DBMSs that host the same Fabric virtual database must have the same user credentials. Any change of password on a machine that is part of Fabric must be kept in sync and applied to all the Neo4j DBMSs that are part of Fabric.

| Database management
2+| Does not support database management. Any database management commands, index and constraint management commands, or user and security management commands must be issued directly to the DBMSs and databases, not the Composite databases.

| Transactions
2+| Only transactions with queries that read from multiple graphs, or read from multiple graphs and write to a single graph, are allowed.

| Neo4j embedded
2+| Not available when Neo4j is used as an embedded database in Java applications. It can be used only in a typical client/server mode when users connect to a Neo4j DBMS from their client application or tool via Bolt or HTTP protocol.
|===

Composite databases cannot guarantee compatibility between constituents from different Neo4j versions.
Constituents from versions without breaking changes should work fine, apart from newly-added features.
If a new feature is introduced, its availability will be limited to the intersection of features available on the DBMS where the composite database is defined, as well as all of its constituents.

Composite databases have the following characteristics:

* Provide access to graphs found on other databases (local or remote).
* Do not store data independently.
* Can be deployed in standalone and cluster deployments.
* Managed using Cypher commands, such as `CREATE COMPOSITE DATABASE` and `CREATE ALIAS`.
* You can shard an existing database with the help of the `neo4j-admin copy` command.
See xref:database-administration/composite-databases/sharding-with-copy.adoc[Sharding data with the copy command] for details.
* Use the existing user for local constituents or the user credentials defined by the remote aliases for remote consituents.
* Do not support privileges, index, and constraint management commands.
These must be defined on the constituent target database in the respective DBMS.
* Allow only transactions with queries that read from multiple graphs, or read from multiple graphs and write to a single graph.
* Do not support Neo4j embedded in Java applications.
Composite databases can be used only in a typical client/server mode when users connect to a Neo4j DBMS from their client application or tool via Bolt or HTTP protocol.

The main concepts that are relevant to understand when working with Composite databases are:

Expand Down
Loading