本文選自 HighScalability上的一篇博客文章，作者系Tokutek公司(Tokutek能夠提升MongoDB, MySQL以及MariaDB的性能20倍)的一位工程師，該公司研究的主要方向是存儲引擎。編譯整理如下：

作為一名軟件開發(fā)者，我們非常看重那些抽象化的東西。API越簡單，對我們越有吸引力。辯證地講，MongoDB最大的優(yōu)勢就是“優(yōu)雅”的API和它的敏捷性，這讓開發(fā)者的編碼過程變得異常的簡單。

但是，當MongoDB涉及到大數(shù)據(jù)可擴展性問題時，開發(fā)者還是需要了解一下它的底層，弄明白那些潛在的問題，然后才能快速地進行解決。如果不理解，最終可能會選擇一個低效的解決方案，而且浪費了時間和金錢。本文重點介紹了，如何為大數(shù)據(jù)的擴展性問題找個一個高效的解決方案。

定義問題

首先，我們要確定應用的上下文，本文主要討論的是MongoDB的應用程序。這意味著，我們將研究一個分布式文檔存儲數(shù)據(jù)庫，而且它還支持二級索引和分片集群。如果是針對其他的NoSQL產(chǎn)品，像Riak或者Cassandra，我們可能會討論I/O瓶頸問題，而本文主要關注MongoDB的一些特性。

其次，這些應用能夠做什么?是做聯(lián)機事務處理( OLTP)還是做聯(lián)機分析處理( OLAP)?本文主要討論的是OLTP，因為對MongoDB而言，OLAP還是一個不小的挑戰(zhàn)，或者說基本不能夠進行處理。

第三，大數(shù)據(jù)是什么?通過大數(shù)據(jù)，我們能夠處理和使用更多的數(shù)據(jù)，不再局限于單機RAM中的那些部分。這樣的話，有些數(shù)據(jù)保留在服務器上，而更多的數(shù)據(jù)則是存放在磁盤中，這就需要I/O的訪問。但是請注意，我們不是在討論數(shù)據(jù)庫夠不夠大，而是關注那些經(jīng)常被存取和使用的數(shù)據(jù)(有時稱之為“工作集”)是不是很小。比如說，磁盤上雖然存儲了好幾年的數(shù)據(jù)，但是應用可能經(jīng)常訪問的只有最后一天的數(shù)據(jù)。

第四，OLTP應用的限制性因素有哪些?簡而言之，就是I/O。硬盤驅動每秒鐘只可以啟動上百次的I/O，而另一方面，RAM每秒可以實現(xiàn)數(shù)百萬次的存取，這個限制性因素就是導致大數(shù)據(jù)應用I/O瓶頸的原因所在。

最后，我們應該如何解決I/O瓶頸?通過分析思維，公式和直接指令給我們提供了很多種方式，但是一個持久性的解決方案就需要“理解”。用戶必須著眼于應用程序的I/O特性，然后才能做出最好的設計決策。

開銷模型

未來解決I/O瓶頸，第一步需要掌握哪些數(shù)據(jù)庫操作會包括I/O。 無論MongoDB，還是其他的數(shù)據(jù)庫類型，都有三種基本的操作：

Point Query：查找一個獨立的文件。在一個給定的位置的文件夾(磁盤或者內(nèi)存上)，檢索該文檔。對于大數(shù)據(jù)來說，該文件可能不在內(nèi)存中。此操作可能會導致一次I/O。

Range Query：在索引中，查找大量的連續(xù)性文件，對比Point Query而言，它是一個更高效的查詢操作。這是因為我們查找的這些數(shù)據(jù)都是打包存放在磁盤上，可以通過極少的I/O操作來直接讀入內(nèi)存。Range Query一般檢索100個文件才會啟動一次I/O，相對比，100個Point Query檢索100個文件可能就需要100次I/O操作。

Write：寫文件到數(shù)據(jù)庫中。類似MongoDB這樣的數(shù)據(jù)庫，都會產(chǎn)生I/O。而對那些“寫優(yōu)化”數(shù)據(jù)結構的數(shù)據(jù)庫而言，比如 TokuMX，僅僅需要很少的I/O。不像MongDB，“寫優(yōu)化”的數(shù)據(jù)結構能夠通過執(zhí)行多次插入來分攤I/O。

