前言
本文主要介绍了关于MongoDB存储数据的相关内容，分享出来供大家参考学习，下面来一起看看详细的介绍：
想要深入了解MongoDB如何存储数据之前，有一个概念必须清楚，那就是Memeory-Mapped Files。
Memeory-Mapped Files
下图展示了数据库是如何跟底层系统打交道的。
内存映射文件是OS通过mmap在内存中创建一个数据文件，这样就把文件映射到一个虚拟内存的区域。 虚拟内存对于进程来说，是一个物理内存的抽象，寻址空间大小为2^64 操作系统通过mmap来把进程所需的所有数据映射到这个地址空间(红线)，然后再把当前需要处理的数据映射到物理内存(灰线) 当进程访问某个数据时，如果数据不在虚拟内存里，触发page fault，然后OS从硬盘里把数据加载进虚拟内存和物理内存 如果物理内存满了，触发swap-out操作，这时有些数据就需要写回磁盘，如果是纯粹的内存数据，写回swap分区，如果不是就写回磁盘。
MongoDB的存储模型
有了内存映射文件，要访问的数据就好像都在内存里面，简单化了MongoDB访问和修改数据的逻辑 MongoDB读写都只是和虚拟内存打交道，剩下都交给OS打理 虚拟内存大小=所有文件大小+其他一些开销(连接，堆栈) 如果journal开启，虚拟内存大小差不多翻番 使用MMF的好处1：不用自己管理内存和磁盘调度2：LRU策略3：重启过程中，Cache依然在。 使用MMF的坏处1：RAM使用会受磁盘碎片的影响，高预读也会影响2：无法自己优化调度算法，只能使用LRU
磁盘上的文件是有extent构成，分配集合空间的时候也是以extent为单位进行分配的 一个集合有一个或者多个etent ns文件里面命名空间记录指向那个集合的第一个extent
数据文件与空间分配
当创建数据库时(其实MongoDB没有显式创建数据库的方法，在向数据库中的集合写入数据时会自动创建该数据库)，MongoDB会在磁盘上分配一组数据文件，所有集合，索引和数据库的其他元数据都保存在这些文件里。数据文件被放在启动时指定的dbpath里，默认放入/data/db下面。典型的一个文件组织结构如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
$ cat /data/db $ ls -al -rw------- 1 root root 16777216 09-18 00:54 local.ns -rw------- 1 root root 67108864 09-18 00:54 local.0 -rw------- 1 root root 2146435072 09-18 00:55 local.1 -rw------- 1 root root 2146435072 09-18 00:56 local.2 -rw------- 1 root root 2146435072 09-18 00:57 local.3 -rw------- 1 root root 2146435072 09-18 00:58 local.4 -rw------- 1 root root 2146435072 09-18 00:59 local.5 -rw------- 1 root root 2146435072 09-18 01:01 local.6 -rw------- 1 root root 2146435072 09-18 01:02 local.7 -rw------- 1 root root 2146435072 09-18 01:03 local.8 -rw------- 1 root root 2146435072 09-18 01:04 local.9 -rw------- 1 root root 2146435072 09-18 01:05 local.10 -rw------- 1 root root 16777216 09-18 01:06 test.ns -rw------- 1 root root 67108864 09-18 01:06 test.0 -rw------- 1 root root 134217728 09-18 01:06 test.1 -rw------- 1 root root 268435456 09-18 01:06 test.2 -rw------- 1 root root 536870912 09-18 01:06 test.3 -rw------- 1 root root 1073741824 09-18 01:07 test.4 -rw------- 1 root root 2146435072 09-18 01:07 test.5 -rw------- 1 root root 2146435072 09-18 01:09 test.6 -rw------- 1 root root 2146435072 09-18 01:11 test.7 -rw------- 1 root root 2146435072 09-18 01:13 test.8 ... -rwxr-xr-x 1 root root 6 09-18 13:54 mongod.lock drwxr-xr-x 2 root root 4096 11-13 18:39 journal drwxr-xr-x 2 root root 4096 11-13 19:02 _tmp |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
{ "db" : "test" , "collections" : 37, "objects" : 317894523, #文档总个数 "avgObjSize" : 232.3416429039893, #单位是字节 "dataSize" : 73860135744, #集合中所有数据实际大小(包括padding factor为每个文档分配的额外空间以允许文档增长)。该值在文档 size 变小的时候，这个值不会减少，除非文档被删除，或者执行compact或者repairDatabase操作 "storageSize" : 97834319392, #分配给集合的空间大小(包括为集合增长预留的额外空间和未分配的已删除空间，即不会因为文档 size 变小或者删除而减小)，实际上从数据文件中分配给集合的空间是以块为单位，也称之为extents，即分配的extents的大小 "numExtents" : 385, "indexes" : 86, "indexSize" : 58687466992, "fileSize" : 182380920832, #所有数据文件大小之和，不包括命名空间文件(ns文件) "nsSizeMB" : 16, "dataFileVersion" : { "major" : 4, "minor" : 5 }, "ok" : 1 } |
使用 db.accesslog.stats() 确认某个集合的使用量
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
{ "ns" : "test.accesslog" , "count" : 145352932, "size" : 37060264352, ＃实际数据大小，不包括索引 "avgObjSize" : 254.967435758365, "storageSize" : 45794676448, #预分配的数据存储空间 "numExtents" : 42, "nindexes" : 4, "lastExtentSize" : 2146426864, "paddingFactor" : 1, #当文档因更新 size 增长时事先padding可以提速，减少碎片的产生 "systemFlags" : 1, "userFlags" : 0, "totalIndexSize" : 31897944512, "indexSizes" : { "_id_" : 6722168208, "action_1_time_1" : 8606482752, "gz_id_1_action_1_time_1" : 10753778336, "time_1" : 5815515216 }, "ok" : 1 } |
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流，谢谢大家对服务器之家的支持。
查看更多关于深入了解MongoDB是如何存储数据的的详细内容...