近日，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)