70 %

Adjacency lists in Dynamodb

One interesting approach to DynamoDB that departs from typical data storage patterns is the idea of an Adjacency List pattern. In short, this is the idea that you can put a lot of different data types in the same DynamoDB table, whereas in SQL land you might use a set of different tables. This is enabled by the fact that you can store arbitrary bags of data in a DynamoDB "row" without affecting the schema of other items.

Generic keys

We'll talk about the data format using JS object notation, since that is familiar and accessible to many people. We can think of an item in our table as an object with the following keys and datatypes.

JS
{
pk: '',
sk: '',
data: {}
}

That is, we have a pk, an sk, and some data which are strings and an object respectively. The pk and sk combine to form the uniqueness constraint on our entire table. The letters stand for Partition Key and Sort Key. The Partition Key is the value DynamoDB uses to distribute writes to shards. If this is the same value, you could end up getting your throughput throttled because all the writes go to the same shard. (More on this in another post).

pkskdata