近期总是提到NoSQL这个词汇。起初仅仅知道，应该是一种数据库而已，仅仅是这样的数据库眼下符合当前互联网的需求，应用比較广泛。逐渐发现，当前的各个公司在招聘信息中会有掌握NoSQL的优先等要求。于是，抱着好奇的心理，来查了一些资料，并进行了整理，来分享给大家！
以下的内容来源于百度百科
NoSQL，泛指非关系型的数据库。
随着互联网web2.0站点的兴起，传统的关系数据库在应付web2.0站点，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了非常多难以克服的问题。而非关系型的数据库则因为其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。
虽然NoSQL流行语火起来才短短一年的时间，可是不可否认，如今已经開始了第二代运动。虽然早期的堆栈代码仅仅能算是一种实验，然而如今的系统已经更加的成熟、稳定。只是如今也面临着一个严酷的事实：技术越来越成熟——以至于原来非常好的NoSQL数据存储不得不进行重写。也有少数人觉得这就是所谓的2.0版本号。这里列出一些比較知名的工具。能够为大数据建立高速、可扩展的存储库。
基本含义
NoSQL(NoSQL = Not Only SQL )，意即“不不过
SQL
”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的
关系型数据库
运用，这一概念无疑是一种全新的思维的注入。
NNoSQL数据库的四大分类
键值(
Key-Value
)存储数据库 这一类数据库主要会使用到一个
哈希表。
这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。
可是假设DBA仅仅对部分值进行查询或更新的时候。Key/value就显得效率低下了。[3] 举比如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存储数据库。
这部分数据库一般是用来应对分布式存储的海量数据。键仍然存在，可是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak.
文档型数据库 文档型数据库的灵感是来自于Lotus Notes办公软件的，并且它同第一种键值存储相类似。
该类型的数据模型是版本号化的文档。半结构化的文档以特定的格式存储，比方JSON。文档型数据库可 以看作是键值数据库的升级版，同意之间嵌套键值。
并且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。
图形(Graph)数据库 图形结构的数据库同其它行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型。而且可以扩展到多个server上。
NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询须要制定数据模型。很多NoSQL数据库都有REST式的数据接口或者查询API。
[2] 如：Neo4J, InfoGrid, Infinite Graph.
因此，我们总结NoSQL数据库在下面的这几种情况下比較适用：1、数据模型比較简单；2、须要灵活性更强的IT系统；3、对数据库性能要求较高。4、不须要高度的数据一致性。5、对于给定key，比較easy映射复杂值的环境。
3NoSQL数据库的四大分类表格分析
| 分类 | Examples举例 | 典型应用场景 | 数据模型 | 长处 | 缺点 |
|---|---|---|---|---|---|
| 键值（key-value） | Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB | 内容缓存，主要用于处理大量数据的高訪问负载，也用于一些日志系统等等。 | Key 指向 Value 的键值对，通经常使用hash table来实现 | 查找速度快 | 数据无结构化，通常仅仅被当作字符串或者二进制数据 |
| 列存储数据库 | Cassandra, HBase, Riak | 分布式的文件系统 | 以列簇式存储，将同一列数据存在一起 | 查找速度快。可扩展性强。更easy进行分布式扩展 | 功能相对局限 |
| 文档型数据库 | CouchDB, MongoDb | Web应用（与Key-Value类似，Value是结构化的，不同的是数据库可以了解Value的内容） | Key-Value相应的键值对，Value为结构化数据 | 数据结构要求不严格。表结构可变，不须要像关系型数据库一样须要预先定义表结构 | 查询性能不高。并且缺乏统一的查询语法。 |
| 图形(Graph)数据库 | Neo4J, InfoGrid, Infinite Graph | 社交网络，推荐系统等。 专注于构建关系图谱 | 图结构 | 利用图结构相关算法。比方最短路径寻址，N度关系查找等 | 非常多时候须要对整个图做计算才干得出须要的信息，并且这样的结构不太好做分布式的集群方案。 |
4
对于NoSQL并没有一个明白的范围和定义，可是他们都普遍存在以下一些共同特征：
- 不须要提前定义模式：不须要 共同特征事先定义数据模式，提前定义表结构。数据中的每条记录都可能有不同的属性和格式。
当插入数据时，并不须要预先定义它们的模式。
- 无共享架构：相对于将全部数据存储的存储区域网络中的全共享架构。NoSQL往往将数据 划分后存储在各个本地server上。由于从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。
- 弹性可扩展：能够在系统执行的时候，动态添加或者删除结点。不须要停机维护。数据能够自己主动迁移。
- 分区：相对于将数据存放于同一个节点，NoSQL数据库须要将数据进行分区。将记录分散在多个节点上面。而且通常分区的同一时候还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题。
- 异步复制：和RAID存储系统不同的是。NoSQL中的复制，往往是基于日志的异步复制。
这样。数据就能够尽快地写入一个节点，而不会被网络传输引起拖延。缺点是并不总是能保证一致性，这种方式在出现问题的时候。可能会丢失少量的数据。
- BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。
BASE是终于一致性和软事务。
NoSQL数据库并没有一个统一的架构，两种NoSQL数据库之间的不同，甚至远远超过两种关系型数据库的不同。
能够说，NoSQL各有所长。成功的NoSQL必定特别适用于某些场合或者某些应用，在这些场合中会远远胜过关系型数据库和其它的NoSQL。
键值(Key-Value)存储数据库
这一类数据库主要会使用到一个哈希表。这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。可是假设DBA仅仅对部分值进行查询或更新的时候，Key/value就显得效率低下了。
[3] 举比如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存储数据库。
这部分数据库一般是用来应对分布式存储的海量数据。键仍然存在。可是它们的特点是指向了多个列。这些列是由列家族来安排的。
如：Cassandra, HBase, Riak.
文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的，并且它同第一种键值存储相类似。该类型的数据模型是版本号化的文档。半结构化的文档以特定的格式存储，比方JSON。文档型数据库可 以看作是键值数据库的升级版。同意之间嵌套键值。并且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。
图形(Graph)数据库
图形结构的数据库同其它行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，而且可以扩展到多个server上。
NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询须要制定数据模型。很多NoSQL数据库都有REST式的数据接口或者查询API。
[2] 如：Neo4J, InfoGrid, Infinite Graph.
因此，我们总结NoSQL数据库在下面的这几种情况下比較适用：1、数据模型比較简单；2、须要灵活性更强的IT系统。3、对数据库性能要求较高；4、不须要高度的数据一致性；5、对于给定key，比較easy映射复杂值的环境。
3NoSQL数据库的四大分类表格分析
分类 Examples举例 典型应用场景 数据模型 长处 缺点
键值（key-value）[3] Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB 内容缓存，主要用于处理大量数据的高訪问负载，也用于一些日志系统等等。[3] Key 指向 Value 的键值对。通经常使用hash table来实现[3] 查找速度快 数据无结构化，通常仅仅被当作字符串或者二进制数据[3]
列存储数据库[3] Cassandra, HBase, Riak 分布式的文件系统 以列簇式存储。将同一列数据存在一起 查找速度快，可扩展性强。更easy进行分布式扩展 功能相对局限
文档型数据库[3] CouchDB, MongoDb Web应用（与Key-Value类似，Value是结构化的，不同的是数据库可以了解Value的内容） Key-Value相应的键值对，Value为结构化数据 数据结构要求不严格。表结构可变。不须要像关系型数据库一样须要预先定义表结构 查询性能不高，并且缺乏统一的查询语法。
图形(Graph)数据库[3] Neo4J, InfoGrid, Infinite Graph 社交网络。推荐系统等。
专注于构建关系图谱 图结构 利用图结构相关算法。比方最短路径寻址，N度关系查找等 非常多时候须要对整个图做计算才干得出须要的信息，并且这样的结构不太好做分布式的集群方案。[3]
4共同特征
对于NoSQL并没有一个明白的范围和定义。可是他们都普遍存在以下一些共同特征：
不须要提前定义模式：不须要事先定义数据模式，提前定义表结构。
数据中的每条记录都可能有不同的属性和格式。当插入数据时。并不须要预先定义它们的模式。
无共享架构：相对于将全部数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地server上。
由于从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。
弹性可扩展：能够在系统执行的时候。动态添加或者删除结点。不须要停机维护，数据能够自己主动迁移。
分区：相对于将数据存放于同一个节点，NoSQL数据库须要将数据进行分区，将记录分散在多个节点上面。而且通常分区的同一时候还要做复制。这样既提高了并行性能。又能保证没有单点失效的问题。
异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。
这样，数据就能够尽快地写入一个节点。而不会被网络传输引起拖延。缺点是并不总是能保证一致性。这种方式在出现问题的时候。可能会丢失少量的数据。
BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。BASE是终于一致性和软事务。
NoSQL数据库并没有一个统一的架构，两种NoSQL数据库之间的不同，甚至远远超过两种关系型数据库的不同。能够说，NoSQL各有所长。成功的NoSQL必定特别适用于某些场合或者某些应用，在这些场合中会远远胜过关系型数据库和其它的NoSQL。
5适用场景
NoSQL数据库在下面的这几种情况下比較适用：1、数据模型比較简单；2、须要灵活性更强的IT系统；3、对数据库性能要求较高。4、不须要高度的数据一致性。5、对于给定key。比較easy映射复杂值的环境。
6发展现状
计算机体系结构在数据存储方面要求具备庞大的水平扩展性。而NoSQL致力于改变这一现状。Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。
NoSQL项目的名字上看不出什么同样之处，可是，它们通常在某些方面同样：它们能够处理超大量的数据。
这场革命仍然须要等待。的确，NoSQL对大型企业来说还不是主流，可是，一两年之后非常可能就会变个样子。在NoSQL运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。
分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验。如何使用更有效和更廉价的方法来管理数据。
“关系型数据库给你强加了太多东西。它们要你强行改动对象数据。以满足RDBMS （relational database management system。关系型数据库管理系统）的须要，”在NoSQL拥护者们看来，基于NoSQL的替代方案“仅仅是给你所须要的”。
水平扩展性(horizontal scalability)指可以连接多个软硬件的特性,这样可以将多个server从逻辑上看成一个实体。
7挑战
虽然大多数NoSQL数据存储系统都已被部署于实际应用中，但归纳其研究现状，还有很多挑战性问题。
已有key-value数据库产品大多是面向特定应用自治构建的，缺乏通用性；
已有产品支持的功能有限（不支持事务特性），导致其应用具有一定的局限性；
已有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不同应用需求而提出的对应解决方式，如支持组内事务特性、弹性事务等，非常少从全局考虑系统的通用性。也没有形成系列化的研究成果；
缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启示式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的支持。
眼下，HBase数据库时安全特性最完好的NoSQL数据库产品之中的一个，而其它的NoSQL数据库多数没有提供内建的安全机制，但随着NoSQL的发展，越来越多的人開始意识到安全的重要。部分NoSQL产品逐渐開始提供一些安全方面的支持。
随着云计算、互联网等技术的发展，大数据广泛存在，同一时候也呈现出了很多云环境下的新型应用，如社交网络网、移动服务、协作编辑等。这些新型应用对海量数据管理或称云数据管理系统也提出了新的需求。如事务的支持、系统的弹性等。同一时候云计算时代海量数据管理系统的设计目标为可扩展性、弹性、容错性、自管理性和“强一致性”。
眼下，已有系统通过支持可任意增减节点来满足可扩展性；通过副本策略保证系统的容错性。基于监測的状态消息协调实现系统的自管理性。“弹性”的目标是满足Pay-per-use 模型，以提高系统资源的利用率。该特性是已有典型NoSQL数据库系统所不完好的，但却是云系统应具有的典型特点；“强一致性”主要是新应用的需求。
NoSQL数据库在下面的这几种情况下比較适用：1、数据模型比較简单。2、须要灵活性更强的IT系统；3、对数据库性能要求较高；4、不须要高度的数据一致性；5、对于给定key。比較easy映射复杂值的环境。
6发展现状
计算机体系结构在数据存储方面要求具备庞大的水平扩展性，而NoSQL致力于改变这一现状。
Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。
NoSQL项目的名字上看不出什么同样之处。可是，它们通常在某些方面同样：它们能够处理超大量的数据。 这场革命仍然须要等待。
的确，NoSQL对大型企业来说还不是主流，可是，一两年之后非常可能就会变个样子。在NoSQL运动的最新一次聚会中。来自世界各地的150人挤满了CBS Interactive的一间会议室。
分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验，如何使用更有效和更廉价的方法来管理数据。
“
关系型数据库给你强加了太多东西。
它们要你强行改动对象数据。以满足RDBMS （relational database management system。关系型数据库管理系统）的须要。”在NoSQL拥护者们看来。基于NoSQL的替代方案“仅仅是给你所须要的”。
水平扩展性(horizontal scalability)指可以连接多个软硬件的特性,这样可以将多个server从逻辑上看成一个实体。
7挑战
虽然大多数NoSQL数据存储系统都已被部署于实际应用中。但归纳其研究现状，还有很多挑战性问题。
- 已有key-value数据库产品大多是面向特定应用自治构建的。缺乏通用性。
- 已有产品支持的功能有限（不支持事务特性），导致其应用具有一定的局限性；
- 已有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不同应用需求而提出的对应解决方式，如支持组内事务特性、弹性事务等，非常少从全局考虑系统的通用性。也没有形成系列化的研究成果；
- 缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启示式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的支持。
- 眼下，HBase数据库时安全特性最完好的NoSQL数据库产品之中的一个，而其它的NoSQL数据库多数没有提供内建的安全机制，但随着NoSQL的发展，越来越多的人開始意识到安全的重要，部分NoSQL产品逐渐開始提供一些安全方面的支持。
随着云计算、互联网等技术的发展。大数据广泛存在，同一时候也呈现出了很多云环境下的新型应用，如社交网络网、移动服务、协作编辑等。这些新型应用对海量数据管理或称云数据管理系统也提出了新的需求，如事务的支持、系统的弹性等。同一时候云计算时代海量数据管理系统的设计目标为可扩展性、弹性、容错性、自管理性和“强一致性”。眼下，已有系统通过支持可任意增减节点来满足可扩展性；通过副本策略保证系统的容错性。基于监測的状态消息协调实现系统的自管理性。“弹性”的目标是满足Pay-per-use 模型。以提高系统资源的利用率。该特性是已有典型NoSQL数据库系统所不完好的，但却是云系统应具有的典型特点。“强一致性”主要是新应用的需求。
以下的内容借鉴：http://www.infoq.com/cn/news/2011/01/nosql-why/
NOSQL的优势
易扩展
NoSQL数据库种类繁多，可是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就很easy扩展。
也无形之间。在架构的层面上带来了可扩展的能力。
大数据量，高性能
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关注在存储上。
传统关系数据库的瓶颈
传统的关系数据库具有不错的性能。高稳定型，久经历史考验，并且使用简单，功能强大。同一时候也积累了大量的成功案例。
在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。
在90年代，一个站点的訪问量一般都不大，用单个数据库全然能够轻松应付。在那个时候，很多其它的都是静态网页，动态交互类型的站点不多。
到了近期10年。站点開始高速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。
在初期。论坛的流量事实上也不大。假设你接触网络比較早。你可能还记得那个时候还有文本型存储的论坛程序，能够想象一般的论坛的流量有多大。
Memcached+MySQL
后来。随着訪问量的上升。差点儿大部分使用MySQL架构的站点在数据库上都開始出现了性能问题，web程序不再只专注在功能上。同一时候也在追求性能。
程序猿们開始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。開始比較流行的是通过文件缓存来缓解数据库压力。可是当訪问量继续增大的时候，多台web机器通过文件缓存不能共享。大量的小文件缓存也带了了比較高的IO压力。在这个时候，Memcached就自然的成为一个很时尚的技术产品。
Memcached作为一个独立的分布式的缓存server，为多个webserver提供了一个共享的高性能缓存服务。在Memcachedserver上，又发展了依据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决添加或降低缓存server导致又一次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数据库也常常存储一些大文本字段。导致数据库表很的大。在做数据库恢复的时候就导致很的慢。不easy高速恢复数据库。比方1000万4KB大小的文本就接近40GB的大小，假设能把这些数据从MySQL省去，MySQL将变得很的小。
关系数据库非常强大。可是它并不能非常好的应付全部的应用场景。
MySQL的扩展性差（须要复杂的技术来实现）。大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发者面临的问题。
以上的就是我总结的有关NoSQL的内容，从以上的内容能够看出，NoSQL必定会引起一次数据库的潮流
