Skip to content
Snippets Groups Projects
Commit 90713cd1 authored by Malte Bauch's avatar Malte Bauch
Browse files

Update 05-implementation.md

adding neo4j
parent 43141bd7
No related branches found
No related tags found
3 merge requests!90Develop,!62Resolve "Update database in order to achieve the long-term goals of the project",!53V.0.1.0 Codename Threadbare
Pipeline #52333 canceled
This commit is part of merge request !53. Comments created here will be created in the context of that merge request.
......@@ -71,6 +71,49 @@ There may be the potential need to store information beyond pure topologies,
actually about network flows, i.e., information about a group of packets
belonging together.
### neo4j
Due to the fact that network topologies, with all their elements and connections,
can be represented well by a graph, the choice of a graph database for persistence was obvious.
After some initial experiments with RedisGraph, Neo4j was chosen,
because Neo4j allows the use of multiple labels (for nodes as well as edges)
and offers a wider range of plugins.
The current implementation offers the possibility to persist different network elements
and their physical topology. It became clear that within the graph database one has to
move away from the basic idea of different independent graphs (topologies) and rather see
the whole construct as a single huge graph with a multitude of relations.
The following figure shows our first idea of a persistence of network topologies with neo4j.
```mermaid
graph TD
subgraph "representation in Database"
PND[PND 1]
A --> |belongs to| PND
B --> |belongs to| PND
C --> |belongs to| PND
D --> |belongs to| PND
E --> |belongs to| PND
A[Node 1] --> |physical| B[Node 2]
D[Node 4] --> |physical| B
B --> |physical| C[Node 3]
B --> |physical| E[Node 5]
A --> |logical1| B
B --> |logical1| C
C --> |logical1| D
D --> |logical1| E
E --> |logical1| A
end
```
The basic idea is to assign the different network elements to a specific Principal Network Domain (PND).
The different topologies are represented by a neo4j relationship between the network elements that are
stored as neo4j nodes. However, with this current variant it is not possible, as required in
[Topology Inventory](#topology-inventory), to represent topologies that are hierarchically
interdependent, since neo4j does not allow relations to be stored as properties (as described [here](https://neo4j.com/docs/cypher-manual/current/syntax/values/#structural-types)
## YANG to code
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment