为什么使用 NoSQL:NoSQL 与 SQL 的区别

1. 概念

SQL (Structured Query Language) 数据库，指关系型数据库。主要代表：SQL Server，Oracle，MySQL，PostgreSQL。

NoSQL（Not Only SQL）泛指非关系型数据库。主要代表：MongoDB，Redis，CouchDB。

2.诞生的原因

随着互联网的不断发展，各种类型的应用层出不穷，在这个云计算的时代，对技术提出了更多的需求，主要体现在下面这四个方面：

1. 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度;

2. 海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量;

3. 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理;

4. 庞大运营成本的考量：IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低;

目前世界上主流的存储系统大部分还是采用了关系型数据库，其主要有一下优点：

1.事务处理—保持数据的一致性；

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

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

虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位，但是由于其天生的几个限制，使其很难满足上面这几个需求：

1. 扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难;

2. 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重;

3. 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升;

4. 有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储;

业界为了解决上面提到的几个需求，推出了多款新类型的数据库，在设计上，它们非常关注对数据高并发地读写和对海量数据的存储等，与关系型数据库相比，它们在架构和数据模型方量面做了“减法”，而在扩展和并发等方面做了“加法”。现在主流的NoSQL数据库有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。

2.NoSQL 优缺点

优点

1.简单的扩展：典型例子是Cassandra，由于其架构是类似于经典的P2P，所以能通过轻松地添加新的节点来扩展这个集群;

2.快速的读写：主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色，单节点每秒可以处理超过10万次读写操作;

3.低廉的成本：这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的License成本;

但瑕不掩瑜，NoSQL不足

1. 不提供对SQL的支持：如果不支持SQL这样的工业标准，将会对用户产生一定的学习和应用迁移成本;

2. 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MS SQL Server和Oracle那样能提供各种附加功能，比如BI和报表等;

3. 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语;

3.NoSQL 使用场景

NoSQL并不是任何场景，NoSQL都要优于关系型数据库。下面我们来具体聊聊，什么时候使用NoSQL比较给力：

1) 数据库表schema经常变化

比如在线商城，维护产品的属性经常要增加字段，这就意味着ORMapping层的代码和配置要改，如果该表的数据量过百万，新增字段会带来额外开销（重建索引等）。NoSQL应用在这种场景，可以极大提升DB的可伸缩性，开发人员可以将更多的精力放在业务层。

2)数据库表字段是复杂数据类型

对于复杂数据类型，比如SQL Sever提供了可扩展性的支持，像xml类型的字段。很多用过的同学应该知道，该字段不管是查询还是更改，效率非常一般。主要原因是是DB层对xml字段很难建高效索引，应用层又要做从字符流到dom的解析转换。NoSQL以json方式存储，提供了原生态的支持，在效率方便远远高于传统关系型数据库。

3)高并发数据库请求

此类应用常见于web2.0的网站，很多应用对于数据一致性要求很低，而关系型数据库的事务以及大表join反而成了”性能杀手”。在高并发情况下，sql与no-sql的性能对比由于环境和角度不同一直是存在争议的，并不是说在任何场景，no-sql总是会比sql快。有篇article和大家分享下，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers

4)海量数据的分布式存储

海量数据的存储如果选用大型商用数据，如Oracle，那么整个解决方案的成本是非常高的，要花很多钱在软硬件上。NoSQL分布式存储，可以部署在廉价的硬件上，是一个性价比非常高的解决方案。

其他使用方式：

NoSQL和关系数据库结合

其实NoSQL数据库仅仅是关系数据库在某些方面（性能，扩展）的一个弥补，单从功能上讲，NoSQL的几乎所有的功能，在关系数据库上都能够满足，所以选择NoSQL的原因并不在功能上。

所以，我们一般会把NoSQL和关系数据库进行结合使用，各取所长，需要使用关系特性的时候我们使用关系数据库，需要使用NoSQL特性的时候我们使用NoSQL数据库，各得其所。

