IO概念

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

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

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

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

順序/并發(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的關鍵因素，就是降底尋道時間，而在連續(xù)IO的情況下，尋道時間很短，僅在換磁道時候需要尋道。在這個前提下，傳輸時間越少，IOPS就越高。

每秒IO吞吐量。顯然，每秒IO吞吐量＝IOPS乘以平均IO SIZE。 Io size越大，IOPS越高，每秒IO吞吐量就越高。設磁頭每秒讀寫數(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, … }

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

　　第一種: 1.6秒

　　第二種: 0.3秒

　　那么問題在哪里呢?

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

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

2.采用特殊的索引結構

我們知道，MongoDB和傳統(tǒng)數(shù)據(jù)庫一樣，都是采用B樹作為索引的數(shù)據(jù)結構。對于樹形的索引來說，保存熱數(shù)據(jù)使用到的索引在存儲上越集中，索引浪費掉的內存也越小。所以我們對比下面兩種索引結構：

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