Non-relational databases store data without a fixed structure, making them flexible for unstructured or changing data.
DynamoDB is a non-relational, NoSQL database. It has millisecond response time. It's fully managed, so it's highly available and scalable by default.
So we've just learnt that relational databases require well defined relationships and the use of SQL to query the data.
This works great for a lot of use cases, and has been the standard type of database historically.
However, these types of rigid SQL databases can have performance and scaling issues when under stress.
The rigid schema* also means you cannot have any variation in the types of data that you store in a table.
*Schema refers to how data is organised in a database! In a relational database, the schema is rigid because you define the exact data format (e.g. numbers, dates, words) and other rules.
Hmmm, this means relational databases might not be the best fit for a data that's a bit less rigid, and is being accessed at a very high rate.
Non-relational databases are use structures other than rows and columns to organise data.
They're sometimes referred to as “NoSQL databases” because of this! So in general, you would not use SQL in a non-relational database. SQL is specifically designed for relational databases, which have a structured table-like format.
Non-relational databases tend to have simple flexible schemas.
One type of structural approach for non-relational databases is key-value pairs.
With key-value pairs, data is organised into items (keys), and items have attributes (values).
For example, you can have a key value pair called "Item name:quantity". Here, the item name is the key, and the quantity is the value. A key-value pair like "Biscuits:5" would mean there are 5 biscuits recorded in the database.
In a key-value database, you can add or remove attributes from items in the table at any time. Not every item in the table has to have the same attributes. Voila - a super flexible database!
Remember the customer record example from the previous topic? Let's have a look at what it'd look like if it was a non-relational database. Notice how we can record Amber's phone number, but not have that in Bruno's record:
Amazon DynamoDB
DynamoDB is Amazon's non-relational database service. Because it is non-relational, it can also be described as a NoSQL database, or a key-value database.
Why we love DynamoDB
DynamoDB is a serverless database, meaning you don't need to manage any underlying servers powering it. You also don't have to install or maintain the database software itself!
Whether you have one item in your table, or 2 million items in your table, DynamoDB manages the underlying storage and scaling for you.
DynamoDB stores identical copies of your data across Availability Zones for you. You won't need to worry about the complex and time-consuming task of managing data availability yourself!
DynamoDB has a millisecond response time (i.e. it reacts to your requests and starts giving you answers in milliseconds), making it a great option for use cases that require high performance while scaling.
When you have applications with potentially millions of users, having scalability and reliable lightning fast response times is important.
One awesome example is on Amazon's Prime Day in 2019, which was a massive virtual event. There were 7.11 trillion calls to the DynamoDB API, peaking at 45.4 million requests per second! That's insanely scalable, all without the underlying database management.
Key facts to know
You can add and remove attributes from items in the table at any time.
Not every item in the table has to have the same attributes.
This flexility is great for datasets that have some variation from item to item.
DynamoDB offers both encryption at rest and in transit
Queries for DynamoDB data are not SQL queries. DynamoDB queries are simpler.
They focus on a collection of items from one table instead of queries that span multiple tables.
This query pattern, along with other factors (e.g. the way that the underlying system is designed) allows DynamoDB to be very quick in response time, and highly scalable.
Bonus: RDS vs DynamoDB 🥊🤺
In the exciting world of cloud databases, we have two contenders ready to compete for your data management needs: Amazon RDS and Amazon DynamoDB! Once you understand your specific needs, you will know which service is your fighter.
RDS 🥊
In the relational corner, we have Amazon RDS, a heavyweight champion engineered for your complex data needs.
It's built for business analytics and complex relational joins. This makes it perfect for businesses that need to analyse complex data scattered across multiple tables, such as a sales and supply chain management system.
Automatic high availability and recovery provided.
You control the data, schema and network.
DynamoDB 🤺
In the NoSQL corner, we have Amazon DynamoDB, a powerful, lightning-fast solution. DynamoDB excels in scenarios where complex relationships are not the primary focus.
Requires no advanced schema (i.e. simplifies your database structure)
Operates as a global database at the touch of a button.
Has massive throughput i.e. it can handle a huge amount of data requests very quickly.
Has petabyte scale potential. 1 petabyte (PB) = 1 million gigabytes (GB)! Well, it's 1,024,000 GB if we want to be specific. 😉
Who's your fighter?
The champion you should choose depends on your specific workload and requirements.
Amazon RDS shines in situations that need data analysis and complex relationships.
Amazon DynamoDB is the champion for any other situation - where simplicity and speed is more important.
Most people use expensive relational databases for situations that have nothing to do with complex relationships. In fact, a lot of what people put into these databases ends up just being simple tables.
For example, if you have a use case like an employee contact list with names, phone numbers, emails, and employee IDs, DynamoDB delivers the knockout punch. There's no need to use a relational database if you don't need the complex data analytics, and DynamoDB removes all the overhead of managing a database too.
