快閃記憶體將改變資料庫儲存引擎的設計

TP_funny發表於2014-09-15
過去十年,固態硬碟(俗稱快閃記憶體)已經從根本上改變了計算機資訊處理技術。在客戶端,U盤取代了CD;在伺服器端,它有高於RAM和磁碟驅動器的價效比。但在過去的幾年裡,資料庫才剛剛開始趕上這一趨勢,而且大部分仍然依賴於針對旋轉磁碟內部資料結構和儲存管理的優化來提升效能。

近日,O'Reilly Media資深編輯Andy Oram發表了一篇文章,他基於對數位資料庫專家的採訪,詳細介紹了快閃記憶體如何改變了資料庫儲存引擎的設計,其中包括Aerospike、Cassandra、FoundationDB、RethinkDB和Tokutek的代表人物。對於正在設計應用程式和尋找最佳儲存方案的讀者而言,他們給出的各種方法會有一定的指導意義。

根據介紹,快閃記憶體影響資料庫儲存引擎設計的關鍵特性如下:
  • 隨機讀:快閃記憶體不同於傳統磁碟,它像記憶體一樣,不管兩次讀的物理距離相差多遠,它都可以以同樣的速度提供資料。不過,它每次會讀取整個塊,所以,應用程式可能仍然會受益於訪問區域性性。比如,如果本次讀與上次讀的位置相近,那麼本次操作可能可以直接從記憶體或者快取讀取資料。
  • 吞吐量:有記錄的原始吞吐量已達到每秒幾十萬次的讀/寫,這比磁碟高兩個數量級,甚至更高。而且,隨著磁碟密度的提高,吞吐量還在增長。
  • 延時:據FoundationDB CEO David Rosenthal說,通常,快閃記憶體的讀延時大約為50到100微秒。而RethinkDB CEO Slava Akhmechetat指出,快閃記憶體至少比磁碟快100倍。不過,快閃記憶體的延時已經達到了極限。
  • 並行:快閃記憶體驅動器提供多個控制器或者單個效能更高的控制器。這對於能夠使用多個執行緒和核心的資料庫設計大有裨益,它可以將工作負載劃分成許多獨立的讀寫操作。

那麼,這些特性對資料庫儲存引擎的設計有什麼影響呢?為了說明這個問題, Oram介紹了一些企業的現行做法。

Aerospike是第一款從設計之初就選擇了快閃記憶體的資料庫產品。它將索引儲存在RAM中,其它資料儲存在快閃記憶體中。這樣,他們可以在RAM中快速查詢索引,然後從多個快閃記憶體驅動器中並行檢索資料。由於索引在RAM中更新,向快閃記憶體寫資料的次數就大大減少了。

Cassandra通過排序資料實現了訪問區域性性。它的基本資料結構是日誌結構的合併樹(LSM-樹)。和快閃記憶體一起使用時,該結構可以顯著減少寫操作。據專案負責人JonathanEllis說,為了保證LSM-樹的效率,Cassandra承擔了許多碎片整理工作,而大部分應用程式都把這項工作留給檔案系統來做。而據Rosenthal說,FoundationDB團隊的做法則與此相反,他們依賴快閃記憶體控制器解決寫碎片問題。快閃記憶體控制器可以完成LSM在資料庫引擎層面所做的工作。現在,大部分快閃記憶體控制器都提供了這些演算法。這裡有一點需要注意,實現訪問區域性性會增加寫操作的開銷。在快閃記憶體吞吐量如此大的情況下,這部分開銷可能會超過多次讀操作的開銷。

Tokutek提供了一個聚簇資料庫TokuDB,他們發現聚簇是檢索範圍資料的理想選擇。TokuDB的壓縮比很高(在MySQL或MariaDB上為5比1或7比1,在MongoDB上為10比1),這有效地減少了讀寫開銷,並降低了儲存成本。而且據官方介紹,它所使用的分形樹索引結構減少了寫操作次數,延長了快閃記憶體的使用壽命。

Aerospike、FoundationDB、RethinkDB和Tokutek都是用MVCC或類似的概念連續寫入新版本資料,並在稍後清理老版本資料,而不是直接用新值替換已存資料。因此,資料庫的一個寫請求會變成多個操作,這稱為寫入放大,是快閃記憶體的一個缺點。但據Bulkowski說,通過將索引儲存在記憶體中,Aerospike的寫入放大僅為2,而在其它應用程式中,這個值通常為10。

此外,按照Rosenthal的說法,快閃記憶體的速度和併發為資料庫設計帶來了最大的變化。他說,“在傳統關係型資料的設計中,每個連線一個執行緒,這在磁碟是瓶頸的時代可以工作的很好,但現在,執行緒成了瓶頸。”因此,FoundationDB內部使用它自己的輕量級程式。在快閃記憶體延遲無法再改善的情況下,併發顯得更重要了。而Bulkowski則表示,由於大量的併發,深佇列在快閃記憶體上比在旋轉型磁碟上工作的更好。

總之,這些新的資料庫儲存引擎設計已經拋棄了許多傳統的設計方案。為了利用這些新的發展成果,應用程式開發人員應該重新審視他們的資料庫模式和訪問模式了。
相關閱讀
評論(2)

相關文章