作者简介
陈运海
DaoCloud 数据平台架构师，长期关注数据库系统、分布式系统、区块链等领域。
这是最好的时代，也是最坏的时代。
在这个时代我们有各种技术可以选择，在这个时代我们有各种技术要选择。
言必称互联网
在计算机科技这块蓬勃发展的领域，新技术形态和新的商业模式源源不断的涌现、令人眼花缭乱。世纪之初的以流量为王互联网泡沫破灭，并不能阻挡当下互联网行业继续攀登高峰，只是在这将近20年的时间里，消费者与互联网从业人员有足够长的时间一点一滴地将行业基础夯实，将原来的浮云垒高台，变为了今天一个实实在在的行业。
互联网已经从计算机网络、通信领域的一个名词慢慢演变成了一个形容词，互联网行业、互联网应用（Internet application）中的互联网代表着高并发、敏态IT、快速伸缩、数据驱动、精益运营等等，一切都显得区别于传统的行业、传统的应用。
支撑互联网应用的 PaaS 平台已经日渐清晰，以 Docker 为代表的容器技术，在势头上已经力压虚拟机，为互联网应用提供了标准的运行环境。而在上层的集群管理、编排标准，大而全的 Kubernetes 和不甘于继续做小巧灵巧的 Swarm，联合开源社区的众多玩家（Spring Cloud, Tyk, Prometheus）等，共同打造了包含负载均衡、弹性伸缩、服务注册与发现、应用监控等功能的面向互联网应用的高可用 PaaS 平台。
另一方面，互联网应用典型的高并发访问量、大数据存储量以及跨地理区域等特性使得传统的基于关系型数据库的应用架构无所适从，NewSQL 的诞生与当前互联网应用的需求密不可分。
NewSQL is a class of modern relational database management systems that seek to provide the same scalable performance of NoSQL systems for online transaction processing （OLTP）read-write workloads while still maintaining the ACID guarantees of a traditional database system.
有着远大愿景的 NewSQL 试图比肩扩展性占优的 NoSQL，并且实现传统关系型数据库所擅长的满足 ACID 特性的事务处理。然而考虑到关系型数据库，从 Edgar F. Codd 的文章 A Relational Model of Data for Large Shared Data Banks 发展到 NoSQL 盛行再到今天，学术界与工业界并进的数据库理论和工程差不多已经经历了四十多年了，那么，标榜为 New 的 NewSQL，到底 New 在哪里？NewSQL 是真有其货还是只是商业上的一种游戏？
关系模型与 SQL 标准
在关系型数据库流行并成为数据库领域真正意义上的标准之前，曾经出现过几个往往被一笔带过的模型的数据库，基本上都可以归类为导航型数据库，它们在物理结构上面向的是磁带存储，在逻辑结构上是现实世界某种程度的映射。例如：层级模型是以树形结构组织数据的，每个子节点只会拥有唯一的父节点。公司内部的组织结构就是我们所熟悉一个层次结构。
A navigational database is a type of database in which records or objects are found primarily by following references from other objects.
不得不提的一个层次模型数据库是诞生于 1968 年的 IBM 的 IMS（Information manangement system）。相传在 1966 年，美国国家航空航天局找到了 IBM，寻求一款软件，以求在登月工程中能够有效的跟踪管理数以万计的火箭零部件。
If we could put a man on the Moon, could we also create a computer program to track the millions of rocket parts it takes?
如今，IMS 依然老当益壮，在大型制造业、银行依然承担着重要的角色，还会时不时的举办社区活动。但是它已经淡出了我们这些标榜为互联网从业人员的视线，毕竟在推崇开源、微服务、敏态 IT、轻资产的互联网行业，它已经显得格格不入了。
但是它对整个数据库领域，甚至整个计算机科学都留下了不可磨灭的贡献，时至今日，再楞头的程序员，也不会轻易把自己深陷在应用自己管理、查询数据的泥淖里。
It helped introduce the idea that an application’s code should be separate from the data that it operates on. This allows developers to write applications that only focus on the access and manipulation of data, and not the complications and overhead associated with how to actually perform these operations.
1970 年，同样是 IBM 的 Edgar Codd 发表了数据库发展史上重量级的一篇文章 A Relational Model of Data for Large Shared Data Banks（文章地址：https://cs.uwaterloo.ca/~david/cs848s14/codd-relational.pdf），Edgar 在这著名的文章里，以数学理论为基础，论证了为了做到对称探索（Symmetric Exploitation），即用户可以根据任何已知的属性组合去探索剩下的未知属性，必须要消除导航数据库中的几个依赖：
- 排序依赖
- 索引依赖
- 访问路径依赖
很多人认为关系型数据库的成功在于其完美的数学模型，但是不可忽视的另外一面，关系型数据库在数据库发展的混沌时期，为其打开了一面窗，原本导航型数据库，关注点在于数据的写入和基于路径的信息检索，而关系型数据库，让人们看到了数据分析的曙光。
之后借助于硬件技术特别是存储设备的发展，出现了支持 Semi-random access 的磁盘，关系型数据库如鱼得水，加上之后演绎出的关系代数、 E-R 模型、SQL 标准、 Codd's 12 rules、数据仓库等等，使其主导了数据库领域近 40 年。
The introduction of low-cost hard drives that provided semi-random access to data led to new models of database storage better suited to these devices. Among these, the relational database and especially SQL became the canonical solution from the 1980s through to about 2010.
关系型数据库中的 关系 并不是指我们直观感受到的表与表之间通过外键关联在一起的 关系，关系（Relation）是一个数学上的概念，其定义为：
简要的表述：
在工业界，1979 年诞生的 Oracle、1983 年诞生的 DB2，90 年代开源领域的 MySQL 和 PostgreSQL，都是各位耳熟能详的几个有名的数据库。
数据库领域下一个大事件就是 SQL 的标准化了。由于 Edgar 并未在那篇著名的论文中指定关系型数据库具体实现方法，只是描述了关系模型，据此，市面上出现了多个关系型数据库，各个系统的存储引擎各不相同，数据的组织形式千差万别。面向过程的数据库操作语言显然是不合适的。
比如，某一个学校组织了一次考试，为了录入每个学生的成绩，教务处老师需要处理以下细节：
1.成绩表的存储位置
2.各个列的组织形式
3.分隔符
4.解压缩算法
...
你也一定会同意，这样不行！的确，这样对应用的侵入性太强。我们哪里在写应用，我们在写琐碎的计算细节！
SQL 是高级的非过程化数据库操纵语言，它允许用户在高层数据结构上工作，不要求用户指定对数据的存放方法，也不需要用户了解其具体的数据操纵方式。它将数据库以一个简单的界面呈现出来，能使具有底层结构完全不同的数据库系统和不同数据库之间，使用相同的 SQL 作为数据的输入、运算与管理。
你只需要用这种标准化的语言，告诉数据库你要做什么，而不是告诉它，为了做这件事情，所要一步步地怎么做。
回到录入成绩那个例子，你只需要对数据库执行以下操作：
create table score(id int, name string, level char);
insert into score values(12, John, 'B')
insert into score values(19, Lily, 'A');
...复制代码查询获得 'A' 的学生名单？小菜一碟：
select * from score where level = 'A';复制代码解耦合是计算机领域一个长盛不衰的话题，纵便有 data locality，存储计算分离也是一股强大的潮流；应用和数据库解耦合催生了数据库，编程与运行平台的解耦合催生了高级编程语言、编译器；应用与承载平台的解耦合催生了容器技术、Docker。
扯远了，有一点是要记清楚的，耦合存在的意义就是被解开，就像记录存在的意义就是被打破一样。
互联网时代的探索
互联网应用犹如一头咆哮的巨兽，对于习惯了传统应用的人们来说，仿佛先民在《山海经》里所描绘的巨兽。
面对互联网应用的高并发、大容量和跨地域等挑战，Sharding 是分而治之的最为朴素的解决方案，基本思想就是面对九头蛇这种怪兽，召集九个有能力对付一条蛇的猎人，一起投入战斗。
Sharding 的具体做法是把一个 Database 切分成几个部分放到不同的服务器上，以分布式的手段增强数据库的性能。Sharding 又有水平切分和垂直切分的区别，如果数据库中 table 较多，可以把不同的表放在不同的服务器上，这便是垂直切分。如果某些 table 的数据量特别大，需要对其进行水平切分，将这个表的数据分发到多个服务器上。在互联网应用场景，一般以水平切分为主，实现上以数据库中间件（Database middleware）为主，之后的讨论不特别说明的情况，Sharding 都是指水平切分。
由于原理上的限制，Sharding方案几乎很难做到有效的扩展。比如，某大型互联网应用预测需要 Sharding 5 台数据库，数据分发策略为：
后来由于业务访问量增加，需要 7 台数据库服务器的时候，相应的数据分发策略为：
为了保障老数据还能够正确的访问，这里就需要做数据的重新分发了，那么大数量的数据重新加载，是一个很漫长而痛苦的过程。互联网应用，一般都不能承受如此长时间的服务中断。可以选择在备库上操作，但是过程相当也烦琐。
当然，深入一点的有一致性 Hash 算法，但往往会造成分片数据库之间的负载倾斜，理论上并无很好的解决办法。
另外，Sharding 方案对事务的支持蜕化严重，有 Sharding 表参与的关联大部分需要应用开发者自己实现其逻辑。
Sharding middleware works well for simple operations like reading or updating a single record.It is more difficult, however, to execute queries that update more than one record in a transaction or join tables.
最终一些公司放弃了 Sharding 中间件的努力，开始开发它们自己的数据库管理系统，开启了 NoSQL 之路。传统的数据库系统往往为了一致性和正确性，而牺牲了高可用性和高性能。这种 trade-off 对于基于 Web 的互联网应用是不合适的，它们需要更多的是系统的高可用性和高并发下的性能，被关系型数据库拒之门外的非结构化数据也是这一过程重要的推手。创新之路最早开始对于一些简单的互联网应用，它们只是重复不断地写入记录，根据主键执行 look-up 查询，这样一来，关系模型和 SQL 都成了累赘，数据的写入和查询都是通过更为高效的 API 来完成，因此，最开始 NoSQL 是 No more SQL 的简称。
后来，在易用性上也有一些系统慢慢加入了部分 SQL 的支持，除此之外， NoSQL 在高可用性、性能等方面也有着不错的表现，NoSQL 最终演变成 Not Only SQL。
然而，放弃了关系模型，支持的 SQL 也只是标准的一小部分，在 API 方面 NoSQL 没有也不可能有一个通用的标准，也就是在 NoSQL A 系统上运行的应用是不可能迁移到 NoSQL B 上的，也就是平常我们所说的技术栈绑定。NoSQL 更像是一个桀骜不驯的野马，伯乐视之若千里马，也有人被摔的鼻青脸肿。
NoSQL 中两个最有名的系统当属 Google 的 Bigtable 和 Amazon 的 Dynamo 了，它们开始都是只对内服务的（现在已经开放为云服务），其他的企业和组织开始根据它们的设计理念，集结开源社区的力量，创建了几个有名的系统，包括 Cassandra, HBase 和 MongoDB。
NewSQL 的回归
计算机行业的发展是一个很有趣的过程，一些对自己需求、现有系统充分了解的大牛们，嫌弃现存的系统对他们强加了太多的限制，于是他们另起炉灶，搞了一套新的好用的东西。之后为了造福于天下，惠及众生，接入了通用性，加入各种各样的接口和规范，成了标准化的产品，继续被新一轮大牛嫌弃并抛弃。
引入了分布式的架构的 NoSQL，在扩展性、高可用性和性能上相对于传统关系型数据库有着很大的提升，然而它们付出的代价是去除了事务支持和关系模型，同时，大部分系统都为了高可用性而放弃了系统的强一致性，而采用最终一致性模型，加上缺少 SQL 和统一的 API 规范，普通的应用开发者很难在这样的系统上正确地构建他们互联网应用。包括 Google 内部的应用开发人员，也有着类似的抱怨。
Developers of many OLTP applications found it difficult to build these applications without a strong schema system, cross-row transactions, consistent replication and a powerful query language.
OLTP 应用开发者关注的重点在数据库的高并发、事务的支持上，这些事务的读写，具有以下几个典型特征：
1.Short-lived （i.e., no user stalls）
2.Touch a small subset of data using index lookups （i.e., no full table scans or large distributed joins）
3.Repetitive （i.e., executing the same queries with different inputs）
而之后的数据分析、数据挖掘等，则不属于 OLTP 的范畴，也不属于 NewSQL 针对的场景。
NewSQL 是某种程度的回归，它试图重新拾起被 NoSQL 抛弃的 ACID，ACID 是数据库事务正确执行的四个基本要素，也就是 NewSQL 试图重拾事务。
- Atomicity 原子性
- Consistency 一致性
- Isolation 隔离性
- Durability 持久性
这里的一致性，与分布式系统常说的一致性并非同一个概念，传统关系型数据库往往是单机版的，这里的一致性指的是事务，不管成功与否，都不会破坏任意已经定义好的关于数据的约束，比如外键约束。而分布式系统中的一致性，也并不是同一份数据的多个副本是完全一致的，而是说不同的观察者，对于同一个数据，读取的内容是一致的。
引入了事务的支持，NewSQL 为了更好的解放开发者，进一步加入了 SQL 的支持和分布式一致性的支持。
NewSQLs enable applications to execute a large number of concurrent transactions to ingest new information and modify the state of the database using SQL (instead of a proprietary API). If an application uses a NewSQL DBMS, then developers do not have to write logic to deal with eventually consistent updates as they would in a NoSQL system.
在 What's Really New with NewSQL? 那篇文章里，作者对于当前存在的 NewSQL 数据库，大致有以下三个分类：
采用全新架构的新系统
分布式 Shared-nothing 基因，零历史包袱，多节点并发控制，多副本容错，分布式查询与优化。
Send the query to the data rather than bring the data to the query
独立管理数据存储，对数据有更直接、更细粒度的控制，不依赖现有的分布式存储系统、分布式文件系统。
Examples: ClustrixDB，CockroachDB，Google Spanner，MemSQL，NuoDB
重新实现的 Sharding 中间件
中心化的中间件负责查询分发、协调事务处理、管理数据与副本分布、节点管理；数据节点负责数据的存储与查询，并接收中间件发来的读写请求，返回结果等。
对应用呈现了一个单体的逻辑层的数据库，不需要修改底层的DBMS。基于传统 RDBMS 的应用甚至可以不修改任何代码就能够无缝的迁移。
Examples: AgilData Scalable Cluster，MariaDB MaxScale，ScaleArc，ScaleBase.
全新架构的云数据库
DataBase as a Service（DBaaS），云服务提供商负责运维，用户只需按需申请资源并按需付费。
Examples: Amazon Aurora，ClearDB.
从文章作者流露于纸面的态度，我们做一个越俎代庖的猜测，作者并不是很认可分类二，有兴趣的同学可以阅读一下原文。另外，其他的 NewSQL 系统也注意到了协议兼容的好处，比如 CockroachDB 兼容 PostgreSQL wire protocol，ClustrixDB 号称兼容 MySQL 等。
Really new ?
回归到 NewSQL 的 New 之争，这部分过于专业，还是建议感兴趣的同学们阅读原文，我们在这里只一个大概的总结。在 What's Really New with NewSQL?（文章地址：http://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf） 文章作者从以下几个方面，对 NewSQl 所采用的技术进行了分析：
- 面向内存的存储
- 数据分区
- 并发控制
- 二级索引
- 副本机制
- 故障恢复
The main takeaway from our analysis is that NewSQL database systems are not a radical departure from existing system architectures but rather represent the next chapter in the continuous development of database technologies. Most of the techniques that these systems employ have existed in previous DBMSs from academia and industry. But many of them were only implemented one-at-a-time in a single system and never all together. What is therefore innovative about these NewSQL DBMSs is that they incorporate these ideas into single platforms. Achieving this is by no means a trivial engineering effort. They are by-products of a new era where distributed computing resources are plentiful and affordable, but at the same time the demands of applications is much greater.
阳光之下，并无新事。NewSQL 所采用的各种技术已经广泛应用在多个数据库中，只是这一次，NewSQL 把这些技术组合在了一起。作者期待 NewSQL 开启一个新的时代，肯定了 NewSQL 特别是 NewSQL 在工程方面的成就，毕竟：
Distributed systems engineering is full of tradeoffs.
未来之光 HTAP
业务的支撑、数据的采集只是企业数据闭环中的一部分，盘活数字资产，打造数据驱动型、商务智能型的公司，是当前互联网行业的一大愿景。然而，由于底层数据的存储结构很难同时折中 Fast analytics 和 Fast inserts and updates 的性能，当今大部分企业依然需要借助于另外一套系统——OLAP。
OLTP 流入系统的数据，通过源源不断 ETL 等过程，导入到 OLAP 分析型数据库，之后通过报表分析和数据挖掘、机器学习等手段，生成决策结果，反作用于业务，调整业务，构成数据闭环。
同时维护了两套数据的 OLTP 和 OLAP 由于数据的冗余，成倍增加了系统的存储开销；依赖于 ETL 的数据复制，决策系统的时效性受到了很大的影响；同时，固定时间的 ETL 过程也对两个系统的性能施加了很大的压力。
人们对大统一的追求是永无止境的。在 What's Really New with NewSQL? 文章中，作者预测数据库系统的下一个大的趋势就是整合 OLTP 和 OLAP，也就是所谓的 Hybrid Transaction-Annlytical Processing。
大数据巨头 Cloudera 在 2015 年推出的 Kudu 存储引擎试图达到这一目标，不过根据目前的 Google trends，这个项目并没有太火。NewSQL 中的诸多厂商都有这样的 Roadmap（虽有厂商号称它们已经是 HTAP 系统，但笔者更倾向于这是一个任重道远的任务），比如 CockroachDB，ClustrixDB，MemSQL。
借一张图来说明 HTAP 的优势。
参考文献
[1] Codd, E.F (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. Classics. 13 (6): 377–387.
[2]Andrew Pavlo , Matthew Aslett, What's Really New with NewSQL?, ACM SIGMOD Record, v.45 n.2, June 2016 [doi>10.1145/3003665.3003674]
[3] J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. Furman, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschild, W. Hsieh, S. Kanthak, E. Kogan, H. Li, A. Lloyd, S. Melnik, D. Mwaura, D. Nagle, S. Quinlan, R. Rao, L. Rolig, Y. Saito, M. Szymaniak, C. Taylor, R. Wang, and D. Woodford. Spanner: Google’s Globally-Distributed Database. In OSDI, 2012.
[4] David F. Bacon, Nathan Bales, Nico Bruno, Brian F. Cooper, Adam Dickinson, Andrew Fikes, Campbell Fraser, Andrey Gubarev, Milind Joshi, Eugene Kogan, Alexander Lloyd, Sergey Melnik, Rajesh Rao, David Shue, Christopher Taylor, Marcel van der Holst, and Dale Woodford.2017. Spanner: Becoming a SQL System. In Proceedings of the 2017 ACM International Conference on Management of Data (SIGMOD '17). ACM, New York, NY, USA, 331-343. DOI: https://doi.org/10.1145/3035918.3056103
[5] ClustrixDB. https://www.clustrix.com/
[6] CockroachDB. https://www.cockroachlabs.com/
[7] Navigational database.
https://en.wikipedia.org/wiki/Navigational_database
[8] Kudu. https://kudu.apache.org/