一、MongoDB综述

1.NoSQL

1.1 NoSQL诞生背景

NoSQL，泛指非关系型的数据库，NoSQL即Not-Only SQL，它可以作为关系型数据库的良好补充。随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

• 1.High performance - 对数据库高并发读写的需求

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

• 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小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。

一些主流的NOSQL产品：

1.2 NoSQL分类

NoSQL数据库的四大分类如下：

键值(Key-Value)存储数据库

    相关产品： Redis

    典型应用： 内容缓存，主要用于处理大量数据的高访问负载。

    数据模型： 一系列键值对

    优势： 快速查询

    劣势： 存储的数据缺少结构化

列存储数据库

    相关产品：HBase

    典型应用：分布式的文件系统

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

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

    劣势：功能相对局限

文档型数据库

    相关产品：MongoDB

    典型应用：Web应用（与Key-Value类似，Value是结构化的）

    数据模型： 一系列键值对

    优势：数据结构要求不严格

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

图形(Graph)数据库

    相关数据库：Neo4J

    典型应用：社交网络

    数据模型：图结构

    优势：利用图结构相关算法。

    劣势：需要对整个图做计算才能得出结果，不容易做分布式的集群方案。

1.3 NoSQL优缺点

NoSQL：Not Only SQL ,本质也是一种数据库的技术，相对于传统数据库技术，它不会遵循一些约束，比如：sql标准、ACID属性，表结构等。

优点

• 满足对数据库的高并发读写
• 对海量数据的高效存储和访问
• 对数据库高扩展性和高可用性
• 灵活的数据结构，满足数据结构不固定的场景

缺点

• 一般不支持事务
• 实现复杂SQL查询比较复杂
• 运维人员数据维护门槛较高
• 目前不是主流的数据库技术

2.MongoDB

MongoDB：是一个数据库 ,高性能、无模式、文档性，目前nosql中最热门的数据库，开源产品，基于c++开发。是nosql数据库中功能最丰富，最像关系数据库的。

2.1 MongoDB特性

• 面向集合文档的存储：适合存储Bson（json的扩展）形式的数据；
• 格式自由，数据格式不固定，生产环境下修改结构都可以不影响程序运行；
• 强大的查询语句，面向对象的查询语言，基本覆盖sql语言所有能力；
• 完整的索引支持，支持查询计划；
• 支持复制和自动故障转移；
• 支持二进制数据及大型对象（文件）的高效存储；
• 使用分片集群提升系统扩展性；
• 使用内存映射存储引擎，把磁盘的IO操作转换成为内存的操作；

2.1 MongoDB基本概念

2.2 MongoDB概念与RDMS概念对比

2.3 应不应该使用MongoDB

并没有某个业务场景必须要使用 MongoDB才能解决，但使用 MongoDB 通常能让你以更低的成本解决问题（包括学习、开发、运维等成本）

应用特征	Yes/ No
应用不需要事务及复杂 join 支持	必须为Yes
新应用，需求会变，数据模型无法确定，想快速迭代开发	?
应用需要2000-3000以上的读写QPS	?
应用需要TB甚至 PB 级别数据存储	?
应用发展迅速，需要能快速水平扩展	?
应用要求存储的数据不丢失	?
应用需要99.999%高可用	?
应用需要大量的地理位置查询、文本查询	?

如果上述有1个 Yes，可以考虑 MongoDB，2个及以上的 Yes，选择MongoDB绝不会后悔！

2.4 MongoDB使用场景

MongoDB 的应用已经渗透到各个领域，比如游戏、物流、电商、内容管理、社交、物联网、视频直播等，以下是几个实际的应用案例：

• 游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存储，方便查询、更新
• 物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。
• 社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引实现附近的人、地点等功能
• 物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这些信息进行多维度的分析
• 视频直播，使用 MongoDB 存储用户信息、礼物信息等

2.5 什么场景不能用MongoDB

• 高度事务性系统：例如银行、财务等系统。MongoDB对事物的支持较弱；
• 传统的商业智能应用：特定问题的数据分析，多数据实体关联，涉及到复杂的、高度优化的查询方式；
• 使用sql方便的时候；数据结构相对固定，使用sql进行查询统计更加便利的时候；