將MongoDB作為Redis式的內(nèi)存數(shù)據(jù)庫的使用方法
基本思想
將MongoDB用作內(nèi)存數(shù)據(jù)庫（in-memory database），也即，根本就不讓MongoDB把數(shù)據(jù)保存到磁盤中的這種用法，引起了越來越多的人的興趣。這種用法對于以下應(yīng)用場合來講，超實用：
- 置于慢速RDBMS系統(tǒng)之前的寫操作密集型高速緩存
- 嵌入式系統(tǒng)
- 無需持久化數(shù)據(jù)的PCI兼容系統(tǒng)
- 需要輕量級數(shù)據(jù)庫而且?guī)熘袛?shù)據(jù)可以很容易清除掉的單元測試（unit testing）
如果這一切可以實現(xiàn)就真是太優(yōu)雅了：我們就能夠巧妙地在不涉及磁盤操作的情況下利用MongoDB的查詢/檢索功能。可能你也知道，在99％的情況下，磁盤IO（特別是隨機(jī)IO）是系統(tǒng)的瓶頸，而且，如果你要寫入數(shù)據(jù)的話，磁盤操作是無法避免的。
MongoDB有一個非?？岬脑O(shè)計決策，就是她可以使用內(nèi)存影射文件（memory-mapped file）來處理對磁盤文件中數(shù)據(jù)的讀寫請求。這也就是說，MongoDB并不對RAM和磁盤這兩者進(jìn)行區(qū)別對待，只是將文件看作一個巨大的數(shù)組，然后按照字節(jié)為單位訪問其中的數(shù)據(jù)，剩下的都交由操作系統(tǒng)（OS）去處理！就是這個設(shè)計決策，才使得MongoDB可以無需任何修改就能夠運(yùn)行于RAM之中。
實現(xiàn)方法
這一切都是通過使用一種叫做tmpfs的特殊類型文件系統(tǒng)實現(xiàn)的。在Linux中它看上去同常規(guī)的文件系統(tǒng)（FS）一樣，只是它完全位于RAM中（除非其大小超過了RAM的大小，此時它還可以進(jìn)行swap，這個非常有用?。?。我的服務(wù)器中有32GB的RAM，下面讓我們創(chuàng)建一個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
接下來要用適當(dāng)?shù)脑O(shè)置啟動MongoDB。為了減小浪費(fèi)的RAM數(shù)量，應(yīng)該把smallfiles和noprealloc設(shè)置為true。既然現(xiàn)在是基于RAM的，這么做完全不會降低性能。此時再使用journal就毫無意義了，所以應(yīng)該把nojournal設(shè)置為true。
nojournal = true
smallFiles = true
noprealloc = true
MongoDB啟動之后，你會發(fā)現(xiàn)她運(yùn)行得非常好，文件系統(tǒng)中的文件也正如期待的那樣出現(xiàn)了：
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
現(xiàn)在讓我們添加一些數(shù)據(jù)，證實一下其運(yùn)行完全正常。我們先創(chuàng)建一個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
}
可以看出，其中的document平均大小為1136字節(jié)，數(shù)據(jù)總共占用了5GB的空間。_id之上的索引大小為130MB?，F(xiàn)在我們需要驗證一件 非常重要的事情：RAM中的數(shù)據(jù)有沒有重復(fù)，是不是在MongoDB和文件系統(tǒng)中各保存了一份？還記得MongoDB并不會在她自己的進(jìn)程內(nèi)緩存任何數(shù)據(jù)，她的數(shù)據(jù)只會緩存到文件系統(tǒng)的緩存之中。那我們來清除一下文件系統(tǒng)的緩存，然后看看RAM中還有有什么數(shù)據(jù)：
# 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用于了文件系統(tǒng)的緩存（緩沖區(qū)，buffer)。為什么即使在清除所有緩存之后，系統(tǒng)中仍然還有5.8GB的文件系統(tǒng)緩存？？其原因是，Linux非常聰明，她不會在tmpfs和緩存中保存重復(fù)的數(shù)據(jù)。太棒了！這就意味著，你在RAM只有一份數(shù)據(jù)。下面我們訪問一下所有的document，并驗證一下，RAM的使用情況不會發(fā)生變化：
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
果不其然！ :)
復(fù)制（replication）呢？
既然服務(wù)器在重啟時RAM中的數(shù)據(jù)都會丟失，所以你可能會想使用復(fù)制。采用標(biāo)準(zhǔn)的副本集（replica set）就能夠獲得自動故障轉(zhuǎn)移（failover），還能夠提高數(shù)據(jù)讀取能力（read capacity）。如果有服務(wù)器重啟了，它就可以從同一個副本集中另外一個服務(wù)器中讀取數(shù)據(jù)從而重建自己的數(shù)據(jù)（重新同步，resync）。即使在大量數(shù)據(jù)和索引的情況下，這個過程也會足夠快，因為索引操作都是在RAM中進(jìn)行的 :)
有一點(diǎn)很重要，就是寫操作會寫入一個特殊的叫做oplog的collection，它位于local數(shù)據(jù)庫之中。缺省情況下，它的大小是總數(shù)據(jù)量的5%。在我這種情況下，oplog會占有16GB的5%，也就是800MB的空間。在拿不準(zhǔn)的情況下，比較安全的做法是，可以使用oplogSize這個選項為oplog選擇一個固定的大小。如果備選服務(wù)器宕機(jī)時間超過了oplog的容量，它就必須要進(jìn)行重新同步了。要把它的大小設(shè)置為1GB，可以這樣：
分片（sharding）呢？
既然擁有了MongoDB所有的查詢功能，那么用它來實現(xiàn)一個大型的服務(wù)要怎么弄？你可以隨心所欲地使用分片來實現(xiàn)一個大型可擴(kuò)展的內(nèi)存數(shù)據(jù)庫。配置服務(wù)器（保存著數(shù)據(jù)塊分配情況）還還是用過采用基于磁盤的方案，因為這些服務(wù)器的活動數(shù)量不大，老從頭重建集群可不好玩。
注意事項
RAM屬稀缺資源，而且在這種情況下你一定想讓整個數(shù)據(jù)集都能放到RAM中。盡管tmpfs具有借助于磁盤交換（swapping）的能力，但其性能下降將非常顯著。為了充分利用RAM，你應(yīng)該考慮：
- 使用usePowerOf2Sizes選項對存儲bucket進(jìn)行規(guī)范化
- 定期運(yùn)行compact命令或者對節(jié)點(diǎn)進(jìn)行重新同步（resync）
- schema的設(shè)計要相當(dāng)規(guī)范化（以避免出現(xiàn)大量比較大的document）
結(jié)論
寶貝，你現(xiàn)在就能夠?qū)ongoDB用作內(nèi)存數(shù)據(jù)庫了，而且還能使用她的所有功能！性能嘛，應(yīng)該會相當(dāng)驚人：我在單線程/核的情況下進(jìn)行測試，可以達(dá)到每秒20K個寫入的速度，而且增加多少個核就會再增加多少倍的寫入速度。
相關(guān)文章
本文主要介紹了Redis批量刪除Key的三種方式小結(jié)，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-04-04
這篇文章主要為大家介紹了Redisson分布式鎖加解鎖的詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2023-03-03
這篇文章主要為大家介紹了Redis緩存的主要異常及解決方案實例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2023-01-01
因為 Redis 官方只提供了命令行版的 Redis 客戶端 redis-cli，以至于我們在使用的時候會比較麻煩，而且命令行版的客戶端看起來也不夠直觀，下面是我這些年使用過的一些 Redis 可視化客戶端，分享給大家2021-06-06
本文主要介紹了redis實現(xiàn)session共享的方法，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-04-04
Redis高可用集群是一個由多個主從節(jié)點(diǎn)群組成的分布式服務(wù)器群，它具有復(fù)制、高可用和分片特性。Redis集群不需要sentinel哨兵也能完成節(jié)點(diǎn)移除和故障轉(zhuǎn)移的功能，只要將每個節(jié)點(diǎn)設(shè)置成集群模式，這種集群模式?jīng)]有中心節(jié)點(diǎn)，可水平擴(kuò)展，官方稱可以線性擴(kuò)展到上萬個節(jié)點(diǎn)2021-06-06
Redis基礎(chǔ)學(xué)習(xí)之管道機(jī)制詳析
這篇文章主要給大家介紹了關(guān)于Redis基礎(chǔ)學(xué)習(xí)之管道機(jī)制的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對大家學(xué)習(xí)或者使用Redis具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2018-11-11
Redis快速實現(xiàn)分布式session的方法詳解
Session是客戶端與服務(wù)器通訊會話跟蹤技術(shù)，服務(wù)器與客戶端保持整個通訊的會話基本信息。本文主要介紹了Redis快速實現(xiàn)分布式session的方法，感興趣的可以學(xué)習(xí)一下2022-01-01
Redis中5種數(shù)據(jù)結(jié)構(gòu)的使用場景介紹
這篇文章主要介紹了Redis中5種數(shù)據(jù)結(jié)構(gòu)的使用場景介紹,本文對Redis中的5種數(shù)據(jù)類型String、Hash、List、Set、Sorted Set做了講解,需要的朋友可以參考下2014-09-09
這篇文章主要介紹了redis集群主從節(jié)點(diǎn)自動切換方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-01-01