mongodb 是把数据放在内存中吗_百度知道
mongodb 是把数据放在内存中吗
我有更好的答案
可能有cache在内存里, 实际还是放在存储里面.为了提高读取的效率,把常用的数据放到内存中,达到高效缓存的目的,要看数据库本身的参数设置,当然数据库缓冲池设置的愈大,读取的效率就越高.
采纳率：66%
mongodb的数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，这样提高查询效率，所谓内存数据映射，所以mongodb本身很吃内存，不过3.0版本以后会好很多。
本回答被提问者采纳
不是，MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。把 MongoDB 当成是纯内存数据库来使用（Redis 风格） - 技术翻译 - 开源中国社区
把 MongoDB 当成是纯内存数据库来使用（Redis 风格）
【已翻译100%】
英文原文：
推荐于 5年前 (共 5 段, 翻译完成于 05-04)
参与翻译&(1人)&:
将MongoDB用作内存数据库（in-memory database），也即，根本就不让MongoDB把数据保存到磁盘中的这种用法，引起了越来越多的人的兴趣。这种用法对于以下应用场合来讲，超实用：
置于慢速RDBMS系统之前的写操作密集型高速缓存
嵌入式系统
无需持久化数据的PCI兼容系统
需要轻量级数据库而且库中数据可以很容易清除掉的单元测试（unit testing）
如果这一切可以实现就真是太优雅了：我们就能够巧妙地在不涉及磁盘操作的情况下利用MongoDB的查询/检索功能。可能你也知道，在99％的情况下，磁盘IO（特别是随机IO）是系统的瓶颈，而且，如果你要写入数据的话，磁盘操作是无法避免的。
MongoDB有一个非常酷的设计决策，就是她可以使用内存影射文件（memory-mapped file）来处理对磁盘文件中数据的读写请求。这也就是说，MongoDB并不对RAM和磁盘这两者进行区别对待，只是将文件看作一个巨大的数组，然后按照字节为单位访问其中的数据，剩下的都交由操作系统（OS）去处理！就是这个设计决策，才使得MongoDB可以无需任何修改就能够运行于RAM之中。
&翻译得不错哦！
这一切都是通过使用一种叫做tmpfs的特殊类型文件系统实现的。在Linux中它看上去同常规的文件系统（FS）一样，只是它完全位于RAM中（除非其大小超过了RAM的大小，此时它还可以进行swap，这个非常有用！）。我的服务器中有32GB的RAM，下面让我们创建一个16GB的 tmpfs：
# mkdir /ramdata
# mount -t tmpfs -o size=16000M tmpfs /ramdata/
Filesystem
Used Available Use% Mounted on
/dev/xvde1
0% /dev/shm
0% /ramdata
接下来要用适当的设置启动MongoDB。为了减小浪费的RAM数量，应该把smallfiles和noprealloc设置为true。既然现在是基于RAM的，这么做完全不会降低性能。此时再使用journal就毫无意义了，所以应该把nojournal设置为true。
dbpath=/ramdata
nojournal = true
smallFiles = true
noprealloc = true
MongoDB启动之后，你会发现她运行得非常好，文件系统中的文件也正如期待的那样出现了：
MongoDB shell version: 2.3.2
connecting to: test
& db.test.insert({a:1})
& db.test.find()
{ "_id" : ObjectId("eafa5d80b5d2c145"), "a" : 1 }
# ls -l /ramdata/
total 65684
-rw-------. 1 root root
Apr 30 15:52 local.0
-rw-------. 1 root root
Apr 30 15:52 local.ns
-rwxr-xr-x. 1 root root
5 Apr 30 15:52 mongod.lock
-rw-------. 1 root root
Apr 30 15:52 test.0
-rw-------. 1 root root
Apr 30 15:52 test.ns
drwxr-xr-x. 2 root root
40 Apr 30 15:52 _tmp
现在让我们添加一些数据，证实一下其运行完全正常。我们先创建一个1KB的document，然后将它添加到MongoDB中4百万次：
& str = ""
& aaa = "aaaaaaaaaa"
aaaaaaaaaa
& for (var i = 0; i & 100; ++i) { str += }
& for (var i = 0; i & 4000000; ++i) { db.foo.insert({a: Math.random(), s: str});}
& db.foo.stats()
"ns" : "test.foo",
"count" : 4000000,
"size" : ,
"avgObjSize" : ,
"storageSize" : ,
"numExtents" : 26,
"nindexes" : 1,
"lastExtentSize" : ,
"paddingFactor" : 1,
"systemFlags" : 1,
"userFlags" : 0,
"totalIndexSize" : ,
"indexSizes" : {
&翻译得不错哦！
可以看出，其中的document平均大小为1136字节，数据总共占用了5GB的空间。_id之上的索引大小为130MB。现在我们需要验证一件
非常重要的事情：RAM中的数据有没有重复，是不是在MongoDB和文件系统中各保存了一份？还记得MongoDB并不会在她自己的进程内缓存任何数据，她的数据只会缓存到文件系统的缓存之中。那我们来清除一下文件系统的缓存，然后看看RAM中还有有什么数据：
# echo 3 & /proc/sys/vm/drop_caches
-/+ buffers/cache:
可以看到，在已使用的6.3GB的RAM中，有5.8GB用于了文件系统的缓存（缓冲区，buffer)。为什么即使在清除所有缓存之后，系统中仍然还有5.8GB的文件系统缓存？？其原因是，Linux非常聪明，她不会在tmpfs和缓存中保存重复的数据。太棒了！这就意味着，你在RAM只有一份数据。下面我们访问一下所有的document，并验证一下，RAM的使用情况不会发生变化：
& db.foo.find().itcount()
-/+ buffers/cache:
# ls -l /ramdata/
total 5808780
-rw-------. 1 root root
Apr 30 15:52 local.0
-rw-------. 1 root root
Apr 30 15:52 local.ns
-rwxr-xr-x. 1 root root
5 Apr 30 15:52 mongod.lock
-rw-------. 1 root root
Apr 30 16:00 test.0
-rw-------. 1 root root
Apr 30 16:00 test.1
-rw-------. 1 root root
Apr 30 16:02 test.10
-rw-------. 1 root root
Apr 30 16:03 test.11
-rw-------. 1 root root
Apr 30 16:03 test.12
-rw-------. 1 root root
Apr 30 16:04 test.13
-rw-------. 1 root root
Apr 30 16:04 test.14
-rw-------. 1 root root
Apr 30 16:00 test.2
-rw-------. 1 root root
Apr 30 16:00 test.3
-rw-------. 1 root root
Apr 30 16:00 test.4
-rw-------. 1 root root
Apr 30 16:01 test.5
-rw-------. 1 root root
Apr 30 16:01 test.6
-rw-------. 1 root root
Apr 30 16:04 test.7
-rw-------. 1 root root
Apr 30 16:03 test.8
-rw-------. 1 root root
Apr 30 16:02 test.9
-rw-------. 1 root root
Apr 30 15:52 test.ns
drwxr-xr-x. 2 root root
40 Apr 30 16:04 _tmp
Filesystem
Used Available Use% Mounted on
/dev/xvde1
0% /dev/shm
% /ramdata
果不其然！ :)
&翻译得不错哦！
复制（replication）呢？
既然服务器在重启时RAM中的数据都会丢失，所以你可能会想使用复制。采用标准的副本集（replica set）就能够获得自动故障转移（failover），还能够提高数据读取能力（read capacity）。如果有服务器重启了，它就可以从同一个副本集中另外一个服务器中读取数据从而重建自己的数据（重新同步，resync）。即使在大量数据和索引的情况下，这个过程也会足够快，因为索引操作都是在RAM中进行的 :)
有一点很重要，就是写操作会写入一个特殊的叫做oplog的collection，它位于local数据库之中。缺省情况下，它的大小是总数据量的5%。在我这种情况下，oplog会占有16GB的5%，也就是800MB的空间。在拿不准的情况下，比较安全的做法是，可以使用oplogSize这个选项为oplog选择一个固定的大小。如果备选服务器宕机时间超过了oplog的容量，它就必须要进行重新同步了。要把它的大小设置为1GB，可以这样：
oplogSize = 1000
&翻译得不错哦！
分片（sharding）呢？
既然拥有了MongoDB所有的查询功能，那么用它来实现一个大型的服务要怎么弄？你可以随心所欲地使用分片来实现一个大型可扩展的内存数据库。配置服务器（保存着数据块分配情况）还还是用过采用基于磁盘的方案，因为这些服务器的活动数量不大，老从头重建集群可不好玩。
RAM属稀缺资源，而且在这种情况下你一定想让整个数据集都能放到RAM中。尽管tmpfs具有借助于磁盘交换（swapping）的能力，但其性能下降将非常显著。为了充分利用RAM，你应该考虑：
使用usePowerOf2Sizes选项对存储bucket进行规范化
定期运行compact命令或者对节点进行重新同步（resync）
schema的设计要相当规范化（以避免出现大量比较大的document）
宝贝，你现在就能够将MongoDB用作内存数据库了，而且还能使用她的所有功能！性能嘛，应该会相当惊人：我在单线程/核的情况下进行测试，可以达到每秒20K个写入的速度，而且增加多少个核就会再增加多少倍的写入速度。
&翻译得不错哦！
我们的翻译工作遵照 ，如果我们的工作有侵犯到您的权益，请及时联系我们
我又重新看了一下原文，感觉这个翻译的确会有点问题，原文的意思貌似是每秒20k次写入，而不是我翻译的可能会让人领会为每秒20kB的写入速度
原理上可以这么说，但有些数据库在设计时并未考虑使用内存作为文件系统，它们在保存数据时除了保存用户数据之外还会保存大量的衍生数据，使得这样的数据库作为内存数据库使用时内存使用效率极其低下，所以拿它们来做内存数据库就相当不合适了。
可能在查询功能和索引方面MonogoDB会略胜一筹？
嗯，这种用法只能是在适当的场合下使用。不过我感觉在集群中使用应该算是相当可靠了
和键值对还是很大区别的。我们数据库做键值对应用，单核的检索是400万行/秒。redis其实是个效率很低的东西。
redis...记不清了，不好意思
和键值对还是很大区别的。我们数据库做键值对应用，单核的检索是400万行/秒。redis其实是个效率很低的东西。啊？？
和键值对还是很大区别的。我们数据库做键值对应用，单核的检索是400万行/秒。redis其实是个效率很低的东西。啊？？求对比/分析报告
表现一下而已，国货当自强深入了解MongoDB是如何存储数据的
转载 &更新时间：日 09:59:53 & 作者：foxracle
MongoDB是一个可扩展、高性能的分布式文档存储数据库，由C 语言编写，下面这篇文章主要给大家介绍了关于MongoDB是如何存储数据的相关资料，文中介绍的非常详细，对大家具有一定的参考学习价值，需要的朋友们下面来一起看看吧。
本文主要介绍了关于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下面。典型的一个文件组织结构如下：
$ cat /data/db
-rw------- 1 root root -18 00:54 local.ns
-rw------- 1 root root -18 00:54 local.0
-rw------- 1 root root
09-18 00:55 local.1
-rw------- 1 root root
09-18 00:56 local.2
-rw------- 1 root root
09-18 00:57 local.3
-rw------- 1 root root
09-18 00:58 local.4
-rw------- 1 root root
09-18 00:59 local.5
-rw------- 1 root root
09-18 01:01 local.6
-rw------- 1 root root
09-18 01:02 local.7
-rw------- 1 root root
09-18 01:03 local.8
-rw------- 1 root root
09-18 01:04 local.9
-rw------- 1 root root
09-18 01:05 local.10
-rw------- 1 root root -18 01:06 test.ns
-rw------- 1 root root -18 01:06 test.0
-rw------- 1 root root -18 01:06 test.1
-rw------- 1 root root -18 01:06 test.2
-rw------- 1 root root -18 01:06 test.3
-rw------- 1 root root
09-18 01:07 test.4
-rw------- 1 root root
09-18 01:07 test.5
-rw------- 1 root root
09-18 01:09 test.6
-rw------- 1 root root
09-18 01:11 test.7
-rw------- 1 root root
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
18:39 journal
drwxr-xr-x 2 root root
19:02 _tmp
mongod.lock中存储了服务器的进程ID，是一个进程锁定文件。数据文件是依据所属的数据库命名的。
test.ns是第一个生成的文件(ns扩展名就是namespace的意思)，数据库中的每个集合和索引都有自己的命名空间，每个命名空间的元数据都存放在这个文件里。默认情况下，.ns文件大小固定在16MB，大约可以存储24000个命名空间。也就是说数据库中的索引和集合总数不能超过24000，该值可以通过mongod的–nssize选项进行定制。
像test.0这样以0开始的整数结尾的文件就是集合和索引数据文件。刚开始的时候，即使只有一条数据，MongoDB也会预分配几个文件，这种预分配的做法，能让数据尽可能连续存储，减少磁盘碎片。在像数据库添加数据时，MongoDB会分配更多的数据文件。每个新数据文件的大小都是上一个已分配文件的两倍(64M-&128M-&256M)，直到预分配文件大小的上限2G。此处基于一个假设，如果总数据大小呈恒定速率增长，应该逐渐增加数据文件分配的空间。当然这个预分配策略也是可以通过–noprealloc关掉，但是不建议在production环境下使用。
默认的local数据库，该数据库不参与replication。当mongod是一个副本集的成员时，在local数据库中就有一个叫做oplog.rs的预分配的capped集合，预分配的大小为磁盘空间的5%。这个大小可以通过–oplogSize进行调整。oplog主要用于副本集Primary和Secondary成员见的replication，它的大小限制了两个副本集之间，在重新完全同步之前，允许多长时间不同步。
journal目录，journal功能2.4版本默认是开启的。
可以使用db.stats()来确认已使用空间和已分配空间。
"db" : "test",
"collections" : 37,
"objects" : , #文档总个数
"avgObjSize" : 232.3, #单位是字节
"dataSize" : , #集合中所有数据实际大小(包括padding factor为每个文档分配的额外空间以允许文档增长)。该值在文档size变小的时候，这个值不会减少，除非文档被删除，或者执行compact或者repairDatabase操作
"storageSize" : , #分配给集合的空间大小(包括为集合增长预留的额外空间和未分配的已删除空间，即不会因为文档size变小或者删除而减小)，实际上从数据文件中分配给集合的空间是以块为单位，也称之为extents，即分配的extents的大小
"numExtents" : 385,
"indexes" : 86,
"indexSize" : ,
"fileSize" : , #所有数据文件大小之和，不包括命名空间文件(ns文件)
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
使用db.accesslog.stats()确认某个集合的使用量
"ns" : "test.accesslog",
"count" : ,
"size" : , ＃实际数据大小，不包括索引
"avgObjSize" : 254.,
"storageSize" : , #预分配的数据存储空间
"numExtents" : 42,
"nindexes" : 4,
"lastExtentSize" : ,
"paddingFactor" : 1, #当文档因更新size增长时事先padding可以提速，减少碎片的产生
"systemFlags" : 1,
"userFlags" : 0,
"totalIndexSize" : ,
"indexSizes" : {
"_id_" : ,
"action_1_time_1" : ,
"gz_id_1_action_1_time_1" : ,
"time_1" :
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流，谢谢大家对脚本之家的支持。
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
这个Size是在内存里面最好吗？
why会有数据大小,索引大小,存储大小
但是 那个5.95G是神马 怎么会比上边加起来还大很多。。
内存是比5.95g还大
还是比Data Size (或者加上索引数据大小)大就可以了？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
1. 如果所有数据都能在内存里当然最好。
2. database = payload + index
3. MongoDB的journal默认开2～3G，可以用--small-files减小
4. 至少应该保证索引在内存里。
同步到新浪微博
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。}