【大话NoSQL】——什么是NoSQL？

开始之前，先说说写这篇博文的背景，本来是想写MongoDB的内容，但是MongoDB又是非关系型数据库中最火的一个。我还是本着自己一直习惯的学习步骤，先有全局观，再着眼于微观，所以有必要先了解一下非关系数据库的发展历史，再开始学习MongoDB。否则，我们学习再多的MongoDB也只能是手中的一把沙，抓的越紧，剩下的越少。

整理的博文内容大部分都来自于网络，也有自己一点点见解吧，废话少说，下面进入我们今天的话题：

 

概念

 

NoSQL（NoSQL=Not Only SQL），意即“不仅仅是SQL”。

产生背景

 

随着web2.0的快速发展，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的社会性网络服务类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型、分布式数据存储则由于其本身的特点得到了快速的发展，它们不保证关系数据的ACID特性。

NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受。在不到一年的时间，NoSQL就开始风生水起，大大小小的Web站点在追求高性能高可靠性方面，不由自主都选择了NoSQL技术作为优先考虑的方面。

NoSQL一词最早出现于1998年，是Carlo Strozzi开发的一个轻量级、开源的、不提供SQL功能的关系数据库。直到2009年NoSQL再次被提出，NoSQL的概念发生了天翻地覆的改变，就像它的名字一样，不提供SQL功能的非关系型数据库。我们知道了NoSQL的产生背景，但是为什么它得到了快速发展？

 

为什么NoSQL得到了快速发展？

 

关键原因是：传统关系型数据库遇到了性能瓶颈。

高并发读写、对海量数据的高效率存储和访问以及对数据库的高可扩展性和高可用性成了关系型数据库难以逾越的鸿沟，关系型数据库应对这三大问题显得力不从心，暴露了很多难以克服的问题，例如：

 

1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

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

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

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

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

2、数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

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

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。下面，我们具体看一下它的分类：

 

分类

具体每种的区别，可以到百度百科看一下即可。NoSQL具体包括哪些类型、适用场景，我们用一张图来概括一下（远远不止）：

 

发展现状

 

NoSQL的发展现状，我们用DB-ENGINES的官方数据来进行具体说明，DB-Engines排行榜会根据各种数据库的受欢迎程度排序，DB-Engines排行榜每月更新一次。2014年12月份的排名情况如下图所示：

DB-Engines（点击查看更多）排行榜

 

从上图我们可以看出，排行中的前100个系统包含了传统关系型数据库以及NoSQL系统。排行的前几名被传统关系型数据库霸占：Oracle、MySQL、SQL Server、PostgreSQL以及DB2。在数据库领域中这些传统数据库仍然一方霸主的存在，然而前100中绝大多数的席位被NoSQL数据库霸占，并且它们变得越发的普及起来。相信，NoSQL的人气将会越来越高。下面再看一下NoSQL的优势：

 

特点

 

易扩展

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

大数据量，高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

高可用

NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。

 

总结

NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。MySQL和NoSQL都有各自的特点和使用的应用场景，让关系数据库关注在关系上，NoSQL关注在存储上。

 

下篇博文，我们开始学习NoSQL数据库中最火的一个：MongoDB，谢谢关注。