IO概念

在資料庫優化和儲存規劃過程中，總會提到IO的一些重要概念，在這裡就詳細記錄一下，對這個概念的熟悉程度也決定了對資料庫與儲存優化的理解程度，以下這些概念並非權威文件，權威程度肯定就不能說了。

讀/寫IO，最為常見說法，讀IO，就是發指令，從磁碟讀取某段扇區的內容。指令一般是通知磁碟開始扇區位置，然後給出需要從這個初始扇區往後讀取的連續扇區個數，同時給出動作是讀，還是寫。磁碟收到這條指令，就會按照指令的要求，讀或者寫資料。控制器發出的這種指令＋資料，就是一次IO，讀或者寫。

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

連續/隨機IO，連續和隨機，是指本次IO給出的初始扇區地址，和上一次IO的結束扇區地址，是不是完全連續的，或者相隔不多的，如果是，則本次IO應該算是一個連續IO，如果相差太大，則算一次隨機IO。連續IO，因為本次初始扇區和上次結束扇區相隔很近，則磁頭幾乎不用換道或換道時間極短；如果相差太大，則磁頭需要很長的換道時間，如果隨機IO很多，導致磁頭不停換道，效率大大降底。

順序/併發IO，這個的意思是，磁碟控制器每一次對磁碟組發出的指令套（指完成一個事物所需要的指令或者資料），是一條還是多條。如果是一條，則控制器快取中的IO佇列，只能一個一個的來，此時是順序IO；如果控制器可以同時對磁碟組中的多塊磁碟，同時發出指令套，則每次就可以執行多個IO，此時就是併發IO模式。併發IO模式提高了效率和速度。

IO併發機率。單盤，IO併發機率為0，因為一塊磁碟同時只可以進行一次IO。對於raid0，2塊盤情況下，條帶深度比較大的時候（條帶太小不能併發IO，下面會講到），併發2個IO的機率為1/2。其他情況請自行運算。

IOPS。一個IO所用的時間＝尋道時間＋資料傳輸時間。 IOPS＝IO併發係數/（尋道時間＋資料傳輸時間），由於尋道時間相對傳輸時間，大幾個數量級，所以影響IOPS的關鍵因素，就是降底尋道時間，而在連續IO的情況下，尋道時間很短，僅在換磁軌時候需要尋道。在這個前提下，傳輸時間越少，IOPS就越高。

每秒IO吞吐量。顯然，每秒IO吞吐量＝IOPS乘以平均IO SIZE。 Io size越大，IOPS越高，每秒IO吞吐量就越高。設磁頭每秒讀寫資料速度為V，V為定值。則IOPS＝IO併發係數/（尋道時間＋IO SIZE/V），代入，得每秒IO吞吐量＝IO併發係數乘IO SIZE乘V/（V乘尋道時間＋IO SIZE）。我們可以看出影響每秒IO吞吐量的最大因素，就是IO SIZE和尋道時間，IO SIZE越大，尋道時間越小，吞吐量越高。相比能顯著影響IOPS的因素，只有一個，就是尋道時間。

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

1.使用組合式的大文件

我們知道MongoDB是一個文件資料庫，其每一條記錄都是一個JSON格式的文件。比如像下面的例子，每一天會生成一條這樣的統計資料：

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

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

而如果採用組合式大文件的話，就可以這樣將一個月的資料全部存到一條記錄裡：

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

通過上面兩種方式儲存，預先一共儲存大約7GB的資料(機器只有1.7GB的記憶體)，測試讀取一年資訊，這二者的讀效能差別很明顯：

　　第一種: 1.6秒

　　第二種: 0.3秒

　　那麼問題在哪裡呢?

實際上原因是組合式的儲存在讀取資料的時候，可以讀取更少的文件數量。而讀取文件如果不能完全在記憶體中的話，其代價主要是被花在磁碟seek上，第一種儲存方式在獲取一年資料時，需要讀取的文件數更多，所以磁碟seek的數量也越多。所以更慢。

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

2.採用特殊的索引結構

我們知道，MongoDB和傳統資料庫一樣，都是採用B樹作為索引的資料結構。對於樹形的索引來說，儲存熱資料使用到的索引在儲存上越集中，索引浪費掉的記憶體也越小。所以我們對比下面兩種索引結構：

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

採用這兩種不同的結構，在插入效能上的差別也很明顯。

當採用第一種結構時，資料量在2千萬以下時，能夠基本保持10k/s 的插入速度，而當資料量再增大，其插入速度就會慢慢降低到2.5k/s，當資料量再增大時，其效能可能會更低。

而採用第二種結構時，插入速度能夠基本穩定在10k/s。

其原因是第二種結構將date欄位放在了索引的第一位，這樣在構建索引時，新資料更新索引時，不是在中間去更新的，只是在索引的尾巴處進行修改。那些插入時間過早的索引在後續的插入操作中幾乎不需要進行修改。而第一種情況下，由於date欄位不在最前面，所以其索引更新經常是發生在樹結構的中間，導致索引結構會經常進行大規模的變化。

3.預留空間

與第1點相同，這一點同樣是考慮到傳統機械硬碟的主要操作時間是花在磁碟seek操作上。

比如還是拿第1點中的例子來說，我們在插入資料的時候，預先將這一年的資料需要的空間都一次性插入。這能保證我們這一年12個月的資料是在一條記錄中，是順序儲存在磁碟上的，那麼在讀取的時候，我們可能只需要一次對磁碟的順序讀操作就能夠讀到一年的資料，相比前面的12次讀取來說，磁碟seek也只有一次。

　　db.metrics.insert([

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

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

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

　　])

結果：

　　如果不採用預留空間的方式，讀取一年的記錄需要62ms

　　如果採用預留空間的方式，讀取一年的記錄只需要6.6ms

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對我們的支援。