关于昨天 Spanner 的文字，有人问 NewSQL 为什么会起名为 New，Spanner 的应用场景又是怎样的？那么这篇就顺着大数据的历史继续聊。
要聊 NewSQL 问什么要称为 NewSQL，它与之前的 SQL 和 NoSQL 有什么不同呢？要回答这个问题，必须要先了解数据库和大数据的发展历史。
数据库从1988年 IBM 发明第一代关系型数据库 SystemR 开始，到目前为止关系型数据库已经过去三四十年了。所谓关系型数据，指的是其数学理论基础-关系代数（不懂关系代数，或者说集合论的，自己回去翻教科书）中的关系二字。基于关系代数，衍生出来的语言是 SQL 。在这里要重点提一下，1990年代，当今最重要的两个开源关系数据库诞生了。1995年在瑞典，基于 ISAM 的 mSQL 系统诞生了 MySQL。而在1994年，两个伯克利大学的研究生在 QUEL 的 Postgres 的代码上添加了 SQL 支持诞生了 PostreSQL 。
关系型数据库最为核心的一点就是事务。由于系统经常会发生各种意外，比如：
- 数据写入到数据库时，突然因为网络、硬件故障等原因中断
- 应用程序由于某个 Bug 的存在，崩溃
- 多个客户端同时写入数据库，数据可能出现丢失
- 。。。
因此，数据库使用了事务去解决这些问题，保证执行数据库的一系列操作要么同时成功，要么同时失败。失败后，应用程序可以安全的进行重试，无需担心部分失败的问题。在某些情况下，这个也被称为一致性。
另外再简单的介绍下 CAP 定理，下面来自于维基百科：
对于一个分布式计算系统来说，不可能同时满足以下三点：
- 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）
- 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
- 分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）
根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。
可以这么理解，在 NewSQL 之前，传统的关系型数据库选择了强 CP ，放弃 A ，因此被局限于一个单机系统。
数据库的历史先放到一边，先来回顾下大数据的历史。前面提到过谷歌发明了 BigTable ，BigTable 虽然挂着一个 Table 的名头，但是 BigTable 本质上还是一个 Key-Value 存储，只不过使用了数据库里的 Table 、Row、 Column 的概念而已。（你可以把它的 key 简单理解为 row column timestamp 的集合体）
BigTable 开启了 NoSQL 的潮流，从某些角度来说，BigTable 给当时的业界一盏明灯，告诉业界，数据存储系统还有另一种实现方式，只要放弃强一致性，就能获得大规模高并发、高可用性和可扩展性。于是，NoSQL 的潮流来了。
坦白来讲，BigTable 的开源实现 Hbase 的查询功能并不好用，关于数据库的复杂逻辑都交给了应用程序去实现，例如要跑一个数据聚合查询，SQL 可能就一条语句实现了(select count(*))，但是 Hbase 则要专门程序去实现这事（例如写 for 循环）。此外，如果批量更新数据，也需要应用程序保证数据不会被部分更新，恰当地处理各种报错。显然，这大大的增加了应用程序的复杂性，把应该属于数据库完成的事交给了应用程序去做，用户体验相当不好。
NoSQL 虽有很多不足，但是随着2000年后互联网业务的大发展，它们面临着大规模的用户数量和并发操作，并且要保证 7*24 小时在线。传统的关系型数据库要支持这样的业务只能不断地升级内存、CPU和硬盘，显然到最后，硬件的成本会高到企业无法承受。互联网业务大部分对于事务也不是那么强要求，BigTable 等支持高并发、水平可扩展的 NoSQL 数据库成了很好地选择。另外，如果业务对数据库事务有要求，需要“对原有的单节点数据库进行数据分片，并存放到由廉价机器组成的分布式的集群里。对于应用程序来说，数据库中间件是一个逻辑上的单节点数据库，但实际上它的存储横跨了多台物理机器。当应用向数据库发起操作时，数据库中间件会自动将操作指令发送到集群中的一个或多个节点来执行。节点执行之后将结果发送回中间件，再由中间件反馈给应用。”使用数据库中间件，业务就需要自己管理数据分片和数据再平衡，嗯，做过这事的都知道，这有多痛苦。
遇到这问题并给出第一个解决方案的是谷歌。谷歌的搜索系统使用的是GFS 、MapReduce 和 BigTable ，但是广告部门一直使用的是 MySQL 集群。在前一篇文章也聊过谷歌广告部门的需求，它们需要 SQL 语言，需要高并发，需要可水平扩展，需要满足 ACID，但是又不需要自己管理数据分片和机器数量变化后的数据再平衡。总的来说，新的数据库既要有关系型数据库的优点，又要兼顾 NoSQL 的优点。这就是 Spanner 。
大数据的下半场开始了，也就是现在很火的 NewSQL 世界。Spanner 的诞生向业界证明了底层使用类似 NoSQL 的数据库存储数据，把计算上推以实现事务和 SQL 是可以兼得关系型数据库和 NoSQL 双方的优点。
现在 NewSQL 为什么 New 呢？读到这里，读者应该有了初步的答案，现在再小结一下：
- NewSQL 采用了全新的架构，例如存储层使用 NoSQL 存储数据，计算层实现事务和 SQL 语言。
- NewSQL 相比于 NoSQL 有完善的事务，支持强一致性，事务级别一般都到了可线性化。
- NewSQL 相比于传统的关系型数据库，它可以分布式水平扩展，上层无需关心底层的数据分片和再平衡逻辑。
- 得益于硬件技术的发展，极大地减少了 CAP 理论中的 P（分区容错性）的可能性，使得 C（一致性） 和 A（可用性） 可以兼得。
- 由于 Raft 算法等分布式一致性和共识算法的发展，相比于传统数据库的集群模式，NewSQL 实现了真正的高可用、高可靠（不用再担心单机的宕机而导致整个系统不可用）。
最后再简单评价下 Spanner ，谷歌目前把 Spanner 放在了它的云上提供服务，据说价格比较昂贵。Spanner 最大的“黑科技”在于使用了原子钟和 GPS 服务的 TrueTime API，由于 TrueTime 的存在，Spanner 解决了分布式系统中最重要的时间问题，实现了真正的全球的事务，换句话说，无论你在亚洲还是北美，看到的底层数据库中的数据都是一致的。
我想 Spanner 相对于谷歌这种跨国企业是有必要的，再比如亚马逊、微软（只不过一直都没有爆出来有相似的实现）。并且，对于很多银行和金融相关的企业，有了 Spanner ，再也不需要高端机器去保证两地三中心的数据一致性。除此以外，对于大部分企业，可能就是一个好看不好用的花架子吧。
除了使用 Spanner 以外，Spanner 独特的架构也启发了 TiDB 、CockcoarhDB 等一系列数据库的发展，虽然这些新的数据库没有 TrueTime 这样的黑科技，但是使用 NTP 协议来实现单机房下的可扩展性和事务，绰绰有余了。
