青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

牽著老婆滿街逛

嚴以律己,寬以待人. 三思而后行.
GMail/GTalk: yanglinbo#google.com;
MSN/Email: tx7do#yahoo.com.cn;
QQ: 3 0 3 3 9 6 9 2 0 .

把 MongoDB 當成是純內存數據庫來使用(Redis 風格)

轉載自:http://www.oschina.net/translate/how-to-use-mongodb-as-a-pure-in-memory-db-redis-style

英文原文:How to use MongoDB as a pure in-memory DB (Redis style)


 

基本思想

將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/
# 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

接下來要用適當的設置啟動MongoDB。為了減小浪費的RAM數量,應該把smallfilesnoprealloc設置為true。既然現在是基于RAM的,這么做完全不會降低性能。此時再使用journal就毫無意義了,所以應該把nojournal設置為true。

dbpath=/ramdata
nojournal = true
smallFiles = true
noprealloc = true

MongoDB啟動之后,你會發現她運行得非常好,文件系統中的文件也正如期待的那樣出現了:

# mongo
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

現在讓我們添加一些數據,證實一下其運行完全正常。我們先創建一個1KB的document,然后將它添加到MongoDB中4百萬次:

> str = ""

> 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字節,數據總共占用了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,你應該考慮:

  • 使用usePowerOf2Sizes選項對存儲bucket進行規范化
  • 定期運行compact命令或者對節點進行重新同步(resync)
  • schema的設計要相當規范化(以避免出現大量比較大的document)

結論

寶貝,你現在就能夠將MongoDB用作內存數據庫了,而且還能使用她的所有功能!性能嘛,應該會相當驚人:我在單線程/核的情況下進行測試,可以達到每秒20K個寫入的速度,而且增加多少個核就會再增加多少倍的寫入速度。


posted on 2014-05-29 22:57 楊粼波 閱讀(500) 評論(0)  編輯 收藏 引用


