学步园

 什么是NoSQL

NoSQL，意即反SQL运动，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
 

　　现今的计算机体系结构在数据存储方面要求具备庞大的水平扩展性①，而NoSQL致力于改变这一现状。目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。

　　NoSQL项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：它们可以处理超大量的数据。

　　这场革命目前仍然需要等待。的确，NoSQL对大型企业来说还不是主流，但是，一两年之后很可能就会变个样子。在NoSQL运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。分享他们如何推翻缓慢而昂贵的关系数据库的暴政，怎样使用更有效和更便宜的方法来管理数据。

　　“关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足RDBMS （relational database management system，关系型数据库管理系统）的需要，”在NoSQL拥护者们看来，基于NoSQL的替代方案“只是给你所需要的”。
NoSQL, 根据WikiPedia上的解释，是 “一种泛称（umbrella term），指那些非关系性的、定义不是很明确的数据存储仓库。“这个术语最早是 Rackspace 公司 的员工 Eric Evans 发明的。在他上年十月发表的博客里出现了NoSQL (现在普遍认为是 Not Only SQL 的意思) 这个词。这篇博客里真正的闪光点是”我们之所以要寻找一个其它类型的数据库的根本原因是想解决关系型数据库存在的各种弊端。“Adam Keys 在他的博客The Real Adam blog post提供了另一个相似的术语：”Post-Relational”。一些
NoSQL数据库还把消除那种关系型数据库对计算机资源、内存占用的问题作为一个目标。NoSQL的其他目标还包括：弱化与编程语言的关系，使用Web技术和RPC调用方式可访问，以及可切换的数据查询方式。

Nosql全称是Not Only SQL，是一种不同于关系型数据库的数据库管理系统设计方式。对NoSQL最普遍的解释是“非关系型的”，强调Key-Value Stores和文档数据库的优点，而不是单纯的反对RDBMS

一. 
NoSQL概念

       开源的数据库用的最多的是PostgreSQL和MySQL。 关于这2者的对比，参考我的Blog：

       MySQL 和 PostgreSQL
对比

       http://blog.csdn.net/tianlesoftware/archive/2011/04/29/6371498.aspx

       NoSQL 它指的是一个整体的概念，在2009年被提了出来。 大部分NoSQL 数据库都是开源的。 NoSQL最常见的解释是“non-relational”，“Not Only SQL”。 “NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。

　NoSQL指不使用传统的关系数据库模型，而是使用如key-value存储、文档型的、列存储、图型数据库、xml等方式存储数据的模型统称。
其中用的最多的是： key-value存储。

       之所以不使用传统的范式，主要是在于它们存储数据的方式发生了变化。

       例如，当你需要存储发票的数据时，在传统的关系数据模型中，需要设计表的结构，然后使用服务器端语言将其转化为实体对象，再传递到用户端(这就是所谓的ORM对象关系映射)，而在NoSQL中，你只要保存发票数据就可以了。       
NoSQL不需要预先设计表和结构就可以储存新的数值。当然， NoSQL不是万能。如果项目中要保存的数据的确需要关系型数据库模型才能完成，那么应该坚持使用关系型数据库。

　　NoSQL的出现主要是为了解决数据库读写性能的问题，随着越来越庞大的Web应用系统的出现，如SNS,微博等应用需要大量对数据进行读和写，并且要求进行分布式的部署，而传统的关系数据模型在大数据访问量和分布式环境下，由于关系模型中经常要对多表进行连接操作，因此性能有时会有所降低，所以NoSQL的强调的是非关系型数据，NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。

       目前，Google 的 BigTable 与 Amazon 的 Dynamo 是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的 Cassandra ， Apache 的 HBase ，也得到了广泛认同。

传统关系数据库的瓶颈

       传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，MySQL为互联网的发展做出了卓越的贡献。

       在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。

       到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。

Memcached+MySQL

       后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。 程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。

       Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。

Mysql主从读写分离

       由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库

       随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。     
虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。

MySQL的扩展性瓶颈

       在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又需要一种新的分库方式。

       MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。

       关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。

NOSQL的优势

（1）易扩展

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

（2）大数据量，高性能

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

（3）灵活的数据模型

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

（4）高可用

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

