MongoDB逻辑架构及存储引擎介绍

     学习一门新的语言,几乎所有的指引都是从helloWorld开始,学习数据库也一样,我们一般从查询语句学起,但之后我们要思考数据是如何存储的,查询怎样才能更高效,本文从MongoDB的逻辑架构、存储引擎和索引来进行分析,以便我们更深的了解MongoDB。

     下图是MongoDB的逻辑架构,来源于参照官方文档:

           

    


    存储引擎作为数据库的组件,决定了数据如何存储,

     MongoDB 3.0引入了插件式存储引擎API,为第三方的存储引擎厂商加入MongoDB提供了方便,目前除了早期的MMAP存储引擎外,还有WiredTiger和In-Memory Storage Engine等,前者更是在被MongoDB公司收购后更是直接引入到了MongoDB 3.0版本中,在3.2版本中的默认存储引擎是WiredTiger

下边分别对两种存储引擎进行介绍,

WriedTiger逻辑架构

 

WiredTiger.basecfg存储基本配置信息

WiredTiger.lock用于防止多个进程连接同一个Wiredtiger数据库

 table*.wt存储各个tale(数据库中的表)的数据

WiredTiger.wt是特殊的table,用于存储所有其他table的元数据信息

WiredTiger.turtle存储WiredTiger.wt的元数据信息

 journal存储Write ahead log

 按照Mongodb默认的配置,WiredTiger的写操作会先写入Cache,并持久化到WAL(Write ahead log),每60slog文件达到2GB时会做一次Checkpoint,将当前的数据持久化,产生一个新的快照。Wiredtiger连接初始化时,首先将数据恢复至最新的快照状态,然后根据WAL恢复数据,以保证存储可靠性。


WiredtigerCache采用Btree的方式组织,每个Btree节点为一个pageroot pagebtree的根节点,internalpagebtree的中间索引节点,leaf page是真正存储数据的叶子节点;btree的数据以page为单位按需从磁盘加载或写入磁盘。

Wiredtiger采用Copy onwrite的方式管理修改操作(insertupdatedelete),修改操作会先缓存在cache里,持久化时,修改操作不会在原来的leaf page上进行,而是写入新分配的page,每次checkpoint都会产生一个新的root page


WriedTiger特性

DocumentLevel Concurrency(文档级别的锁):多个写操作可以同时修改同一集合中的不同文档,修改同一文档时必须串行执行。

Snapshotsand Checkpoints(快照和检查点):mongoDB每60秒或日志文件【jonurnal】达到2G会创建一个检查点(产生一个snapshot[快照]),该Snapshot呈现的是内存中数据的一致性视图,当向Disk写入数据时,WiredTiger将Snapshot中的所有数据以一致性方式写入到数据文件(Disk Files)中

Journal(日志): 开启 journal 后,每次写入会记录一条操作日志(通过journal可以重新构造出写入的数据),一次写入,会对应数据、索引,oplog的修改,而这3个修改,会对应一条journal操作日志

Compression(压缩):WiredTiger压缩存储集合(Collection)和索引(Index),压缩减少Disk空间消耗,但是消耗额外的CPU执行数据压缩和解压缩的操作。

默认情况下,WiredTiger使用块压缩(Block Compression)算法来压缩Collections,使用前缀压缩(Prefix Compression)算法来压缩Indexes,Journal日志文件也是压缩存储的。对于大多数工作负载(Workload),默认的压缩设置能够均衡(Balance)数据存储的效率和处理数据的需求,即压缩和解压的处理速度是非常高的。

 MemoryUse(内存使用)

从MongoDB 3.2 版本开始,WiredTiger内部缓存的使用量,默认值是:1GB 或 60% of RAM - 1GB,取两值中的较大值;文件系统缓存的使用量不固定,MongoDB自动使用系统空闲的内存,这些内存不被WiredTiger缓存和其他进程使用,数据在文件系统缓存中是压缩存储的。

MMAPV1存储引擎逻辑架构:

个Database(DB)由一个.ns文件及若干个数据文件组成 

存储按照db来分目录, 每个db目录下有 .ns文件 {dbname}.0, {dbname}.1 等文件。

 

 

 

Namespace

每个DB包含多个namespace(对应mongodb的collection名),mydb.ns实际上是一个hash表(采用线性探测方式解决冲突),用于快速定位某个namespace的起始位置。

