Google Cloud SQL & AWS RDS
Google Cloud SQL & AWS RDS
Here is a quick recap of the main functionalities of both products:
Functionality
|
AWS RDS
|
Cloud SQL
|
---|---|---|
CPU & RAM
|
RDS supports three types of instance classes: Standard, Memory Optimized, and Burstable Performance.
|
Cloud SQL is divided into shared-core, standard and high memory machines.
|
Types of Storage
|
General Purpose SSD, Provioned IOPS (SSD) and Magnetic
|
Supports both SSD and HDD (magnetic)
|
IOPS ratio (SSD)
|
General Purpose (SSD) has the ability to burst to 3,000 IOPS for extended periods of time. Baseline performance for these volumes is determined by the volume's size. Baseline is 3 IOPS per GiB.
|
SSD provides IOPS gurantee in a 30:1 ratio. The included 100-GB gurantees for 3000 IOPS. SSDs are preferred over HDD, as it provides lower latency and higher data throughput.
|
Scaling options
|
Allocated storage can be scaled or converted to another storage type (General SSD to PIOPS SSD). During the scaling process, the DB instance is available for use but might experience performance degradation.
|
Automatic storage increase can be enabled in cloud SQL. This automatically increases the storage, if the allocated storage is filled. Storage scaling does not cause any downtime.
|
Failover Possible
|
YES
|
YES
|
Jargon
|
It is called Multi-AZ deployment. Deploys the stand-by instance to a different availability zone in the same region.
|
Failover Replica. This replica is placed in a different zone within the same region.
|
Replication Technology
|
The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy, eliminate I/O freezes, and minimize latency spikes during system backups.
|
Semi-Synchronous replication is implemented. This is better than synchronous replication in AWS & Azure. To understand the various types of replication, refer https://goo.gl/2CW2st. Stand-by instance is required.
|
Advantages
|
RDS instances switches to stand-by during palnned maintenance, software patches which ensures no downtime during system maintenance.
|
Failover replica can be used as read replica. Semi-Synchronous is better than synchronous replication as the performance impact/cost is greater in the later.
|
Dis-Advanatages
|
DB instances using Multi-AZ deployments may have increased write and commit latency compared to a Single-AZ deployment, due to the synchronous data replication that occurs.
|
Performance impact due to semi-synchronous replication, but better than the AWS & Azure's counterparts.
|
Cross-Region read replica (Useful for Global scale out, Disaster recovery, migration)
|
Possible
|
Not Possible
|
Max.No.of Read replicas
|
5
|
Not mentioned
|
High Availabilty of Read Replica (Deploying a standBy replica in a different zone)
|
Possible. This is independent of Master DB instance's high availability.
|
No High availability for read replica
|
Manual Backup (DB snapshots can be created anytime manually)
|
Possible
|
Possible
|
Applicable Backup Retention Period
|
1 to 35 days
|
Life-time of DB. (Doubtful though, I could not find any resource to prove this point)
|
Advantages
|
Free backup storage up to the size of the database. For eg: 100 GB of database storage/M, will provide 100 GB/M of backup storage at no additional charge.
|
Backup retention period is life-time (Not sure, though)
|
Comments
Post a Comment