- 論壇徽章:
- 0
|
前一段時(shí)間研究了一下mongodb的官方手冊(cè)(mongodb2.6),對(duì)其中一些進(jìn)行了總結(jié),供大家參考
每個(gè)數(shù)據(jù)庫(kù)都有一個(gè)”主分片” [1] 用來(lái)存儲(chǔ)這個(gè)數(shù)據(jù)庫(kù)中所有未開(kāi)啟分片的集合的數(shù)據(jù).
--------------------------------------------------------------------------------------------------------------------
分片為應(yīng)對(duì)高吞吐量與大數(shù)據(jù)量提供了方法.
使用分片減少了每個(gè)分片需要處理的請(qǐng)求數(shù),因此,通過(guò) 水平擴(kuò)展 ,集群可以提高自己的存儲(chǔ)容量和吞吐量.
舉例來(lái)說(shuō),當(dāng)插入一條數(shù)據(jù)時(shí),應(yīng)用只需要訪問(wèn)存儲(chǔ)這條數(shù)據(jù)的分片.
使用分片減少了每個(gè)分片存儲(chǔ)的數(shù)據(jù).
舉例來(lái)說(shuō),如果一個(gè)數(shù)據(jù)庫(kù)有1TB數(shù)據(jù),并有4個(gè)分片,則每個(gè)分片只需要存儲(chǔ)256GB數(shù)據(jù),如果數(shù)據(jù)庫(kù)有40個(gè)分片,則每個(gè)分片只需要存儲(chǔ)25GB數(shù)據(jù).
在某些情況下,使用分片是 唯一 的解決辦法,在以下情況下使用 集群 :
你的數(shù)據(jù)接近或者超過(guò)一個(gè)MongoDB實(shí)例所能容納的上限.
系統(tǒng)中 working set 的大小接近系統(tǒng)的內(nèi)存 上限 .
單一的MongoDB實(shí)例不能滿足寫性能要求,并且所有其他方法都沒(méi)有明顯作用.
如果這些特性在你的系統(tǒng)中都沒(méi)有出現(xiàn),使用分片只會(huì)增加系統(tǒng)的復(fù)雜程度,而不會(huì)帶來(lái)什么好處.
-------------------------------------------------------------------------------------------------------------------
在測(cè)試與開(kāi)發(fā)環(huán)境下,每個(gè) 分片 可以是單獨(dú)的 mongod 而不用必須是復(fù)制集.在生產(chǎn)環(huán)境中 必須 部署3臺(tái)配置服務(wù)器.
-------------------------------------------------------------------------------------------------------------------
基于范圍的分片方式與基于哈希的分片方式性能對(duì)比
基于范圍的分片方式提供了更高效的范圍查詢,給定一個(gè)片鍵的范圍,分發(fā)路由可以很簡(jiǎn)單地確定哪個(gè)數(shù)據(jù)塊存儲(chǔ)了請(qǐng)求需要的數(shù)據(jù),并將請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的分片中.
不過(guò),基于范圍的分片會(huì)導(dǎo)致數(shù)據(jù)在不同分片上的不均衡,有時(shí)候,帶來(lái)的消極作用會(huì)大于查詢性能的積極作用.比如,如果片鍵所在的字段是線性增長(zhǎng)的,一定時(shí)間內(nèi)的所有請(qǐng)求都會(huì)落到某個(gè)固定的數(shù)據(jù)塊中,最終導(dǎo)致分布在同一個(gè)分片中.在這種情況下,一小部分分片承載了集群大部分的數(shù)據(jù),系統(tǒng)并不能很好地進(jìn)行擴(kuò)展.
與此相比,基于哈希的分片方式以范圍查詢性能的損失為代價(jià),保證了集群中數(shù)據(jù)的均衡.哈希值的隨機(jī)性使數(shù)據(jù)隨機(jī)分布在每個(gè)數(shù)據(jù)塊中,因此也隨機(jī)分布在不同分片中.但是也正由于隨機(jī)性,一個(gè)范圍查詢很難確定應(yīng)該請(qǐng)求哪些分片,通常為了返回需要的結(jié)果,需要請(qǐng)求所有分片.
------------------------------------------------------------------------------------------------------------------
配置服務(wù)器在 config 數(shù)據(jù)庫(kù) 中存儲(chǔ)了集群的元信息, mongos 緩存了這個(gè)數(shù)據(jù)庫(kù)用來(lái)做讀寫的路由分發(fā).
如果集群中一個(gè)或者兩個(gè)配置服務(wù)器不可用,集群的元信息將變?yōu)?可讀 ,你還可以從分片中讀寫信息,但是數(shù)據(jù)塊的遷移以及數(shù)據(jù)塊的分裂在所有配置服務(wù)器都恢復(fù)可用之前不能夠進(jìn)行.
如果所有的三個(gè)配置服務(wù)器都不可用,在重啟 mongos 之前集群依然可用. 但是一旦試圖重啟 mongos ,集群將不能提供任何服務(wù).
沒(méi)有集群的元信息,集群將不能正常工作,因此,要 時(shí)刻 保持配置服務(wù)器的可用和完整.因此,配置服務(wù)器的備份是很重要的.與分片中的數(shù)據(jù)相比,配置服務(wù)器存儲(chǔ)的信息要小很多.這意味著配置服務(wù)器有相對(duì)較小的請(qǐng)求負(fù)載,而且對(duì)于集群的正常運(yùn)行,并不需要所有配置服務(wù)器任意時(shí)刻都可用,所以,備份配置服務(wù)器是一件容易的事情.
如果集群使用的配置服務(wù)器變換了ip或者域名,你需要重啟 所有 的 mongod 和 mongos .可以在集群部署時(shí)使用CNAMEs避免重啟.
------------------------------------------------------------------------------------------------------------------
MongoDB中默認(rèn)的 chunk 大小是64M,你可以 調(diào)整數(shù)據(jù)塊的大小,但要注意到這有可能會(huì)集群造成性能影響.
數(shù)據(jù)塊大小較小時(shí)可以使得分片間的數(shù)據(jù)更均衡,但是是以頻繁的遷移為代價(jià)的,會(huì)對(duì) mongos 造成壓力.
數(shù)據(jù)塊大小較大時(shí)會(huì)使得均衡較少,這從網(wǎng)絡(luò)傳輸 與 mongos 的角度來(lái)說(shuō)更高效,但是,這種高效是通過(guò)數(shù)據(jù)不均衡的加重為代價(jià)的.
在很多情況下,以分片間數(shù)據(jù)略微的不均衡來(lái)防止頻繁的遷移或者無(wú)效的遷移,是合理的.
-------------------------------------------------------------------------------------------------------------------
為了使均衡對(duì)集群性能的影響減小到最低,在不同分片之間的數(shù)據(jù)塊數(shù)量差異達(dá)到閾值時(shí), balancer 不會(huì)開(kāi)始工作,閾值是指集群中 chunks 最多的分片與數(shù)據(jù)塊最少的分片之間數(shù)據(jù)塊數(shù)量的差,均衡器有以下閾值:
在 2.2 版更改: 以下的閾值在版本2.2首次出現(xiàn),在此之前,只有在集群中不同分片之間數(shù)據(jù)塊的數(shù)量差達(dá)到8個(gè)時(shí),均衡才會(huì)開(kāi)始.
數(shù)據(jù)塊的數(shù)量 遷移閾值
少于20個(gè) 2
20到79 4
80 and greater 8
-------------------------------------------------------------------------------------------------------------------
按照順序操作分片:
records 數(shù)據(jù)庫(kù)中的 people 集合使用 { "zipcode": 1, "name": 1 } 片鍵開(kāi)啟分片.
這個(gè)集合使用 zipcode 字段重新分配數(shù)據(jù).如果很多文檔都有相同的 zipcode 值, chunk 會(huì)按照 name 的值進(jìn)行 分裂.
people 數(shù)據(jù)庫(kù)中的 addresses 集合使用片鍵 { "state": 1, "_id": 1 }.
這個(gè)片鍵使用 state 字段重新分配數(shù)據(jù).如果很多文檔都有相同的 state 值, chunk 會(huì)按照 _id 的值進(jìn)行 分裂.
assets 數(shù)據(jù)庫(kù)中的 chairs 集合使用 { "type": 1, "_id": 1 } 做片鍵.
這個(gè)片鍵使用 type 字段重新分配數(shù)據(jù).如果很多文檔都有相同的 type 值, chunk 會(huì)按照 _id 的值進(jìn)行 分裂.
events 數(shù)據(jù)庫(kù)中的 alerts 集合使用 { "_id": "hashed" } 做片鍵.
-------------------------------------------------------------------------------------------------------------------
在第一個(gè) mongos 連接到一組 配置服務(wù)器 時(shí), 會(huì)以默認(rèn)的64M大小的數(shù)據(jù)塊初始化集群,在大多數(shù)情況下,默認(rèn)的大小工作得很好.然而,如果你發(fā)現(xiàn)在默認(rèn)的數(shù)據(jù)塊大小下,自動(dòng)遷移鎖花費(fèi)的I/O超過(guò)了系統(tǒng)可承受的極限,可以將數(shù)據(jù)塊大小調(diào)小.對(duì)于自動(dòng)分裂和遷移,較小的數(shù)據(jù)塊可以使得遷移速度較快且較頻繁.合法的數(shù)據(jù)塊大小在1M到1024M之間,包含1M和1024M
配置 chunkSize 和選項(xiàng) --chunkSize 作為啟動(dòng)參數(shù)啟動(dòng) mongos ,在初始化集群之后 不要 影響數(shù)據(jù)塊大小.
為避免引起混亂,只使用 save() 修改數(shù)據(jù)塊大小,而不使用在啟動(dòng) mongos 時(shí)傳遞參數(shù)修改.
-------------------------------------------------------------------------------------------------------------------
在GridFS存儲(chǔ)中,對(duì) chunks 集合進(jìn)行分片時(shí), 只有 兩個(gè)片鍵可以選擇,``{ files_id : 1 , n : 1 }`` 與 { files_id : 1 } .
-------------------------------------------------------------------------------------------------------------------
|
|