NoSQL没落了？NewSQL有机会挑大梁吗？

2018年4月20日，苹果宣布开源FoundationDB——一款支持多种数据模型、高性能、高可用、可扩展，且具备ACID事务的分布式KV NoSQL系统。FoundationDB已在苹果公司内部的生产环境使用三年，主要用于iCloud上的云存储服务。

苹果于2015年收购开源的FoundationDB并将其闭源。此次再次开源，是因为苹果预见到：FoundationDB有潜力成为下一代分布式数据库系统的底层基础设施。同时，也希望借助社区的力量，利用FoundationDB设计的分层机制，开发以其为底层核心且符合各种应用定制需求的存储系统。这也间接使得苹果的底层基础设施更安全、更可靠，而最终实现公司和社区双赢的结果。

抛开苹果开源FoundationDB背后的商业利益不谈，FoundationDB在技术上有两点值得关注：

• NoSQL+ACID+SQL Layer=NewSQL

在独立的KV存储服务上实现事务ACID语义，再通过分层设计在应用层支持文档、图、SQL等多种数据模型。

• MVCC+OCC=SSI

基于多版本/乐观并发控制技术实现可串行化的快照隔离级别。

一、NoSQL的没落?

提起NoSQL，大家一定会想到Google的Bigtable(2008年)和Amazon的Dynamo(2007年)，前者出于互联网企业数据量爆发的扩展性需求，实现了一个CP系统;而后者则出于商业用户的写高可用需求，实现了一个AP系统。

1、Bigtable & Dynamo

在CAP定理(2000年)的推波助澜下，NoSQL运动发展的如火如荼(AP系统如Cassandra、Voldemort、Tokyo Cabinet、Riak，CP系统如HBase、Hypertable、MongoDB、Redis)，并总结出了自己的设计哲学：

• no SQL
• no ACID
• no schema
• high performance
• high scalability
• high availability
• low latency
• relaxed consistency

然而，随着NoSQL系统在应用中的广泛使用，系统设计中抛弃的技术债务成了应用开发人员的负担，开发接口千奇百怪，数据不一致问题状况百出，事务一致性无法保证，正如Eric Brewer所说：

The hidden cost of forfeiting consistency, which is the need to know the system's invariants. The subtle beauty of a consistent system is that the invariants tend to hold even when the designer does not know what they are.

尤其是在互联网业内具备神级存在的Google公开的Spanner(2012)，成为压垮NoSQL的最后一根稻草，又一次改变了分布式数据库系统发展的方向。

2、Google从NoSQL转向NewSQL的历程

Google内部的存储系统，在自身业务需求的推动下，经历了几代系统的演变，Bigtable、Percolator、Megastore、NoSQL Spanner、F1、SQL Spanner，本质上是一个NoSQL到NoSQL+APP ACID到NoSQL+ACID到NoSQL with ACID到NoSQL with ACID+SQL到SQL的过程。

Percolator(2010，NoSQL+APP ACID)

该系统实现为一个基于Bigtable的业务系统，用于搜索索引的构建，作者在论文中指出了Bigtable对应用需求的限制：

Distributed storage systems like Bigtable can scale to the size of our repository but don't provide tools to help programmers maintain data invariants in the face of concurrent updates.

同时也描述了支持事务语义的好处：

...make it more tractable for the user to reason about the state of the system and to avoid the introduction of errors into a long-lived repository.

Percolator通过2PL技术实现了多行ACID事务：

...stores its locks in special in-memory columns in the same Bigtable that stores data and reads or modifies the locks in a Bigtable row transaction when accessing data in that row...

Megastore(2011，NoSQL+ACID)

该系统用于内部交互式在线NoSQL系统，作者在论文中也指出了实现事务语义的好处：

Despite the operational advantages of eventually consistent systems,it is currently too difficult to give up the read-modify-write idiom in rapid application development.

Megastore通过OCC技术实现了单分区上的ACID事务，但论文中并没有详细描述实现细节。

Spanner(2012，NoSQL with ACID)

该系统是第一个不依赖Bigtable，从头打造的分布式数据库系统，作者在论文中也强调了支持事务语义的好处：

...it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.

Spanner通过2PL技术实现了跨分区的多行ACID事务。

F1(2012，NoSQL with ACID + SQL)

该系统基于NoSQL Spanner实现为AdWords的存储系统，作者在论文中(同上)从业务视角直接陈述了事务和SQL的缺失对业务开发造成的影响：

...the complexity of dealing with a non-ACID data store in every part of our business logic would be too great, and there was simply no way our business could function without SQL queries.

F1借助Spanner基于乐观锁实现了乐观事务，并详尽描述了优缺点(无法避免幻读)，这个和数据库层面基于OCC技术实现的事务有本质的区别.

Spanner(2017，SQL)

该系统是一个全功能的SQL系统，作者在论文中再次强调了支持事务和SQL的重要性：

...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.

如果没有强表达能力的查询语言：

...developers had to write complex code to process and aggregate the data in their applications.

与此同时，作者对NoSQL with ACID + SQL的技术架构也寄予了高度的肯定：

A scalable, manageable, transactional key-value store is perhaps the lowest common denominator for building enterprise-strength global storage systems. It has been demonstrated by our colleagues from the F1 team that a transactional NoSQL core can be used to build a scalable SQL DBMS.

并且，在存储系统中松耦合还是紧耦合实现SQL还是一个需要认真讨论的问题：

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!