将MongoDB作为Redis式的内存数据库的使用方法 - 主机乐

> 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
}

可以看出，其中的document平均大小为1136字节，数据总共占用了5GB的空间。_id之上的索引大小为130MB。现在我们需要验证一件非常重要的事情：RAM中的数据有没有重复，是不是在MongoDB和文件系统中各保存了一份？还记得MongoDB并不会在她自己的进程内缓存任何数据，她的数据只会缓存到文件系统的缓存之中。那我们来清除一下文件系统的缓存，然后看看RAM中还有有什么数据：

# echo 3 > /proc/sys/vm/drop_caches
# free
             total       used       free     shared    buffers     cached
Mem:      30689876    6292780   24397096          0       1044    5817368
-/+ buffers/cache:     474368   30215508
Swap:            0          0          0

可以看到，在已使用的6.3GB的RAM中，有5.8GB用于了文件系统的缓存（缓冲区，buffer)。为什么即使在清除所有缓存之后，系统中仍然还有5.8GB的文件系统缓存？？其原因是，Linux非常聪明，她不会在tmpfs和缓存中保存重复的数据。太棒了！这就意味着，你在RAM只有一份数据。下面我们访问一下所有的document，并验证一下，RAM的使用情况不会发生变化：

> db.foo.find().itcount()
4000000

# free
             total       used       free     shared    buffers     cached
Mem:      30689876    6327988   24361888          0       1324    5818012
-/+ buffers/cache:     508652   30181224
Swap:            0          0          0
# ls -l /ramdata/
total 5808780
-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 16:00 test.0
-rw——-. 1 root root 33554432 Apr 30 16:00 test.1
-rw——-. 1 root root 536608768 Apr 30 16:02 test.10
-rw——-. 1 root root 536608768 Apr 30 16:03 test.11
-rw——-. 1 root root 536608768 Apr 30 16:03 test.12
-rw——-. 1 root root 536608768 Apr 30 16:04 test.13
-rw——-. 1 root root 536608768 Apr 30 16:04 test.14
-rw——-. 1 root root 67108864 Apr 30 16:00 test.2
-rw——-. 1 root root 134217728 Apr 30 16:00 test.3
-rw——-. 1 root root 268435456 Apr 30 16:00 test.4
-rw——-. 1 root root 536608768 Apr 30 16:01 test.5
-rw——-. 1 root root 536608768 Apr 30 16:01 test.6
-rw——-. 1 root root 536608768 Apr 30 16:04 test.7
-rw——-. 1 root root 536608768 Apr 30 16:03 test.8
-rw——-. 1 root root 536608768 Apr 30 16:02 test.9
-rw——-. 1 root root 16777216 Apr 30 15:52 test.ns
drwxr-xr-x. 2 root root        40 Apr 30 16:04 _tmp
# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvde1             5905712   4973960    871756 86% /
none                  15344936         0 15344936   0% /dev/shm
tmpfs                 16384000   5808780 10575220 36% /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，你应该考虑：