主頁(yè) > 知識(shí)庫(kù) > MongoDB磁盤IO問(wèn)題的3種解決方法

MongoDB磁盤IO問(wèn)題的3種解決方法

熱門標(biāo)簽:老虎洗衣店地圖標(biāo)注 怎么投訴地圖標(biāo)注 云南外呼系統(tǒng) 呼和浩特電銷外呼系統(tǒng)加盟 蘋果汽車租賃店地圖標(biāo)注 杭州人工電銷機(jī)器人價(jià)格 濟(jì)南電銷機(jī)器人加盟公司 廣州長(zhǎng)安公司怎樣申請(qǐng)400電話 電銷機(jī)器人是什么軟件

IO概念

在數(shù)據(jù)庫(kù)優(yōu)化和存儲(chǔ)規(guī)劃過(guò)程中,總會(huì)提到IO的一些重要概念,在這里就詳細(xì)記錄一下,對(duì)這個(gè)概念的熟悉程度也決定了對(duì)數(shù)據(jù)庫(kù)與存儲(chǔ)優(yōu)化的理解程度,以下這些概念并非權(quán)威文檔,權(quán)威程度肯定就不能說(shuō)了。

讀/寫IO,最為常見(jiàn)說(shuō)法,讀IO,就是發(fā)指令,從磁盤讀取某段扇區(qū)的內(nèi)容。指令一般是通知磁盤開(kāi)始扇區(qū)位置,然后給出需要從這個(gè)初始扇區(qū)往后讀取的連續(xù)扇區(qū)個(gè)數(shù),同時(shí)給出動(dòng)作是讀,還是寫。磁盤收到這條指令,就會(huì)按照指令的要求,讀或者寫數(shù)據(jù)??刂破靼l(fā)出的這種指令+數(shù)據(jù),就是一次IO,讀或者寫。

大/小塊IO,指控制器的指令中給出的連續(xù)讀取扇區(qū)數(shù)目的多少,如果數(shù)目很大,比如128,64等等,就應(yīng)該算是大塊IO,如果很小,比如1, 4,8等等,就應(yīng)該算是小塊IO,大塊和小塊之間,沒(méi)有明確的界限。

連續(xù)/隨機(jī)IO,連續(xù)和隨機(jī),是指本次IO給出的初始扇區(qū)地址,和上一次IO的結(jié)束扇區(qū)地址,是不是完全連續(xù)的,或者相隔不多的,如果是,則本次IO應(yīng)該算是一個(gè)連續(xù)IO,如果相差太大,則算一次隨機(jī)IO。連續(xù)IO,因?yàn)楸敬纬跏忌葏^(qū)和上次結(jié)束扇區(qū)相隔很近,則磁頭幾乎不用換道或換道時(shí)間極短;如果相差太大,則磁頭需要很長(zhǎng)的換道時(shí)間,如果隨機(jī)IO很多,導(dǎo)致磁頭不停換道,效率大大降底。

順序/并發(fā)IO,這個(gè)的意思是,磁盤控制器每一次對(duì)磁盤組發(fā)出的指令套(指完成一個(gè)事物所需要的指令或者數(shù)據(jù)),是一條還是多條。如果是一條,則控制器緩存中的IO隊(duì)列,只能一個(gè)一個(gè)的來(lái),此時(shí)是順序IO;如果控制器可以同時(shí)對(duì)磁盤組中的多塊磁盤,同時(shí)發(fā)出指令套,則每次就可以執(zhí)行多個(gè)IO,此時(shí)就是并發(fā)IO模式。并發(fā)IO模式提高了效率和速度。

IO并發(fā)幾率。單盤,IO并發(fā)幾率為0,因?yàn)橐粔K磁盤同時(shí)只可以進(jìn)行一次IO。對(duì)于raid0,2塊盤情況下,條帶深度比較大的時(shí)候(條帶太小不能并發(fā)IO,下面會(huì)講到),并發(fā)2個(gè)IO的幾率為1/2。其他情況請(qǐng)自行運(yùn)算。

