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?的更多相关文章

  1. Amazon Aurora解读(SIGMOD 2017)

    Amazon在SIGMOD 2017发表了论文<Amazon Aurora: DesignConsiderations for High Throughput Cloud-Native Rela ...

  2. Distributed PostgreSQL on a Google Spanner Architecture – Storage Layer

    转自:https://blog.yugabyte.com/distributed-postgresql-on-a-google-spanner-architecture-storage-layer/ ...

  3. 全球分布式数据库:Google Spanner(论文翻译)

    本文由厦门大学计算机系教师林子雨翻译,翻译质量很高,本人只对极少数翻译得不太恰当的地方进行了修改. [摘要]:Spanner 是谷歌公司研发的.可扩展的.多版本.全球分布式.同步复制数据库.它是第一个 ...

  4. Google Spanner (中文版)

    温馨提示:本论文由厦门大学计算机系林子雨翻译自英文论文,转载请注明出处,仅用于学习交流,请勿用于商业用途. [本文翻译的原始出处:厦门大学计算机系数据库实验室网站林子雨老师的云数据库技术资料专区htt ...

  5. 分布式数据库Google Spanner原理分析

    Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) .Spanner的扩展性达到了令人咋舌的全球级,可以扩展到数百万的机器,数已百计的 ...

  6. 一篇文章带你看懂AWS re:Invent 2018大会,揭秘Amazon Aurora

    本文由云+社区发表 | 本文作者: 刘峰,腾讯云NewSQL数据库产品负责人.曾职于联想研究院,Teradata北京研发中心,从事数据库相关工作8年.2017年加入腾讯数据库产品中心,担任NewSQL ...

  7. Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases

    INTRODUCTION   In modern distributed cloud services, resilience and scalability are increasingly ach ...

  8. Distributed PostgreSQL on a Google Spanner Architecture – Query Layer

    转自:https://blog.yugabyte.com/distributed-postgresql-on-a-google-spanner-architecture-query-layer/ Ou ...

  9. google spanner

    REF 论文 google spanner spanner 介绍 http://blog.jobbole.com/110262/

随机推荐

  1. 配置yum源方法,以及失效时的处理

    正常方法如下: step1: 备份原CentOS-Base.repo 文件 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-B ...

  2. platform总线驱动代码分析

    /************************************************************************/ Linux内核版本:2.6.35.7 运行平台:三 ...

  3. [转载]MVC、MVP以及Model2(上)

    对于大部分面向最终用户的应用来说,它们都需要具有一个可视化的UI与用户进行交互,我们将这个UI称为视图(View).在早期,我们倾向于将所有与视图相关的逻辑糅合在一起,这些逻辑包括数据的呈现.用户操作 ...

  4. Jenkins 使用 Build Flow 插件配置工作流任务依赖

    Jenkins 使用 Build Flow 插件配置工作流任务依赖 Jenkins 多任务依赖方式的配置方法目前可以通过MultiJob Project 或者Build Flow 或者Piplelin ...

  5. 使用centos官方镜像制作jdk8环境镜像

    首先将jdk文件或者tar包放在/var/local路径下 然后Dockerfile中写 # 以 centos7 为基础镜像 FROM centos:latest MAINTAINER chen # ...

  6. myeclipse过期以后提示过期以后怎么办?!

    昨天电脑上装的myeclipse到期了,不能进到工作空间里边,只有激活和退出选项,在网上百度了一下,有很多破解工具, 1.刚开始直接使用工具破解,没有成功,总是提示要么激活,要么退出 2.继续想办法, ...

  7. cesium编程入门(五)绘制形状

    通过Entity添加形状 先来看一个添加立方体的例子 var viewer = new Cesium.Viewer('cesiumContainer'); var redBox = **viewer. ...

  8. MaxScript粒子流塌陷

    也是帮网友写的.不过最后没用上.哈哈. targetPF = $ startTime = AnimationRange.Start.Frame endTime = AnimationRange.End ...

  9. MaxScript镜像函数

    看到有网友需要写的,其实镜像就是缩放改为负数 Fn MirrorObject argObjects argAxisName = ( local axisNames = #(#x,#y,#z) do ( ...

  10. Android : M 与 N 的权限管理

    从 M 开始,permission 分为 Normal permission Runtime permission Normal permission 直接在 manifest 里声明就可以用了. a ...