Differences Between Relational Data Design and NoSQL
Relational database systems (RDBMS) and NoSQL databases have different strengths and weaknesses:
In RDBMS, data can be queried flexibly, but queries are relatively expensive and don’t scale well in high-traffic situations (see First Steps for Modeling Relational Data in DynamoDB).
In a NoSQL database such as DynamoDB, data can be queried efficiently in a limited number of ways, outside of which queries can be expensive and slow.
These differences make database design very different between the two systems:
In RDBMS, you design for flexibility without worrying about implementation details or performance. Query optimization generally doesn’t affect schema design, but normalization is very important.
In DynamoDB, you design your schema specifically to make the most common and important queries as fast and as inexpensive as possible. Your data structures are tailored to the specific requirements of your business use cases.
Two Key Concepts for NoSQL Design
NoSQL design requires a different mindset than RDBMS design. For an RDBMS, you can go ahead and create a normalized data model without thinking about access patterns. You can then extend it later when new questions and query requirements arise. You can organize each type of data into its own table.
NoSQL design is different:
For DynamoDB, by contrast, you shouldn’t start designing your schema until you know the questions it will need to answer. Understanding the business problems and the application use cases up front is essential.
You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.
Approaching NoSQL Design
The first step in designing your DynamoDB application is to identify the specific query patterns that the system must satisfy.
In particular, it is important to understand three fundamental properties of your application’s access patterns before you begin:
Data size: Knowing how much data will be stored and requested at one time will help determine the most effective way to partition the data.
Data shape: Instead of reshaping data when a query is processed (as an RDBMS system does), a NoSQL database organizes data so that its shape in the database corresponds with what will be queried. This is a key factor in increasing speed and scalability.
Data velocity: DynamoDB scales by increasing the number of physical partitions that are available to process queries, and by efficiently distributing data across those partitions. Knowing in advance what the peak query loads might be helps determine how to partition data to best use I/O capacity.
The serverless world is pretty awesome once you find the right tools — and burn the middle layer to the ground
The true magic of SPAs is when you “deploy” an application, you’re simply copying index.html, bundle.js, and a handful of file dependencies to an S3 bucket front-ended by a CloudFront distribution. This gives you rock-steady distribution and loading behavior, and also enables multi-version management and any deployment methodology you prefer — just by managing text files.
.. In many respects, the hardest part of getting to serverless has been truly coming to grips with DynamoDB. You definitely make a few mistakes in the first few iterations, and its tempting to ditch the whole thing and go back to RDS where everything is known and comfortable.
SQL has been my crutch for a long time, and I’ll confess to putting way too much business logic into databases. But RDMS systems are just another monolith — failing to scale well and they don’t support the idea of organically evolving agile systems.
.. DynamoDB is a completely different animal. When you get it right, the NoSQL database provides blistering performance, massive scale, and practically no administrative overhead. But you really have to invest the time in exploring how it works — and the initial phases are full of gotchas aplenty.
.. You need to understand the way DynamoDB works, spend some time to understand indexing strategies, and how you intend to query the data. It’s very easy to jump into it without knowing all you need to know, so many people get burned and then move back to RDMS at exactly the wrong moment. Make mistakes and push through them.
One of the least-discussed joys of DynamoDB is the way you can attach code to table events using streams — like an SQL trigger that can do anything. These are extremely powerful.
.. My early experimentation with Lambda was a clunky affair of coding directly into the AWS console and getting frustrated that it took a lot of work and error messages to do some trivial things. The bridge that connects your IDE to a production environment is missing.
Well, its’ missing until you discover serverless framework which is honestly the most exciting thing I’ve found in ages.
.. cost 70–90% less.