Database systems and engines can be grouped into two broad categories: Relational Database Management Systems (RDBMS) and NoSQL (or non-relational) databases.
A relational database can be categorized as either an Online Transaction Processing (OLTP) or Online Analytical Processing (OLAP) database system, depending on how the tables are organized and how the application uses the relational database. OLTP refers to transactionoriented applications that are frequently writing and changing data (for example, data entry and e-commerce). OLAP is typically the domain of data warehouses and refers to reporting or analyzing large data sets. Large applications often have a mix of both OLTP and OLAP databases.
Amazon RDS provides support for six popular relational database engines: MySQL, Oracle, PostgreSQL, Microsoft SQL Server, MariaDB, and Amazon Aurora.
Data Warehouses is often a specialized type of relational database that can be used for reporting and analysis via OLAP.
Amazon Redshift is a high-performance data warehouse designed specifically for OLAP use cases.
A common use case for NoSQL is managing user session state, user profiles, shopping cart data, or time-series data.
Amazon Relational Database Service (Amazon RDS)
Amazon RDS does not provide shell access to Database (DB) Instances.
Amazon
RDS currently supports the following database engines: MySQL, PostgreSQL, MariaDB,Oracle, SQL Server, and Amazon Aurora.
Existing DB Instances can be changed or resized using the API ModifyDBInstance
AWS Database Migration Service also helps convert databases from one database engine to another.
For example with Amazon RDS, you cannot use Secure Shell (SSH) to log in to the host instance and install a custom piece of software. You can, however,
connect using SQL administrator tools or use DB option groups and DB parameter groups to change the behavior or feature configuration for a DB Instance.
If you want full control of the Operating System (OS) or require elevated permissions to run, then consider installing your database on Amazon EC2 instead of Amazon RDS.
Comparison of Operational Responsibilities
Database Engines
Amazon RDS supports six database engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora. Features and capabilities vary slightly depending on the engine that you select.
MySQL
The engine is running the open source Community Edition with InnoDB as the default and recommended database storage engine.
Amazon RDS MySQL supports Multi-AZ deployments for high availability and read replicas for horizontal scaling.
PostgreSQL
PostgreSQL also supports Multi-AZ deployment for high availability and read replicas for horizontal scaling.
MariaDB
Amazon RDS fully supports the XtraDB storage engine for MariaDB DB Instances and, like Amazon RDS MySQL and PostgreSQL, has support for Multi-AZ deployment and read replicas.
Oracle
Amazon RDS Oracle supports three different editions of the popular database engine:
Standard Edition One, Standard Edition, and Enterprise Edition.
Microsoft SQL Server
Amazon RDS SQL Server also supports four different editions of SQL Server: Express Edition,Web Edition, Standard Edition, and Enterprise Edition.
Licensing
AWS offers two licensing models: License Included and Bring Your Own License (BYOL).
Amazon Aurora
Amazon Aurora can deliver up to five times the performance of MySQL without requiring changes to most of your existing web applications.You can use
the same code, tools, and applications that you use with your existing MySQL databases with Amazon Aurora.
Storage Options
Amazon RDS is built using Amazon Elastic Block Store (Amazon EBS) and allows you to select the right storage option based on your performance and cost requirements.
you can scale up to 4 to 6TB in provisioned storage and up to 30,000 IOPS.
Amazon RDS supports three storage types: Magnetic, General Purpose(Solid State Drive [SSD]), and Provisioned IOPS (SSD).
Amazon RDS Storage Types
For most applications, General Purpose (SSD) is the best option and provides a good mix of lower-cost and higher-performance characteristics.
Backup and Recovery
Amazon RDS provides two mechanisms for backing up the database: automated backups and manual snapshots.
Each organization typically will define a Recovery Point Objective (RPO) and Recovery Time Objective (RTO).
It’s common for enterprise systems to have an RPO measured in minutes and an RTO measured in hours or even days.
RPO is defined as the maximum period of data loss that is acceptable in the event of a failure or incident.
RTO is defined as the maximum amount of downtime that is permitted to recover from
backup and to resume processing.
Automated Backups
Amazon RDS creates a storage volume snapshot of your DB Instance, backing up the entire DB Instance and not just individual databases.
you can modify the retention period up to a maximum of 35 days.Keep in mind
that when you delete a DB Instance, all automated backup snapshots are deleted and cannot be recovered. Manual snapshots, however, are not deleted.
Automated backups will occur daily during a configurable 30-minute maintenance window called the backup window.
Automated backups are kept for a configurable number of days, called the backup retention period.
manual DB snapshots are kept until you explicitly delete them with the Amazon RDS console or the DeleteDBSnapshot action.
For busy databases, use Multi-AZ to minimize the performance impact of a snapshot.
During the backup window, storage I/O may be suspended while your data is being
backed up, and you may experience elevated latency. This I/O suspension typically lasts for the duration of the snapshot. This period of I/O suspension is shorter for Multi-AZ DB deployments because the backup is taken from the standby, but latency can occur during the backup process.
You cannot restore from a DB snapshot to an existing DB Instance.
Multi-AZ deployments are available for all types of Amazon RDS database engines.When you create a Multi-AZ DB Instance, a primary instance is created in one Availability Zone and a secondary instance is created in another Availability Zone.
Amazon RDS will automatically fail over to the standby instance without user intervention.The DNS name remains the same,but the Amazon RDS service changes the CNAME to point to the standby.
It is important to remember that Multi-AZ deployments are for disaster recovery
only; they are not meant to enhance database performance. The standby DB Instance is not available to offline queries from the primary master DB Instance. To improve
database performance using multiple DB Instances, use read replicas or other DB
caching technologies such as Amazon ElastiCache.
Scaling Up and Out
Vertical Scalability
Adding additional compute, memory, or storage resources to your database allows you to process more transactions, run more queries, and store more data.
Horizontal Scalability with Partitioning
A relational database can be scaled vertically only so much before you reach the maximum instance size. Partitioning a large relational database into multiple instances or shards is a common technique for handling more requests beyond the capabilities of a single instance.
Horizontal Scalability with Read Replicas
There are a variety of use cases where deploying one or more read replica DB Instances is helpful. Some common scenarios include:
Scale beyond the capacity of a single DB Instance for read-heavy workloads.
Handle read traffic while the source DB Instance is unavailable. For example, due to I/O
suspension for backups or scheduled maintenance, you can direct read traffic to a replica.
Offload reporting or data warehousing scenarios against a replica instead of the primary
DB Instance.
You can create one or more replicas of a database within a single AWS Region or
across multiple AWS Regions. To enhance your disaster recovery capabilities or reduce
global latencies, you can use cross-region read replicas to serve read traffic from a region closest to your global users or migrate your databases across AWS Regions.
Security
All logs, backups, and snapshots are encrypted for an encrypted Amazon RDS instance.