转自 http://blog.csdn.net/qq_16313365/article/details/52232623

1.初识NoSql

1.1关系型数据库

      在认识NoSql之前先来简单的了解下什么是关系型数据库。

    **关系型数据库以行和列的二维表格形式来存储数据**，这一系列的行和列被称为表，一组表组成了数据库。表与表之间存在着关系，这种关系采用现实世界中实体与实体之间的关系模型。**关系型数据库并不是唯一的高级数据库模型，也完全不是性能最优的模型，但是关系型数据库确实是现今使用最广泛、最容易理解和使用的数据库模型。**现在流行的大型关系型数据库有Oracle、DB2、PostgreSQL、Microsoft SQL Server、Microsoft Access、MySQL等等。

1.2非关系型数据库

1.2.1概念

    **NoSql**，Not only Sql，意为“不仅仅是sql”，泛指非关系型的数据库。**关系型数据库中，表都是存储格式化结构的数据**，每个元组（可以理解为二维表中的一行，在数据库中经常被称为记录）字段的组成都是一样的，即使不是每个元组都需要所有的字段，但数据库会为每个元组都分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系数据库性能瓶颈的一个因素。

    **而非关系数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加或减少一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。**

1.2.2发展

    NoSQL一词首先是CarloStrozzi在1998年提出来的，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。这个定义跟我们现在对NoSQL的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，我们要的不是“no sql”，而是“no relational”。

    2009年初，JohanOskarsson举办了一场关于开源分布式数据库的讨论，Eric Evans在这次讨论中再次提出了NoSQL一词，用于指代那些非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统。Eric Evans使用NoSQL这个词，并不是因为字面上的“没有SQL”的意思，他只是觉得很多经典的关系型数据库名字都叫“**SQL”,所以为了表示跟这些关系型数据库在定位上的截然不同，就是用了“NoSQL“一词。

    随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS（社交网络服务）类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。就目前来讲，NoSql对大型企业来说还不是主流，但再过一两年后，NoSql很有可能成为主流。

1.2.3分类

    **NoSql又分为四大类数据库：**键值(Key-Value)存储数据库、列存储数据库、文档型数据库、图形(Graph)数据库。它们的对比分析如下：

|

分类

|

Examples举例

|

典型应用场景

|

数据模型

|

优点

|

缺点

|
|

键值（key-value）

|

Tokyo Cabinet/Tyrant，

Redis，

Voldemort，

Oracle BDB

|

内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。

|

Key 指向 Value 的键值对，通常用hash table来实现

|

查找速度快

|

数据无结构化，通常只被当作字符串或者二进制数据

|
|

列存储数据库

|

Cassandra, HBase, Riak

|

分布式的文件系统

|

以列簇式存储，将同一列数据存在一起

|

查找速度快，可扩展性强，更容易进行分布式扩展

|

功能相对局限

|
|

文档型数据库

|

CouchDB，

MongoDB

|

Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）

|

Key-Value对应的键值对，Value为结构化数据

|

数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构

|

查询性能不高，而且缺乏统一的查询语法。

|
|

图形(Graph)数据库

|

Neo4J，

InfoGrid，

Infinite Graph

|

社交网络，推荐系统等。专注于构建关系图谱

|

图结构

|

利用图结构相关算法。比如最短路径寻址，N度关系查找等

|

很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。

|

1.2.4应用场景

1. 数据模型比较简单

2. 需要灵活性更强的IT系统

3. 对数据库性能要求较高

4. 不需要高度的数据一致性

5. 对于给定key，比较容易映射复杂值的环境

1.3关系与非关系型数据库的对比

关系型数据库和非关系型数据库的特性、优点、缺点及应用场景对比如下：

| |

特性

|

优点

|

缺点

|
|

关系型数据库

|

1.采用关系模型来组织数据

2.事务的一致性

3. 一个关系型数据库是由关系模型（即二维表格模型）及其之间的关联关系组成的一个数据组织

|

1.容易理解。二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更易理解

2.使用方便。标准的sql语言使得操作关系数据库非常方便

3.易于维护。丰富的完整性（实体完整性、参照完整性和用户定义的完整性）大大降低了数据冗余和数据不一致的概率。

