NewSQL 究竟新在哪里?

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

  • 为何须要NewSQL?
  • NewSQL的分类
  • NewSQL的技术挑战有哪些?
  • 讨论

本文收录在个人github中papers项目,papers项目旨在学习和总结分布式系统相关的论文。
同时本文也同步发布在我的博客oserror.comjava

为何须要NewSQL?

数据库的发展一般是随着业务需求的变化,在2000年左右,随着互联网的兴起,有许多同时在线的用户,这对数据库领域带来了很是大的挑战,数据库一般会成为瓶颈,因此,此时业务针对数据库的需求,主要体如今可扩展上面。git

这时期数据库的扩展性,每每采用以下两种方案:github

  1. 垂直扩展:使用更好的硬件,来作数据库的服务器
  2. 水平扩展:采用中间件,作sharding的方式,即分库分表的方式

垂直扩展中使用更好的硬件意味者成本高,而且更换硬件后,须要把数据从老的机器迁移到新的机器,中间可能须要停服务,所以每每采用水平扩展,例如,Google's MySQL-based cluster。sql

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

后续,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在时钟同步上的不一样选择:

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高可用,可扩展,强一致性等需求。

PS:
本博客更新会在第一时间推送到微信公众号,欢迎你们关注。

qocde_wechat

参考文献

相关文章
相关标签/搜索