DynamoDB scales by breaking data into 'shards' across different servers automatically, allowing it to scale beyond the bounds of a single server seamlessly. With flexible access patterns, though, can come a performance impact, as these complex queries can be slow to run ( read more here).Īnother key difference is that relational databases are traditionally designed to run on a single server, and scaling beyond a single server's capacity can be an involved process. You can instead use tools like SQL joins to query for whatever combination of data your application needs. With relational databases, you do not need to consider access patterns ahead of time. When working with a NoSQL database, it's important to plan your application's data access patterns and design your tables around them. NoSQL databases are optimized to query for items by a known key ('Get me user Emily's email and phone number'). Many people are more familiar with relational (or SQL) databases, and there are some important differences between NoSQL and relational databases. relational databasesĭynamoDB is a serverless NoSQL database. Once I had a more complex database requirements like storing, querying, and updating subscriber data, I began using DynamoDB. In the earliest version of the app, the only data I stored was vocabulary words in a CSV file in Amazon S3.
The database architecture of my daily Chinese vocab app has evolved over time.
#Dynamodb table example code
Look out for part 2 where I cover migrating to the new data model and code changes to interact with it! Jump to: In this post, I explain why I chose single-table design, the resources I used to learn it, and walk through the design process and a few example access patterns. This blog post is part 1 in a series on refactoring my daily Chinese vocab app to a single-table design in Amazon DynamoDB.
0 kommentar(er)
