基本思想
将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：
# mount -t tmpfs -o size=16000M tmpfs /ramdata/
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvde1 5905712 4973924 871792 86% /
none 15344936 0 15344936 0% /dev/shm
tmpfs 16384000 0 16384000 0% /ramdata</div>
接下来要用适当的设置启动MongoDB。为了减小浪费的RAM数量，应该把smallfiles和noprealloc设置为true。既然现在是基于RAM的，这么做完全不会降低性能。此时再使用journal就毫无意义了，所以应该把nojournal设置为true。
nojournal = true
smallFiles = true
noprealloc = true</div>
MongoDB启动之后，你会发现她运行得非常好，文件系统中的文件也正如期待的那样出现了：
MongoDB shell version: 2.3.2
connecting to: test
> db.test.insert({a:1})
> db.test.find()
{ "_id" : ObjectId("51802115eafa5d80b5d2c145"), "a" : 1 }
# ls -l /ramdata/
total 65684
-rw-------. 1 root root 16777216 Apr 30 15:52 local.0
-rw-------. 1 root root 16777216 Apr 30 15:52 local.ns
-rwxr-xr-x. 1 root root 5 Apr 30 15:52 mongod.lock
-rw-------. 1 root root 16777216 Apr 30 15:52 test.0
-rw-------. 1 root root 16777216 Apr 30 15:52 test.ns
drwxr-xr-x. 2 root root 40 Apr 30 15:52 _tmp</div>
现在让我们添加一些数据，证实一下其运行完全正常。我们先创建一个1KB的document，然后将它添加到MongoDB中4百万次：
> aaa = "aaaaaaaaaa"
aaaaaaaaaa
> for (var i = 0; i < 100; ++i) { str += aaa; }
> for (var i = 0; i < 4000000; ++i) { db.foo.insert({a: Math.random(), s: str});}
> db.foo.stats()
{
"ns" : "test.foo",
"count" : 4000000,
"size" : 4544000160,
"avgObjSize" : 1136.00004,
"storageSize" : 5030768544,
"numExtents" : 26,
"nindexes" : 1,
"lastExtentSize" : 536600560,
"paddingFactor" : 1,
"systemFlags" : 1,
"userFlags" : 0,
"totalIndexSize" : 129794000,
"indexSizes" : {
"_id_" : 129794000
},
"ok" : 1
}</div>
可以看出，其中的document平均大小为1136字节，数据总共占用了5GB的空间。_id之上的索引大小为130MB。现在我们需要验证一件 非常重要的事情：RAM中的数据有没有重复，是不是在MongoDB和文件系统中各保存了一份？还记得MongoDB并不会在她自己的进程内缓存任何数据，她的数据只会缓存到文件系统的缓存之中。那我们来清除一下文件系统的缓存，然后看看RAM中还有有什么数据：
# free
total used free shared buffers cached
Mem: 30689876 6292780 24397096 0 1044 5817368
-/+ buffers/cache: 474368 30215508
Swap: 0 0 0</div>
可以看到，在已使用的6.3GB的RAM中，有5.8GB用于了文件系统的缓存（缓冲区，buffer)。为什么即使在清除所有缓存之后，系统中仍然还有5.8GB的文件系统缓存？？其原因是，Linux非常聪明，她不会在tmpfs和缓存中保存重复的数据。太棒了！这就意味着，你在RAM只有一份数据。下面我们访问一下所有的document，并验证一下，RAM的使用情况不会发生变化：
4000000
# free
total used free shared buffers cached