网站建设资讯

NEWS

网站建设资讯

支持事务的nosql,支持事务的数据库有哪些

什么是NoSQL数据库?

2. 什么是NoSQL?

站在用户的角度思考问题,与客户深入沟通,找到鹤山网站设计与鹤山网站推广的解决方案,凭借多年的经验,让设计与互联网技术结合,创造个性化、用户体验好的作品,建站类型包括:成都做网站、成都网站制作、成都外贸网站建设、企业官网、英文网站、手机端网站、网站推广、申请域名网站空间、企业邮箱。业务覆盖鹤山地区。

2.1 NoSQL 概述

NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,

泛指非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题,包括超大规模数据的存储。

(例如谷歌或Facebook每天为他们的用户收集万亿比特的数据)。这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展。

2.2 NoSQL代表

MongDB、 Redis、Memcache

3. 关系型数据库与NoSQL的区别?

3.1 RDBMS

高度组织化结构化数据

结构化查询语言(SQL)

数据和关系都存储在单独的表中。

数据操纵语言,数据定义语言

严格的一致性

基础事务

ACID

关系型数据库遵循ACID规则

事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性:

A (Atomicity) 原子性

原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚。比如银行转账,从A账户转100元至B账户,分为两个步骤:1)从A账户取100元;2)存入100元至B账户。这两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了100元。

C (Consistency) 一致性

一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。

I (Isolation) 独立性

所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的

D (Durability) 持久性

持久性是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失。

3.2 NoSQL

代表着不仅仅是SQL

没有声明性查询语言

没有预定义的模式

键 - 值对存储,列存储,文档存储,图形数据库

最终一致性,而非ACID属性

非结构化和不可预知的数据

CAP定理

高性能,高可用性和可伸缩性

分布式数据库中的CAP原理(了解)

CAP定理:

Consistency(一致性), 数据一致更新,所有数据变动都是同步的

Availability(可用性), 好的响应性能

Partition tolerance(分区容错性) 可靠性

P: 系统中任意信息的丢失或失败不会影响系统的继续运作。

定理:任何分布式系统只可同时满足二点,没法三者兼顾。

CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,

因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:

CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。

CP - 满足一致性,分区容忍性的系统,通常性能不是特别高。

AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。

而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。

所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。

说明:C:强一致性 A:高可用性 P:分布式容忍性

举例:

CA:传统Oracle数据库

AP:大多数网站架构的选择

CP:Redis、Mongodb

注意:分布式架构的时候必须做出取舍。

一致性和可用性之间取一个平衡。多余大多数web应用,其实并不需要强一致性。

因此牺牲C换取P,这是目前分布式数据库产品的方向。

4. 当下NoSQL的经典应用

当下的应用是 SQL 与 NoSQL 一起使用的。

代表项目:阿里巴巴商品信息的存放。

去 IOE 化。

ps:I 是指 IBM 的小型机,很贵的,好像好几万一台;O 是指 Oracle 数据库,也很贵的,好几万呢;M 是指 EMC 的存储设备,也很贵的。

难点:

数据类型多样性。

数据源多样性和变化重构。

数据源改造而服务平台不需要大面积重构。

NoSQL是什么意思

什么是NoSQL数据库?从名称“非SQL”或“非关系型”衍生而来,这些数据库不使用类似SQL的查询语言,通常称为结构化存储。这些数据库自1960年就已经存在,但是直到现在一些大公司(例如Google和Facebook)开始使用它们时,这些数据库才流行起来。该数据库最明显的优势是摆脱了一组固定的列、连接和类似SQL的查询语言的限制。有时,NoSQL这个名称也可能表示“不仅仅SQL”,来确保它们可能支持SQL。 NoSQL数据库使用诸如键值、宽列、图形或文档之类的数据结构,并且可以如JSON之类的不同格式存储。

如何搞定NoSQL事务机制

在SequoiaDB巨杉数据库联合创始人兼CTO王涛看来,目前只有少量的NoSQL数据库支持事务机制,如VoltDB、RavenDB、SequoiaDB、MarkLogic。并且,“NoSQL支持事务(ACID)是未来的趋势,不支持事务的NoSQL会大大缩小其应用场景。”对于ACID来说,是指数据库事务机制正确执行的四大基本要素,包含了:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。

如何选择NoSQL数据库

NoSQL,指的是非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的

SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

NoSQL(NoSQL

= Not Only SQL

),意即“不仅仅是SQL”,是一项全新的数据库革命性运动,早期就有人提出,发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数

据存储,相对于铺天盖地的关系型数据库运用,这一概念无疑是一种全新的思维的注入。

从这一新兴技术中选择一款正确的NoSQL数据库是非常具有挑战性的。比一下网建议在选择时考虑以下因素:

并发控制

