Design your DynamoDB for your startup to get the most out of it
DynamoDB(DDB) is the number one choice of all startups who selects AWS as the cloud service provider. The number one reason for choosing DynamoDB(DDB) is you can be within the free tier for an entire year. In the very beginning, you are convinced that you don’t have to pay a single penny for your database for the whole first year. If you happen to select a SQL DB from AWS you are likely to pay hundreds of dollars per month.
Most of us are coming from SQL based databases. If you are coming from Couchbase or MongoDB still the mental model is very different.
DynamoDB(DDB) gives a fast and predictable performance. Which means you always have the same latency. You can get seamless scalability always if you design properly.
If you don’t design your DDB carefully, your DDB bill can go from 0$ to infinity as your startup grows.
Design your database according to your access patterns, not looking at your data relationships.
The way to design a good DDB is to list down all your access patterns. The most common mistake is trying to optimize infrequent access patterns. You have to decide between infrequent filter operations vs frequent GSI sync cost and GSI storage cost.
The rule of thumb is table scans are costly and should be avoided! Filter by SK(short key) is much performance because they are stored in the same partition so accessing SK for a particular PK(partition key) is very fast.
Unlike the base table, the GSIs can return multiple items for a given PK and SK. It could be a very smart idea to get the multiple items and then filter them through an expression until you get what you want.
Why are we talking about Schema
DDB is actually schema-less. But you are working with the cloud. Everything that you do has a cost. You have to design your schema to maximize the performance and minimize the throughput cost. This article is not about guiding you on how to design your schema. But will look into the many important aspects.
GSI overloading
You can go up to 25 GSI. But If u design your table carefully you will never go more than 5 or 6 GSIs most of the time. The caveat here is when you add a GSI it automatically duplicates your data and creates a new table. This consumes your WC. Most importantly you have to allocate RCU/WCU to your GSI separately. They don’t share with your base table. And it takes to storage cost as well. So you have to choose GSI wisely.
In your startup, you are more likely to maintain Dev, UAT, and Production environments. In that case, you will keep 3 DynamoDB tables for each environment. You get only 25 RCU in your free tier. If you have 3 GSIs, you can only allocate 2 RCU for each table/GSI.
- RCU for tables and GSI -> 3*3 = 9
- No of environments -> 9*3 = 27
Which means you can only allocate 2 RCUs for a table/GSI.
Have a good understanding of Indexes.
Revisit your access patterns. Evaluate if you any underutilized GSIs. Rethink how GSI, LSI, and sparse indexes can help you to reduce your cost and improve your performance.
AWS NoSQL Workbench is your new friend.
Many developers don’t know about this great tool. They keep using the traditional console UI for DDB. It is hard to get the overall picture of the DB using the console UI. Install the NoSQL workbench on your local machine and you can connect your DDB to this.
On behalf of team LiveRoom, written by Sashrika Waidyaratna