在了解三個基本操作對I/O的影響之后，還需要理解MongoDB數(shù)據(jù)庫語句對I/O的影響。MongoDB包含了這三個基本操作，同時還構建了四個用戶級別的操作：

插入：將一個新文件寫到數(shù)據(jù)庫中。

查詢：在集合上使用索引，這樣做一個Range Queries和Point Query的整合。如果該索引是一個覆蓋索引或者是集群索引，那么接下來基本上只需要做范圍查詢。否則的話，整合的范圍查詢和點查詢就會被啟用。

修改和刪除：這是一個查詢和寫操作的整合。查詢操作用于發(fā)現(xiàn)那些需要更新和刪除的文件，然后寫操作再對這些文件進行修改或者是刪除。

現(xiàn)在，我們理解了開銷模型。不過為了解決I/O的瓶頸問題，用戶還需要知道哪些應用啟動了I/O操作。這就需要我們了解數(shù)據(jù)庫的行為。I/O啟動是源于查詢操作嗎?如果是這樣的話，查詢行為是如何影響I/O的?還是源于修改操作?如果是因為修改導致的影響，那么是因為修改過程中的查詢操作還是插入操作?一旦用戶掌握了哪些因素會影響 I/O，接下來就可以逐步來解決瓶頸的問題了。

假設我們明白了某個應用的I/O特性，我們就可以探討幾種途徑來解決這一問題。我最喜歡的方式是這樣的：首先嘗試使用軟件來解決該問題，如果不能完美的解決，那么再考慮硬件。畢竟軟件的成本更低且易于維護。#p#

可行的軟件解決方案

一個可行的軟件解決方案，就是需要減少軟件或者應用的I/O啟動次數(shù)。針對不同的瓶頸，下面列舉了對應可行的解決方案：

問題：插入操作導致過多的I/O

可行方案：使用一個寫優(yōu)化的數(shù)據(jù)庫，比如說TokuMX，使用TokuMX的一項優(yōu)勢就是它能夠大幅度減少對寫操作的I/O請求，而索引方式使用的是Fractal Trees( TokuDB實際上還對Fractal Trees做了改進，將插入的IO數(shù)量級從log(N)提高到了logB(N))

問題：查詢操作導致過多的I/O

可行方案：使用一個更好的索引，減少點查詢，盡量使用范圍查詢替代。在我看來，還是需要“理解索引”。我解釋了索引能夠減少查詢操作的I/O請求。當然這不是用一兩段話就可以說得清的，但是要點如下：減少應用的I/O請求首先要避免獨立的點查詢來檢索每個文件夾，為了實現(xiàn)這點，我們要使用覆蓋或者集群索引，這樣可以智能地過濾掉在查詢過程中已經(jīng)分析過的文件，然后再使用范圍查詢報告結果。

誠然，一個好的索引方式還不足夠，如果是一個OLTP應用，那么所有的查詢從本質上講都是點查詢(因為他們只是檢索極少的文件)，即使使用一個完全適合的索引，用戶還是會出現(xiàn)I/O的瓶頸問題。在這種情況下，硬件的解決方案就是必要的。

當然，增加索引也意味著增加插入的成本，因為每個插入操作都要保證索引的及時更新，但是寫優(yōu)化的數(shù)據(jù)庫可以減少一定的成本。這也是我一直強調(diào)我們需要理解應用的原因所在，對于某些應用來說，一個可行的解決方案，并不代表也適用于其他的應用。

問題：修改或者刪除導致過多的I/O

解決方案：整合以上所有的解決方案

修改和刪除之所以復雜是因為這是查詢和插入的一個整合。提升它們的性能要求對操作開銷有一個很好的理解。哪部分操作會涉及到I/O?是查詢?如果這樣，我們就提升索引。是寫操作?還是兼而有之?簡單來講，就是哪部分操作牽涉到I/O問題，我們就應用對應的解決方案。

一個很常見的錯誤就是：當我們使用一個寫優(yōu)化的數(shù)據(jù)庫(像TokuMX)，在不改變?nèi)魏嗡饕那闆r下，就希望它能夠消除修改或者刪除的I/O瓶頸問題。畢竟，寫優(yōu)化的數(shù)據(jù)庫還是不足夠的，在修改/刪除過程中的隱含的查詢也必須進行處理。