IOPS。一個(gè)IO所用的時(shí)間=尋道時(shí)間+數(shù)據(jù)傳輸時(shí)間。 IOPS=IO并發(fā)系數(shù)/(尋道時(shí)間+數(shù)據(jù)傳輸時(shí)間),由于尋道時(shí)間相對(duì)傳輸時(shí)間,大幾個(gè)數(shù)量級(jí),所以影響IOPS的關(guān)鍵因素,就是降底尋道時(shí)間,而在連續(xù)IO的情況下,尋道時(shí)間很短,僅在換磁道時(shí)候需要尋道。在這個(gè)前提下,傳輸時(shí)間越少,IOPS就越高。

每秒IO吞吐量。顯然,每秒IO吞吐量=IOPS乘以平均IO SIZE。 Io size越大,IOPS越高,每秒IO吞吐量就越高。設(shè)磁頭每秒讀寫數(shù)據(jù)速度為V,V為定值。則IOPS=IO并發(fā)系數(shù)/(尋道時(shí)間+I(xiàn)O SIZE/V),代入,得每秒IO吞吐量=IO并發(fā)系數(shù)乘IO SIZE乘V/(V乘尋道時(shí)間+I(xiàn)O SIZE)。我們可以看出影響每秒IO吞吐量的最大因素,就是IO SIZE和尋道時(shí)間,IO SIZE越大,尋道時(shí)間越小,吞吐量越高。相比能顯著影響IOPS的因素,只有一個(gè),就是尋道時(shí)間。

MongoDB磁盤IO問(wèn)題的3種解決方法

1.使用組合式的大文檔

我們知道MongoDB是一個(gè)文檔數(shù)據(jù)庫(kù),其每一條記錄都是一個(gè)JSON格式的文檔。比如像下面的例子,每一天會(huì)生成一條這樣的統(tǒng)計(jì)數(shù)據(jù):

  { metric: content_count, client: 5, value: 51, date: ISODate(2012-04-01 13:00) }

  { metric: content_count, client: 5, value: 49, date: ISODate(2012-04-02 13:00) }

而如果采用組合式大文檔的話,就可以這樣將一個(gè)月的數(shù)據(jù)全部存到一條記錄里:

  { metric: content_count, client: 5, month: 2012-04, 1: 51, 2: 49, ... }

通過(guò)上面兩種方式存儲(chǔ),預(yù)先一共存儲(chǔ)大約7GB的數(shù)據(jù)(機(jī)器只有1.7GB的內(nèi)存),測(cè)試讀取一年信息,這二者的讀性能差別很明顯:

  第一種: 1.6秒

  第二種: 0.3秒

  那么問(wèn)題在哪里呢?

實(shí)際上原因是組合式的存儲(chǔ)在讀取數(shù)據(jù)的時(shí)候,可以讀取更少的文檔數(shù)量。而讀取文檔如果不能完全在內(nèi)存中的話,其代價(jià)主要是被花在磁盤seek上,第一種存儲(chǔ)方式在獲取一年數(shù)據(jù)時(shí),需要讀取的文檔數(shù)更多,所以磁盤seek的數(shù)量也越多。所以更慢。

實(shí)際上MongoDB的知名使用者foursquare就大量采用這種方式來(lái)提升讀性能。

2.采用特殊的索引結(jié)構(gòu)

我們知道,MongoDB和傳統(tǒng)數(shù)據(jù)庫(kù)一樣,都是采用B樹(shù)作為索引的數(shù)據(jù)結(jié)構(gòu)。對(duì)于樹(shù)形的索引來(lái)說(shuō),保存熱數(shù)據(jù)使用到的索引在存儲(chǔ)上越集中,索引浪費(fèi)掉的內(nèi)存也越小。所以我們對(duì)比下面兩種索引結(jié)構(gòu):

  db.metrics.ensureIndex({ metric: 1, client: 1, date: 1}) 與 db.metrics.ensureIndex({ date: 1, metric: 1, client: 1 })

采用這兩種不同的結(jié)構(gòu),在插入性能上的差別也很明顯。

當(dāng)采用第一種結(jié)構(gòu)時(shí),數(shù)據(jù)量在2千萬(wàn)以下時(shí),能夠基本保持10k/s 的插入速度,而當(dāng)數(shù)據(jù)量再增大,其插入速度就會(huì)慢慢降低到2.5k/s,當(dāng)數(shù)據(jù)量再增大時(shí),其性能可能會(huì)更低。

