NewSQL

2018/11/18 |

Programming/ NewSQL

| Programming SQL NewSQL

NewSQL

Bigtable & NoSQL

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

从 NoSQL 转向 NewSQL

Spanner (2012/2017, NoSQL is Out and NewSQL is In) 是一个全功能的 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 还是一个需要认真讨论的问题：

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

它们的共同点是都依赖于一个支持事务的 NoSQL 基础系统。从这些项目的实现架构来看，主要分为两种：

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

事务并发控制

从 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 实现。

总结

• https://cloud.google.com/spanner/docs/overview
• https://cloud.google.com/spanner/docs/data-types
• https://cloud.google.com/spanner/docs/schema-design
• https://cloud.google.com/spanner/docs/sql-best-practices
• https://help.aliyun.com/document_detail/26481.html
• https://www.cockroachlabs.com/docs/stable/data-types.html
• https://pingcap.com/docs-cn/sql/datatype/
• https://github.com/pingcap/docs-cn/blob/master/op-guide/docker-compose.md

生产级 NewSQL 数据库	年份	并发控制	隔离级别	客户端
Cloud Spanner	2017	MVCC + SS2PL	Linearizability	ANSI 2011 SQL
OceanBase 2.0	2016	MVCC + SS2PL	RC	Oracle & MySQL wire protocol
CockroachDB 2.1.5	2017	MVCC + TO	SSI	PostgreSQL wire protocol
TiDB 2.1.4	2017	MVCC + SS2PL	SI	MySQL wire protocol
FoundationDB 6.0.18	2018	MVCC + OCC	SSI