Anna 鍵值存儲系統性價是 DynamoDB 355 倍

過去似乎每周都在宣布新的資料庫。雖然近期新推出資料庫的速度已大大放慢，但還不至於完全停滯。

來自加州大學伯克利分校的RISELabs近日將其Anna資料庫由版本0提升到了版本1，變成了可識別雲。這種資料庫是一種每個核心一個線程的無共享架構，避免了所有協調機制，因而獲得極高的速度。

Anna的架構圖

看看發生了什麼變化。

Anna不僅速度極快，而且異常高效且極具彈性：這是一種自動擴展、多存儲層、選擇性複製的雲服務。所有這些適應性意味著Anna為冷數據減少了消耗的資源，為熱數據增加了所需的資源。你可以獲得所需的所有多核Anna性能，但又不必為不需要的性能付費。

僅舉幾個數字，我們測得Anna以同樣的成本提供了比DynamoDB高355倍的性能。 不，我認為這不是由於AWS在DynamoDB上獲得高出355倍的利潤！問題在於，除了速度快幾個數量級外，現在Anna的效率也比與之競爭的系統高出幾個數量級。

RISELabs在《快速又便宜：我們如何使Anna可以自動擴展？》中撰文介紹了Anna新的強大功能，內容如下：

我們使用Anna v0作為一種內存存儲引擎，一心想要解決上述的雲存儲問題。我們還旨在讓雲端速度最快的KVS發展成為適應性最強、成本效益高的系統。為此，我們為Anna添加了三種關鍵的機制：垂直分層、水平彈性和選擇性複製。

Anna v1 的核心組件是監測系統和策略引擎，共同實現了工作負載的響應性和適應性。為了滿足用戶定義的性能（請求延遲）和成本方面的目標，監測服務對工作負載的變化進行跟蹤，並相應調整資源。每台存儲伺服器收集所處理的請求方面的統計信息和存儲的數據等信息。監測系統定期獲取和處理這些數據，而策略引擎利用這些統計信息，通過上述三種機制中的一種來執行操作。每種操作的觸發規則很簡單：

彈性：為了讓系統適應不斷變化的工作負載，系統必須能夠自動增加或減少資源，以匹配它所看到的請求量。當某一層達到計算或存儲容量的最大值時，我們為集群添加節點；當資源未得到充分利用時，節點就被移除，以節省成本。

選擇性複製：就實際的工作負載而言，常常有一組熱鍵，它們應該複製（不僅僅是為了滿足容錯要求），以提升性能。這增加了處理常見請求可供使用的處理器核心和網路帶寬。Anna v0讓用戶能夠對鍵實現多主複製，但是所有鍵都有一個固定的複製因子。很自然，這樣的成本高得離譜。在Anna v1中，監測引擎選擇訪問最頻繁的鍵，相應增加那些鍵的副本數量，又不支付額外的成本來複製冷數據。

升級和降級：就像傳統的內存層次結構，雲存儲系統應該將熱數據保存在高性能、內存速度的存儲層中，以提高訪問效率，而冷數據應放在速度較慢的存儲層上，以節省成本。我們的監測服務可根據訪問模式，在不同的存儲層之間自動轉移數據。

為了實現這些機制，我們不得不對Anna的設計做出了兩個重大的改變。首先，我們將存儲引擎部署在多種存儲介質（目前是內存和快閃記憶體盤）上。與傳統的內存層次結構類似，這每一個存儲層代表了成本和性能之間不同的取捨。我們還實現了一項路由服務，它將用戶請求發送到相應存儲層的相應伺服器上。無論數據存儲在什麼地方，這為用戶提供了一套統一的API。這每一個存儲層同樣擁有由Anna第一個版本繼承而來的豐富的一致性模型，因此開發人員只需要操心僅僅一種廣泛參數化的一致性模型。

我們的試驗表明，無論在性能還是成本效益方面，Anna都表現出眾。在同樣的固定價位下，Anna提供了8倍於AWS ElastiCache的吞吐量和355倍於DynamoDB的吞吐量。Anna 還能夠通過準確地添加節點和複製數據來應對工作負載的變化。

RISELab的目標是讓計算機能夠做出智能化的實時決策。你可能不記得去年RISELab從AMPLab涅槃而生。AMPLab培育出了像Apache Spark和Apache Mesos這些成功的開源項目，所以別犯這個錯誤：以為它們所做的工作純粹只是為了搞學術研究，它們旨在創造美好未來。

Anna的論文：《用Anna消除雲存儲方面的界限》https://arxiv.org/pdf/1809.00089.pdf

Anna的代碼：https://github.com/fluent-project/fluent/tree/master/kvs

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！