When leveraging multiple access patterns

Photo by LinkedIn Sales Navigator on Unsplash

Initializing Situation …

When designing a NoSQL database model, there are a few things that you need to pay attention to, to make sure that your design will be able to fully fulfill your product requirements. When it comes to non-relational data stores, access patterns are at the center of it, which means, you have to make sure that the data model can actually answer ALL questions you may ask of your solution. This is very important. There are several solutions that you can go for, but for this particular case, we’ll focus on AWS DynamoDB.

DynamoDB does allow for indexing, which at a high level is a way to introduce new access patterns to your model. But why do we even need them? Let’s cover some basics first, DynamoDB tables have 2 special fields: a primary/partition key and a secondary/sort key. The combination of these two fields must be unique for every single record. There are 2 ways to read data from a DynamoDB table:

• Scan: Iterate through all the data. Ideal for bulk workloads like migration tasks, but not end-user queries.
• Query: Retrieve specific records by providing the full partition key and an optional sort key. Ideal for end-users performing normal “OLTP-type” tasks.

This gets limiting pretty quickly (querying based on 2 fields) and that’s why DynamoDB introduces Secondary Indexes to enrich access patterns. There are 2 types:

• Local Secondary Index: same partition key as table but different sort key
• Global Secondary Index: Different partition key from table while the sort key could be the same or different.

#cloud-computing #dynamodb #serverless #aws #nosql