发控制指的是当多个用户同时更新运行时,用于保护数据库完整性的各种技术。并发机制不正确可能导致脏读、幻读和不可重复读等此类问题。并发控制的目的是保

证一个用户的工作不会对另一个用户的工作产生不合理的影响。在某些情况下,这些措施保证了当用户和其他用户一起操作时,所得的结果和她单独操作时的结果是

一样的。在另一些情况下,这表示用户的工作按预定的方式受其他用户的影响。

封锁

就是事务T在对某个数据对象(例如表、记录等)操作之前,先向系统发出请求,对其加锁。加锁后事务T就对该数据对象有了一定的控制,在事务T释放它的锁之前,其它的事务不能更新此数据对象。

封锁是一次只允许一个用户读取或修改的一种机制,是实现并发控制的一个非常重要的技术。

MVCC

Multi-Version Concurrency Control多版本并发控制,维持一个数据的多个版本使读写操作没有冲突。MVCC优化了数据库并发系统,使系统在有大量并发用户时得到最高的性能,并且可以不用关闭服务器就直接进行热备份。

ACID

数据库事务正确执行的四个基本要素的缩写。包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久

性(Durability)。一个支持事务(Transaction)的数据库系统,必需要具有这四种特性,否则在事务过程(Transaction

processing)当中无法保证数据的正确性,交易过程极可能达不到交易方的要求。

None

一些系统不提供原子性。

镜像

数据库镜像是DBMS根据DBA的要求,自动把整个数据库或其中的关键数据复制到另一个磁盘上,每当主数据库更新时,DBMS会自动把更新后的数据复制过去,即DBMS自动保证镜像数据与主数据的一致性。

镜像分为同步和异步。

数据存储

指的是数据的物理特性怎样被存储在数据库中。

磁盘 数据被存储在硬盘驱动器里;

GFS或谷歌文件系统是一个由谷歌开发的专有的分布式文件系统;

Hadoop是Apache软件框架,免费许可下支持数据密集型分布式应用程序;

RAM随机存储器;

插件 可以添加外部插件;

Amazon S3通过Web服务接口提供存储;

BDB:BDB

全称是 “Berkeley DB”,它是MySQL具有事务能力的表类型,由Sleepycat

Software开发。BDB表类型提供了MySQL用户长久期盼的功能,即事务控制能力。在任何RDBMS中,事务控制能力都是一种极其重要和宝贵的功

能。事务控制能力使得我们能够确保一组命令确实已经全部执行成功,或者确保当任何一个命令出现错误时所有命令的执行结果均被退回。

实现语言

实现语言会影响数据库的发展速度。典型的NoSQL数据库是用低级语言如C / C + +编写的。另一方面,那些更高层次的语言如Java,使自定义更容易。

实现语言有:C, C++, Erlang, Java, Python

特性

考虑下列哪一个特点对你的数据库是最重要的:

持久性

可用性

一致性

分区容忍性

证书类型

下面这些许可证是一个不同的开放源码许可的形式:

GPL:通用公共许可证

BSD:伯克利软件分发

MPL:Mozilla公共许可证

EPL:Eclipse公共许可证

IDPL:最初的开发者的公共许可证

LGPL:较宽松通用公共许可证

存储类型

存储类型是NoSQL数据库最大的不同,是决定使用哪款数据库的一个首要指标。

关键字:支持get、put和删除操作

按列存储:相对于传统的按行存储,数据集成容易多了

面向文件系统:存储像是JSON或XML这样的结构化文件,很容易就能从面向对象软件中获取数据。

nosql数据库是什么 具有代表性以key-value的形式存储的

什么是NoSQL

大家有没有听说过“NoSQL”呢?近年,这个词极受关注。看到“NoSQL”这个词,大家可能会误以为是“No!SQL”的缩写,并深感愤怒:“SQL怎么会没有必要了呢?”但实际上,它是“Not Only SQL”的缩写。它的意义是:适用关系型数据库的时候就使用关系型数据库,不适用的时候也没有必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储。

为弥补关系型数据库的不足,各种各样的NoSQL数据库应运而生。

为了更好地了解本书所介绍的NoSQL数据库,对关系型数据库的理解是必不可少的。那么,就让我们先来看一看关系型数据库的历史、分类和特征吧。

关系型数据库简史

1969年,埃德加?6?1弗兰克?6?1科德(Edgar Frank Codd)发表了划时代的论文,首次提出了关系数据模型的概念。但可惜的是,刊登论文的《IBM Research Report》只是IBM公司的内部刊物,因此论文反响平平。1970年,他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文,终于引起了大家的关注。

科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升,加之使用简单、性能优越等优点,关系型数据库得到了广泛的应用。

通用性及高性能

虽然本书是讲解NoSQL数据库的,但有一个重要的大前提,请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低,它具有非常好的通用性和非常高的性能”。毫无疑问,对于绝大多数的应用来说它都是最有效的解决方案。

