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照旧一个必要当真接头的题目：

（编辑：河北网）

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