Google Spanner vs Amazon Aurora: Who’ll Get the Enterprise?
https://www.clustrix.com/bettersql/spanner-vs-aurora/
Google Spanner versus Amazon Aurora
In July 2015, Amazon delivered Aurora, the AWS-only Enterprise RDBMS they’d been claiming since November 2014 would have “5x Enterprise performance at 1/5 the price.” Amazon was making a big play in the MySQL market—they’d recognized that there is a lot of demand for scaling MySQL workloads, and that Enterprises would be willing to pay for it. MySQL has always been considered great for startups, i.e., small to medium-sized companies, but the received wisdom is that “true Enterprise deployments” inevitably needed to migrate to SQL Server or Oracle RDBMS. Instead, Amazon is firmly putting their foot down and saying, “there is definitely an Enterprise-level market for MySQL-compatible databases,” one which demands Enterprise-grade features and availability, and of course Enterprise-grade scale and performance. Newly released Google Spanner challenges this "Enterprise performance" promise of Aurora.
Aurora: Enterprise Features for MySQL Workloads
Feature-wise, Aurora was designed for Enterprise-level HA, utilizing quorum writes and reads across 3 AWS Availability Zones, with a promised 4x 9s uptime. But it’s Aurora’s performance that has always been its biggest selling factor: “5x Enterprise performance” is the claim. However, once actual customers got their hands on Aurora, the reality is a bit more pedestrian: Aurora is still based on MySQL single-master/multiple-slave architecture. In other words, Aurora’s write performance is hard-limited to the largest single instance that can be deployed on AWS, which at this time is a 32-core (vcpu) 8XL. So what are the multi-AZ ‘quorum writes’ doing? Actually, the multiple AZs are designed for HA; the writes are not scaled-out, but are instead redundant. Having additional AZs to write to doesn’t speed up Aurora, but in fact represents a performance hit in their quest for HA. Correspondingly, Aurora claws back performance by leveraging ‘durability by network’ when they write to each of those AZs, which in turn can have durability considerations in a multi-AZ outage, let alone a full region outage.
Performance-wise, Aurora’s single write-master is no slouch; it can support thousands of connections, which increases overall throughput. However, as the number of connections scale, so does latency. All the AWS benchmarks for Aurora, from that single write-master, result in high latency per transaction. For instance, their Sysbench 100% writes benchmark generated latency north of 160ms to get their 100k TPS result. But is raw performance at the expense of latency enough for Enterprise workloads?
Google Spanner: Enterprise-Ready Scale
Google’s newly-released Cloud Spanner offers scale-out right out of the box. Specifically, this means Spanner is capable of the following:
- Scales-out both writes and reads without any application changes
- Continues to grow performance of both writes and reads by simply adding additional servers
- Constantly maintains transactional ACID guarantees (especially consistency and durability) across all the nodes in the database
Thus in a very real way, Google Spanner actually delivers on a lot of the “Enterprise performance” promise of Aurora.
Spanner’s Compatibility Problem
Although Spanner has the ability to scale out performance, it has no built-in compatibility with current applications. This is significant. Spanner does not use any standard JDBC or ODBC driver; it uses its own client libraries and the syntax it uses is a variant of SQL that is customized for Google Spanner. In other words, in order to use Spanner, some level of re-architecture and/or replatforming is needed for your applications to work correctly. Comparatively, Aurora’s native compatibility with MySQL allows applications to easily migrate from MySQL with a minimum of changes. Thus, applications wanting to leverage Spanner will have to be heavily rewritten, or written from scratch—similar to the replatforming necessary when migrating to Oracle or SQL Server.
Avoiding that replatforming cost is very important to decision makers choosing between augmenting their current MySQL systems, or taking the plunge of replatforming to a “bigger database.” So the question is whether the replatforming cost for Spanner is significantly less than the cost of replatforming to SQL Server or Oracle.
Do Enterprises Want Spanner or Aurora?
The market AWS is targeting with Aurora exists. No longer is the expectation “we’ll migrate off MySQL when we get bigger.” For one, migrating to the “bigger database” is a huge outlay of replatforming effort, requiring thorough code rewrites and often application re-architecture. But let’s not forget cost—both SQL Server and Oracle cost significantly more than either Aurora or Spanner. So if ‘Enterprise-ready” databases like Aurora or Spanner can provide sufficient Enterprise features, especially performance at scale, all the numbers are on their side when it comes to managing DevOps and IT budgets.
However, performance at scale is very important to the Enterprise market as well.
Aurora’s Scale Problem
Aurora can pick up any RDS MySQL deployments—that's a natural progression. Compatibility is the win. However, similar to other MySQL DBaaS offerings (Azure SQL, Cloud SQL, RDS MySQL, etc) there is still a “hard stop” when it comes to write scale: each of these MySQL-based databases are limited to a single write master.
This problem cannot be overemphasized. Aurora’s inability to scale out writes is often surprising news to people trying Aurora for the first time—the expectation has been set for “high performance and capacity,” but after the capacity of Aurora’s single write master is exceeded, any additional scale requires application changes:
- Read fan-out to leverage read slaves. (“Read Replicas” on Amazon—more of a “read compute node” rather than having a full local copy of the DB. Replicas still have latency due to needing to wait for write locks to be released.) Read Replicas require different endpoints, as well as the ability of the application to handle delayed consistency.
- Write scale-out requires sharding, which Amazon Aurora does not support out of the box. This requires significant application changes to create and maintain consistency, as well as ongoing data management to ensure even distribution and avoid hotspots.
And all of this represents significant cost outlays as well.
ClustrixDB: MySQL-compliant Scale-out RDBMS
If you have a MySQL-compliant application that needs scale, you hit a wall with Aurora… or you have to spend significant capital to create and maintain a shard-aware application, as well as a sharded infrastructure on Amazon.
Correspondingly, if you have a MySQL-compliant application that requires scale, you’ll need to rewrite it to leverage the scale-out capabilities of Spanner.
Your better option is ClustrixDB, a MySQL-compliant scale-out RDBMS that provides linear write scale, cross-server ACID transactional guarantees, high performance, and low latency. It has the scale-out features of Spanner and the MySQL-compatibility of Aurora.
Deployed for many years in production at hundreds of sites worldwide, ClustrixDB is available on any cloud or datacenter.
If you have a MySQL-compatible workload in need of write scale up to 100 nodes and low latency, ClustrixDB might be your answer.
Google Spanner vs Amazon Aurora: Who’ll Get the Enterprise?的更多相关文章
- Amazon Aurora解读(SIGMOD 2017)
Amazon在SIGMOD 2017发表了论文<Amazon Aurora: DesignConsiderations for High Throughput Cloud-Native Rela ...
- Distributed PostgreSQL on a Google Spanner Architecture – Storage Layer
转自:https://blog.yugabyte.com/distributed-postgresql-on-a-google-spanner-architecture-storage-layer/ ...
- 全球分布式数据库:Google Spanner(论文翻译)
本文由厦门大学计算机系教师林子雨翻译,翻译质量很高,本人只对极少数翻译得不太恰当的地方进行了修改. [摘要]:Spanner 是谷歌公司研发的.可扩展的.多版本.全球分布式.同步复制数据库.它是第一个 ...
- Google Spanner (中文版)
温馨提示:本论文由厦门大学计算机系林子雨翻译自英文论文,转载请注明出处,仅用于学习交流,请勿用于商业用途. [本文翻译的原始出处:厦门大学计算机系数据库实验室网站林子雨老师的云数据库技术资料专区htt ...
- 分布式数据库Google Spanner原理分析
Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) .Spanner的扩展性达到了令人咋舌的全球级,可以扩展到数百万的机器,数已百计的 ...
- 一篇文章带你看懂AWS re:Invent 2018大会,揭秘Amazon Aurora
本文由云+社区发表 | 本文作者: 刘峰,腾讯云NewSQL数据库产品负责人.曾职于联想研究院,Teradata北京研发中心,从事数据库相关工作8年.2017年加入腾讯数据库产品中心,担任NewSQL ...
- Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases
INTRODUCTION In modern distributed cloud services, resilience and scalability are increasingly ach ...
- Distributed PostgreSQL on a Google Spanner Architecture – Query Layer
转自:https://blog.yugabyte.com/distributed-postgresql-on-a-google-spanner-architecture-query-layer/ Ou ...
- google spanner
REF 论文 google spanner spanner 介绍 http://blog.jobbole.com/110262/
随机推荐
- Java 设计模式系列(十三)模板方法
Java 设计模式系列(十三)模板方法 模板方法模式是类的行为模式.准备一个抽象类,将部分逻辑以具体方法以及具体构造函数的形式实现,然后声明一些抽象方法来迫使子类实现剩余的逻辑.不同的子类可以以不同的 ...
- centos7 单台zookeeper安装
1.创建 /usr/local/services/zookeeper 文件夹: mkdir -p /usr/local/services/zookeeper 2.进入到 /usr/local/ser ...
- [转]如何创建一个自签名的SSL证书(X509)
原文出自:http://www.joyios.com/?p=47 引言 使用HTTP(超文本传输)协议访问互联网上的数据是没有经过加密的.也就是说,任何人都可以通过适当的工具拦截或者监听到在网络上传输 ...
- swift学习之-- UIAlertViewController -alert
// // ViewController.swift // alertView // // Created by su on 15/12/7. // Copyright © 2015年 tia ...
- java并发编程实战:第六章----任务执行
任务:通常是一些抽象的且离散的工作单元.大多数并发应用程序都是围绕"任务执行"来构造的,把程序的工作分给多个任务,可以简化程序的组织结构便于维护 一.在线程中执行任务 任务的独立性 ...
- B-spline Curves 学习之B样条曲线定义(4)
B-spline Curves: Definition 本博客转自前人的博客的翻译版本,前几章节是原来博主的翻译内容,但是后续章节博主不在提供翻译,后续章节我在完成相关的翻译学习. (原来博客网址:h ...
- [label][phalcon] How to install Phalcon extension for Zend Server 6.3.0 for windows 7 64bit
At first , you should download Phalcon DLL file. You can download from this link under. http://stati ...
- CAS实战の自定义登录
由于每个版本的改动较大,所以先把版本号列出: 服务端版本:cas server 4.0.0 客户端版本:cas client 3.3.3 一.自定义登录页面 页面路径:/WebContent/WEB- ...
- Android-bindService本地服务-初步
在Android开发过程中,Android API 已经有了startService方式,为什么还需要bindService呢? 答:是因为bindService可以实现Activity-->S ...
- 指定的 LINQ 表达式包含对与不同上下文关联的查询的引用
解决方法是分两次查询. 报错的原因是在涉及到内存中的对象与EF里的对象混合查询时,内存中的对象要是基元类型. 第一次查询实际上会因为EF的延时加载,不会立即将数据查询到内存中. 解决方法是对第一次查询 ...