1、 NoSQL的概念
NoSQL是指非关系型的数据库，NoSQL（Not Only SQL），意即“不仅仅是SQL”，是一项全新的数据库革命性运动，随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS（Social Networking Services，即社会性网络服务）类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。
2、 传统关系型数据库面临的问题
2.1. High performance（对数据库高并发读写的需求）
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。
2.2. Huge Storage（对海量数据的高效率存储和访问的需求）
对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。
2.3. High Scalability &&High Availability（对数据库的高可扩展性和高可用性的需求）
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。
3、NoSQL与关系型数据库设计理念比较
关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。
4、NoSQL优点
4.1. 性能瓶颈大幅提升
NoSQL的支持者称，通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间，执行速度变得更快。“SQL并非适用于所有的程序代码，”对于那些繁重的重复操作的数据，SQL值得花钱。但是当数据库结构非常简单时，SQL可能没有太大用处。
4.2. 操作相对较少
虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那么多。
4.3. 扩展相对容易
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
4.4. 高性能、大数据量、高可用性(三高)
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用 Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的 Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
5、常用的NoSQL数据库
5.1. Redis
键值（Key-Value）数据库[ Redis ]
适用场景：
储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID（键）挂钩，这种情景下键值数据库是个很好的选择。
不适用场景：
a.取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径
b.需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
c.事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。
5.2. MongoDB
面向文档（Document-Oriented）数据库[ MongoDB ]
数据可以使用XML、JSON或者JSONB等多种形式存储。
适用场景：
a.日志
b.分析
不适用场景：不支持事务
5.3. HBase
列存储（Wide ColumnStore/Column-Family）数据库[ HBase ]
列存储数据库将数据储存在列族（column family）中，一个列族存储经常被一起查询的相关数据。举个例子，如果我们有一个Person类，我们通常会一起查询他们的姓名和年龄而不是薪资。这种情况下，姓名和年龄就会被放入一个列族中，而薪资则在另一个列族中。
适用场景：
a.日志
b.博客平台，我们储存每个信息到不同的列族中。举个例子，标签可以储存在一个，类别可以在一个，而文章则在另一个。
不适用场景：
a.ACID事务
b.原型设计。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。
