Examples for DynamoDB Materialized Graph Pattern

Question

I started looking into DynamoDB, but got stuck reading this part about the materialized graph pattern: Best Practices for Managing Many-to-Many Relationships.

I guess I get some ideas, but don't understand the whole thing yet. As far as I understand the pattern the main table stores edges and each edge can have properties (the data-attribute).

For example (taken from the shown tables): Node 1 (PK 1) has an edge to Node 2 which is of type DATE, and the edge is of type BIRTH (SK DATE|2|BIRTH).

I guess this would somewhat be the same as ()-[:BIRTH]->(:DATE { id: 2 }) in Cipher, right?

But after this it becomes unclear how everything fits together. For example:

1. Can the data attribute be a map?
2. Does the data attribute have to be written to two places on writes? E.g. under (1, DATE|2|BIRTH) and (2, DATE|2)?
3. If I want to add a new person that is born 1980-12-19, do I have to look up the corresponding node first?
4. How can I get all properties associated with a node? How to get all properties associated with an edge?
5. How can I query adjacent nodes?
6. ...

Can someone explain to me how everything fits together by walking through a few use cases?

Thanks in advance.

Answer 1

Hopefully this answers all of your questions. Here's a couple of introductory things. I'll be using a generic table for all of my examples. The hash key is node_a and the sort key is node_b. There is a reverse lookup GSI where node_b is the hash key and node_a is the sort key.

1. Can the data attribute be a map?

The data attribute can be any of the supported data types in DynamoDB, including a map.

2. Does the data attribute have to be written to two places on writes?

The data attribute should be written to only one place. For the example of birthdate, you could do either one of these DynamoDB entries:

node_a    | node_b    | data
----------|-----------|---------------
user-1    | user-1    | {"birthdate":"2000-01-01", "firstname": "Bob", ...}
user-1    | birthdate | 2000-01-01

In the first row, we created an edge from the user-1 node that loops back on itself. In the second row, we created an edge from user-1 to birthdate. Either way is fine, and the best choice depends on how you will be accessing your data. If you need to be able to find users with a birthdate in a given range, then you should create a birthdate node. If you just need to look up a user's information from their user ID, then you can user either strategy, but the first row will usually be a more efficient use of your table's throughput.

3. If I want to add a new person that is born 1980-12-19, do I have to look up the corresponding node first?

No. Just insert one of the rows from the example above.

You only have to look up the node if there is a more complex access pattern, such as "update the name of the person who was born on 1980-12-19". In that case, you would need to look up by birthdate to get the person node, and then modify something related to the person node. However, that use case is really two different operations. You can rephrase that sentence as "Find the person who was born on 1980-12-19, and update the name", which makes the two operations more apparent.

4.(a) How can I get all properties associated with a node?

Suppose you want to find all the edges for "myNode". You would query the main table with the key condition expression of node_a="myNode" and query the reverse lookup GSI with the key condition expression of node_b="myNode". This is the equivalent of SELECT * FROM my_table WHERE node_a="myNode" OR node_b="myNode".

4.(b) How to get all properties associated with an edge?

All of the properties of an edge are stored directly in the attributes of the edge, but you may still run into a situation where you don't know exactly where the data is. For example:

node_a    | node_b    | data
----------|-----------|---------------
thing-1   | thing-2   | Is the data here?
thing-2   | thing-1   | Or here?

If you know the ordering of the edge nodes (ie. which node is node_a and node_b) then you need only one GetItem operation to retrieve the data. If you don't know which order the nodes are in, then you can use BatchGetItems to look up both of the rows in the table (only one of the rows should exist unless you're doing something particularly complex involving a directed graph).

5. How can I query adjacent nodes?

Adjacent nodes are simply two nodes that have an edge connecting them. You would use the same query as 4a, except that instead of being interested in the data attribute, you're interested in the IDs of the other nodes.

Some more examples

• Using a graph pattern to model a simple social network
• Using a graph pattern to model user-owned resources
• How to model a circular relationship between actors and films in DynamoDB (answer uses a graph pattern)
• Modeling many-to-many relationships in DynamoDB
• From relational DB to single DynamoDB table: a step-by-step exploration. This is a killer piece. It's got an AWS re:Invent talk embedded in it, and the author of this blog post adds his own further explanation on top of it.