NewSQL究竟新在哪里？

                                       NewSQL究竟新在哪里？

本文来自技术博客：http://oserror.com/

微信订阅号有置顶功能，欢迎读者置顶架构文摘：ArchDigest

近几年来，数据库领域出现了一种新的关系数据库类型，称为NewSQL，例如，Google的Spanner，Amazon的Aurora等等，这些数据库相对于传统数据库来讲，区别在哪里？What’s Really New with NewSQL?给了很好的总结，本篇文章主要是总结该论文的观点，最后会有一个简单的讨论部分，全文的组织结构如下：

• 为什么需要NewSQL？

• NewSQL的分类

• NewSQL的技术挑战有哪些？

• 讨论

本文收录在我的github中papers项目，papers项目旨在学习和总结分布式系统相关的论文。

为什么需要NewSQL？

数据库的发展通常是随着业务需求的变化，在2000年左右，随着互联网的兴起，有许多同时在线的用户，这对数据库领域带来了非常大的挑战，数据库通常会成为瓶颈，所以，此时业务针对数据库的需求，主要体现在可扩展上面。

这时期数据库的扩展性，往往采用如下两种方案：

1. 垂直扩展：使用更好的硬件，来做数据库的服务器

2. 水平扩展：采用中间件，做sharding的方式，即分库分表的方式

垂直扩展中使用更好的硬件意味者成本高，并且更换硬件后，需要把数据从老的机器迁移到新的机器，中间可能需要停服务，因此往往采用水平扩展，例如，Google’s MySQL-based cluster。

采用中间件方式也有缺点，中间件一般要求轻量级，简单数据库操作可以搞定，但是，如果需要做分布式事务或者联表操作，会非常复杂，通常这些逻辑会放到应用层来做。

后续，NOSQL兴起，主要有几个原因：

1. 传统关系数据库更倾向于一致性，而在性能和可用性比较差

2. 全功能的关系型数据库太重

3. 关系模型对于简单的查询太重，不必要

NOSQL以Google’s BigTable 和 Amazon’s Dynamo为代表，开源版对应为HBase和Cassandra。

NOSQL往往是不保证强一致性的，而对于一些应用来讲（例如金融服务），是需要强一致性和事务的，因此，如果它们基于NOSQL系统来开发的话，应用层需要些大量的逻辑来处理一致性和事务相关的问题。此时，业务需求是拥有可扩展性的基础上，能够支持强一致性。

因此，这里有几条路：

1. 性能更好的单个服务器来做数据库服务器

2. 中间件层支持分布式事务

使用更好的单个服务器的话，不满足业务需求的可扩展性。

使用中间件的话，会有如下问题，例如：

1. 中间件层往往是比较轻量级的，要实现一致性，必须在中间件层实现分布式事务，这点是非常困难的

2. 中间件层本身的高可用很难保证

上面两条路都不能很好的满足应用的需求，因此，NewSQL出现了。

首先来看NEWSQL的定义：针对OLTP的读写，提供与NOSQL相同的可扩展性和性能，同时能支持满足ACID特性的事务。即保持NOSQL的高可扩展和高性能，并且保持关系模型。

NEWSQL的优点：

1. 轻松的获得可扩展性

2. 能够使用关系模型和事务，应用逻辑会简化很多

注意，此篇论文中的NEWSQL偏向于OLTP型数据库，和一些OLAP类型的数据库不同，OLAP数据库更偏向于复杂的只读查询，查询时间往往很长。

而NEWSQL数据库的特性如下，针对其读写事务：

1. 执行时间短

2. 一般只查询一小部分数据，通过使用索引来达到高效查询的目的

3. 一般执行相同的命令，使用不同的输入参数

NewSQL的分类

分三大类：

1. 从头开始，使用新架构的系统

2. 中间件

3. DAAS，数据库即服务

New Architectures

采用新架构的NewSQL有如下特点：

1. 无共享存储

2. 多节点的并发控制

3. 基于多副本做高可用和容灾

4. 流量控制

5. 分布式查询处理

优势：

1. 所有的部分都可以为分布式环境做优化，例如查询优化，通信协议优化。例如，所有的NEWSQL DBMS可以直接在节点间发送查询，而不是通过中心节点，例如中间件系统

2. 本身负责数据分区，因此，可以把查询发送给有数据的分区，而不是把数据发送给查询。

3. 拥有自身的存储，可以指定更复杂的多副本的方式

缺点：

1. 懂该数据库的人少，缺少专业的运维

代表产品：Spanner，CockroachDB