只有注冊用戶登錄后才能發表評論。
網站導航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            香蕉久久国产| 美国十次了思思久久精品导航| 亚洲视屏一区| 亚洲自拍另类| 欧美亚洲综合另类| 欧美一级专区| 久久精品国产亚洲高清剧情介绍| 欧美在线视频观看| 久久亚洲综合色| 欧美成人中文| 欧美日韩大片| 国产精品国产三级欧美二区| 国产精品久久久久久久久久直播| 国产精品女主播在线观看| 国产欧美日韩另类一区| 国产综合精品| 亚洲高清视频一区| 一本久久综合亚洲鲁鲁五月天| 日韩一区二区久久| 亚洲综合色丁香婷婷六月图片| 欧美一区二区私人影院日本| 久久久蜜桃精品| 欧美成人午夜| 99精品99| 欧美在线观看日本一区| 免费欧美电影| 国产精品大全| 在线播放国产一区中文字幕剧情欧美| 亚洲黄色成人| 亚洲综合久久久久| 免费人成精品欧美精品| 亚洲裸体在线观看| 欧美一区二区三区的| 美女999久久久精品视频| 欧美日韩亚洲另类| 国产专区综合网| 99视频精品全国免费| 久久精品国产在热久久| 91久久久亚洲精品| 午夜精品福利电影| 欧美高清在线观看| 国产欧美视频一区二区| 亚洲精选视频在线| 久久精品主播| 亚洲精品一区在线观看| 久久久久成人精品免费播放动漫| 欧美日韩国产专区| 激情久久中文字幕| 亚洲欧美视频一区| 亚洲高清视频一区二区| 亚洲欧美三级在线| 欧美日韩福利| 激情五月婷婷综合| 亚洲欧美日韩中文视频| 亚洲风情亚aⅴ在线发布| 小黄鸭精品aⅴ导航网站入口| 欧美精品一区三区| 精品成人国产| 欧美在线观看你懂的| 亚洲美女精品久久| 卡一卡二国产精品| 国产亚洲精品aa| 亚洲自拍啪啪| 亚洲欧洲综合| 免费亚洲婷婷| 精品白丝av| 久久精品中文字幕一区| 国产精品99久久不卡二区| 欧美精品v日韩精品v韩国精品v| 国内精品久久久久久久果冻传媒| 亚洲欧美国产三级| 亚洲精品视频啊美女在线直播| 久久人人九九| 国语自产精品视频在线看抢先版结局| 午夜精品久久| 一区二区欧美日韩| 欧美日产一区二区三区在线观看| 亚洲级视频在线观看免费1级| 久久综合九色九九| 欧美在线1区| 国产小视频国产精品| 性欧美videos另类喷潮| 一区二区欧美在线观看| 欧美日韩在线视频一区二区| av成人福利| 91久久在线播放| 欧美大胆成人| 亚洲精品视频在线观看网站| 欧美成人精品1314www| 久久人人爽爽爽人久久久| 国产主播在线一区| 久久亚洲精品视频| 久久精品72免费观看| 国产视频在线一区二区 | 亚洲激情国产| 欧美国产丝袜视频| 亚洲精品影院在线观看| 亚洲日本欧美天堂| 欧美日韩成人精品| 亚洲一区二区少妇| 一区二区三区日韩在线观看| 国产精品久久久久影院色老大 | 99一区二区| 亚洲精品视频免费在线观看| 欧美精品日韩三级| 9l视频自拍蝌蚪9l视频成人| 亚洲精品国产精品乱码不99 | 99国产精品99久久久久久| 亚洲精品久久久久久久久| 欧美日韩第一区| 亚洲综合第一页| 午夜免费电影一区在线观看| 国产中文一区| 欧美电影免费| 欧美精品aa| 亚洲欧美在线x视频| 午夜精品久久久久久久久| 国内精品视频在线观看| 欧美高清在线一区| 欧美精品亚洲一区二区在线播放| 亚洲午夜精品福利| 午夜老司机精品| 在线免费观看一区二区三区| 亚洲国产精品福利| 欧美日韩国产91| 午夜精品久久久久久99热软件| 性视频1819p久久| 亚洲国产mv| 亚洲精品综合精品自拍| 国产欧美日韩综合精品二区| 欧美成人亚洲成人| 欧美日韩中文字幕| 久久精品中文字幕一区| 欧美国产欧美综合| 亚洲欧美国产毛片在线| 久久久亚洲国产天美传媒修理工| 日韩视频在线一区| 亚洲综合精品四区| 亚洲国产欧美在线| 一区二区三区精品| 激情久久中文字幕| 日韩午夜剧场| 在线看片第一页欧美| 亚洲免费观看高清完整版在线观看| 国产日本欧美一区二区三区在线 | 久久久久久亚洲精品中文字幕 | 欧美国产丝袜视频| 久久国产精品第一页| 欧美高清在线播放| 久久久久久久一区二区三区| 欧美精品二区| 久久久久久久久久久久久9999| 欧美日产一区二区三区在线观看| 久久精品国产99精品国产亚洲性色| 欧美激情视频在线播放| 久久精品99国产精品日本| 欧美国产日韩精品| 久久久久国产一区二区| 欧美日韩伦理在线| 欧美电影美腿模特1979在线看| 国产精品午夜在线| 亚洲乱码精品一二三四区日韩在线 | 日韩午夜中文字幕| 伊人夜夜躁av伊人久久| 亚洲一区国产视频| 亚洲美女免费精品视频在线观看| 欧美一区午夜精品| 亚洲一区欧美激情| 欧美福利一区二区三区| 毛片基地黄久久久久久天堂| 国产精品免费一区二区三区观看| 亚洲国产欧美在线人成| 激情综合久久| 先锋资源久久| 亚洲在线一区二区三区| 欧美高清在线精品一区| 欧美成人一区在线| 国产一区二区三区在线观看精品 | 亚洲欧洲在线看| 亚洲第一狼人社区| 欧美在线观看一二区| 午夜精品一区二区三区在线视| 欧美高清在线一区二区| 欧美成年网站| 伊人成综合网伊人222| 午夜精品久久久久久久99黑人| 亚洲欧美视频一区| 国产精品久久久久久久久久久久久| 亚洲激情在线| 亚洲人成高清| 免费日韩精品中文字幕视频在线| 久久亚洲二区| 国产专区综合网| 久久精品国产亚洲精品 | 午夜亚洲性色视频| 国产精品大片| 亚洲一区二区在| 先锋影音国产精品| 国产精品视频免费观看www| 亚洲午夜视频在线观看|