標籤:blog io os 使用 ar strong 檔案 資料 sp
與關係型資料庫相比,MongoDB的優點:
①弱一致性(最終一致),更能保證使用者的訪問速度:
舉例來說,在傳統的關係型資料庫中,一個COUNT類型的操作會鎖定資料集,這樣可以保證得到“當前”情況下的精確值。這在某些情況下,例 如通過ATM查看賬戶資訊的時候很重要,但對於Wordnik來說,資料是不斷更新和增長的,這種“精確”的保證幾乎沒有任何意義,反而會產生很大的延 遲。他們需要的是一個“大約”的數字以及更快的處理速度。
但某些情況下MongoDB會鎖住資料庫。如果此時正有數百個請求,則它們會堆積起來,造成許多問題。我們使用了下面的最佳化方式來避免鎖定:
每次更新前,我們會先查詢記錄。查詢操作會將對象放入記憶體,於是更新則會儘可能的迅速。在主/從部署方案中,從節點可以使用“-pretouch”參數運行,這也可以得到相同的效果。
使用多個mongod進程。我們根據訪問模式將資料庫拆分成多個進程。
②文檔結構的儲存方式,能夠更便捷的擷取資料。
對於一個層級式的資料結構來說,如果要將這樣的資料使用扁平式的,表狀的結構來儲存資料,這無論是在查詢還是擷取資料時都十分困難。
舉例1:
就拿一個“字典項”來說,雖然並不十分複雜,但還是會關係到“定義”、“詞性”、“發音”或是“引用”等內容。大部分工程師會將這種模型使用關係型資料庫 中的主鍵和外鍵表現出來,但把它看作一個“文檔”而不是“一系列有關係的表”豈不更好?使用 “dictionary.definition.partOfSpeech=‘noun‘”來查詢也比表之間一系列複雜(往往代價也很高)的串連查詢方便 且快速。
舉例2:在一個關係型資料庫中,一篇部落格(包含文章內容、評論、評論的投票)會被打散在多張資料表中。在MongoDB中,能用一個文檔來表示一篇部落格, 評論與投票作為文檔數組,放在本文主文件中。這樣資料更易於管理,消除了傳統關係型資料庫中影響效能和水平擴充性的“JOIN”操作。
CODE↓
> db.blogposts.save({ title : "My First Post", author: {name : "Jane", id :1},
comments : [{ by: "Abe", text: "First" },
{ by : "Ada", text : "Good post" }]
})
> db.blogposts.find( { "author.name" : "Jane" } )
> db.blogposts.findOne({ title : "My First Post", "author.name": "Jane",
comments : [{ by: "Abe", text: "First" },
{ by : "Ada", text : "Good post" } ]
})
> db.blogposts.find( { "comments.by" : "Ada" } )
> db.blogposts.ensureIndex( { "comments.by" : 1 } );
舉例③:
MongoDB是一個面向文檔的資料庫,目前由10gen開發並維護,它的功能豐富,齊全,完全可以替代MySQL。在使用MongoDB做產品原型的過程中,我們總結了MonogDB的一些亮點:
使用JSON風格文法,易於掌握和理解:MongoDB使用JSON的變種BSON作為內部儲存的格式和文法。針對MongoDB的操作都使用JSON風格文法,用戶端提交或接收的資料都使用JSON形式來展現。相對於SQL來說,更加直觀,容易理解和掌握。
Schema-less,支援嵌入子文檔:MongoDB是一個Schema-free的文檔資料庫。一個資料庫可以有多個Collection,每 個Collection是Documents的集合。Collection和Document和傳統資料庫的Table和Row並不對等。無需事先定義 Collection,隨時可以建立。
Collection中可以包含具有不同schema的文檔記錄。 這意味著,你上一條記錄中的文檔有3個屬性,而下一條記錄的文檔可以有10個屬 性,屬性的類型既可以是基本的資料類型(如數字、字串、日期等),也可以是數組或者散列,甚至還可以是一個子文檔(embed document)。這 樣,可以實現逆正常化(denormalizing)的資料模型,提高查詢的速度。
③內建GridFS,支援大容量的儲存。
GridFS是一個出色的Distributed File System,可以支援海量的資料存放區。
內建了GridFS了MongoDB,能夠滿足對大資料集的快速範圍查詢。
④內建Sharding。
提供基於Range的Auto Sharding機制:一個collection可按照記錄的範圍,分成若干個段,切分到不同的Shard上。
Shards可以和複製結合,配合Replica sets能夠實現Sharding+fail-over,不同的Shard之間可以負載平衡。查詢是對 用戶端是透明的。用戶端執行查詢,統計,MapReduce等操作,這些會被MongoDB自動路由到後端的資料節點。這讓我們關注於自己的業務,適當的 時候可以無痛的升級。MongoDB的Sharding設計能力最大可支援約20 petabytes,足以支撐一般應用。
這可以保證MongoDB運行在便宜的PC伺服器叢集上。PC叢集擴充起來非常方便並且成本很低,避免了“sharding”操作的複雜性和成本。
⑤第三方支援豐富。(這是與其他的NoSQL相比,MongoDB也具有的優勢)
現在網路上的很多NoSQL開來源資料庫完全屬於社區型的,沒有官方支援,給使用者帶來了很大的風險。
而開來源文件資料庫MongoDB背後有商業公司10gen為其提供供商業培訓和支援。
而且MongoDB社區非常活躍,很多開發架構都迅速提供了對MongDB的支援。不少知名大公司和網站也在生產環境中使用MongoDB,越來越多的創新型企業轉而使用MongoDB作為和Django,RoR來搭配的技術方案。
⑥效能優越:
在使用場合下,千萬層級的文檔對象,近10G的資料,對有索引的ID的查詢不會比mysql慢,而對停用字詞段的查詢,則是全面勝出。 mysql實際無法勝任大資料量下任意欄位的查詢,而mongodb的查詢效能實在讓我驚訝。寫入效能同樣很令人滿意,同樣寫入百萬層級的數 據,mongodb比我以前試用過的couchdb要快得多,基本10分鐘以下可以解決。補上一句,觀察過程中mongodb都遠算不上是CPU殺手。
與關係型資料庫相比,MongoDB的缺點:
①mongodb不支援事務操作。
所以事務要求嚴格的系統(如果銀行系統)肯定不能用它。(這點和優點①是對應的)
②mongodb佔用空間過大。
關於其原因,在官方的FAQ中,提到有如下幾個方面:
1、空間的預分配:為避免形成過多的硬碟片段,mongodb每次空間不足時都會申請產生一大塊的硬碟空間,而且申請的量從64M、128M、256M那 樣的指數遞增,直到2G為單個檔案的最大體積。隨著資料量的增加,你可以在其資料目錄裡看到這些整塊產生容量不斷遞增的檔案。
2、欄位名所佔用的空間:為了保持每個記錄內的結構資訊用於查詢,mongodb需要把每個欄位的key-value都以BSON的形式儲存,如果 value域相對於key域並不大,比如存放數值型的資料,則資料的overhead是最大的。一種減少空間佔用的方法是把欄位名盡量取短一些,這樣佔用 空間就小了,但這就要求在易讀性與空間佔用上作為權衡了。我曾建議作者把欄位名作個index,每個欄位名用一個位元組表示,這樣就不用擔心欄位名取多長 了。但作者的擔憂也不無道理,這種索引方式需要每次查詢得到結果後把索引值跟原值作一個替換,再發送到用戶端,這個替換也是挺耗費時間的。現在的實現算是 拿空間來換取時間吧。
3、刪除記錄不釋放空間:這很容易理解,為避免記錄刪除後的資料的大規模挪動,原記錄空間不刪除,只標記“已刪除”即可,以後還可以重複利用。
4、可以定期運行db.repairDatabase()來整理記錄,但這個過程會比較緩慢
③MongoDB沒有如MySQL那樣成熟的維護工具,這對於開發和IT運營都是個值得注意的地方。
mongodb與mysql相比的優缺點