nosql在云运用的优势,nosql数据库的明显优势在于

为什么海量数据场景中NoSQL越来越重要

本质是因为：随着互联网的进一步发展与各行业信息化建设进程加快、参与者的增多，人们对软件有了更多更新的要求，需要软件不仅能实现功能，而且要求保证许多人可以共同参与使用，因而软件所需承载的数据量和吞吐量必须达到相应的需求。而目前的关系型数据库在某些方面有一些缺点，导致不能满足需要。

成都创新互联是一家专注于成都网站建设、网站建设与策划设计,进贤网站建设哪家好?成都创新互联做网站,专注于网站建设十多年,网设计领域的专业建站公司;建站业务涵盖:进贤等地区。进贤做网站价格咨询:028-86922220

具体则需要对比关系型数据库与Nosql之间的区别可以得出

关系型数据库

关系型数据库把所有的数据都通过行和列的二元表现形式表示出来。

关系型数据库的优势：

1. 保持数据的一致性（事务处理）

2.由于以标准化为前提，数据更新的开销很小（相同的字段基本上都只有一处）

3. 可以进行Join等复杂查询

其中能够保持数据的一致性是关系型数据库的最大优势。

关系型数据库的不足：

不擅长的处理

1. 大量数据的写入处理（这点尤为重要）

2. 为有数据更新的表做索引或表结构（schema）变更

3. 字段不固定时应用

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

--大量数据的写入处理

读写集中在一个数据库上让数据库不堪重负，大部分网站已使用主从复制技术实现读写分离，以提高读写性能和读库的可扩展性。

所以在进行大量数据操作时，会使用数据库主从模式。数据的写入由主数据库负责，数据的读入由从数据库负责，可以比较简单地通过增加从数据库来实现规模化，但是数据的写入却完全没有简单的方法来解决规模化问题。

第一，要想将数据的写入规模化，可以考虑把主数据库从一台增加到两台，作为互相关联复制的二元主数据库使用，确实这样可以把每台主数据库的负荷减少一半，但是更新处理会发生冲突，可能会造成数据的不一致，为了避免这样的问题，需要把对每个表的请求分别分配给合适的主数据库来处理。

第二，可以考虑把数据库分割开来，分别放在不同的数据库服务器上，比如将不同的表放在不同的数据库服务器上，数据库分割可以减少每台数据库服务器上的数据量，以便减少硬盘IO的输入、输出处理，实现内存上的高速处理。但是由于分别存储字不同服务器上的表之间无法进行Join处理，数据库分割的时候就需要预先考虑这些问题，数据库分割之后，如果一定要进行Join处理，就必须要在程序中进行关联，这是非常困难的。

--为有数据更新的表做索引或表结构变更

在使用关系型数据库时，为了加快查询速度需要创建索引，为了增加必要的字段就一定要改变表结构，为了进行这些处理，需要对表进行共享锁定，这期间数据变更、更新、插入、删除等都是无法进行的。如果需要进行一些耗时操作，例如为数据量比较大的表创建索引或是变更其表结构，就需要特别注意，长时间内数据可能无法进行更新。

--字段不固定时的应用

如果字段不固定，利用关系型数据库也是比较困难的，有人会说，需要的时候加个字段就可以了，这样的方法也不是不可以，但在实际运用中每次都进行反复的表结构变更是非常痛苦的。你也可以预先设定大量的预备字段，但这样的话，时间一长很容易弄不清除字段和数据的对应状态，即哪个字段保存有哪些数据。

--对简单查询需要快速返回结果的处理  （这里的“简单”指的是没有复杂的查询条件）

这一点称不上是缺点，但不管怎样，关系型数据库并不擅长对简单的查询快速返回结果，因为关系型数据库是使用专门的sql语言进行数据读取的，它需要对sql与越南进行解析，同时还有对表的锁定和解锁等这样的额外开销，这里并不是说关系型数据库的速度太慢，而只是想告诉大家若希望对简单查询进行高速处理，则没有必要非使用关系型数据库不可。

NoSQL数据库

关系型数据库应用广泛，能进行事务处理和表连接等复杂查询。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。

