NNosql数据库的四大分类
3Nosql数据库的四大分类表格分析
| 分类 | Examples举例 | 典型应用场景 | 数据模型 | 优点 | 缺点 |
|---|---|---|---|---|---|
| 键值（key-value） | Tokyo Cabinet/Tyrant,Oracle BDB | 内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。 | Key 指向 Value 的键值对，通常用hash table来实现 | 查找速度快 | 数据无结构化，通常只被当作字符串或者二进制数据 |
| 列存储数据库 | Cassandra,Riak | 分布式的文件系统 | 以列簇式存储，将同一列数据存在一起 | 查找速度快，可扩展性强，更容易进行分布式扩展 | 功能相对局限 |
| 文档型数据库 | CouchDB,MongoDb | Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容） | Key-Value对应的键值对，Value为结构化数据 | 数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构 | 查询性能不高，而且缺乏统一的查询语法。 |
| 图形(Graph)数据库 | Neo4J,Infinite Graph | 社交网络，推荐系统等。专注于构建关系图谱 | 图结构 | 利用图结构相关算法。比如最短路径寻址，N度关系查找等 | 很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。[3] |
-
不需要预定义模式：不需要 共同特征事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时，并不需要预先定义它们的模式。
-
无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据 划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。
-
弹性可扩展：可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可以自动迁移。
-
分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题。
-
异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。
-
BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。BASE是最终一致性和软事务。
键值(Key-Value)存储数据库
这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。[3] 举例如：Tokyo Cabinet/Tyrant,Oracle BDB.
列存储数据库。
这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra,Riak.
文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB,MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。
图形(Graph)数据库
图形结构的数据库同其他行列以及刚性结构的sql数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。Nosql数据库没有标准的查询语言(sql)，因此进行数据库查询需要制定数据模型。许多Nosql数据库都有REST式的数据接口或者查询API。[2] 如：Neo4J,Infinite Graph.
因此，我们总结Nosql数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
3Nosql数据库的四大分类表格分析
分类 Examples举例 典型应用场景 数据模型 优点 缺点
键值（key-value）[3] Tokyo Cabinet/Tyrant,Oracle BDB 内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。[3] Key 指向 Value 的键值对，通常用hash table来实现[3] 查找速度快 数据无结构化，通常只被当作字符串或者二进制数据[3]
列存储数据库[3] Cassandra,Riak 分布式的文件系统 以列簇式存储，将同一列数据存在一起 查找速度快，可扩展性强，更容易进行分布式扩展 功能相对局限
文档型数据库[3] CouchDB,MongoDb Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容） Key-Value对应的键值对，Value为结构化数据 数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构 查询性能不高，而且缺乏统一的查询语法。
图形(Graph)数据库[3] Neo4J,Infinite Graph 社交网络，推荐系统等。专注于构建关系图谱 图结构 利用图结构相关算法。比如最短路径寻址，N度关系查找等 很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。[3]
4共同特征
对于Nosql并没有一个明确的范围和定义，但是他们都普遍存在下面一些共同特征：
不需要预定义模式：不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时，并不需要预先定义它们的模式。
无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构。Nosql往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。
弹性可扩展：可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可以自动迁移。
分区：相对于将数据存放于同一个节点，Nosql数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题。
异步复制：和RAID存储系统不同的是，Nosql中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。
BASE：相对于事务严格的ACID特性，Nosql数据库保证的是BASE特性。BASE是最终一致性和软事务。
Nosql数据库并没有一个统一的架构，两种Nosql数据库之间的不同，甚至远远超过两种关系型数据库的不同。可以说，Nosql各有所长，成功的Nosql必然特别适用于某些场合或者某些应用，在这些场合中会远远胜过关系型数据库和其他的Nosql。
5适用场景
Nosql数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
6发展现状
计算机体系结构在数据存储方面要求具备庞大的水平扩展性，而Nosql致力于改变这一现状。Google的 BigTable 和Amazon 的Dynamo使用的就是Nosql型数据库。
Nosql项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：它们可以处理超大量的数据。
这场革命仍然需要等待。的确，Nosql对大型企业来说还不是主流，但是，一两年之后很可能就会变个样子。在Nosql运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验，怎样使用更有效和更便宜的方法来管理数据。
“关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足RDBMS （relational database management system，关系型数据库管理系统）的需要，”在Nosql拥护者们看来，基于Nosql的替代方案“只是给你所需要的”。
水平扩展性(horizontal scalability)指能够连接多个软硬件的特性,这样可以将多个服务器从逻辑上看成一个实体。
7挑战
尽管大多数Nosql数据存储系统都已被部署于实际应用中，但归纳其研究现状，还有许多挑战性问题。
已有key-value数据库产品大多是面向特定应用自治构建的，缺乏通用性；
已有产品支持的功能有限（不支持事务特性），导致其应用具有一定的局限性；
已有一些研究成果和改进的Nosql数据存储系统，但它们都是针对不同应用需求而提出的相应解决方案，如支持组内事务特性、弹性事务等，很少从全局考虑系统的通用性，也没有形成系列化的研究成果；
缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启发式的优化策略、两段封锁协议等）、标准规范（如sql语言）的支持。
目前，HBase数据库时安全特性最完善的Nosql数据库产品之一，而其他的Nosql数据库多数没有提供内建的安全机制，但随着Nosql的发展，越来越多的人开始意识到安全的重要，部分Nosql产品逐渐开始提供一些安全方面的支持。
随着云计算、互联网等技术的发展，大数据广泛存在，同时也呈现出了许多云环境下的新型应用，如社交网络网、移动服务、协作编辑等。这些新型应用对海量数据管理或称云数据管理系统也提出了新的需求，如事务的支持、系统的弹性等。同时云计算时代海量数据管理系统的设计目标为可扩展性、弹性、容错性、自管理性和“强一致性”。目前，已有系统通过支持可随意增减节点来满足可扩展性；通过副本策略保证系统的容错性；基于监测的状态消息协调实现系统的自管理性。“弹性”的目标是满足Pay-per-use 模型，以提高系统资源的利用率。该特性是已有典型Nosql数据库系统所不完善的，但却是云系统应具有的典型特点；“强一致性”主要是新应用的需求。
-
已有key-value数据库产品大多是面向特定应用自治构建的，缺乏通用性；
-
已有产品支持的功能有限（不支持事务特性），导致其应用具有一定的局限性；
-
已有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不同应用需求而提出的相应解决方案，如支持组内事务特性、弹性事务等，很少从全局考虑系统的通用性，也没有形成系列化的研究成果；
-
缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启发式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的支持。
-
目前，HBase数据库时安全特性最完善的NoSQL数据库产品之一，而其他的NoSQL数据库多数没有提供内建的安全机制，但随着NoSQL的发展，越来越多的人开始意识到安全的重要，部分NoSQL产品逐渐开始提供一些安全方面的支持。
下面的内容借鉴：http://www.infoq.com/cn/news/2011/01/nosql-why/
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关注在存储上。
传统关系数据库的瓶颈
传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，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的开发人员面临的问题。