加入收藏 | 设为首页 | 会员中心 | 我要投稿 网站开发网_安阳站长网 (https://www.0518zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长百科 > 正文

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

发布时间:2019-01-31 05:02:05 所属栏目:站长百科 来源:龙逢
导读:副标题#e# 2018年4月20日,苹果宣布开源FoundationDB一款支持多种数据模型、高性能、高可用、可扩展,且具备ACID事务的分布式KV NoSQL系统。FoundationDB已在苹果公司内部的生产环境使用三年,主要用于iCloud上的云存储服务。 苹果于2015年收购开源的Founda

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的终止。
  • 严格性:先发生写操作的事务的提交或终止应先于其它冲突事务的提交或终止。

(编辑:网站开发网_安阳站长网)

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