优点：

易于数据的分散

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

典型的NoSQL数据库

临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase）

一、 键值存储

它的数据是以键值的形式存储的，虽然它的速度非常快，但基本上只能通过键的完全一致查询获取数据，根据数据的保存方式可以分为临时性、永久性和两者兼具 三种。

（1）临时性

所谓临时性就是数据有可能丢失，memcached把所有数据都保存在内存中，这样保存和读取的速度非常快，但是当memcached停止时，数据就不存在了。由于数据保存在内存中，所以无法操作超出内存容量的数据，旧数据会丢失。总结来说：

。在内存中保存数据

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

。数据有可能丢失

（2）永久性

所谓永久性就是数据不会丢失，这里的键值存储是把数据保存在硬盘上，与临时性比起来，由于必然要发生对硬盘的IO操作，所以性能上还是有差距的，但数据不会丢失是它最大的优势。总结来说：

。在硬盘上保存数据

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

。数据不会丢失

（3） 两者兼备

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

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

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

。保存在硬盘上的数据不会消失（可以恢复）

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

二、面向文档的数据库

MongoDB、CouchDB属于这种类型，它们属于NoSQL数据库，但与键值存储相异。

（1）不定义表结构

即使不定义表结构，也可以像定义了表结构一样使用，还省去了变更表结构的麻烦。

（2）可以使用复杂的查询条件

跟键值存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据，虽然不具备事务处理和Join这些关系型数据库所具有的处理能力，但初次以外的其他处理基本上都能实现。

三、 面向列的数据库

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

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

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

总结：关系型数据库与NoSQL数据库并非对立而是互补的关系，即通常情况下使用关系型数据库，在适合使用NoSQL的时候使用NoSQL数据库，让NoSQL数据库对关系型数据库的不足进行弥补。

什么是NoSQL，它有什么优缺点？

NoSQL，指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。

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

NoSQL的优点/缺点

优点:

- 高可扩展性

- 分布式计算

- 低成本

- 架构的灵活性，半结构化数据

- 没有复杂的关系

缺点:

- 没有标准化

- 有限的查询功能（到目前为止）

- 最终一致是不直观的程序 （BY三人行慕课）

简述什么是nosql数据库，并列举两种常见的nosql数据库名称及其特点

NoSQL太火，冒出太多产品了，保守估计也成百上千了。

互联网公司常用的基本集中在以下几种，每种只举一个比较常见或者应用比较成功的例子吧。

1. In-Memory KV Store : Redis

in memory key-value store，同时提供了更加丰富的数据结构和运算的能力，成功用法是替代memcached，通过checkpoint和commit log提供了快速的宕机恢复，同时支持replication提供读可扩展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盘的key-value storage, 模型单一简单，数据量不受限于内存大小，数据落盘高可靠，Google的几位大神出品的精品，LSM模型天然写优化，顺序写盘的方式对于新硬件ssd再适合不过了，不足是仅提供了一个库，需要自己封装server端。

3. Document Store: Mongodb

分布式nosql，具备了区别mysql的最大亮点：可扩展性。mongodb 最新引人的莫过于提供了sql接口，是目前nosql里最像mysql的，只是没有ACID的特性，发展很快，支持了索引等特性，上手容易，对于数据量远超内存限制的场景来说，还需要慎重。

4. Column Table Store: HBase

这个富二代似乎不用赘述了，最大的优势是开源，对于普通的scan和基于行的get等基本查询，性能完全不是问题，只是只提供裸的api,易用性上是短板，可扩展性方面是最强的，其次坐上了Hadoop的快车，社区发展很快，各种基于其上的开源产品不少，来解决诸如join、聚集运算等复杂查询。

NoSQL中的灵活性具体体现在哪里

Nosql:“非关系型数据库”能够以两种基本的方式带来业务灵活性。

模式自由的逻辑数据模型有助于在为任何业务进行调整时带来更快的周转时间，把对现有应用和功能造成影响减到最少。在大多数情况下因任意的变更而给你带来的迁移工作几乎为零。

