秒殺Redis的KVS資料庫上雲了！伯克利重磅開源Anna 1.0
天下武功，唯快不破。今年3月份，伯克利 RISE 實驗室推出了最新的鍵值儲存資料庫 Anna，提供了驚人的存取速度、超強的伸縮性和史無前例的一致性保證。Anna論文也被評為"Best of ICDE 2018"，其加長版即將應邀發表在IEEE TKDE期刊上。Anna一經推出即在業界引發熱烈討論（AI前線報道回顧[伯克利推出世界最快的KVS資料庫Anna：秒殺Redis和Cassandra](https://mp.weixin.qq.com/s/3WmGpZkEuSz-ox_2CPCsqg )）。不少讀者關心它何時開源、後續有什麼新的進展。今天，AI前線給大家帶來了Anna的最新訊息，過去這半年裡，伯克利RISE實驗室對Anna的設計進行了重大變更，新版本的Anna能夠更好地在雲端擴充套件。實驗表明，無論是在效能還是成本效益方面，Anna都表現突出，它明顯優於AWS ElastiCache的memcached以及較早之前的Masstree，也比AWS DynamoDB更具成本優勢。與此同時，Anna所有原始碼也正式登陸Github，開放給所有開發者。
背景
在之前的一篇博文中，我們介紹了Anna系統，它使用了一個核心對應一個執行緒的無共享執行緒架構，通過避免執行緒間的協調來實現閃電般的速度。Anna還使用晶格組合來實現多樣的無協調一致性級別。第一個版本的Anna吊打現有的記憶體KV儲存系統：它的效能優於Masstree 700倍，優於TBB 800倍。你可以重溫之前的博文（https://databeta.wordpress.com/2018/03/09/anna-kvs/ ） ，或者閱讀完整的論文（http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf ）。我們將第一個Anna版本稱為“Anna v0”。在這篇文章中，我們介紹如何將這個最快的KV儲存系統變得極具成本效益和適應性。
現如今，公共基礎設施雲使用者可選擇的儲存系統真是太多了。AWS提供兩種物件儲存服務（S3和Glacier）和兩種檔案系統服務（ EBS和EFS），另外還有七種不同的資料庫服務，從關係資料庫到NoSQL鍵值儲存。真是花樣繁多，令人眼花繚亂，使用者自然會問，哪個服務才適合他們。最直接（然而並不樂觀）的答案是，把它們全都用起來就對了。
這些儲存服務都提供了非常有限的成本與效能之間的權衡。例如，AWS ElastiCache速度很快，但很貴，而AWS Glacier雖然便宜，但速度較慢。因此，使用者門面對一個窘境：他們必須要麼放棄節約成本的目標，大規模部署高效能儲存叢集，要麼放棄效能，利用低成本的系統例如DynamoDB或者S3。
更糟糕的是，大多數實際應用展現出偏斜的資料訪問模式。頻繁被訪問的資料是“熱”資料，其他則為“冷”資料，而這些服務要麼是專門為“熱資料”而設計，要麼專門為“冷資料”而設計。因此，不想在效能或成本上妥協的使用者必須手動將這些解決方案拼湊在一起，跟蹤服務間的資料和請求，以及管理不同的API，並做出一致性保證。
更糟糕的是，高效能的雲端儲存產品不具備彈性：向叢集新增資源或從叢集中移除資源都需要人工干預。這意味著雲開發者們設計並實現自定義解決方案來監控工作負載變化、修改資源分配以及在儲存引擎之間移動資料。
這是非常糟糕的。應用程式開發人員不斷被迫重新發明輪子，而不是把精力放在他們最關心的指標上：效能和成本。我們想要改變這種現狀。
Anna v1
我們藉助Anna v0這個記憶體儲存引擎來解決上述的雲端儲存問題。我們的目標是將最快的Anna同時發展成為最具適應性和成本效益的KV儲存系統。我們向Anna中添加了3個關鍵的機制：垂直分層、水平彈性和選擇性複製。
Anna v1的核心元件是監控系統和策略引擎，可實現工作負載的響應性和適應性。為了滿足使用者定義的效能目標（ 請求延遲）和成本，監控服務對工作負載變化進行監控和調整。儲存伺服器會收集請求和資料的統計資訊。監視系統定期搜尋和處理這些資料，策略引擎基於這些統計資訊執行上述的三個操作。操作的觸發規則很簡單：
- 彈性：為了讓系統適應變化的工作負載，系統需要能夠根據工作量自動擴充套件和收縮。當一個層達到計算或儲存容量最大值時新增節點，當某個節點明顯得不到未充分利用時將其移除。
- 選擇性複製：在實際工作環境下，訪問量很大的key需要被廣泛的複製到多個節點和CPU核從而提高效能。Anna v0啟用了key的多主複製，但在複製所有key時提供了一個固定的複製因子。正如讀者們想象的，這是一個成本很大的設計。在Anna v1中，監控服務僅選擇性的複製訪問次數高的“熱”key而不復制“冷”key，從而減小儲存成本。
- 升級和降級：與傳統的記憶體層次結構中一樣，熱資料應該儲存在更快的儲存介質中提高訪問效率，冷資料應該儲存在較慢的儲存介質中節約成本。我們的監測服務會根據資料的熱度變化自動將它們移至合適的儲存介質。
為了實現這些機制，我們不得不對Anna的設計做出兩個重大變更。首先，我們讓儲存引擎支援多種儲存介質——目前是記憶體和快閃記憶體。與傳統的儲存層次結構類似，這些儲存層的成本與效能權衡是不一樣的。我們還實現了一個路由服務，它將使用者請求傳送到目標層的伺服器上。無論資料儲存在什麼地方，都可以為使用者提供統一的API。這些層都從第一版Anna繼承了同等豐富的一致性模型，因此開發者可以靈活挑選並自定義合適的一致性模型。
我們的實驗表明，無論是在效能還是成本效益方面，Anna都達到了令人印象深刻的水平。在同一成本下，Anna提供優於AWS ElastiCache8倍的吞吐量和優於DynamoDB 355倍的吞吐量。Anna還能夠通過新增節點和恰到好處的資料複製來應對工作負載的變化：
這篇文章只提供了Anna的設計概述，如果你有興趣瞭解更多，可以在這裡（https://arxiv.org/pdf/1809.00089.pdf ）和這裡（https://github.com/fluent-project/fluent/tree/master/kvs ）找到完整的論文和程式碼。這個專案的進展讓我們很滿意，我們也很樂意收到你的反饋。後續，我們會有更多的計劃，將Anna的高效能和靈活性拓展到其他的系統中，敬請關注！
檢視英文原文：https://rise.cs.berkeley.edu/blog/going-fast-and-cheap-how-we-made-anna-autoscale/
感謝蔡芳芳對本文的審校。