http://www.cnblogs.com/sunli/archive/2011/01/14/nosql_why.html
总结：孙立 前辈的为何要使用nosql的解读。 以下内容纯手敲--让自己印象深刻点
NoSQL 概念
web2.0时代，非关系型，分布式快速发展。他们不保证关系型 数据 ACID的特性。NoSQL最常见的解释是"non-relationnal","Not Only SQL"也被很多人接受（"NoSQL"最早于1998年被用于轻量级关系数据库的名字）
NoSQL被我们用的最多的当数key-value存储，当然还有其他文档型，列存储，图形数据库，xml数据库等。在NoSQL概念提出之前，这些数据库就被用于各种系统当中，但是却很少用于web互联网应用。比如cdb,qdbm,bdb数据库
传统关系数据库的瓶颈
传统的关系数据库具有不错的性能，高稳定性，久经历史考验，而且使用简单，功能强大，同时也积累了大量成功案例。在互联网领域，MySQL 成为了绝对靠前的王者。
90年代，一个网站访问量不大，单个数据库轻松应付，更多的都是静态页面，动态交互类型网站也不多。
后期网站开始快速发展。火爆的论坛，微博，SNS，微博卓见引领web领域的潮流。有个文本型存储论坛程序，可以想象一般的论坛的流量有多大。
memcached+MySQL
随着访问量的上升，大部分使用MySQL架构的网站都出现了性能问题，web程序不在仅仅专注在功能上，同时也在追求性能。程序员开始大量使用缓存技术来缓解数据库的压力。优化数据的架构和索引。开始比较流行的使用文件缓存来缓存数据库压力，但是当时访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带来了比较高的IO压力。在这个时候，Memcached就自然受追捧
memcached作为一个分布式的缓存服务器，为多个web服务器提供了一个共享高性能缓存服务，在memcached服务器上，又发展了根据hash算法来进行多台memcached缓存服务的扩展，然后出现了一致性hash来解决或减少缓存服务器导致重新hash带来的大量缓存失败的弊端。
MySQL 主从读写分离
由于数据库的写入压力增加，memcached 只能缓存数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分的网站开始使用主从复制技术来达到读写分离，以提高读写性能和可扩展性。MySQL的master-slave模式也开始成为网站的标配了。
分表分库
随着web2.0的继续高速发展，memcached的告诉缓存，MySQL的主从复制，读写分离的基础上，这时MySQL主库的压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用锁表，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎来代替MyISAM.同事，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一门热门技术。MySQL推出了还不太稳定的分区表，给技术实力一般的公司带来了希望。虽然MySQL推出MySQL Clster集群，但是由于互联网几乎没有成功案例，性能也不能满足互联网的需求，只是高可靠性提供了非常大的保障。
MySQL 的扩展性瓶颈
在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是CPU密集型的话，那么很可能你的MySQL性能设计得有性能问题，需要优化了。大数据量的高并发环境下的MySQL应用开发越来越复杂，也越来越具有挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的字库到一定阶段又面临问题。还有就是需求的变更，可能又需要一种新的分库方式。
MySQL数据库也经常存储一些大文本字段，导致数据库表非常大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB大小，如果能把这些数据从MySQL省去，MySQL将变的非常小。
NOSQL的优势
易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构层面上带来了可扩展的能力
大数据量，高性能
NoSQL数据库具有非常高的读写性能，尤其在大数据量下，同样表现优秀，这是宜于它的无关系性，数据库的架构简单。一般MySQL 使用Query Cache,每次表的更新cache就会失败，是一种大粒度的cache，在针对web2.0的交互频繁的应用，cache性能不高。而NoSQL的cache是记录级的，是一种细颗粒度的cache,所以nosql在这个层面上来说性能高很多。
灵活的数据模型
nosql无需实现为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量web2.0时代尤其明显
高可用
nosql在不太影响性能的情况，就可以方便的实现高可用的架构。比如cassandra,HBase模型，通过复制模型也能实现高可用
总结
nosql 数据库的出现，弥补了关系数据库（比如MySQL）在某些方面的不足，在某些发那个面能极大的节省开发成本和维护成本
以下内容为： 简朝阳 叙述
http://tech.it168.com/a2013/1118/1560/000001560928.shtml
功能：
oracle全才，无论OLAP还是OLTP，无论是锁定机制还是事物处理，无论是内置函数还是外部可扩展功能，都比较全面。
MySQL OLTP型选手，但由于缺少hash join,以及分析函数相对较少，所以OLAP方面功能相对欠缺，但对事物的支持以及锁定机制都比较齐全
NoSQL K/V型选手，主要提供高效的简单查询，虽然部分的NoSQL产品也支持的相对复杂一点的检索，但在事物以及Join方面都为支持，功能弱
性能（写入）
oracle需要记录redo log 且保证每次事物都fsync到物理磁盘以保证事物安全，连续写，数据的写入大多是在内存中完成，后台进程内存到磁盘的定期批量刷新，随即写为主。
MySQL InnoDB引擎 与oracle类似；MyISAM引擎无事物所以没有事物日志到磁盘的fsync问题，由于其锁表的原因，并发稍弱，从总体的使用经验来看和oracle相差不大
NoSQL 在数据存储及日志记录方面的架构及实现优化，使之在写入性能方面较传统数据库有较大优势
性能（复杂查询）
oracle统计信息涉及的方面非常多，优化器相对于MySQL来说也先进很多，再加上多join方式的全面支持，无论是功能还是性能角度来说，多表join都是oracle的优势所在。
MySQL其擦汗腺优化器所能参考的统计信息相对较少，优化器深度也比oracle少很多，所以在多表join的时候出现执行计划异常并不少见。此外，不支持hash join的天生缺陷也让其join能力大打折扣
NoSQL不支持join，不具可比性，无疑是最弱的
扩展能力
oracle 由于其极高的一致性要求，造成架构上不少限制。导致其扩展成本相对高很多
MySQL原声分布式架构的优势在于并发限制，但延迟问题一直被广为诟病，所以大部分场景下是手动进行分布式拆分，但其replication特性加上对一致性约束相较oracle弱，使其架构灵活性很高
NoSQL大多都原声支持分布式部署架构，具有极好的scale out能力。
可维护性
oracle这一点上非常大的优势，无论是性能跟踪还是常规维护方面，oracle都提供了非常丰富的工具和系统
MySQL原声工具相对简单，但由于其开源的特性，有一些第三方的工具支持，比如percona提供的一套工具（原mktools）,但总提仍然比oracle少了一些
NoSQL无论是从性能跟踪还是常规维护来说，都远不如前两者
商业支持
Oracle商业软件，全套的商业服务支持。 上百本文档手册支持，几乎涵盖所有的内容。
MySQL有商业服务支持，但文档相对简单，包含的内容也比较少。
NoSQL少有商业支持，文档非常简单，网络资料也相对少很多
本文出自 “晴空” 博客，谢绝转载！
原文地址：http://7179867.blog.51cto.com/7169867/1656342
