（弥补关系数据库的不足，处理海量数据利器）NoSQL运动全解析

一、理解NOSQL
关系数据库借助SQL，以其广泛的商业用途和使用的便利性，三十年来打造了一种“one size fit all”的模式。但是，随着大规模非结构化应用在互联网领域的出现，尤其是web2.0的异军突起，传统的关系数据库为了保证“通用性”的设计而带来的功能复杂、性能开销大、价格昂贵的问题，急切呼唤出现一种替代方案：对于专门的应用，设计一种专门的数据库，从而做针对性的优化，提升性能和使用灵活度，以及更好的支持集群化运行来处理海量数据。这种趋势总结为：“Not
Only SQL”，即不仅仅是使用SQL进行数据查询和管理的关系型数据库了，对于特殊的应用需要设计更合适的替代方案。而具有代表意义的就是Key-value数据库（google的bigtable），图数据库，面向列的数据库（amazon的dynamo）等。
二、NOSQL驱动力
使用NOSQL的理由如下：
1、避免不需要的复杂性
多种功能和ACID强事物一致性是很多应用不需要的。
2、更高的吞吐量
比关系DBMS的写入、处理和读取能力更强。比如，google的bigtable借助MapReduce每天可以处理20Tb的数据量。
3、在商用硬件上的水平扩展能力
传统DBMS较之NOSQL的局限性：
a、处理数据量不足（如facebook每天50GB的邮箱搜索，ebay每天2TB的交易数据）；
b、对单个服务器要求较高；
c、严格的模式（schema）设计。
相反，NOSQL可以在普通商业硬件上自由扩展。
4、避免繁重的对象-关系映射
NOSQL支持简单的数据结构，可以和大多数面向对象的语言很好的结合进行过程化编程，不要在和SQL的关系表进行映射管理。
5、NOSQL实现了大表的自动分割（sharding）功能，更好的支持分布式处理。
6、在性能和可靠性之间的折中
并不是所有数据都需要做持久化处理，比如会话数据，就是当会话结束后就可以自动删除。
7、云计算的需求（从中心模式转到分布模式）
三、NOSQL发展论述
关系性DBMS退出历史舞台的基因：
1、产生于70年的SYSTEM R，如今硬件性能、编程模式都发生了变化；
2、从应对传统的商业数据扩展到了多种数据领域，包括文本、视频、流数据等；
3、即使是商业数据领域：其单击基因也导致了并行性能的低下。
当前数据库设计系统的设计问题：
1、主存可以处理Tb级数据（最大的商业OLAP数据量也就是几Tb，并且数据量增长缓慢）；
2、多线程和资源限制：主存数据库IO开销很小，事务可以很快执行完，因此，没有必要花费精力去设计精细的多线程代码。同时，单线程带来高可靠性，以及更高的性能。但是，对于大的事物需要进行事物分割。
3、无共享结构（见另一片NOSQL设计十大原则）的译文，不许要共享主存和磁盘空间，而是网络相连的自治主机，类似于网格计算。
4、高可靠性、高容灾能力
传统的log容灾处理，转换为多机备份。而事物的原子性可以通过内存中结构来实现。
5、自诊断、自优化
在人力资源昂贵的今天，降低对熟练DBA的要求，让系统自己良好的运行。
具体实现问题见Stonebraker【1】等的（google 中搜索该文章即可）论文。
总结：“we are heading toward a world with at least 5 (and probably more) specialized engines and the death of the “one size fits all” legacy systems”
我们需要开启一个新的世界，由五种（或者更多）的专用数据库引擎替代当前的“一刀切“的系统。
可以预测的专业领域是：
1、数据仓库；
2、流数据处理；
3、文本处理；
4、面向科学计算的数据库；
5、半结构化数据。
四、主要驱动者
1、web大型公司（google，amazon，facebook等）
2、云计算公司
3、具有特定应用需求的公司
五、批评
1、开源项目居多，故障支持很难做；
2、没有新意，老技术；

【1】Stonebraker, Michael ; Bear, Chuck ; Çetintemel, Uğur ; Cherniack, Mitch ; Ge,
Tingjian ; Hachem, Nabil ; Harizopoulos, Stavros ; Lifter, John ; Rogers, Jennie ;
Zdonik, Stan: One Size Fits All? – Part 2: Benchmarking Results. In: Proc. CIDR, 2007,
p. 173–184