2.4.1　NoSQL的产生

随着互联网Web 2.0网站的兴起，非关系型的数据库成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付Web 2.0网站，特别是超大规模和高并发的SNS类型的Web 2.0纯动态网站方面，已经显得力不从心，暴露了很多难以克服的问题，主要包括以下几个方面：

（1）对数据库高并发读/写的性能需求：Web 2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以，基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读/写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘I/O就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。

（2）对海量数据的高效率存储和访问的需求：对于大型的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下甚至是不可忍受的。再例如大型Web网站的用户登录系统，如腾讯和盛大，动辄数以亿计的账号，关系数据库也很难应付。

（3）对数据库的高可扩展性和高可用性的需求：在基于Web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像网页服务器和应用服务器那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

为什么数据库不能通过不断地添加服务器节点来实现水平扩展呢？

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于Web 2.0网站来说，关系数据库的很多主要特性却往往无用武之地，主要表现在以下几个方面：

（1）数据库事务一致性需求：很多Web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此，数据库事务管理成了数据库高负载下一个沉重的负担。

（2）数据库的写实时性和读实时性需求：对于关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多Web应用来说，并不要求这么高的实时性。

（3）对复杂的SQL查询，特别是多表关联查询的需求：任何大数据量的Web系统，都非常忌讳多个大表的关联查询以及复杂数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，往往从需求以及产品设计角度就避免了这种情况的产生。一般而言，这类Web系统更多的只是单表的主键查询以及单表的简单条件分页查询，SQL的功能被极大地弱化了。

因此，关系数据库在这些越来越多的应用场景下就显得不那么合适了，为了解决这类问题的非关系数据库由此应运而生了NoSQL，它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。NoSQL在2009年初得到了广泛的认同。

当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而NoSQL存储就是为了实现这个需求。Google的BigTable与Amazon的Dynamo是非常成功的商业NoSQL实现。一些开源的NoSQL体系，如Facebook的Cassandra、Apache的HBase，也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处，比如Hadoop、Voldemort、Dynomite等，当然，还存在其他很多NoSQL项目。