CODEWITHSUNDEEP
nosqlamazon-dynamodbpartitioning
Alok Sharma
Alok Sharma

Reputation: 303

NoSQL database design using single table

How satisfied are you with the statement "You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table." ?

I have listed down my use cases for a NoSQL design but restricting myself for a single table design makes the design complex and requires every developer working with NoSQL table to understand the logical complexity adhering to principles of partitioning and performance gain. just to write few my app do following things :

  1. Register a user account with mobile device.
  2. Allow multiple users to check their account on any mobile device having the app installed on it.
  3. Logs user activities which could go from 10 to 1000 in a day per user.
  4. There is a batch job which periodically checks if any user account get updates then it sends the notification on all devices which have been logged in by the user ( as the last logged user on device ).
  5. Ofcourse these FCM notifications are based on user preferences for notifications.
  6. And at last the user account is hinged around a unique email address and the user can have updates to all other attributes of his account from any device.

I found the batch processing job which periodically scans the whole table forcing me to create a second table so that I can spawn as many threads to process the row(s).

How can I make this all fit in a single table ?

Upvotes: 3

Views: 1573

Answers (1)

Ant Stanley
Ant Stanley

Reputation: 76

So this is all Rick Houlihan's fault. He's a Principal Engineer at AWS, focusing on DynamoDB.

So the opening statement that most well design applications only require one table, but what is missing is the design guidance on how you should structure your table to be effective.

For single table design in your example you would want a partition per device and a partition per user, which you would write the relevant information per device or per user too. You would mix and match this all in your single table. You would use global secondary indexes to retrieve the relevant data, but that index design would be dependent on your access patterns.

Essentially the way you model your data for a single table design is completely different to an RDBMS, so you need to throw everything you knew out the window and learn it all again.

I recommend reading these blog posts

and watching Rick's reInvent session on it multiple times... typically by about the 10th time light bulbs start going off...

Rick's DynamoDB Advanced Design Patterns talk - https://www.youtube.com/watch?v=6yqfmXiZTlM

There is a fair amount of depth to it. Good luck!

Upvotes: 2

Related Questions