Databases Flashcards
Which RDS databases can be configured as multi-AZ or single-AZ?
- SQLServer
- Oracle
- MySQL
- PostgreSQL
- MariaBD
Which RDS database is always multi-AZ?
Amazon Aurora
Advantages of RDS?
- up and running in minutes (not days)
- multi-AZ
- failover capability
- automated backups
When do we use RDS?
- for online transaction processing (OTP)*
- for customer orders
- for completing large numbers of small transactions in real time
When don’t we want to use RDS?
- OLAP (Online Analytical Processing)
- complex queries
- large amounts of data
- data analysis
Instead, use a data warehouse like Redshift, which is optimized for Online Analytics Processing
How does Multi-AZ RDS work?
- creates an exact copy of your production database in another AZ
- AWS handles the replication for you
What happens in RDS with an Unplanned Failure or maintenance?
- If AWS notices that you lose your primary DB, there is an automatic failover by updating the DNS to point to the secondary DB
What is Multi-AZ for?**
- disaster recovery
- NOT improving performance
What are Read Replicas for?
- for improving performance
- a read-only copy of your database
- for querying and read-heavy workloads
- NOT for DR
Can Read Replicas be Multi-AZ?
Yes,
- can be in different regions
How many read replicas can you have per DB?
5
Read Replica basics
- a read-only copy of your primary DB in the same AZ, cross-AZ, or cross-region
- used to increase or scale read performance
- great for read-heavy workloads
- takes the load off your primary DB
What is Amazon Aurora?
- Amazon’s proprietary DB
- MySQL & PostgreSQL
- combines speed & availability at a low price point
How much faster is Aurora than mySQL or PostgreSQL?
- 5x faster than mySQL
- 3x faster than PostgreSQL
Aurora Basics
- Storage Auto Scaling - starts with 10 GB. Scales in 10 GB increments up to 128 TB.
- Compute can scale up to 96 vCPUs and 768 GB of memory.
How redundant is Aurora?*
2 copies of your data are stored in each AZ, with a minimum of 3 AZs
- it’s really redundant
Scaling Aurora
it’s designed to transparently handle the loss of 2 copies of data w/o affecting database write availability and 3 copies of data w/o affecting read availability
How is Aurora self-healing?*
- Aurora data blocks and disks are continuously scanned for errors and repaired automatically
Aurora Replica limits by type*
Aurora Replicas - up to 15 Aurora replicas
- MYSQL Replicas - up to 5 read replicas
- PostGres Replicas - up to 5 read replicas
Aurora Backups*
- automated backups always enabled
- backups do not impact database performance
- can take snapshots (does not impact performance)
- can share snapshots with other AWS accounts
Aurora Serverless *
- on demand
- auto-scaling
- for the MySQL and PostGres editions of Aurora
- automatically starts up, shuts down, scales capacity up and down
What is Aurora Serverless for?
- infrequent, intermittent, unpredictable workloads
- for questions on exam where you need the performance of Aurora but have spiky workloads
Dynamo DB
- Fully managed
- A fast & flexible noSQL database for all applications that need consistent, single-digit-millisecond latency at any scale
- Supports document and key-value data models
Dynamo DB use cases
- mobile
- web
- gaming
- ad-tech
- IoT, etc.
Dynamo Facts
- stored on SSD storage
- spread across 3 geographically distinct data centers
- eventually consistent reads (by default)
- strongly consistent reads (as an option)
Eventually Consistent Reads *
consistency between all copies of the database is achieved within 1 second
Strongly Consistent Reads *
returns a result that reflects all writes that received a successful response prior to the read.
Dynamo DB Accelerator (DAX)
- fully managed, highly available, in-memory cache
- 10x performance improvement
- reduces request time from milliseconds to microseconds, even under load
- no need for developers to manage caching logic
- compatible with Dynamo Db API calls
Dynamo DB On-Demand Capacity
- pay-per-request pricing
- balances cost & performance
- pay more per request than with provisioned capacity
- use for new product launches
Dynamo Security
- encryption at rest with KMS
- site-to-site VPN
- DirectConnect (DX)
- IAM policies and roles
- fine-grained access
- Cloud Watch & Cloud Trail
- VPC endpoints
Dynamo DB Transactions *
ACID:
- Atomic - all changes to the DB must be performed successfully, or not at all
- Consistent - data must be in a consistent state before and after the transaction
- Isolated - No other processes can change the data while the transaction is running
- Durable - the changes made by a transaction must persist.
How do you use ACID w/ Dynamo DB?
- by using transactions
- transactions provide atomicity, consistency, isolation and durability across 1 or more tables within a single AWS account or region
Use Cases for Transactions in DynamoDB*
- apps that need coordinated inserts, deletes or updates to multiple items as part of a single logical business operation
- financial transactions, managing orders
- building multi-player game engines
- coordinating actions across distributed services
- up to 25 items or 4 MB of data per transaction
What does ACID boil down to?*
All or nothing. No partially successful updates.
3 options for reads
- eventual consistency
- strong consistency
- transactional
2 options for writes:
- standard
- transactional
Dynamo On-Demand Backup & Restore
- full backups at any time
- zero impact on table performance or availability
- consistent w/i seconds & retained until deleted
- operates in the same region as the source table
Dynamo Point in Time Recovery (PITR)
- restore to any point in the last 35 days
- incremental backups
- not turned on by default
- latest restorable point - 5 minutes in the past
Dynamo DB Streams
- time-ordered sequence of item-level changes in a table
- FIFO
- every time your data changes it comes w/ a sequence number
- for inserts, updates and deletes
- stored for 24 hours
- broken into shards
- can combine Lambda functions for functionality like stored procedures
Shards
collections of stream records with sequential numbers
Dynamo Global Tables
a way of replicating your Dynamo DB tables from one region to another
- managed multi-master, multi-region replication
- great for globally distributed applications*
- based on Dynamo DB streams (must be enabled to use Global tables)
- multi-region redundancy for recovery or high availability*
- no need to re-write your app, just go into the console and turn it on*
- replication latency under 1 second