可行的硬件解決方案

就像上文提到的那樣，當軟件解決方案不能夠解決問題的時候，我們就需要尋求硬件的解決方案。我們先分析一下硬件的優(yōu)勢和劣勢：

購買盡可能多的內(nèi)存，即使難以做到，也要把工作集放到內(nèi)存中

使用SSD來增加IOPS

購買更多的服務器，并使用一個可擴展的解決方案，其中包括

通過副本進行讀擴展

分片

購買更多的內(nèi)存

RAM是很昂貴的，而且在一臺機器上可擴展的內(nèi)存也是有限的。如果數(shù)據(jù)太大，都保存在RAM中也不是一個可行的選擇。這種解決方案可能適于用大多數(shù)的應用，但我們更關注那些這種方案解決不了的應用。

使用SSD存儲

不可否認，如果存儲設備使用SSD提升吞吐量，這絕對是一個很實用的解決方案。如果I/O成為應用的限制性因素，那么增加IOPS(每秒的I/O操作)理所當然地能夠增加吞吐量，簡單且使用。

然而，SSD的成本和硬盤的成本也不一樣，SSD絕對可以顯著地提升I/O的吞吐量，雖然成本也不便宜，但是更輕、容量更大，速率也更快。那么為了降低成本，數(shù)據(jù)壓縮就是一個關鍵。 其實，雖然硬件成本增加了，但這并不意味著管理成本也會增加：

通過副本進行讀擴展

當查詢操作成為應用的瓶頸，那么通過副本進行讀擴展就是一個非常有效的解決方案。想法如下：

使用備份功能，將多個數(shù)據(jù)拷貝到相互獨立的機器上

分布地在不同的機器上進行讀取，這樣將會提升讀的吞吐量

如果在單一的機器上進行讀操作而且傳輸出來，這樣會出現(xiàn)很大的瓶頸。如果有多個副本的話，應用將有更多的資源可用，因此讀寫方面都將有很大的提升。

如果是插入、修改或者是刪除過程存在瓶頸，那么副本可能就不會那么的高效。這是因為寫操作需要將數(shù)據(jù)備份到所有的服務器的副本集上，機器在數(shù)據(jù)的輸入過程中也面臨同樣的瓶頸問題。

分片

基于shard key，分片片將數(shù)據(jù)切分到不同的副本集，集群中不同副本集負責相應范圍的值。所以，可以通過將寫操作分配給集群中不同的副本集來提升應用程序的寫吞吐量。對于寫負載高的應用，分片可以非常有效的。

在shard key空間中將數(shù)據(jù)按范圍劃分，使用shard key橫跨多個副本做范圍查詢可以非常有效。如果將shard key哈希，那么所有范圍查詢必須運行在集群中的所有分片，但是在shard key上的點查詢只運行在一個分片上。shard key哈希，據(jù)結構模型并且不支持join，分片用起來非常的高效且簡單。如果上述的方案都不足以解決應用的瓶頸問，那么你可以在分片上多下工夫了。

無論如何，分片都是一個重量級的解決方案，而且成本非常之高。對初入者來說，你的硬件投入預算需要增加好幾倍。不僅僅需要為分片設置增加服務器，還需要增加一整套副本集。你還需要增加和管理配置服務器，考慮到成本問題，用戶需要慎重考慮分片是不是很必要。通常來講，上面所有方案都比這個節(jié)省成本。

另外一個很大的挑戰(zhàn)就是選擇一個shard key，一個好的shard key有以下特點：

大多數(shù)(如果不是全部)的查詢都使用shard key，任何查詢(沒有使用shard key)必須運行在所有的分片上。這點可能比較麻煩。

shard key應該非常有利于集群不同副本及上的分布寫操作，如果所有的寫操作都對應到集群上同一個副本集，那么該副本集對于寫操作來講，就會成為一個瓶頸，就好像處在一個非分片的設置中，這樣的話，這種情況糟糕到就像使用時間戳作為shard key。

這些要求并不是很容易實現(xiàn)。有時，一個好的shard key并不存在，這讓分片變得極不高效。

總結

很多解決方案都行得通，但是沒有一個能百分百得到保障的，甚至包括分片。這也是作者強調(diào)的：理解應用的特性是至關重要的。工具可以解決問題，但是如何更好地使用工具，這就取決于用戶了。