quickdb 另辟捷徑高效解決NOSQL數據庫 數據持久性問題
目前的NOSQL主要分為兩種，一種是基于內存型的如redis、memcached，一種是基于磁盤型的如Tokyo Tyrant、Tokyo Cabinet、Berkeley DB。
redis、memcached這類內存型NOSQL。雖然讀寫效率很高，但是有一個大問題，就是數據庫持久性。memcached是一重啟進程數 據就沒 了。redis支持兩種持久化方式，一種是 Snapshotting（快照）也是默認方式，另一種是Append-only file（縮寫aof）的方式。但是這兩種效率都不高。 怎樣才能做到高效讀寫，又能保持數據持久性了?
quickdb 是 一款基于內存文件系統的 HashTable數據結構的Key-Value數據引擎. . 什么是內存文件系統了？就是操作系統把系統內存劃出一部分當作硬盤使用。你可以像操作磁盤那樣的操作內存。但效率遠遠比硬盤來的快多了。通俗叫做內存文件 系統，只要服務器不重起數據將一直都在。
通俗的來講 redis、memcached是自己申請內存管理數據。當進程重啟或者掛了就會丟失數據。quickdb是把實體數據儲存在內存文件系統里的。當 quickdb進程掛了， 實體數據依然還在。 一個進程可能因為各種原因比如修改了配置文件或者要調試數據。要經常重啟。但是一個服務器不可能三天兩天的重啟或者死機。 一般服務器都是半年，或者 好幾年都不重起的。 如果你的服務器經常斷電或者死機重啟那就不叫服務器了。叫家用電腦了。嘿嘿 為了起見,quickdb可以定期的從內存文件系統的數據同步到磁盤中去。這樣當服務器重啟，也不會丟失數據。 簡單的來講，進程可能會經常因為各種原 因要重啟或者掛了，但是服務器不可能經常重啟或者死機。這樣很大程度上保證了數據持久性，也保證了讀寫效率。做到魚和熊掌
quickDB Benchmark 性能測試
寫入3145739條數據 花費4.38秒 讀取 3145739條數據花費3.88秒
Q: 既然是基于內存文件系統的，那leveldb、tokyocabinet等磁盤類的NOSQL可以直接使用了，為啥還用quickdb了?
A: leveldb、tokyocabinet是專門為硬盤特性而優化的NOSQL。比如增加了合并多個寫為一次性寫,并有內部的內存緩存系統。 如果使用內存文件系統的話，就會造成多次內存浪費。 quickdb不用緩存，不用合并寫。做到簡單就是快。
Q: 如果服務器內存不夠大,是不是用不了quickdb
A: 內存不夠大,也可以用quickdb。 內存文件系統可以用tmpfs。tmpfs是當內存不足的時候，把數據交換到swap區。下面講解了linux下的三種不同的內存文件系統類型
quickdb 下載: http://code.google.com/p/loongsso/downloads/detail?name=quickdb-beta1.tar.bz2&can=2&q=#makechanges
目前quickdb是 測試版，只實現了基本的寫入，和讀取。年后回來就會出一個完善版1 |
tar -jxvf quickdb.tar.bz2 |
2 |
./install.sh |
3 |
./quickdb /dev/shm/db/quickdb(內存文件系統路徑) 3145739(讀寫的次數) |
Linux 下的三種內存文件系統
(1)ramdisk,使用前需要先創建文件系統,并且調整文件系統大小比較麻煩,需要修改內核引導參數并重新啟動操作系統,在繁雜多變的應用與 需要 7X24不間斷運行的系統來說,并不是一個可以接受的選擇.好處是自2.0版本起內核便支持(這也算好處?嗯,確實算,如果你手頭真有這樣的系統的話)
(2)ramfs,使用前不需要去創建文件系統了,直接通過mount的方式即可掛載上來用,需要的時候可以使用"mount -o remount,maxsize=..."這種方式來調整大小.
(3)tmpfs,同ramfs在表面上基本上一樣啦,不同于ramfs針對"物理內存",tmpfs是在虛擬內存下分配空間的,也就是說tmpfs實例中存儲的文件既可能存在于物理內存中,也可能存在于交換分區中,具體存在哪里,是由"虛擬內存子系統"來調度的.
純性能角度講,ramfs會在進程占用內存使用較多的情況下會優于tmpfs,在沒有交換分區或進程占用內存較小而不發生swap行為的情況下,兩者性能不會有差異
文章出處：cellphp