Service - Graph Handler: Difference between revisions
No edit summary |
|||
| Line 1: | Line 1: | ||
= Overview = | = Overview = | ||
Service that manages a graph database, intended to be deployed any number of times, each instance managing one graph within a project. Most relationships will be stored | Service that manages a graph database, intended to be deployed any number of times, each instance managing one graph within a project. Most project relationships will be stored in graphs, other services can duplicate subsets of relationship data or element data if they choose or can use the graphs as their store. | ||
As the project grows relationship data can be extended to allow for analysis of relationships, weighting same type connections etc.. | As the project grows relationship data can be extended to allow for analysis of relationships, weighting same type connections etc.. | ||
Use standardized labeling of nodes to allow graphs to be merged or connected later. | |||
= Repository = | = Repository = | ||
| Line 9: | Line 11: | ||
https://bitbucket.org/stb_working/graph-handler/src/master/ | https://bitbucket.org/stb_working/graph-handler/src/master/ | ||
= | = Neo4j graph = | ||
Scales well with a large number of node labels / relationship types. | |||
= DynamoDB tables = | = DynamoDB tables = | ||
| Line 23: | Line 25: | ||
= Query language = | = Query language = | ||
Focus on using | Focus on using Cypher. | ||
== | = Querying data in graph database = | ||
Planning all Put/Update/Delete/CRUD queries to pass through an API/Graph Handler Lambda functions. | |||
Read/Get queries could query the graph directly using eg IAM constraints/throttling, but currently unable to lock the EC2 on a private server and allow Lambda's outside of the VPC to access the database, so all requests will pass through Graph Handler Lambda functions until infrastructure allows for a better design. | |||
= Working documents = | = Working documents = | ||
Revision as of 12:18, 15 May 2021
Overview
Service that manages a graph database, intended to be deployed any number of times, each instance managing one graph within a project. Most project relationships will be stored in graphs, other services can duplicate subsets of relationship data or element data if they choose or can use the graphs as their store.
As the project grows relationship data can be extended to allow for analysis of relationships, weighting same type connections etc..
Use standardized labeling of nodes to allow graphs to be merged or connected later.
Repository
https://bitbucket.org/stb_working/graph-handler/src/master/
Neo4j graph
Scales well with a large number of node labels / relationship types.
DynamoDB tables
Standard Config Table Per Service
Configuration tags
...
Query language
Focus on using Cypher.
Querying data in graph database
Planning all Put/Update/Delete/CRUD queries to pass through an API/Graph Handler Lambda functions.
Read/Get queries could query the graph directly using eg IAM constraints/throttling, but currently unable to lock the EC2 on a private server and allow Lambda's outside of the VPC to access the database, so all requests will pass through Graph Handler Lambda functions until infrastructure allows for a better design.