以下来自百度百科
基本含义
Nosql(Nosql = Not Only sql )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。Nosql的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
这一类数据库主要会使用到一个
哈希表，这个表中有一个特定的键和一个指针指向特定的数据。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数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。Nosql数据库没有标准的查询语言(sql)，因此进行数据库查询需要制定数据模型。许多Nosql数据库都有REST式的数据接口或者查询API。
[2]
如：Neo4J,InfoGrid,Infinite Graph.
因此，我们总结Nosql数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
| 分类 | Examples举例 | 典型应用场景 | 数据模型 | 优点 | 缺点 |
|---|---|---|---|---|---|
| 键值（key-value）[3] | 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并没有一个明确的范围和定义，但是他们都普遍存在下面一些共同特征：
-
不需要预定义模式：不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时，并不需要预先定义它们的模式。
-
异步复制：和RAID存储系统不同的是，Nosql中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。
Nosql数据库并没有一个统一的架构，两种Nosql数据库之间的不同，甚至远远超过两种关系型数据库的不同。可以说，Nosql各有所长，成功的Nosql必然特别适用于某些场合或者某些应用，在这些场合中会远远胜过关系型数据库和其他的Nosql。
Nosql项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：它们可以处理超大量的数据。
这场革命仍然需要等待。的确，Nosql对大型企业来说还不是主流，但是，一两年之后很可能就会变个样子。在Nosql运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验，怎样使用更有效和更便宜的方法来管理数据。
“
关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足RDBMS （relational database management system，
关系型数据库管理系统）的需要，”在Nosql拥护者们看来，基于Nosql的替代方案“只是给你所需要的”。
水平扩展性(horizontal scalability)指能够连接多个软硬件的特性,这样可以将多个服务器从逻辑上看成一个实体。
尽管大多数Nosql数据存储系统都已被部署于实际应用中，但归纳其研究现状，还有许多挑战性问题。
-
已有key-value数据库产品大多是面向特定应用自治构建的，缺乏通用性；
随着云计算、互联网等技术的发展，大数据广泛存在，同时也呈现出了许多云环境下的新型应用，如社交网络网、移动服务、协作编辑等。这些新型应用对海量数据管理或称云数据管理系统也提出了新的需求，如事务的支持、系统的弹性等。同时云计算时代海量数据管理系统的设计目标为可扩展性、弹性、容错性、自管理性和“强一致性”。目前，已有系统通过支持可随意增减节点来满足可扩展性；通过副本策略保证系统的容错性；基于监测的状态消息协调实现系统的自管理性。“弹性”的目标是满足Pay-per-use 模型，以提高系统资源的利用率。该特性是已有典型Nosql数据库系统所不完善的，但却是云系统应具有的典型特点；“强一致性”主要是新应用的需求。
原文链接：https://www.f2er.com/nosql/203481.html