IO概念

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

讀/寫IO，最為常見說法，讀IO，就是發(fā)指令，從磁盤讀取某段扇區(qū)的內(nè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，大塊和小塊之間，沒有明確的界限。

連續(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è)的來，此時(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問題的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, ... }

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

　　第一種: 1.6秒

　　第二種: 0.3秒

　　那么問題在哪里呢?

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

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

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

我們知道，MongoDB和傳統(tǒng)數(shù)據(jù)庫(kù)一樣，都是采用B樹作為索引的數(shù)據(jù)結(jié)構(gòu)。對(duì)于樹形的索引來說，保存熱數(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千萬以下時(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í)間過早的索引在后續(xù)的插入操作中幾乎不需要進(jìn)行修改。而第一種情況下，由于date字段不在最前面，所以其索引更新經(jīng)常是發(fā)生在樹結(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)中的例子來說，我們?cè)诓迦霐?shù)據(jù)的時(shí)候，預(yù)先將這一年的數(shù)據(jù)需要的空間都一次性插入。這能保證我們這一年12個(gè)月的數(shù)據(jù)是在一條記錄中，是順序存儲(chǔ)在磁盤上的，那么在讀取的時(shí)候，我們可能只需要一次對(duì)磁盤的順序讀操作就能夠讀到一年的數(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é)

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