二.  NoSQL
的选择

NoSQL的分类

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

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

选择合适的NoSQL

       如此多类型的NoSQL，而每种类型的NoSQL又有很多，选择也可能有多种，随着业务场景，需求的变更可能选择又会变化。我们常常需要根据如下情况考虑：

（1）.      数据结构特点。包括结构化、半结构化、字段是否可能变更、是否有大文本字段、数据字段是否可能变化。

（2）.      写入特点。包括insert比例、update比例、是否经常更新数据的某一个小字段、原子更新需求。

（3）.      查询特点。包括查询的条件、查询热点的范围。比如用户信息的查询，可能就是随机的，而新闻的查询就是按照时间，越新的越频繁。

NoSQL和关系数据库结合

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

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

NoSQL代替MySQL

       在某些应用场合，比如一些配置的关系键值映射存储、用户名和密码的存储、Session会话存储等等，用NoSQL完全可以替代MySQL存储。不但具有更高的性能，而且开发也更加方便。

NoSQL作为缓存服务器

       MySQL+Memcached的架构中，我们处处都要精心设计我们的缓存，包括过期时间的设计、缓存的实时性设计、缓存内存大小评估、缓存命中率等等。

       NoSQL数据库一般都具有非常高的性能，在大多数场景下面，你不必再考虑在代码层为NoSQL构建一层Memcached缓存。NoSQL数据本身在Cache上已经做了相当多的优化工作。

       Memcached这类内存缓存服务器缓存的数据大小受限于内存大小，如果用NoSQL来代替Memcached来缓存数据库的话，就可以不再受限于内存大小。虽然可能有少量的磁盘IO读写，可能比Memcached慢一点，但是完全可以用来缓存数据库的查询操作。

规避风险

       由于NoSQL是一个比较新的东西，特别是我们选择的NoSQL数据库还不是非常成熟的产品，所以我们可能会遇到未知的风险。

       为了得到NoSQL的好处，又要考虑规避风险， 现在业内很多公司的做法就是数据的备份。在往NoSQL里面存储数据的时候还会往MySQL里面存储一份。NoSQL数据库本身也需要进行备份（冷备和热备）。或者可以考虑使用两种NoSQL数据库，出现问题后可以进行切换（避免出现digg使用Cassandra的悲剧）。

就像当年波士顿的爱国者为反抗英国重税的行动一样，NoSQL的支持者们从各地涌来，分享他们如何推翻缓慢而昂贵的关系数据库的暴政，怎样使用更有效和更便宜的方法来管理数据，他们开始对SQL说不！NoSQL组织上个月在旧金山的行动让人闻到了数据库革命的味道，好像一个现代IT业版的波士顿倾茶事件正在策划之中。
在NoSQL运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。

就像当年波士顿的爱国者为反抗英国重税的行动一样，NoSQL的支持者们从各地涌来，分享他们如何推翻缓慢而昂贵的关系数据库的暴政，怎样使用更有效和更便宜的方法来管理数据。云计算可能会为数据库技术的发展带来新的契机，如果想在云中获得丰富而随需应变的可伸缩性，你需要一个非关系数据库。

“关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足RDBMS （relational database management system，关系型数据库管理系统）的需要，”Java工具提供商SpringSource公司的首席工程师Jon Travis说，他是本次集会的10位发言人之一，在他看来，基于NoSQL的替代方案“只是给你所需要的”。

开源的兴起

反SQL运动的主要倡导者都是Web和Java开发者，他们中许多人都在创业的初期历经了资金短缺并因此与Oracle说再见，然后效仿Google和Amazon的道路建设起自己的数据存储解决方案，并随后将自己的成果开源发布。现在，他们的开源数据商店管理着成百TB甚至PB的数据，由于Web 2.0和云计算的兴起，无论从技术上还是从经济上他们都无需再返回从前，甚至连想也不用想。

“Web 2.0的企业应该抓住机会，他们需要可扩展性，”总部设在伦敦的NoSQL会议组织者Johan Oskarsson说，他任职于著名的音乐网站Last.fm，其他的大多数与会者也都是网络开发者。