而采用第二種結(jié)構(gòu)時(shí),插入速度能夠基本穩(wěn)定在10k/s。

其原因是第二種結(jié)構(gòu)將date字段放在了索引的第一位,這樣在構(gòu)建索引時(shí),新數(shù)據(jù)更新索引時(shí),不是在中間去更新的,只是在索引的尾巴處進(jìn)行修改。那些插入時(shí)間過(guò)早的索引在后續(xù)的插入操作中幾乎不需要進(jìn)行修改。而第一種情況下,由于date字段不在最前面,所以其索引更新經(jīng)常是發(fā)生在樹(shù)結(jié)構(gòu)的中間,導(dǎo)致索引結(jié)構(gòu)會(huì)經(jīng)常進(jìn)行大規(guī)模的變化。

3.預(yù)留空間

與第1點(diǎn)相同,這一點(diǎn)同樣是考慮到傳統(tǒng)機(jī)械硬盤的主要操作時(shí)間是花在磁盤seek操作上。

比如還是拿第1點(diǎn)中的例子來(lái)說(shuō),我們?cè)诓迦霐?shù)據(jù)的時(shí)候,預(yù)先將這一年的數(shù)據(jù)需要的空間都一次性插入。這能保證我們這一年12個(gè)月的數(shù)據(jù)是在一條記錄中,是順序存儲(chǔ)在磁盤上的,那么在讀取的時(shí)候,我們可能只需要一次對(duì)磁盤的順序讀操作就能夠讀到一年的數(shù)據(jù),相比前面的12次讀取來(lái)說(shuō),磁盤seek也只有一次。

  db.metrics.insert([

  { metric: content_count, client: 3, date: 2012-01, 0: 0, 1: 0, 2: 0, ... }

  { .................................., date:

  { .................................., date:

  { .................................., date:

  { .................................., date:

  { .................................., date:

  { .................................., date:

  { .................................., date:

  { .................................., date:

  { .................................., date:

  { .................................., date:

  { .................................., date:

  ])

結(jié)果:

  如果不采用預(yù)留空間的方式,讀取一年的記錄需要62ms

  如果采用預(yù)留空間的方式,讀取一年的記錄只需要6.6ms

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,如果有疑問(wèn)大家可以留言交流,謝謝大家對(duì)腳本之家的支持。

您可能感興趣的文章:
  • 解決啟動(dòng)MongoDB錯(cuò)誤:error while loading shared libraries: libstdc++.so.6:cannot open shared object file:
  • 關(guān)于Mongodb參數(shù)說(shuō)明與常見(jiàn)錯(cuò)誤處理的總結(jié)
  • Mongodb常見(jiàn)錯(cuò)誤與解決方法小結(jié)(Mongodb中經(jīng)常出現(xiàn)的錯(cuò)誤)
  • MongoDB錯(cuò)誤32-bit servers don''t have journaling enabled by default解決方法
  • 解決mongodb在ubuntu下啟動(dòng)失敗,提示couldn‘t remove fs lock errno:9 Bad file descriptor的錯(cuò)誤
  • mongodb錯(cuò)誤tcmalloc: large alloc out of memory, printing stack and exiting解決辦法
  • MongoDB最大連接數(shù)設(shè)置失效的異常分析過(guò)程與解決方法
  • Win10 安裝 MongoDB 3.6.5 失敗的問(wèn)題及解決方法
  • mongodb 3.4下遠(yuǎn)程連接認(rèn)證失敗的解決方法
  • MongoDb的"not master and slaveok=false"錯(cuò)誤及解決方法

標(biāo)簽:自貢 廈門 興安盟 遼陽(yáng) 雞西 泰安 無(wú)錫 玉林

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《MongoDB磁盤IO問(wèn)題的3種解決方法》,本文關(guān)鍵詞  MongoDB,磁盤,問(wèn),題的,3種,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《MongoDB磁盤IO問(wèn)題的3種解決方法》相關(guān)的同類信息!
  • 本頁(yè)收集關(guān)于MongoDB磁盤IO問(wèn)題的3種解決方法的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章