AWS ‐ Database Services ‐ RDS | DocumentDB | DynamoDB | ElastiCache | Keyspaces | Neptune | Quantum Ledger | Aurora | Redshift | Timestream

Relational Database

• Data is stored in a relationship structure
• Data stored in tables as Rows and Columns (property information about the row)
• Use SQL to access/query the data

Data Integrity

• Completeness of the data (you can define constraints such as firstname, lastname canot be null, so the consumer of the data will have complete information)
• Consistency - consumer can rely on the data
• Accuracy - defining data model, relationship properly

Database Transactions

• Collection of SQL statements processed in sequence
• All or None functionality - If all these statement executions are succeed then the changes are applied to the database, if any one statement is fail then no changes are applied.
• Db Transactions must be ACID
  • Atomic - entire execution of statements should be successful, not just part of it
  • Consistent - data written in db must adhere to all the rules and constraints defined
  • Isolation - transactions independent, doesnt rely on any other trnx for it to succeed
  • Durable - all the changes made to db are permanent

Amazon Relational Databases supported

• Amazon Aurora
• MariaDb
• MS SQL Server
• MySQL
• Oracle
• PostgreSQL

NoSQL (Non-Relational) Databases

• To support varied data model (unstructured schema)

• Used to store large amount of data - with less constraints

• Supports Flexible data models

• Provides Low latency - because less validations on the constraints and rules compared to relational database

• Scalability & Performance - less processing and validations, efficient to compress and store data

• Flexibility - stores different types of data

Types of NoSQL Database

• Key-Value
• DocumentDb
• Graph db
• Search db
• In-Memory db

Comparison between sql and nosql database

Database Consistency Models

DynamoDB

• NoSQL Db, boasts performance and scalability, it is fully managed

• It is serverless db, automatically scalable without worry about infra

• It supports strong consistency model

  • all writes are completed before any read operation is performed, all latest data is guaranteed to be returned
  • data is always upto date
  • it is more resource intensive, hence lower performance

• It also supports eventual consistency where you may not read the same data immediately after the write as there will be some delay

• Default: Eventual Consistency

• maximize performance of read operation

• may not capture recent writes, i.e when eventual consistency enabled, subsequent read operation does not guarantee the data of write operation, but it will be eventually available for sure (after few seconds), not immediately. So the read operation may return stale data due to this delay in write/update/delete opeartion

• Eventual consistency - is normal in scenarios where there is replication happen, multiple availability zones

• Supports Strong Consistent Read

• It can be deployed in single or multiple region (replication hapen accross region),

• It supports availability zone