Transparent Sharding Middleware

中间件负责的事情如下：

1. 对查询请求做路由

2. 分布式事务的协调者

3. 数据分布，数据多副本控制，数据分区

往往在各个数据库节点，需要装代理与中间件沟通，负责如下事情：

1. 在本地节点执行中间节点发来的情况，并且返回结果

优点：

1. 应用通常不需要做变化

缺点：

1. 各个节点还是运行传统数据库，即以磁盘为核心的数据库，对现有的大内存，多核服务器难以高效地利用

2. 重复的查询计划和查询优化，在中间件做一次，在各个DBMS做一次

备注：有研究表明，以磁盘为主要存储的传统DBMS，很难有效地利用非常多的核，以及更大的内存容量。

代表产品: MariaDB MaxScale, ScaleArc

Database-as-a-Service

特点：

1. 用户可以按需使用

2. 数据库本身可能使用云产品，例如云存储等，可以较容易的实现可扩展性

代表产品：

1. Amazon Aurora

2. ClearDB

NewSQL的技术挑战有哪些？

Main Memory Storage

传统数据库都是以磁盘为存储中心的架构，读盘操作相对较慢，一般是内存中缓存页。

现在来讲，内存较便宜，容量大，能存储大量的数据。这些纯内存操作带来的好处是，读取和写入数据速度较快。

现有的大内存服务器，对数据库对内存的管理提出了新的要求，不再是像传统数据库那样，只是用来做页缓存，可以采用更高效地内存管理方式。

Partitioning/Sharding

数据分区一般以某几列做hash或者range分区。

特点：

• 数据库需要能在多个分区执行SQL，并且合并数据结果的功能。

• 把同一个用户的数据可以放在一起，即使是不同数据表的数据，可以减少通信开销。

• 可以在线的添加或者删除机器。

• 可以在线的迁移或复制分区。

Concurrency Control

数据库通过Concurrency Control来提供ACID中的Atomicity和Isolation。

Atomicity

分布式场景下，一般采用类2PC的协议，根据事务是否需要中心节点，分为以下两类：

1. 中心节点：单点，容量限制

2. 非中心节点：需要时钟的同步

关于时钟同步，不同数据库也有不同的做法，Spanner和CroachDB在时钟同步上的不同选择：

1

But what makes Spanner differ- ent is that it uses hardware devices (e.g., GPS, atomic clocks) for high-precision clock synchronization. The DBMS uses these clocks to assign timestamps to transactions to enforce consistent views of its multi-version database over wide-area networks. CockroachDB also purports to provide the same kind of consistency for transactions across data centers as Span- ner but without the use of atomic clocks. They instead rely on a hybrid clock protocol that combines loosely synchronized hardware clocks and logical counters [41].

Isolation

现有实现Isolation的技术主要包括：

• 2PL：two phase locking

• MVCC: Multiversion Concurrency Control

• OCC: Optimistic Concurrency Control

大部分的数据库还是在选择使用MVCC，例如CockroachDB；有些数据库使用2PL+MVCC，修改数据的时候，还是采用2PL，例如，InnoDB，Spanner 

Secondary Indexes

一般有两种实现方式：局部索引VS全局索引

局部索引：

1. 每个partition有一部分索引数据，每次修改索引，只需要修改一个节点，但查找数据需要可能涉及多个节点

全局索引：

1. 每个partition都有完整的索引数据，每次修改索引，都需要使用分布式事务，修改所有包含此索引副本的节点，查找数据只需要在一个节点

Replication

两个需要考虑的点：

1. 如何保证一致性：Paxos和2PC（跨Partition）

2. 同步的方式：采用同步执行命令的方式，还是同步状态的方式

Crash Recovery

如何最小化宕机时间？

采用主备切换

如何优化新加机器恢复到同步的时间？

一般手段为做checkpoint

讨论

可扩展性是NewSQL的一个非常重要的特点，对于中间件的方式，其上需要存路由信息，其本身的可扩展性比较难以解决，个人认为，其不应该算入NewSQL。

NewSQL的技术挑战除了上述提到的之外，还有如何实现多租户架构及租户之间的隔离，负载均衡等等问题。

从整篇论文中描述的内容可以看出，NewSQL中并没有开拓性的理论技术的创新，更多的是架构的创新，以及把现有的技术如何更好地适用于当今的服务器，适用于当前的分布式架构，使得这些技术有机的结合起来，形成高效率的整体，实现NewSQL高可用，可扩展，强一致性等需求。

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-