4.支持Sql及事务处理。可以进行复杂查询，事务支持使得其能保证数据一致性

|

1.读写性能差。为了维护数据一致性所付出的巨大代价就是其读写性能比较差

2.高并发读写需求

3.海量数据高效率读写

4.固定的表结构。不擅长为有数据的表做索引或表结构的变更

|
|

非关系型(NoSql)

|

1.以键值对存储

2.分布式

3.一般不支持ACID特性（即数据库事务特性：原子性、一致性、隔离性、持久性）

4.NoSql严格上讲不是一种数据库，应该是一种数据结构化存储方法的集合

|

1.灵活的数据存储模型。数据结构不固定

2.易扩展。数据之间无耦合，非常容易扩展

3. 高性能。能够适应现代网络对数据库高并发读写请求以及对海量数据的高速访问能力，得益于它的无关系性

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

|

1. 不提供对SQL的支持。Sql是工业标准，不支持sql将对用户产生一定的学习和迁移成本

2. 应用局限性。大多数NoSql数据库都不支持事务，现有产品功能不够完善，附加功能如Bi和报表等也不支持

3.现有产品不成熟。缺乏类似关系型数据库所具有的强有力的理论、技术、标准规范（如sql）等支持。

|

2.初识MongoDB

2.1简介

    通过上面的了解可以知道，**MongoDB属于NoSql的一种，且是属于NoSql中的基于分布式文件存储的文档型数据库。由C++语言编写，旨在为WEB应用提供可扩展的高性能数据存储解决方案。**

    **MongoDB是一个介于关系数据库和非关系数据库之间的产品**，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似json的bson（是一种类json的一种二进制形式的存储格式，简称Binary JSON）格式，因此可以存储比较复杂的数据类型。**Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。**

2.2特点

它的特点是高性能、易部署、易使用，存储数据非常方便。主要功能特性有：

*** 面向集合存储，易存储对象类型的数据。**

*** 模式自由。**

*** 支持动态查询。**

*** 支持完全索引，包含内部对象。**

*** 支持查询。**

*** 支持复制和故障恢复。**

*** 使用高效的二进制数据存储，包括大型对象（如视频等）。**

*** 自动处理碎片，以支持云计算层次的扩展性。**

*** 支持RUBY，PYTHON，JAVA，C++，PHP，C#等多种语言。**

*** 文件存储格式为BSON（一种JSON的扩展）。**

*** 可通过网络访问。**

2.3数据模型

    **一个MongoDB 实例可以包含一组数据库，一个DataBase 可以包含一组Collection（集合），一个集合可以包含一组Document（文档）。一个Document包含一组field（字段），每一个字段都是一个key/value pair。**

key: 必须为字符串类型。

value：可以包含如下类型

1）基本类型，例如，string，int，float，timestamp，binary 等类型。

2）一个document。

3）数组类型

2.4使用原理

    所谓“面向集合”（Collection-Oriented），意思是数据被分组存储在数据集中，被称为一个集合（Collection)。每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需要定义任何模式（schema)。Nytro MegaRAID技术中的闪存高速缓存算法，能够快速识别数据库内大数据集中的热数据，提供一致的性能改进。

    模式自由（schema-free)，意味着对于存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。存储在集合中的文档，被存储为键-值对的形式。键用于唯一标识一个文档，为字符串类型，而值则可以是各种复杂的文件类型。我们称这种存储形式为BSON（Binary Serialized Document Format）。

2.5应用场景

** MongoDB 的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）和传统的RDBMS 系统（具有丰富的功能）之间架起一座桥梁，它集两者的优势于一身，适用于以下场景**：

1）网站数据：Mongo 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。

2）缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo 搭建的持久化缓存层可以避免下层的数据源过载。

3）大尺寸、低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。

4）高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库，Mongo 的路线图中已经包含对MapReduce 引擎的内置支持。

5）用于对象及JSON 数据的存储：Mongo 的BSON 数据格式非常适合文档化格式的存储及查询。

不适用场景：

1）高度事务性的系统：例如，银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。

2）传统的商业智能应用：针对特定问题的BI 数据库会产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。

3）需要SQL 的问题。