举个简单的例子吧，比如用户评论的存储，评论大概有主键id、评论的对象aid、评论内容content、用户uid等字段。我们能确定的是评论内容content肯定不会在数据库中用where content=’’查询，评论内容也是一个大文本字段。那么我们可以把 主键id、评论对象aid、用户id存储在数据库，评论内容存储在NoSQL，这样数据库就节省了存储content占用的磁盘空间，从而节省大量IO，对content也更容易做Cache。

//从MySQL中查询出评论主键id列表 commentIds=DB.query(“SELECT id FROM comments where aid=’评论对象id’ LIMIT 0,20”); //根据主键id列表，从NoSQL取回评论实体数据 CommentsList=NoSQL.get(commentIds);NoSQL代替MySQL

在某些应用场合，比如一些配置的关系键值映射存储、用户名和密码的存储、Session会话存储等等，用NoSQL完全可以替代MySQL存储。不但具有更高的性能，而且开发也更加方便。

NoSQL作为缓存服务器

MySQL+Memcached的架构中，我们处处都要精心设计我们的缓存，包括过期时间的设计、缓存的实时性设计、缓存内存大小评估、缓存命中率等等。

NoSQL数据库一般都具有非常高的性能，在大多数场景下面，你不必再考虑在代码层为NoSQL构建一层Memcached缓存。NoSQL数据本身在Cache上已经做了相当多的优化工作。

Memcached这类内存缓存服务器缓存的数据大小受限于内存大小，如果用NoSQL来代替Memcached来缓存数据库的话，就可以不再受限于内存大小。虽然可能有少量的磁盘IO读写，可能比Memcached慢一点，但是完全可以用来缓存数据库的查询操作。

4. NoSQL 与 SQL 的区别

SQL 数据库

在使用之前需要定义表的一个模式

在表中存储相关联的数据

支持 join 多表查询

提供事务

使用一个强声明性语言查询

提供足够的支持,专业技能和工具

NoSQL 数据库

将相关联的数据存储在类似 JSON 格式，名称-值

可以保存没有指定格式的数据

保证更新一个文档 – 但不是多个文档

提供出色的性能和可伸缩性

使用 JSON 数据对象查询

a 存储方式

SQL数据存在特定结构的表中；

而NoSQL则更加灵活和可扩展，存储方式可以是JSON文档、哈希表或者其他方式。

b 表/集合数据的关系

SQL中，必须定义好表和字段结构后才能添加数据，例如定义表的主键(primary key)，索引(index),触发器(trigger),存储过程(stored procedure)等。表结构可以在被定义之后更新，但是如果有比较大的结构变更的话就会变得比较复杂。

在NoSQL中，数据可以在任何时候任何地方添加，不需要先定义表。

NoSQL也可以在数据集中建立索引。以MongoDB为例，会自动在数据集合创建后创建唯一值_id字段，这样的话就可以在数据集创建后增加索引。从这点来看，NoSQL可能更加适合初始化数据还不明确或者未定的项目中。

b 外部数据存储

SQL中如果需要增加外部关联数据的话，规范化做法是在原表中增加一个外键，关联外部数据表。

NoSQL中除了这种规范化的外部数据表做法以外，我们还能用如下的非规范化方式把外部数据直接放到原数据集中，以提高查询效率。缺点也比较明显，更新审核人数据的时候将会比较麻烦。

c SQL中的JOIN查询

SQL中可以使用JOIN表链接方式将多个关系数据表中的数据用一条简单的查询语句查询出来。

NoSQL未提供对多个数据集中的数据做查询。

d 数据耦合性

SQL中不允许删除已经被使用的外部数据，例如审核人表中的"熊三"已经被分配给了借阅人熊大，那么在审核人表中将不允许删除熊三这条数据，以保证数据完整性。

而NoSQL中则没有这种强耦合的概念，可以随时删除任何数据。

转载自:

http://blog.csdn.net/xlgen157387/article/details/47908797

http://www.cnblogs.com/jeakeven/p/5402095.htm