Oskarsson说，许多人甚至抛弃了MySQL开源数据库这个长期以来Web 2.0的宠儿，而改由NoSQL的方案来替代，因为优势实在是引人注目。51CTO.com之前曾报道过MySQL创始人宣布创建开源数据库联盟的消息，过度的商业化是MySQL失去原来的优势。

例如Facebook建立了自己的Cassandra数据商店并且在其网站上重点推出一项新的搜索功能，没有使用到现有的MySQL数据库。据Facebook的工程师Avinash Lakshma介绍，Cassandra仅用0.12毫秒就可以写入50GB的数据，比MySQL快了超过2500倍。Google也开始公测他们的云数据库Fusion Tables，这是一个和传统数据库完全不同的数据库，主要优势能够简单的解决关系型数据库中管理不同类型数据麻烦，以及排序整合的常见操作的性能问题等。

什么是NoSQL（从技术上说）？

从这些NoSQL项目的名字上看不出什么相同之处：Hadoop、Voldemort、Dynomite，还有其它很多。

但是，它们通常在某些方面相同：

不要叫它们数据库。Amazon.com的首席技术官Werner Vogels将他们的重要的Dynamo系统称作“高可用性的键值商店”。Google将自己的BigTable称作“管理结构化数据的分布式存储系统”，在51CTO.com之前的外电《云服务颠覆开发传统观念》中曾提到，Google的Big Table不是SQL数据库，原因是SQL数据库支持的一些功能实在难以进行分割，这与我们跨机器存储数据的想法无法结合。它们都是许多NoSQL追随者的效仿模式。

它们可以处理超大量的数据。比如Zvents公司以BigTable模式搭建的开源数据库Hypertable，据Zvents工程师Doug Judd介绍，它可以每天在搜索引擎中写入10亿单元数据。

另外，BigTable与其姊妹技术MapReduce相结合，每天可以处理多达20PB的数据。

“毫无疑问，数据量越来越巨大也让人们寻找其他的数据库替代技术，”SpringSource的Travis说。

它们运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。

Google曾表示一个BigTable的大集群可以管理数千台服务器上多达6PB的数据。

“Oracle会告诉你需要购买一些硬件然后正确配置Oracle RAC，然而用其他的神奇软件你也可以达到相同的可扩展性。但是两者的开销可是天差地别。”SpringSource首席技术官Javier Soltero说。

它们击碎了性能瓶颈。NoSQL的支持者称，通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间，执行速度变得更快。

“SQL并非适用于所有的程序代码，”数据库分析师Curt Monash说。对于那些繁重的重复操作的数据，SQL值得花钱。但是当数据库结构非常简单时，SQL可能没有太大用处。

Adobe公司资深计算机科学家Raffaele Sena说，当一年半前Adobe准备重新更新ConnectNow网络协作服务时，正是由于上面的理由，他们决定不采用关系型数据库。

Adobe决定使用Terracotta 提供的Java集群软件，管理Java格式的数据，Sena说，这使ConnectNow的性能提高到前一版本的2至3倍。

没有过多的操作。虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那么多。

以Adobe的ConnectNow为例，Sena说，当用户在线时它会不通过数据库而制作三份会话数据，在离线后删除。“因此我们并不需要数据库，因为具体所需要的数据是在内存中的，”他说。

Bootstrap支持

因为NoSQL项目都是开源的，因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样，不得不从社区中寻求支持。

但是一些人承认，没有正式的官方支持，万一出了差错会是可怕的，至少很多管理人员是这样看。

“我们确实需要做一些说服工作，”Adobe的Sena承认，“但基本在他们看到我们的第一个原型运行良好之后，我们就能够说服他们，这是条正确的道路。”

“大多数大型企业已经习惯于使用关系型数据库管理系统。因此他们会想为什么要改变呢？”Monash说。比如MapReduce和类似的项目“对企业有意。但是在具体使用时，它很可能会和一个分析DBMS（数据库管理系统）相集成。”

即使NoSQL的组织者Oskarsson也承认，就算是他自己的公司Last.fm也还没有做好转为NoSQL替代者的准备，现在依然在使用开源数据库。

他认为这场革命目前仍然需要等待。

非关系型数据库，最大特点是没有固定模式，即表的格式不固定，一般都舍弃了事务处理功能而注重海量存储下的读写性能。