2017年2月16日，Google发布了基于Spanner的数据库服务CloudSpanner (Beta，https://cloudplatform.googleblog.com/2017/02/introducing-Cloud-Spanner-a-global-database-service-for-mission-critical-applications.html)，发布中提及了两个客户JDA和Quizlet，后者发表了一篇挺长的测试报告( https://quizlet.com/blog/quizlet-cloud-spanner)。
【Cloud Spanner是什么】
Google的广告计费系统AdWords原本使用MySQL + sharding，但MySQL的扩展性缺失和可靠性欠缺促使Google从2008年底开始研制了F1及Spanner系统（Google确实很有远见，那个时候就看到了MySQL的上述问题并拟进行淘汰）：
Resharding this revenue-critical database asit grew in the number of customers and their data was extremely costly. The last resharding took over two years of intense effort,and involved coordination and testing across dozens of teams to minimize risk.
(摘自Google的Spanner论文，色彩部分为本文所加)
F1本来是Google的AdWords重构项目，Spanner则是其中的分布式数据库。Spanner最关键的特性是事务(ACID)、跨数据中心同步等，其中TrueTime对于事务的实现十分关键。F1基于Spanner，其关键特性包括SQL（可能并非国际标准的SQL，而是Google自己的SQL标准）、二级索引支持等。除了最早的AdWords外，据说Google还有一些其他应用基于F1。
Cloud Spanner是Google基于Spanner提供的、可用于关键业务的云数据库服务。
【Quizlet测试报告】
Quizlet是一家提供便捷在线学习及工具的美国公司，“通过搜索数百万学习集或创建自己的学习集，通过用单词卡、游戏和其他功能提高学习成绩”。Quizlet把其业务系统从MySQL迁移到Cloud Spanner的原因与Google把AdWords从MySQL迁移到Spanner/F1类似：MySQL的扩展性缺失。
总体上，Quizlet的测试报告对Cloud Spanner给出了相当正面的评价：
Cloud Spanner的扩展性非常好，几乎跟其节点（不是物理接点，而是一种虚拟接点）个数成线性正比；
尽管跟Google内部的Spanner有一些差别，但CloudSpanner依然有很高的可用性；
Cloud Spanner有两个非常有用的管理数据局部性的功能（data locality），一个类似于table group，即把经常同时访问的表放置在一起，提升IO性能；另一个是stored index（有人译文存储索引），即把通过二级索引经常要访问的数据直接存储在二级索引中，这样就省去了回表；
Cloud Spanner支持一个比一般传统关系数据库支持的SQL小、自己定义的类似于SQL:2011标准的SQL，支持的功能包括join、create table、二级索引等；
Cloud Spanner支持7种数据类型：bool, int64, float64, string, bytes, date, timestamp。
Quizlet的测试报告也指出了CloudSpanner的一些不足之处：
Cloud Spanner不支持insert，update等SQL DML，而是通过指定主键的RPC直接实现行的修改；
Cloud Spanner在正常压力下（分析应该是同城数据中心部署），简单事务的最小响应时间大约5ms；
Cloud Spanner的二级索引功能很强大，但写入时导致的开销也非常大，即使写入的数据有很强的局部性，这可能跟二级索引更新时的锁影响了其他需要二级索引的访问。Quizlet的解决方法是把二级索引包含在主键之中；
可能是代价估算的偏差，CloudSpanner在执行SQL时选择索引并不是非常精确，最好的办法是通过类似于hint手段指定索引；
Cloud Spanner非常复杂，但用户却无法探查事务在Cloud Spanner内部的执行状况，这是CloudSpanner最大的问题。CloudSpanner没有接口来观察当前正在执行的查询，也无法知道正在进行的索引构建的情况，仅仅有一些内部状态的信息，例如CPU利用率，IO次数和数据量等，没有一些关键的例如数据分片的分布情况，大查询的状况等。
【Spanner与OceanBase的技术方案对比】
Spanner在世界上首次在跨地域尺度上实现了ACID，并且很好地实现了水平扩展，解决了基于普通廉价PC服务器的数据库高可用，这是一个了不起的创新。Spanner大约从2008年底开始研发，但直到2012年其论文发表后才为外界所知。
OceanBase在2010年6月立项，并独立发展了自己的ACID、水平扩展以及基于普通PC服务器的数据库高可用技术等。
Spanner没有支持国际标准SQL及其接口（ODBC/JDBC等），也没有采用真正的关系模型（尽管支持join等），主要原因也许是Spanner最早定位于Google内部应用。这些缺失使得Spanner能够以较小地成本和较短的时间投入生产运行，并且更好其契合内部应用（例如采用树形模型代替关系模型），但这也使得迁移已有的基于关系数据库的业务到Spanner的工作量和难度很大，对Spanner的外部应用和推广将的负面影响无法忽视。
OceanBase从第一天就强调采用标准的关系模型和支持国际标准SQL。由于工作量的原因，OceanBase对完善SQL标准和接口的支持比较晚，直到OceanBase 1.0才完全与MySQL语义语法和接口兼容，这使得OceanBase从开始研发到大量的内部应用经历了更长的时间，但也使得OceanBase与传统关系数据库更相似，后续推广应用的代价更小，比如MySQL应用可以不做任何修改地无缝迁移到OceanBase。
关于TrueTime：Spanner通过TrueTime实现了大规模、跨地域分布式数据库系统的快照读隔离级别（snapshot isolation），这非常了不起，但这个技术方案导致单次访问延迟在5ms甚至更长（即使是同城部署），许多业务无法忍受如此之大的延时。
OceanBase必须保证对简单访问的响应时间小于1ms（正常压力下）------类似于传统关系数据库，跨地域的访问也仅仅在事务提交时才必须，因此OceanBase采用跟TrueTime迥异的机制，但也实现了跨地域的数据库高可用。
Spanner通过F1用于Google生产系统，应该没有直接用于生产系统，并且早先主要用于少量内部关键项目（例如AdWords），因此Spanner缺乏像传统商业数据库的各种内部状态和事务执行过程跟踪和分析手段，这对于Spanner的外部应用推广也会有较大的影响。
OceanBase从一开始的目标就是像传统关系数据库一样直接用于生产系统，因此内部状态和事务执行过程的跟踪与分析十分必要，虽然限于工作量和人力投入的原因，OceanBase直到1.0版本后才有比较完善的内部监控和事务执行跟踪机制。
修改Spanner的TrueTime的挑战比较大，改变其树状的数据模型也有一定的挑战，假如Cloud Spanner能够得到较大的推广和应用，其他的缺陷应该可以逐步得到弥补和改善。