突出的优势

关系型数据库作为应用广泛的通用型数据库,它的突出优势主要有以下几点:

保持数据的一致性(事务处理)

由于以标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处)

可以进行JOIN等复杂查询

存在很多实际成果和专业技术信息(成熟的技术)

这其中,能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性和处理完整性的情况下,用关系型数据库是肯定没有错的。但是有些情况不需要JOIN,对上述关系型数据库的优点也没有什么特别需要,这时似乎也就没有必要拘泥于关系型数据库了。

关系型数据库的不足

不擅长的处理

就像之前提到的那样,关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库,并不能完全适应所有的用途。具体来说它并不擅长以下处理:

大量数据的写入处理

为有数据更新的表做索引或表结构(schema)变更

字段不固定时应用

对简单查询需要快速返回结果的处理

。。。。。。

NoSQL数据库

为了弥补关系型数据库的不足(特别是最近几年),NoSQL数据库出现了。关系型数据库应用广泛,能进行事务处理和JOIN等复杂处理。相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处。

易于数据的分散

如前所述,关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的,就是说,各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理,关系型数据库不得不把数据存储在同一个服务器内,这不利于数据的分散。相反,NoSQL数据库原本就不支持JOIN处理,各个数据都是独立设计的,很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上,减少了每个服务器上的数据量,即使要进行大量数据的写入操作,处理起来也更加容易。同理,数据的读入操作当然也同样容易。

提升性能和增大规模

下面说一点题外话,如果想要使服务器能够轻松地处理更大量的数据,那么只有两个选择:一是提升性能,二是增大规模。下面我们来整理一下这两者的不同。

首先,提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法,程序方面也不需要进行变更,但需要一些费用。若要购买性能翻倍的服务器,需要花费的资金往往不只是原来的2倍,可能需要多达5到10倍。这种方法虽然简单,但是成本较高。

另一方面,增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更,但由于使用廉价的服务器,可以控制成本。另外,以后只要依葫芦画瓢增加廉价服务器的数量就可以了。

不对大量数据进行处理的话就没有使用的必要吗?

NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话,NoSQL数据库的应用就没有意义吗?

答案是否定的。的确,它在处理大量数据方面很有优势。但实际上NoSQL数据库还有各种各样的特点,如果能够恰当地利用这些特点将会是非常有帮助。具体的例子将会在第2章和第3章进行介绍,这些用途将会让你感受到利用NoSQL的好处。

希望顺畅地对数据进行缓存(Cache)处理

希望对数组类型的数据进行高速处理

希望进行全部保存

多样的NoSQL数据库

NoSQL数据库存在着“key-value存储”、“文档型数据库”、“列存储数据库”等各种各样的种类,每种数据库又包含各自的特点。下一节让我们一起来了解一下NoSQL数据库的种类和特点。

NoSQL数据库是什么

NoSQL说起来简单,但实际上到底有多少种呢?我在提笔的时候,到NoSQL的官方网站上确认了一下,竟然已经有122种了。另外官方网站上也介绍了本书没有涉及到的图形数据库和对象数据库等各个类别。不知不觉间,原来已经出现了这么多的NoSQL数据库啊。

本节将为大家介绍具有代表性的NoSQL数据库。

key-value存储

这是最常见的NoSQL数据库,它的数据是以key-value的形式存储的。虽然它的处理速度非常快,但是基本上只能通过key的完全一致查询获取数据。根据数据的保存方式可以分为临时性、永久性和两者兼具三种。

临时性

memcached属于这种类型。所谓临时性就是 “数据有可能丢失”的意思。memcached把所有数据都保存在内存中,这样保存和读取的速度非常快,但是当memcached停止的时候,数据就不存在了。由于数据保存在内存中,所以无法操作超出内存容量的数据(旧数据会丢失)。

在内存中保存数据

可以进行非常快速的保存和读取处理

数据有可能丢失

永久性

Tokyo Tyrant、Flare、ROMA等属于这种类型。和临时性相反,所谓永久性就是“数据不会丢失”的意思。这里的key-value存储不像memcached那样在内存中保存数据,而是把数据保存在硬盘上。与memcached在内存中处理数据比起来,由于必然要发生对硬盘的IO操作,所以性能上还是有差距的。但数据不会丢失是它最大的优势。

在硬盘上保存数据

可以进行非常快速的保存和读取处理(但无法与memcached相比)

数据不会丢失

两者兼具

Redis属于这种类型。Redis有些特殊,临时性和永久性兼具,且集合了临时性key-value存储和永久性key-value存储的优点。Redis首先把数据保存到内存中,在满足特定条件(默认是15分钟一次以上,5分钟内10个以上,1分钟内10000个以上的key发生变更)的时候将数据写入到硬盘中。这样既确保了内存中数据的处理速度,又可以通过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。