数据文件

每个数据文件被划分成多个extent,每个extent只包含一个namespace的数据,同一个namespace的所有extent之间以双向链表形式组织。

Extent

每个extent包含多个Record(对应mongodb的document),同一个extent下的所有record以双向链表形式组织。

Record

每个Record对应mongodb里的一个文档,每个Record包含固定长度16bytes的描述信息。

mmap引擎加载某个database时,首先初始化namespaceIndex,namespaceIndex相当于database的元数据入口。因此.ns文件是一个hashtable的内存镜像。

 

MMAPV1存储引擎特性:

Journal(日志) :为了确保所有更改都能持久化到数据文件中,mongoDB通过写文件文件的方式来保证,同时也可以通过日志文件来恢复数据。

RecordStorage Characteristics(记录存储特性):顺序存储、记录分配的空间不够,会重新分配,耗时并产生碎片,3.0以后版本采用2倍倍增方式,(如:32,64,128…2MB),如果记录超过2M,将分配最接近2MB的倍数(如果大小是3MB,那可能就是分配4MB)。

RecordAllocation Strategies(记录分配策略):mongoDB允许在给一条记录分配空间的时候留一点空闲空间,以便更新操作,这样来减少空间再分配。当然对一些固定的行也可以在建立文档的时候指定不需要些特性。

MemoryUse(内存使用):使用MMAPv,mongodb 自动使用所有机器的空闲的内存作为它的cache,系统资源监视器监视mongodb 使用的内存情况,这意外这着mongodb将尽可能多的使用空闲的内存,如果其他的进程突然需要服务器大量的内存,mongdb将会释放内存给其它进程。  

 MongoDB索引

MongoDB中的索引和其他数据库索引类似,也是使用B-Tree结构。MongoDB的索引是在collection级别上的,并且支持在任何列或者集合内的文档的子列中创建索引。

mongoDB支持_id索引 、单键索引、多键索引(当一个被索引的值是数组时,MongoDB会索引这个数组中的每一个元素。更多信息在 multikey模块有详细说明)、复合索引(多个字段,可以分别指定升降序)、时期过期索引(过一段时间索引失效)、全文索引、地理位置索引、稀疏索引(允许索引的字段为空值,建立时跳过)、部分索引(对满足条件的字段建立索引,比如给月工资1W以上的小伙伴建立索引)




### MongoDB 架构详解 #### 1. 数据库核心组件 MongoDB 是一种面向文档的 NoSQL 数据库,采用 BSON 格式存储数据[^1]。其架构设计围绕着几个关键组件展开: - **mongod**: 这是 MongoDB 的主要守护进程,负责管理数据文件并处理客户端请求。 - **内存映射文件存储引擎 (WiredTiger 或 MMAPv1)**: 使用这些高效的存储引擎来实现快速的数据访问和持久化。 #### 2. 复制机制 为了提高系统的可靠性和可用性,MongoDB 支持两种类型的复制机制: - **副本集(Replica Set)**: 至少由三个节点组成的一组 mongod 实例,通过选举协议选出一个主节点用于写入操作,其他成员则保持同步备份状态。这种方式不仅增强了容错能力还提供了自动故障转移功能[^2]。 - **分片集群(Sharded Cluster)**: 当单台服务器无法满足海量数据量的需求时,则可以通过配置多个 shard 来分布存储整个集合中的记录;每个 shard 又可以独立构建自己的副本集以保障局部区域内的高可用性。 #### 3. 查询路由服务 对于大型分布式环境下的应用来说,直接连接到具体的 shards 上会变得非常复杂且难以维护。因此,在实际部署中通常还会引入一层名为 `mongos` 的代理层作为统一入口点接收来自应用程序端发起的各种 CRUD 请求,并将其转发给相应的 backend nodes 完成具体业务逻辑处理后再返回结果给前端调用方[^4]。 ```bash # 启动 Mongos 路由器实例 mongos --configdb <replicaset_name>/<host>:<port> ``` #### 4. 配置服务器 在 sharding 场景下还需要额外设置一些专门用来保存元数据信息(比如 chunk 划分情况以及各部分分配位置等)的服务节点即 config servers 。它们同样是以 replica set 形态存在从而确保即使个别机器出现问题也不会影响全局视图一致性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值