当今社会已经进入互联网时代，数据在爆炸式的增长， 产生了大量写少读多的数据，随着对数据的高度可扩充性/高并发量的需求的增加，传统的基于关系型的数据库已经很难满足需求。于是基于NoSQL 的数据库得到了很大的发展，产生了好多NoSQL的产品（Hbase, MongoDB, Cassandra ）
NoSQL系统舍弃了一些SQL标准中的功能，取而代之的是提供了一些简单灵活的功能。NoSQL 的构建思想就是尽量简化数据操作，尽量让执行操作的效率可预知。在很多NoSQL系统里，复杂的操作都是留给应用层来做的，这样的结果就是我们对数据层进 行的操作得到简化，让操作效率可预知。
NoSQL系统不仅舍弃了很多关系数据库中的操作。它还可能不具备关系数据库以下的一些特性：比如通常银行系统中要求的事务保证，一致性保证以及数 据可靠性的保证等。事务机制提供了在执行多个命令时的all-or-nothing保证。一致性保证了如果一个数据更新后，那么在其之后的操作中都能看到 这个更新。可靠性保证如果一个数据被更新，它就会被写到持久化的存储设备上（比如说磁盘），并且保证在数据库崩溃后数据可恢复。
通过放宽对上述几点特性的要求，NoSQL系统可以为一些非银行类的业务提供以性能换稳定的策略。而同时，对这几点要求的放宽，又使得NoSQL系统能够轻松的实现分片策略，将远远超出单机容量的大量数据分布在多台机器上的。
1. 关系型数据库缺点：
关联型的数据模型定义了高度结构化的数据结构，以及对这些结构之间关系的严格定义。在这样的数据模型上执行的查询操作会比较局限，而且可能会导致复杂的数据遍历操作。数据结构的复杂性及查询的复杂性，会导致系统产生如下的一些限制：
- 复杂导致不确定性。使用SQL的一个问题就是计算某个查询的代价或者产生的负载几乎是不可能的。使用简单的查询语言可能会导致应用层的逻辑更复杂，但是这样可以将存储系统的工作简单化，让它只需要响应一些简单的请求。
- 对一个问题建模有很多种方式。其中关联型的数据模型是非常严格的一种：表结构的定义规定了表中每一行数据的存储内容。如果你的数据结构化并没有那 么强，或者对每一行数据的要求比较灵活，那可能关联型的数据模型就太过严格了。类似的，应用层的开发人员可能对关联型的数据结构并不满意。比如很多应用程 序是用面向对象的语言写的，数据在这些语言中通常是以列表、队列或集合的形式组织的，程序员们当然希望他们的数据存储层也能和应用层的数据模型一致。
- 当数据量增长到一台机器已经不能容纳，我们需要将不同的数据表分布到不同的机器。而为了避免在不同机器上的数据表在进行联合查询时需要跨网络进 行。我们必须进行反范式的数据库设计，这种设计方式要求我们把需要一次性查询到的数据存储在一起。这样做使得我们的系统变得就像一个主键查询系统一样，于 是我们开始思考，是否有其它更适合我们数据的数据模型。
2. NoSQL DB 的优点：
a. 弹性扩展
多年来,数据库管理员一直依赖于向上扩展(scale up)－随着数据库负载的增加购买更大的数据库服务器―而不是向外扩展－随着负载的增加将数据库分不到多个不同的主机上.然而,随着每秒事务数与可用性需 求的提高,以及数据库往云或虚拟环境的迁移,向外扩展到廉价硬件的经济优势越来越难以抵挡.
RDBMS或许比较难以在廉价的集群上进行向外扩展,但是,NoSQL数据库的新品从设计之初就是为了利用新节点的优势进行透明扩展,他们通常在设计时就考虑使用低成本的廉价硬件.
b. 大数据量
在过去10年,与每秒事务数的增长超出了认知一样,存储的数据的规模也出现了极大的增长.O’Reilly明智的称此为”数据的工业革命.”RDBMS的 容量也在增长以匹配这些数据的增长,但是,与每秒事务数一样,单个RDBMS可有效管理的数据规模限制让部分企业越来越难以忍受.今天,大规模数据量可以 交由NoSQL系统来处理,比如Hadoop,超过目前最大的RDBMS可以管理的数据规模.
c. 经济性
NoSQL数据库通常使用廉价服务器集群来管理暴增的数据与事务规模,而RDBMS倾向于依赖昂贵的专有服务器与存储系统.其结果是,NoSQL数据库的每GB数据或每秒事务数的成本要远远低于RDBMS,使得你可以以更低的价格来存储与处理更多的数据.
d. 灵活的数据模型
在大量的生产环境数据库中,变更管理是一个非常棘手的问题.哪怕是对数据模型的很小的变更,在RDBMS中也需要进行小心的管理,甚至还需要停机或降低服务级别.
在数据模型的限制这一点上，NoSQL数据库要宽松的多，或者完全不存在. NoSQL的键值存储(Key value Store)与文档数据库(Document Database)允许应用在一个数据单元中存入它想要的任何结构.即使是定义更加严格的基于BigTable的NoSQL数据库,通常也允许创建新的字 段而不致带来麻烦.
其结果是,应用的变更与数据库结构的变更不需要绑定在一个变更单元中进行管理.理论上,这可以提高应用的迭代速度,然而,显然,如果应用无法管理数据的完整性,它将带来不良的副作用.