mongodb入门-关系型RDMS数据库对比及适用场景

引言

 

最近工做接触到了mongodb数据库，记录下我的对其的理解和使用状况。虽然mongodb 出来的时间已经不短，可是相对mysql mssql oracle 这样传统的关系型数据库来讲仍是比较年轻，接触其的程序员应该也不多，本文从仅做介绍用。

名字看MongoDB疑似Humongous Database（网络资料看到）。中文意思就是巨大无比的数据库，顾名思义，MongoDB就是为处理大数据而生，以解决海量数据的存储和高效查询使用为使命。

说道mongodb不得不说到nosql ，由于mongo就是nosql的一种。NoSQL是Not only SQL的缩写，NoSQL不使用SQL做为查询语言。其数据存储能够不须要固定的表格模式，也常常避免使用SQL的join操做，通常有水平可扩展性的特征。

no sql出现缘由：

随着web2.0的兴起，关系型数据库自己没法克服的缺陷愈来愈明显：
一、对海量数据的高效率存储和访问的需求。
二、对数据库的高可扩展性和高可用性的需求。
三、数据库写实性和读写时性需求

 

这也是nosql 或者mongo能够解决的问题。

 

mongodb介绍

 

    MongoDB 是一个可扩展的高性能，开源，模式自由，介于关系数据库和非关系数据库之间，面向文档的数据库。它使用C++编写。MongoDB特色:

  a.面向集合的存储：适合存储对象及JSON形式的数据。

  b.动态查询：mongo支持丰富的查询表达方式，查询指令使用JSON形式的标记，可轻易查询文档中的内嵌的对象及数组。

  c.完整的索引支持:包括文档内嵌对象及数组。mongo的查询优化器会分析查询表达式，并生成一个高效的查询计划。

  d.查询监视：mongo包含一个监视工具用于分析数据库操做性能。

  e.复制及自动故障转移：mongo数据库支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。复制的主要目的是提供冗余及自动故障转移。

  f.高效的传统存储方式：支持二进制数据及大型对象（如照片或图片）。

  g.自动分片以支持云级别的伸缩性：自动分片功能支持水平的数据库集群，可动态添加额外的机器。语法有点相似于面向对象的查询语言，几乎能够实现相似关系数据库单表查询的绝大部分功能，并且还支持对数据创建索引。它的特色是高性能、易部署、易使用，存储数据很是方便。

 

MongoDB的特色

一、非关系型

不适用复杂的多文档（多表）的级联查询，若是有这样的需求，咱们仍是用关系型数据库吧，MongoDB不适合。不合适事物型系统如银行系统

二、模型自由(模型高度可扩展性)

MongoDB一个数据库实例能够有多个Collection（集合）（对应关系型数据库的表Table），一个Collection里有多个Document（对应关系型数据库的行Row），所谓模型自由，用关系型数据库的话说，就是表Table的列Column的数量和类型不肯定。
对于存储在MongoDB数据库中的文件，咱们不须要知道它任何结构定义。若是须要的话，你彻底能够把不一样结构的文件存储在同一个数据库里。

三、副本集和分片集群（Replica Sets and Sharded Clusters）

MongoDB提供副本集和分片集群技术，从先天上支持数据库的高扩展性和高伸缩性，能够简单的是使用基于X86的小服务器集群，提供强大的处理能力，并且很容易扩展，目前3.0版本已经支持高达50个副本集。分片集群会让不停增加的数据始终如一的提供初始的访问性能，而不会随着数据的增加，系统的访问速度愈来愈慢。

四、支持彻底索引，包含内部对象

五、文件存储格式为BSON（一种json扩展）

BSON（Binary Serialized document Format）存储形式是指：存储在集合中的文档，被存储为键-值对的行式。键用于标识一个文档，为字符串类型，而值则能够是各类复杂文件类型。高效的二进制数据存储，包括大型对象（如视频等）

六、丰富的查询语言、函数
提供大部分关系型sql的查询功能，如 where limit group by  max min 等

 

mongo使用场景

    mongodb的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集二者的优点于一身。mongo适用于如下场景：

  a.网站数据：mongo很是适合实时的插入，更新与查询，并具有网站实时数据存储所需的复制及高度伸缩性。

  b.缓存：因为性能很高，mongo也适合做为信息基础设施的缓存层。在系统重启以后，由mongo搭建的持久化缓存能够避免下层的数据源过载。

  c.大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此以前，不少程序员每每会选择传统的文件进行存储。

  d.高伸缩性的场景：mongo很是适合由数十或者数百台服务器组成的数据库。

  e.用于对象及JSON数据的存储：mongo的BSON数据格式很是适合文档格式化的存储及查询。

不适合的场景：

  a.高度事物性的系统：例如银行或会计系统。传统的关系型数据库目前仍是更适用于须要大量原子性复琐事务的应用程序。

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

  c.须要SQL的问题。

 

案例1

1. 用在应用服务器的日志记录，查找起来比文本灵活，导出也很方便。也是给应用练手，从外围系统开始使用MongoDB。
2. 用在一些第三方信息的获取或者抓取，由于MongoDB的schema-less，全部格式灵活，不用为了各类格式不同的信息专门设计统一的格式，极大的减小开发的工做。

案例2

mongodb以前有用过，主要用来存储一些监控数据，No schema 对开发人员来讲，真的很方便，增长字段不用改表结构，并且学习成本极低。

案例3

使用MongoDB作了O2O快递应用，·将送快递骑手、快递商家的信息（包含位置信息）存储在 MongoDB，而后经过 MongoDB 的地理位置查询，这样很方便的实现了查找附近的商家、骑手等功能，使得快递骑手能就近接单，目前在使用MongoDB 上没遇到啥大的问题，官网的文档比较详细，很给力。

 

选型建议（网搜资料）

常常跟一些同窗讨论 MongoDB 业务场景时，会听到相似『你这个场景 mysql 也能解决，不必必定用 MongoDB』的声音，的确，并无某个业务场景必需要使用 MongoDB才能解决，但使用 MongoDB 一般能让你以更低的成本解决问题（包括学习、开发、运维等成本），下面是 MongoDB 的主要特性，你们能够对照本身的业务需求看看，匹配的越多，用 MongoDB 就越合适。

MongoDB 特性	优点
事务支持	MongoDB 目前只支持单文档事务，须要复琐事务支持的场景暂时不适合
灵活的文档模型	JSON 格式存储最接近真实对象模型，对开发者友好，方便快速开发迭代
高可用复制集	知足数据高可靠、服务高可用的需求，运维简单，故障自动切换
可扩展分片集群	海量数据存储，服务能力水平扩展
高性能	mmapv一、wiredtiger、mongorocks（rocksdb）、in-memory 等多引擎支持知足各类场景需求
强大的索引支持	地理位置索引可用于构建 各类 O2O 应用、文本索引解决搜索的需求、TTL索引解决历史数据自动过时的需求
Gridfs	解决文件存储的需求
aggregation & mapreduce	解决数据分析场景需求，用户能够本身写查询语句或脚本，将请求都分发到 MongoDB 上完成

从目前阿里云 MongoDB 云数据库上的用户看，MongoDB 的应用已经渗透到各个领域，好比游戏、物流、电商、内容管理、社交、物联网、视频直播等，如下是几个实际的应用案例。

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

若是你还在为是否应该使用 MongoDB，不如来作几个选择题来辅助决策（注：如下内容改编自 MongoDB 公司 TJ 同窗的某次公开技术分享）。

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

若是上述有1个 Yes，能够考虑 MongoDB，2个及以上的 Yes，选择MongoDB毫不会后悔