MongoDB3.0發佈--新特性

插件式存儲引擎API

MongoDB向MySQL看齊,開發了插件式存儲引擎API,爲第三方的存儲引擎廠商加入Mongodb提供了方便。已經支持和即將支持的一些存儲引擎:
- MMAP v1 默認存儲引擎
- WiredTiger
- RocksDB
- TokuFT
- FusionIO(裸設備)

WiredTiger存儲引擎

毫無疑問,WiredTiger存儲引擎的引進是此版本最大的亮點。MongoDB公司已然感受到Tokumx深深的惡意和廣大使用者對mongodb耗費巨大內存和磁盤的深惡痛絕,所以MongoDB拿(爲)出(了)了(不)最(跳)大(票)的(更)誠(久)意,直接收購了WiredTiger,做了一個土豪應該做的事情。下面看一下這個存儲引擎都給MongoDB的使用者帶來了哪些福音。

1. 文檔鎖
WiredTiger通過多版本控制(MVCC)實現了文檔鎖,再也不用忍受庫鎖帶來的併發性問題。這將大大提高諸如比價,打車等全update類型應用的可用性。這是一個現代數據庫應該做的,不用說謝謝。

2. 壓縮
當,監控報表上幾十臺機器磁盤報警的時候,當,刪了表不釋放空間的時候,當,挨個機器重新同步釋放碎片的時候,允許我哭一會。現在好了,wiredTiger壓縮一切,壓縮journal,壓縮表,壓縮索引,且都是單獨文件存儲,想刪就刪,刪了就釋放,渾身上下哪哪都不疼了。
WiredTiger支持snappy(默認)、zlib壓縮算法和None高端不壓縮算法。snappy根據測試可以減少80%的磁盤使用。雖然可能會提高一些cpu,但是相比壓縮帶來的好處,天空飄來五個字兒….

3. 內存可配置
通過wiredTiger.engineConfig.cacheSizeGB參數可以配置運行時MongoDB內存使用大小,默認爲物理內存的一半。老闆再也不說MongoDB是內存小惡魔了。
wiredtiger還有其他一些參數配置,具體詳見:http://docs.mongodb.org/v3.0/reference/program/mongod/#cli-wiredtiger-options

MMAP v1存儲引擎

MongoDB給之前內存映射的存儲也起了個名字,那就是“內存映射第一版”,MMAPv1依舊是MongoDB的默認存儲引擎。此版本最大的改進就是鎖力度變成集合鎖,也就是表鎖。但最大的問題是表空間還是按照庫名來的,所以刪除表依舊不會釋放空間。爲了解決空間重用問題和碎片問題,mongodb這次徹底的將Power of 2 Sized Allocations扶正,也就是之前說的usePowerOf2Size,將padding factor廢棄。對於增刪改頻繁的業務,使用Power of 2 Sized Allocations,以提升效率。對於純寫入的應用,使用no padding,以節省空間。
【另外扒的】【在MMAP存儲引擎中,文檔按照寫入順序排列存儲。如果文檔更新後長度變長且原有存儲位置後面沒有足夠的空間放下增長部分的數據,那麼文檔就要移動到文件中的其他位置。這種因更新導致的文檔位置移動會嚴重降低寫性能,因爲一旦文檔發生移動,集合中的所有索引都要同步修改文檔新的存儲位置。
MMAP存儲引擎爲了減少這種情況的發生提供了兩種文檔空間分配方式:基於paddingFactor(填充因子)的自適應分配方式和基於usePowerOf2Sizes的預分配方式,其中前者爲默認方式。第一種方式會基於每個集合中文檔更新歷史計算文檔更新的平均增長長度,然後在新文檔插入或舊文檔移動時填充一部分空間,如當前集合paddingFactor的值爲1.5,那麼一個大小爲200字節的文檔插入時就會自動在文檔後填充100個字節的空間。第二種方式則不考慮更新歷史,直接爲文檔分配2的N次方大小的存儲空間,如一個大小同樣爲200字節的文檔插入時直接分配256個字節的空間。
MongoDB 3.0版本中的MMAPv1拋棄了基於paddingFactor的自適應分配方式,因爲這種方式看起來很智能,但是因爲一個集合中的文檔的大小不一,所以經過填充後的空間大小也不一樣。如果集合上的更新操作很多,那麼因爲記錄移動後導致的空閒空間會因爲大小不一而難以重用。目前基於usePowerOf2Sizes的預分配方式成爲默認的文檔空間分配方式,這種分配方式因爲分配和回收的空間大小都是2的N次方(當大小超過2MB時則變爲2MB的倍數增長),因此更容易維護和利用。如果某個集合上只有insert或者in-place update,那麼用戶可以通過爲該集合設置noPadding標誌位,關閉空間預分配。】

查詢和索引

  • 修改explain函數,現在explain可以支持count,find,group,aggregate,update,remove等操作。顯示結果更全面更精細化。
  • 後臺索引建立過程中,不能進行刪庫刪表刪索引操作。
  • 使用 createIndexes命令可以同時建立多個索引,並且只掃描一遍數據,提升了建索引的效率。
  • 廢棄dropDups參數,以後不能通過這個刪除重複數據了。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章