欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

MongoDB磁盤IO問題的3種解決方法

 更新時間:2018年07月06日 14:12:57   作者:luzq  
磁盤IO是不可避免的,除去減少或延緩磁盤操作,也需要盡量的增強磁盤IO性能和吞吐量。下面這篇文章主要給大家介紹了關(guān)于MongoDB磁盤IO問題的3種解決方法,需要的朋友可以參考借鑒,需要的朋友們下面來一起看看吧

IO概念

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

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

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

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

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

IO并發(fā)幾率。單盤,IO并發(fā)幾率為0,因為一塊磁盤同時只可以進行一次IO。對于raid0,2塊盤情況下,條帶深度比較大的時候(條帶太小不能并發(fā)IO,下面會講到),并發(fā)2個IO的幾率為1/2。其他情況請自行運算。

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

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

MongoDB磁盤IO問題的3種解決方法

1.使用組合式的大文檔

我們知道MongoDB是一個文檔數(shù)據(jù)庫,其每一條記錄都是一個JSON格式的文檔。比如像下面的例子,每一天會生成一條這樣的統(tǒng)計數(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) }

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

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

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

  第一種: 1.6秒

  第二種: 0.3秒

  那么問題在哪里呢?

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

實際上MongoDB的知名使用者foursquare就大量采用這種方式來提升讀性能。

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

我們知道,MongoDB和傳統(tǒng)數(shù)據(jù)庫一樣,都是采用B樹作為索引的數(shù)據(jù)結(jié)構(gòu)。對于樹形的索引來說,保存熱數(shù)據(jù)使用到的索引在存儲上越集中,索引浪費掉的內(nèi)存也越小。所以我們對比下面兩種索引結(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ù)據(jù)量在2千萬以下時,能夠基本保持10k/s 的插入速度,而當(dāng)數(shù)據(jù)量再增大,其插入速度就會慢慢降低到2.5k/s,當(dāng)數(shù)據(jù)量再增大時,其性能可能會更低。

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

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

3.預(yù)留空間

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

比如還是拿第1點中的例子來說,我們在插入數(shù)據(jù)的時候,預(yù)先將這一年的數(shù)據(jù)需要的空間都一次性插入。這能保證我們這一年12個月的數(shù)據(jù)是在一條記錄中,是順序存儲在磁盤上的,那么在讀取的時候,我們可能只需要一次對磁盤的順序讀操作就能夠讀到一年的數(shù)據(jù),相比前面的12次讀取來說,磁盤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é)

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

相關(guān)文章

  • MongoDB的基礎(chǔ)知識簡介

    MongoDB的基礎(chǔ)知識簡介

    這篇文章主要介紹了MongoDB的基礎(chǔ)知識簡介,需要的朋友可以參考下
    2017-05-05
  • mongodb eval 執(zhí)行服務(wù)器端腳本

    mongodb eval 執(zhí)行服務(wù)器端腳本

    在MongoDB的服務(wù)器端可以通過db.eval函數(shù)來執(zhí)行javascript腳本,如我們可以定義一個javascript函數(shù),然后通過db.eval在服務(wù)器端來運行!我們前面其實也接觸過在服務(wù)器段運行一個預(yù)定義的javascript腳本的情況,如在$where查詢,執(zhí)行mapreduce任務(wù)等。
    2015-05-05
  • MongoDB日常使用的技巧與注意事項匯總

    MongoDB日常使用的技巧與注意事項匯總

    這篇文章主要給大家總結(jié)介紹了關(guān)于MongoDB日常使用的一些技巧與注意事項,文中通過示例代碼介紹的非常詳細,對大家學(xué)習(xí)或者使用MongoDB具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧。
    2017-11-11
  • mongoDB4.0數(shù)據(jù)庫的操作方法

    mongoDB4.0數(shù)據(jù)庫的操作方法

    這篇文章主要介紹了mongoDB4.0數(shù)據(jù)庫的操作方法及注意事項,非常不錯,具有一定的參考借鑒價值,需要的朋友可以參考下
    2019-10-10
  • MongoDB分片詳解

    MongoDB分片詳解

    本文分享了MongoDB分片詳細介紹,分片是MongoDB的擴展方式,通過分片能夠增加更多的機器來用對不斷增加的負載和數(shù)據(jù),還不影響應(yīng)用,
    2018-03-03
  • MongoDB中的常用操作$push、$pushAll和$pull示例詳解

    MongoDB中的常用操作$push、$pushAll和$pull示例詳解

    MongoDB從2.2版本開始支持$push操作符,$push是用于在數(shù)組中添加一個元素的更新操作符,它將指定的值追加到數(shù)組的末尾,本文給大家介紹MongoDB的常用操作$push、$pushAll和$pull,感興趣的朋友一起看看吧
    2023-12-12
  • MongoDB中的Primary Shard詳解

    MongoDB中的Primary Shard詳解

    在MongoDB的Sharding架構(gòu)中,每個database中都可以存儲兩種類型的集合,一種是未分片的集合,一種是通過分片鍵,被打散的集合,下面給大家介紹MongoDB中的Primary Shard詳解,感興趣的朋友跟隨小編一起看看吧
    2024-08-08
  • Java操作MongoDB數(shù)據(jù)庫方法詳解

    Java操作MongoDB數(shù)據(jù)庫方法詳解

    本文給大家分享的是使用Java操作MongoDB的一些基本方法,包含多種數(shù)據(jù)庫的連接方式,增刪改查等方法,非常的實用,有需要的小伙伴可以參考下
    2018-01-01
  • MongoDB數(shù)據(jù)庫授權(quán)認證的實現(xiàn)

    MongoDB數(shù)據(jù)庫授權(quán)認證的實現(xiàn)

    本文主要介紹了MongoDB數(shù)據(jù)庫授權(quán)認證的實現(xiàn),文中通過示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2021-12-12
  • MongoDB聚合分組取第一條記錄的案例與實現(xiàn)方法

    MongoDB聚合分組取第一條記錄的案例與實現(xiàn)方法

    這篇文章主要給大家介紹了關(guān)于MongoDB聚合分組取第一條記錄的案例與實現(xiàn)方法,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2019-01-01

最新評論