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

both the loosely coupled (in case of F1) and tightly coupled SQL designs can be deployed successfully, and even simultaneously, on a transactional NoSQL core. A detailed exploration of the pros and cons of these designs is still outstanding. But it is perhaps fair to say that from the perspective of many engineers working on the Google infrastructure, the SQL vs NoSQL dichotomy may no longer be relevant.

二、NewSQL的繁荣?

根据论文中的定义，NewSQL的核心特性如下：

• 支持SQL接口。
• 支持ACID事务语义。
• 在OLTP场景下具备NoSQL的高性能、高可用、高扩展性。

Spanner和F1论文发表至今，催生了一些优秀的NewSQL开源项目：

• 2015年6月4日，前Google员工创办CockroachDB;2015年融资600万美元;2016年融资2000万美元;2017年融资2700万美元。
• 2015年中，前豌豆荚员工发布TiDB;2017年融资1500万美元。
• 2015年5月24日，HP开源Trafodion，一款基于HBase，支持ACID事务、SI隔离级别的SQL数据库;2018年1月10日，Apache宣布Trafodion成为顶级项目。
• 2017年11月2日，前Facebook员工创办YugaByte DB;2017年融资800万美元;2018年融资1600万美元。

从这些项目的实现架构来看，主要分为两种：

• 原生实现：如CockroachDB、YugaByteDB
• NoSQL+ACID+SQL：如TiDB、Trafodion

VoltDB在评价FoundationDB的博文中对NoSQL+ACID+SQL架构下SQL实现的性能表示了质疑，这种架构的主要技术缺陷是计算无法下沉到存储节点会导致大量的网络传输开销。

然而，2017年Google的Spanner论文中已经将类似这种架构的F1与SQL Spanner相提并论，两种架构的优劣性仍然有待观察和研究，但它们的共同点是都依赖于一个支持事务的NoSQL基础系统。从这个视角来看，以下这些支持事务的NoSQL系统也具备演变成NewSQL的可能性：

• 2009年，FoundationDB开源，基于MVCC NoSQL，支持SSI隔离级别;2015年闭源;2018年4月开源。
• 2016年3月28日，Yahoo开源Omid，基于HBase，支持SI隔离级别;后续闭源，商业化为LeanXscale，同时支持SQL。
• 2016年3月7日，Tephra开源，基于HBase，支持SI隔离级别;由Cask公司商业化运作。
• 2018年2月15日，MongoDB宣布将在今年夏季发布的4.0版本中支持多文档ACID事务，基于WiredTiger存储引擎改造。

三、事务的心脏——并发控制

从上述章节NewSQL的发展趋势来看，ACID事务的回归是必然的，而且在分布式场景下，均致力于实现可扩展、高性能的串行化隔离级别，这在传统数据库的实现中是难以达到的。事务管理的核心技术是并发控制，原子性、一致性、隔离性都与它相关，本章简单科普一下事务并发控制技术。

事务的并发控制是为了实现事务的调度。

一个正确、高效的事务调度应满足如下属性：

• 可串行化：多个并发事务的调度S与一个串行化的调度产生相同的结果，则称这个调度S是可串行化的;在数据库实现中，一般使用冲突可串行化技术。
• 可恢复性：已经提交的事务没有读过被终止的事务写过的数据，防止脏读异常。
• 避免级联终止：避免由于事务T1的终止而导致事务T2的终止。
• 严格性：先发生写操作的事务的提交或终止应先于其它冲突事务的提交或终止。

并发控制从实现思路维度可以分为如下三类：

• 乐观：重在事后检测，在事务提交时检查是否满足隔离级别。满足，则提交;否则回滚并自动重新执行。
• 悲观：重在事前预防，在事务执行时检查是否满足隔离级别。满足，则继续执行;否则等待或回滚。
• 半乐观：混合使用乐观和悲观技术实现事务并发控制。

并发控制从实现方式维度可以分为如下几种：

• 基于锁的并发控制

2PL(two-phase locking)：事务在执行期间被明确的划分为growing和shrinking阶段，growing阶段只能持有锁不能释放锁;shrinking阶段只能释放锁不能持有锁，仅满足可恢复性;

S2PL(strict two-phase locking)：在满足2PL的前提下，要求持有的排它锁必须在事务提交后才释放，避免了级联回滚;

SS2PL(strong strict two-phase locking)：在满足2PL的前提下，要求事务提交之前不得释放任何锁，保证了严格性。

• 基于时间戳的并发控制

在事务开始时生成一个单调递增的时间戳，数据项上维护最近读时间戳和最近写时间戳。每次读写操作，系统都会将事务时间戳与数据项上的时间戳进行检查，对于任意读写操作，如果事务时间戳小于数据项的最近写时间戳，则将事务回滚;对于写操作，如果事务时间戳小于数据项的最近读时间戳，则将事务回滚;如果都满足，则继续访问下一个数据项。

• 基于OCC的并发控制

事务的生命周期被划分为三个阶段，将串行化检测推迟到提交阶段：

读阶段：事务写操作仅是对事务私有空间中数据的更新，并不对数据库中的数据项进行真实的更新，保证读阶段没有任何事务冲突及锁开销;

验证阶段：检测事务是否满足串行化隔离级别;

写阶段：将事务私有空间中的更新数据写入数据库。

• 基于多版本的并发控制

每一次写操作会生成一个新的数据项版本，数据项的版本号可以使用事务的时间戳或事务号;系统维护多个数据版本，读操作根据所在事务的时间戳或事务号能够读到指定的版本，做到读-写或写-读操作不阻塞，写-写操作的冲突依赖2PL实现。

上述只是传统数据库时代总结的并发控制技术，在分布式场景下一般会采用MVCC与其它并发控制技术的组合，目的是提高并发度，减小同步开销。

四、悲观还是乐观

在了解了数据库的基本并发控制技术后，本章针对现今感兴趣的生产级NewSQL分布式数据库使用的并发控制技术进行了简单的总结：

由上表可以看出，FoundationDB是第一个使用OCC技术实现ACID事务的生产级数据库系统(严格地说，Google的MegaStore也使用了OCC并用于Google APP Engine等业务，但它的ACID事务实现仅作用于单个分区)。

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

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