同时在内存和硬盘上保存数据

可以进行非常快速的保存和读取处理

保存在硬盘上的数据不会消失(可以恢复)

适合于处理数组类型的数据

面向文档的数据库

MongoDB、CouchDB属于这种类型。它们属于NoSQL数据库,但与key-value存储相异。

不定义表结构

面向文档的数据库具有以下特征:即使不定义表结构,也可以像定义了表结构一样使用。关系型数据库在变更表结构时比较费事,而且为了保持一致性还需修改程序。然而NoSQL数据库则可省去这些麻烦(通常程序都是正确的),确实是方便快捷。

可以使用复杂的查询条件

跟key-value存储不同的是,面向文档的数据库可以通过复杂的查询条件来获取数据。虽然不具备事务处理和JOIN这些关系型数据库所具有的处理能力,但除此以外的其他处理基本上都能实现。这是非常容易使用的NoSQL数据库。

不需要定义表结构

可以利用复杂的查询条件

面向列的数据库

Cassandra、Hbase、HyperTable属于这种类型。由于近年来数据量出现爆发性增长,这种类型的NoSQL数据库尤其引人注目。

面向行的数据库和面向列的数据库

普通的关系型数据库都是以行为单位来存储数据的,擅长进行以行为单位的读入处理,比如特定条件数据的获取。因此,关系型数据库也被称为面向行的数据库。相反,面向列的数据库是以列为单位来存储数据的,擅长以列为单位读入数据。

高扩展性

面向列的数据库具有高扩展性,即使数据增加也不会降低相应的处理速度(特别是写入速度),所以它主要应用于需要处理大量数据的情况。另外,利用面向列的数据库的优势,把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同,应用起来十分困难。

高扩展性(特别是写入处理)

应用十分困难

最近,像Twitter和Facebook这样需要对大量数据进行更新和查询的网络服务不断增加,面向列的数据库的优势对其中一些服务是非常有用的,但是由于这与本书所要介绍的内容关系不大,就不进行详细介绍了。

总结:

NoSQL并不是No-SQL,而是指Not Only SQL。

NoSQL的出现是为了弥补SQL数据库因为事务等机制带来的对海量数据、高并发请求的处理的性能上的欠缺。

NoSQL不是为了替代SQL而出现的,它是一种替补方案,而不是解决方案的首选。

绝大多数的NoSQL产品都是基于大内存和高性能随机读写的(比如具有更高性能的固态硬盘阵列),一般的小型企业在选择NoSQL时一定要慎重!不要为了NoSQL而NoSQL,可能会导致花了冤枉钱又耽搁了项目进程。

NoSQL不是万能的,但在大型项目中,你往往需要它!

nosql是什么

NoSQL,泛指非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题。

虽然NoSQL流行语火起来才短短一年的时间,但是不可否认,现在已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验,然而现在的系统已经更加的成熟、稳定。不过现在也面临着一个严酷的事实:技术越来越成熟——以至于原来很好的NoSQL数据存储不得不进行重写,也有少数人认为这就是所谓的2.0版本。这里列出一些比较知名的工具,可以为大数据建立快速、可扩展的存储库。

NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,是一项全新的数据库革命性运动,早期就有人提出,发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储,相对于铺天盖地的关系型数据库运用,这一概念无疑是一种全新的思维的注入。

对于NoSQL并没有一个明确的范围和定义,但是他们都普遍存在下面一些共同特征:

不需要预定义模式:不需要事先定义数据模式,预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时,并不需要预先定义它们的模式。

无共享架构:相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能,从而提高了系统的性能。

弹性可扩展:可以在系统运行的时候,动态增加或者删除结点。不需要停机维护,数据可以自动迁移。

分区:相对于将数据存放于同一个节点,NoSQL数据库需要将数据进行分区,将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能,又能保证没有单点失效的问题。

异步复制:和RAID存储系统不同的是,NoSQL中的复制,往往是基于日志的异步复制。这样,数据就可以尽快地写入一个节点,而不会被网络传输引起迟延。缺点是并不总是能保证一致性,这样的方式在出现故障的时候,可能会丢失少量的数据。

BASE:相对于事务严格的ACID特性,NoSQL数据库保证的是BASE特性。BASE是最终一致性和软事务。

NoSQL数据库并没有一个统一的架构,两种NoSQL数据库之间的不同,甚至远远超过两种关系型数据库的不同。可以说,NoSQL各有所长,成功的NoSQL必然特别适用于某些场合或者某些应用,在这些场合中会远远胜过关系型数据库和其他的NoSQL。


标题名称:支持事务的nosql,支持事务的数据库有哪些
文章URL:http://cdweb.net/article/dsspcio.html