目录导航
前言
前面的章节,关于分布式缓存技术,我们分析了《分布式缓存技术之Redis的使用以及原理》、从这一节开始,来说说MongoDB。
关于MongoDB,一共五小节内容,分别是:
MongoDB是一个基于分布式文件存储的数据库。由 C++语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。 MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。在这里我们有必要先简单介绍一下非关系型数据库(NoSQL)
什么是 NoSQL
NoSQL,指的是非关系型的数据库。NoSQL 有时也称作 Not Only SQL 的缩写,是对不同于传统的关系型数据库的数据库管理系统的统称。NoSQL 用于超大规模数据的存储。(例如谷歌或 Facebook 每天为他们的用户收集万亿比特的数据)。这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展。
NoSQL最大的特点:
- 默认支持分布式(内置分布式解决方案)
- 高性能,高可用性和可伸缩性
在NoSQL界,MongoDB是一个最像关系型数据库的非关系型数据库
关系型数据库 PK 非关系型数据库
关系型数据库 | NoSQL 数据库 |
---|---|
高度组织化结构化数据 | 代表着不仅仅是 SQL |
结构化查询语言(SQL) | 没有声明性查询语言 |
数据和关系都存储在单独的表中 | 没有预定义的模式 |
数据操作语言,数据定义语言 | 键-值对存储,列存储,文档存储,图形数据库 |
严格的一致性 | 最终一致性,而非 ACID 属性 |
基础事务 | 非结构化和不可预知的数据 |
/ | CAP 定理 |
/ | 高性能,高可用性和可伸缩性 |
NoSQL 数据库分类
类型 | 典型代表 | 特点 |
---|---|---|
列存储 | Hbase 、Cassandra、Hypertable | 顾名思义,是按照列存储数据的。最大的特点是方便存储结构化和半结构化的数据,方便做数据压缩,对针对某一列或者某几列的查询有非常大的 IO 优势 |
文档存储 | MongoDB、CounchDB | 文档存储一般用类似 json 的格式存储,存储的内容是文档型的。这样也就有机会对某些字段建立索引,实现关系数据库的某些功能。 |
Key-value 存储 | Tokyo Cabinet/Tyrant、Berkelery DB、Memcache、Redis | 可以通过 key 快速查询到其value 。一般来说,存储不管value 的格式,照单全收。(Redis包含了其他功能) |
图存储 | Neo4J、FlockDB | 图形关系的最佳存储。使用传统关系数据库来解决的话性能低下,而且设计使用不方便。 |
对象存储 | Db4o、Versant | 通过类似面向对象语言的语法操作数据库,通过对象的方式存储数据。 |
XML 数据库 | Berkeley DB XML、BaseX | 高效的存储 XML 数据,并存储 XML的 内 部 查 询 语 法 , 比 如XQuery,Xpath。 |
MongoDB的数据结构与关系型数据库数据结构对比
项目 | Value | Value |
---|---|---|
Database | Database | 数据库 |
Table | Collection | 数据库表/集合 |
Row | Document | 数据记录行/文档 |
Column | Field | 数据列/数据字段 |
Index | Index | 索引 |
Table joins | \ | 表关联/MongoDB 不支持 |
Primary Key | Object ID | 主键/MongoDB 自动将_id 设置为主键 |
MongoDB中的数据类型
数据类型 | 说明 | 解释 | 举例 |
---|---|---|---|
Null | 空值 | 表示空值或者未定义的对象 | {“x”:null} |
Boolean | 布尔值 | 真或者假: true 或者false | {“x”:true} |
Integer | 整数 | 整型数值。用于存储数值。根据你所采用的服务器,可分为 32 位或 64位 | \ |
Double | 浮点数 | 双精度浮点值 | {“x”:3.14,”y”:3} |
String | 字符串 | UTF-8 字符串 | \ |
Symbol | 符号 | 基本上等同于字符串类型,但不同的是,它一般用于采用特殊符号类型的语言。 | \ |
ObjectID | 对象 ID | 用于创建文档的 ID | {“id”: ObjectId()} |
Date | 日期 | 用 UNIX 时间格式来存储当前日期或时间 | {“date”:new Date()} |
Timestamp | 时间戳 | 从标准纪元开始的毫秒数 | \ |
Regular | 正则表达式 | 文档中可以包含正则表达式,遵循 JavaScript的语法 | {“foo”:/testdb/i} |
Code | 代码 | 可以包含 JavaScript代码 | {“x”:function() {}} |
Undefined | 未定义 | 已废弃 | \ |
Array | 数组 | 值的集合或者列表 | {“arr”: [“a”,”b”]} |
Binary Data | 二进制 | 用于存储二进制数据 | \ |
Object | 内嵌文档 | 文档可以作为文档中某个 key 的 value | {“x”:{“foo”:”bar”}} |
Min/Max key | \ | 将一个值与 BSON(二进Min/Max keys 最小/大值 制的 JSON)元素的最低值和最高值相对比 | \ |
图解MongoDB底层原理
MongoDB 的集群部署方案中有三类角色:实际数据存储结点、配置文件存储结点和路由接入结点。
连接的客户端直接与路由结点相连,从配置结点上查询数据,根据查询结果到实际的存储结点上查询和存储数据。MongoDB 的部署方案有单机部署、复本集(主备)部署、分片部署、复本集与分片混合部署。混合的部署方式如图:
混合部署方式下向 MongoDB 写数据的流程如图:
混合部署方式下读 MongoDB 里的数据流程如图:
对于复本集,又有主和从两种角色,写数据和读数据也是不同,写数据的过程是只写到主结点中,由主结点以异步的方式同步到从结点中:
而读数据则只要从任一结点中读取,具体到哪个结点读取是可以指定的:
对于 MongoDB 的分片,假设我们以某一索引键(ID)为片键,ID 的区间[0,50],划分成 5 个 chunk,分别存储到 3 个片服务器中,如图所示:
假如数据量很大,需要增加片服务器时可以只要移动 chunk 来均分数据即可。
配置结点:
存储配置文件的服务器其实存储的是片键与 chunk 以及 chunk 与 server 的映射关系,用上面的数据表示的配置结点存储的数据模型如下表:
MongoDB的应用场景和不适用场景
适用场景
对于 MongoDB 实际应用来讲,是否使用 MongoDB 需要根据项目的特定特点进行一一甄别,这就要求我们对 MongoDB 适用和不适用的场景有一定的了解。
根据 MongoDB 官网的说明,MongoDB 的适用场景如下:
1)网站实时数据:MongoDB 非常适合实时的插入,更新与查询,并具备网站实时数据存储所需的复制及高度伸缩性。
例如:日志、Timeline、用户行为(代替方案:用日志)
2)数据缓存:由于性能很高,MongoDB 也适合作为信息基础设施的缓存层。在系统重启之后,由 MongoDB 搭建的持久化缓存层可以避免下层的数据源过载。
缓存的数据,它一定是临时的 (关系型数据有一份已经持久化)
3)大尺寸、低价值数据存储:使用传统的关系型数据库存储一些数据时可能会比较昂贵,在此之前,很多时候程序员往往会选择传统的文件进行存储。
搜索引擎的图片文件、视频文件(结构化),一份存磁盘、一份存Mongo
4)高伸缩性场景:MongoDB 非常适合由数十或数百台服务器组成的数据库。MongoDB 的路线图中已经包含对 MapReduce 引擎的内置支持。
机器可以任意的增减
5)对象或 JSON 数据存储:MongoDB 的 BSON 数据格式非常适合文档化格式的存储及查询。
完全可以选择用Redis
不适用场景
了解了 MongoDB 适用场景之后,还需要了解哪些场景下不适合使用 MongoDB,具体如下:
1)高度事务性系统:例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
例如:金融系统的核心数据、高机密的用户数据(只能选择传统关系型数据库)
2)传统的商业智能应用:针对特定问题的 BI 数据库会对产生高度优化的查询方式。对于此类应用,数据仓库可能是更合适的选择。
结构化查询要求非常高,经常做关联查询统计
(如果都是单表查询,用Java程序来实现关联) Map,List (id_az_a)
3)需要复杂 SQL 查询的问题。
相信通过上面的说明,你已经大致了解了 MongoDB 的使用规则,需要说明一点的是,MongoDB 不仅仅是数据库,更多的使用是将 MongoDB 作为一个数据库中间件在实际应用中合理划分使用细节,这一点对于 MongoDB 应用来讲至关重要!
路由结点:
路由角色的结点在分片的情况下起到负载均衡的作用。
后记
更多架构知识,欢迎关注本套Java系列文章,地址导航:Java架构师成长之路