关系数据库还是NoSQL数据库.docVIP

关系数据库还是NoSQL数据库

上一篇简单的说明了为什么要使用NoSQL。接下来我们看下如何把NoSQL引入到我们的项目中，我们到底要不要把NoSQL引入到项目中。

在过去，我们只需要学习和使用一种数据库技术，就能做几乎所有的数据库应用开发。因为成熟稳定的关系数据库产品并不是很多，而供你选择的免费版本就更加少了，所以互联网领域基本上都选择了免费的MySQL数据库。在高速发展的WEB2.0时代，我们发现关系数据库在性能、扩展性、数据的快速备份和恢复、满足需求的易用性上并不总是能很好的满足我们的需要，我们越来越趋向于根据业务场景选择合适的数据库，以及进行多种数据库的融合运用。几年前的一篇文章《OneSizeFitsAll-AnIdeaWhoseTimeHasComeandGone》就已经阐述了这个观点。

当我们在讨论是否要使用NoSQL的时候，你还需要理解NoSQL也是分很多种类的，在NoSQL百花齐放的今天，NoSQL的正确选择比选择关系数据库还具有挑战性。虽然NoSQL的使用很简单，但是选择却是个麻烦事，这也正是很多人在观望的一个原因。

NoSQL的分类

NoSQL仅仅是一个概念，NoSQL数据库根据数据的存储模型和特点分为很多种类。

类型部分代表特点

列存储HbaseCassandraHypertable顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。

文档存储MongoDBCouchDB文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有有机会对某些字段建立索引，实现关系数据库的某些功能。

key-value存储TokyoCabinet/TyrantBerkeleyDBMemcacheDBRedis可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。(Redis包含了其他功能)

图存储Neo4JFlockDB图形关系的最佳存储。使用传统关系数据库来解决的话性能低下，而且设计使用不方便。

对象存储db4oVersant通过类似面向对象语言的语法操作数据库，通过对象的方式存取数据。

xml数据库BerkeleyDBXMLBaseX高效的存储XML数据，并支持XML的内部查询语法，比如XQuery,Xpath。

以上NoSQL数据库类型的划分并不是绝对，只是从存储模型上来进行的大体划分。它们之间没有绝对的分界，也有交差的情况，比如TokyoCabinet/Tyrant的Table类型存储，就可以理解为是文档型存储，BerkeleyDBXML数据库是基于BerkeleyDB之上开发的。

NoSQL还是关系数据库

虽然09年出现了比较激进的文章《关系数据库已死》，但是我们心里都清楚，关系数据库其实还活得好好的，你还不能不用关系数据库。但是也说明了一个事实，关系数据库在处理WEB2.0数据的时候，的确已经出现了瓶颈。

那么我们到底是用NoSQL还是关系数据库呢?我想我们没有必要来进行一个绝对的回答。我们需要根据我们的应用场景来决定我们到底用什么。

如果关系数据库在你的应用场景中，完全能够很好的工作，而你又是非常善于使用和维护关系数据库的，那么我觉得你完全没有必要迁移到NoSQL上面，除非你是个喜欢折腾的人。如果你是在金融，电信等以数据为王的关键领域，目前使用的是Oracle数据库来提供高可靠性的，除非遇到特别大的瓶颈，不然也别贸然尝试NoSQL。

然而，在WEB2.0的网站中，关系数据库大部分都出现了瓶颈。在磁盘IO、数据库可扩展上都花费了开发人员相当多的精力来优化，比如做分表分库(databasesharding)、主从复制、异构复制等等，然而，这些工作需要的技术能力越来越高，也越来越具有挑战性。如果你正在经历这些场合，那么我觉得你应该尝试一下NoSQL了。

选择合适的NoSQL

如此多类型的NoSQL，而每种类型的NoSQL又有很多，到底选择什么类型的NoSQL来作为我们的存储呢?这并不是一个很好回答的问题，影响我们选择的因素有很多，而选择也可能有多种，随着业务场景，需求的变更可能选择又会变化。我们常常需要根据如下情况考虑：

数据结构特点。包括结构化、半结构化、字段是否可能变更、是否有大文本字段、数据字段是否可能变化。写入特点。包括insert比例、update比例、是否经常更新数据的某一个小字段、原子更新需求。查询特点。包括查询的条件、查询热点的范围。比如用户信息的查询，可能就是随机的，而新闻的查询就是按照时间，越新的越频繁。NoSQL和关系数据库结合

其实NoSQL数据库仅仅是关系数据库在某些方面(性能，扩展)的一个弥补，单从功能上讲，N