NoSQL简介
写在前面，本文就是学习的记录笔记，大部分内容都属于参考，分享给大家
关系与非关系数据库
那么应该了解下影响关系数据库性能的主要原因：
- 在关系型数据库中，导致性能欠佳的最主要因素是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询;
- 即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。
非关系型数据库提出另一种理念，以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询，仅需要根据id取出相应的value就可以完成查询。
目前数据库面临的挑战
- High performance – 对数据库高并发读写的需求
- web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。
- Huge Storage – 对海量数据的高效率存储和访问的需求
- 类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
- High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
- 在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
关系数据库的问题
- 数据库事务一致性需求
- 数据库的写实时性和读实时性需求
- 对复杂的SQL查询，特别是多表关联查询的需求
为了解决关系数据库的问题，nosql应运而生
- 满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare
- 满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB
- 满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort
Redis:
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)和zset(有序集合)、Hash(哈希类型的映射表)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。 在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写。
mongodb:
mongodb是一种分布式文档存储数据库，c++编写，是基于文档的存储的（而非表） mongo主要解决的是海量数据的访问效率问题。因为Mongo主要是支持海量数据存储的，所以mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储。由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎。 根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。
参考
http://blog.csdn.net/burningsheep/article/details/7725181
http://robbin.iteye.com/blog/524977
http://blog.csdn.net/zhu_xun/article/details/16804075