水平伸缩性能够在当越来越多的用户负载造成负载周期性变化，或者应用突然变更的使用模式时，提供坚固的保障。面向水平伸缩性的架构也是迈向基于SLA构建(例如云)的第一步，这样才能保证在不断变化的使用情形下业务的延续性。

为什么要使用NoSQL？NOSQL的优势

非常荣幸能受邀在InfoQ开辟这样一个关于NoSQL的专栏，InfoQ是我非常尊重的一家技术媒体，同时我也希望借助InfoQ，在国内推动NoSQL的发展，希望跟我一样有兴趣的朋友加入进来。这次的NoSQL专栏系列将先整体介绍NoSQL，然后介绍如何把NoSQL运用到自己的项目中合适的场景中，还会适当地分析一些成功案例，希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。 NoSQL概念随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。） NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前，这些数据库就被用于各种系统当中，但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。 传统关系数据库的瓶颈 传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。 到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期，论坛的流量其实也不大，如果你接触网络比较早，你可能还记得那个时候还有文本型存储的论坛程序，可以想象一般的论坛的流量有多大。 Memcached+MySQL 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时，如果你去面试，你说你有Memcached经验，肯定会加分的。 Mysql主从读写分离 由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。 分表分库随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。 MySQL的扩展性瓶颈 在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又需要一种新的分库方式。 MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。 关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。 NOSQL的优势易扩展NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。 大数据量，高性能 NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。 灵活的数据模型 NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。 高可用NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。 总结NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。 MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在存储上。

什么是New SQL?分析NewSQL是如何融合NoSQL和RDBMS两者的优势

NewSQL是对一类现代关系型数据库的统称，这类数据库对于一般的OLTP读写请求提供可横向扩展的性能，同时支持事务的ACID保证。这些系统既拥有NoSQL数据库的扩展性，又保持传统数据库的事务特性。NewSQL重新将“应用程序逻辑与数据操作逻辑应该分离”的理念带回到现代数据库的世界，这也验证了历史的发展总是呈现出螺旋上升的形式。

在21世纪00年代中，出现了许多数据仓库系统 (如 Vertica，Greeplum 和AsterData)，这些以处理OLAP 请求为设计目标的系统并不在本文定义的NewSQL范围内。OLAP 数据库更关注针对海量数据的大型、复杂、只读的查询，查询时间可能持续秒级、分钟级甚至更长。

NoSQL的拥趸普遍认为阻碍传统数据库横向扩容、提高可用性的原因在于ACID保证和关系模型，因此NoSQL运动的核心就是放弃事务强一致性以及关系模型，拥抱最终一致性和其它数据模型 (如 key/value，graphs 和Documents)。

两个最著名的NoSQL数据库就是Google的BigTable和Amazon的Dynamo，由于二者都未开源，其它组织就开始推出类似的开源替代项目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些创业公司也加入到这场NoSQL运动中，它们不一定是受BigTable和Dynamo的启发，但都响应了NoSQL的哲学，其中最出名的就是MongoDB。

在21世纪00年代末，市面上已经有许多供用户选择的分布式数据库产品。使用NoSQL的优势在于应用开发者可以更关注应用逻辑本身，而非数据库的扩展性问题；但与此同时许多应用，如金融系统、订单处理系统，由于无法放弃事务的一致性要求被拒之门外。

一些组织，如Google，已经发现他们的许多工程师将过多的精力放在处理数据一致性上，这既暴露了数据库的抽象、又提高了代码的复杂度，这时候要么选择回到传统DBMS时代，用更高的机器配置纵向扩容，要么选择回到中间件时代，开发支持分布式事务的中间件。这两种方案成本都很高，于是NewSQL运动开始酝酿。

NewSQL数据库设计针对的读写事务有以下特点：

1、耗时短。

2、使用索引查询，涉及少量数据。

3、重复度高，通常使用相同的查询语句和不同的查询参考。

也有一些学者认为NewSQL系统是特指实现上使用Lock-free并发控制技术和share-nothing架构的数据库。所有我们认为是NewSQL的数据库系统确实都有这样的特点。