|
|
| (4 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| = Overview = | | = removed = |
|
| |
|
| Service that manages a project level graph database that records relationships. Most relationships will be stored here, other services can duplicate relationship data if they choose or can use this graph as their source.
| | Can delete this page once confident all links and previous edits have been updated elsewhere |
| | |
| As the project grows relationship data can be extended to allow for analysis of relationships, weighting same type connections etc..
| |
| | |
| = Repository =
| |
| | |
| https://bitbucket.org/stb_working/project-graph/src/master/
| |
| | |
| = Neptune graph =
| |
| | |
| (planning on one single linked property graph)
| |
| | |
| = DynamoDB tables =
| |
| | |
| == [[Standard Config Table Per Service]] ==
| |
| | |
| === Configuration tags ===
| |
| | |
| ...
| |
| | |
| = Property Graph =
| |
| | |
| == Comparison with RDF ==
| |
| | |
| Property Graph was chosen over RDF because connectivity with external services is not a priority, and can be extracted from a Property Graph. The expected design will have a lot of relationships (predicates) that themselves have properties. Also queries and visualizing the projects objects into a Property Graph seems simpler than using an RDF.
| |
| | |
| = Query language =
| |
| | |
| Focus on using Apache TinkerPop Gremlin for queries as it is the standard used by AWS Neptune for Property Graphs.
| |
| | |
| = Querying data in graph database =
| |
| | |
| Planning all Put/Update/Delete queries to pass through an API/Lambda, however Read/Get queries are able to query the graph directly.
| |
| | |
| = Working documents =
| |
| | |
| [[:Category:Working_documents - Project Graph|Working_documents - Project Graph]]
| |
| | |
| [[Category:Backend services| Project Graph]]
| |
Latest revision as of 02:47, 1 March 2021
removed
Can delete this page once confident all links and previous edits have been updated elsewhere