虽然09年出现了比较激进的文章《关系数据库已死》，但是我们心里都清楚，关系数据库其实还活得好好的，你还不能不用关系数据库。但是也说明了一个事实，关系数据库在处理WEB2.0数据的时候，的确已经出现了瓶颈。
那么我们到底是用NoSQL还是关系数据库呢？我想我们没有必要来进行一个绝对的回答。我们需要根据我们的应用场景来决定我们到底用什么。
如果关系数据库在你的应用场景中，完全能够很好的工作，而你又是非常善于使用和维护关系数据库的，那么我觉得你完全没有必要迁移到NoSQL上面， 除非你是个喜欢折腾的人。如果你是在金融，电信等以数据为王的关键领域，目前使用的是Oracle数据库来提供高可靠性的，除非遇到特别大的瓶颈，不然也 别贸然尝试NoSQL。
然而，在WEB2.0的网站中，关系数据库大部分都出现了瓶颈。在磁盘IO、数据库可扩展上都花费了开发人员相当多的精力来优化，比如做分表分库 （database sharding）、主从复制、异构复制等等，然而，这些工作需要的技术能力越来越高，也越来越具有挑战性。如果你正在经历这些场合，那么我觉得你应该尝 试一下NoSQL了。
选择合适的NoSQL
如此多类型的NoSQL，而每种类型的NoSQL又有很多，到底选择什么类型的NoSQL来作为我们的存储呢？这并不是一个很好回答的问题，影响我们选择的因素有很多，而选择也可能有多种，随着业务场景，需求的变更可能选择又会变化。我们常常需要根据如下情况考虑：
1. 数据结构特点。包括结构化、半结构化、字段是否可能变更、是否有大文本字段、数据字段是否可能变化。
2. 写入特点。包括insert比例、update比例、是否经常更新数据的某一个小字段、原子更新需求。
3. 查询特点。包括查询的条件、查询热点的范围。比如用户信息的查询，可能就是随机的，而新闻的查询就是按照时间，越新的越频繁。
NoSQL和关系数据库结合
其实NoSQL数据库仅仅是关系数据库在某些方面（性能，扩展）的一个弥补，单从功能上讲，NoSQL的几乎所有的功能，在关系数据库上都能够满足，所以选择NoSQL的原因并不在功能上。
所以，我们一般会把NoSQL和关系数据库进行结合使用，各取所长，需要使用关系特性的时候我们使用关系数据库，需要使用NoSQL特性的时候我们使用NoSQL数据库，各得其所。
举个简单的例子吧，比如用户评论的存储，评论大概有主键id、评论的对象aid、评论内容content、用户uid等字段。我们能确定的是评论内 容content肯定不会在数据库中用where content=’’查询，评论内容也是一个大文本字段。那么我们可以把 主键id、评论对象aid、用户id存储在数据库，评论内容存储在NoSQL，这样数据库就节省了存储content占用的磁盘空间，从而节省大量IO， 对content也更容易做Cache。
//从MySQL中查询出评论主键id列表
commentIds=DB.query("SELECT id FROM comments where aid='评论对象id' LIMIT 0,20");
//根据主键id列表，从NoSQL取回评论实体数据
CommentsList=NoSQL.get(commentIds);