正文
比如对于 RDS 的扩展方案，我介绍两个比较典型的：第一个是阿里云的 DRDS （不过现在好像从阿里云的产品列表里拿掉了？），DRDS 其实思路很简单，就是比 RDS 多一小步，在刚才提到的 RDS 的中间层中加入用户配置的路由策略，比如用户可以指定某个表的某些列作为 sharding key 根据一定规则路由到特定的实例，也可以垂直的配置分库的策略。
其实 DRDS 的前身就是淘宝的 TDDL，只不过原来 TDDL 是做在 JDBC 层，现在将 TDDL 做进了 Proxy 层（有点像把 TDDL 塞到 Cobar 的感觉）。这样的好处是，将应用层分库分表的工作封装起来了，但是本质上仍然是一个中间件的方案，尽管能对简单的业务做到一定程度的 SQL 兼容。
对于一些复杂查询，多维度查询，跨 Shard 事务支持都是有限了。毕竟中间路由层对 SQL 的理解有限，至于更换 Sharding key 、DDL、备份也是很麻烦的事情。从 Youtube 开源的中间件 Vitess 的实现和复杂程度来看甚至并不比实现一个数据库简单，但是兼容性却并没有重新写一个数据库来得好。
Amazon Aurora
后来时间来到了 2015 年，Amazon 走了另外一条路。在 2015 年，Amazon Aurora 发布。Aurora 的资料在公网上并不多，Aurora 提供了 5x 于单机 MySQL 5.6 的读吞吐能力，不过最大也就扩展到 15 个副本，副本越多对写吞吐影响越大，因为只有一个 Primary Instance 能提供写入服务，单个副本最大支持容量 64T，而且支持高可用以及弹性的扩展。
值得一提的是 Aurora 的兼容性。其实做数据库的都知道，兼容性是一个很难解决的问题，可能实现上很小的差异就会让用户的迁移成本变得很大，这也是为什么中间件和分库分表的方案如此反人类的原因，我们大多都在追求用户平滑的迁移体验。
Aurora 另辟蹊径，由于公开的资料不多，我猜想 Aurora 在 MySQL 前端之下实现了一个基于 InnoDB 的分布式共享存储层（
https://www.percona.com/blog/2015/11/16/amazon-aurora-looking-deeper/
）。对于读实例来说是很好水平扩展的，这样就将 workload 均摊在前端的各个 MySQL 实例上，有点类似 Oracle RAC 那样的 Share everything 的架构。
这个架构的好处相对中间件的方案很明显，兼容性更强，因为还是复用了 MySQL 的 SQL 解析器。优化器，业务层即使有复杂查询也没关系，因为连接的就是 MySQL。
但是也正是由于这个原因，在节点更多，数据量更大的情况下，查询并不能利用集群的计算能力（对于很多复杂查询来说，瓶颈出现在 CPU 上），而且 MySQL 的 SQL 优化器能力一直是 MySQL 的弱项，而且对于大数据量的查询的 SQL 引擎的设计是和单机有天壤之别的。一个简单的例子，分布式 Query Engine 比如 SparkSQL / Presto / Impala 的设计肯定和单机的 SQL 优化器完全不同，更像是一个分布式计算框架。
所以我认为 Aurora 是一个在数据量不太大的情况下（有容量上限），对简单查询的读性能优化的方案，另外兼容性比中间件的方案好得多。但是缺点是对于大数据量，复杂查询的支持还是比较弱，另外对于写入性能 Aurora 其实没有做太多优化（单点写入），如果写入上出现瓶颈，仍然需要在业务层做水平或者竖直拆分。
Google Cloud BigTable
Google 作为大数据的祖宗一样的存在，对于云真是错过了一波又一波：虚拟化错过一波让 VMWare 和 Docker 抢先了（Google 早在十年前就开始容器的方案，要知道容器赖以生存的 cgroups 的 patch 就是 Google 提交的）；云服务错过一波让 Amazon 抢先了（Google App Engine 真是可惜）：大数据存储错过一波让开源的 Hadoop 拿下了事实标准，以至于我觉得 Google Cloud BigTable 服务中兼容 Hadoop HBase API 的决定，当时实现这些 Hadoop API for BigTable 的工程师心中应该是滴血的 :)
不过在被 Amazon / Docker / Hadoop 刺激到以后，Google 终于意识到社区和云化的力量，开始对 Google Cloud 输出 Google 内部各种牛逼的基础设施，2015 年终于在 Google Cloud Platform 上正式亮相。对于 BigTable 的架构相信大多数分布式存储系统工程师都比较了解，毕竟 BigTable 的论文也是和 Amazon Dynamo 一样是必读的经典，我就不赘述了。
BigTable 云服务的 API 和 HBase 兼容，所以也是 {Key : 二维表格结构}，由于在 Tablet Server 这个层次还是一个主从的结构，对一个 Tablet 的读写默认都只能通过 Tablet Master 进行，这样使得 BigTable 是一个强一致的系统。这里的强一致指的是对于单 Key 的写入，如果服务端返回成功，接下来发生的读取，都能是最新的值。
由于 BigTable 仍然不支持 ACID 事务，所以这里的强一致只是对于单 Key 的操作而言的。对于水平扩展能力来说， BigTable 其实并没有什么限制，文档里很嚣张的号称 Incredible scalability，但是 BigTable 并没有提供跨数据中心（Zone）高可用和跨 Zone 访问的能力。
也就是说，一个 BigTable 集群只能部署在一个数据中心内部。这其实看得出 BigTable 在 Google 内部的定位，就是一个高性能低延迟的分布式存储服务，如果需要做跨 Zone 高可用需要业务层自己做复制在两个 Zone 之间同步，构建一个镜像的 BigTable 集群。
