伯克利推出世界最快的KVS數據庫Anna：秒殺Redis和Cassandra

AI 前線導讀：天下武功，惟快不破。伯克利 RISE 實驗室推出了最新的鍵值存儲數據庫 Anna，提供了驚人的存取速度、超強的伸縮性和前所未有的一致性保證。Jeff Dean 說，當一個系統增加到十倍規模時，就須要進行從新設計。那麼，對於 RISE 實驗室的研究員們來講，怎樣才能設計出一個具有指數級增加規模的鍵值存儲數據庫呢？

更多幹貨內容請關注微信公衆號「AI 前線」，（ID：ai-front）

題外話：RISE 實驗室的前身是赫赫有名的伯克利 AMP 實驗室，該實驗室曾開發出了一大批大獲成功的分佈式技術，這些技術對高性能計算產生了深遠的影響，包括 Spark、Mesos、Tachyon 等。現在，原 AMP 實驗室博士生，同時也是 Spark 和 Mesos 核心做者之一的 Matei 已經轉身去了斯坦福，並於去年年末推出了以普及機器學習實踐爲目的的開源項目 DAWN（詳見 AI 前線報道 )，而 RISE 實驗室也在沒多久後推出了志在取代 Spark 的新型分佈式執行框架 Ray（詳見 AI 前線報道）。

過去幾年，RISE 實驗室把研究重點放在如何設計一個無需協調的分佈式系統上。他們提出了 CALM 基礎理論（http://db.cs.berkeley.edu/papers/sigrec10-declimperative.pdf），設計出了新編程語言 Bloom（http://bloom-lang.net/），開發出了跨平臺程序分析框架 Blazes（https://arxiv.org/pdf/1309.3324.pdf），發佈了事務協議 HATs（http://www.vldb.org/pvldb/vol8/p185-bailis.pdf）。但在推出 Anna 以前，他們還未就這些理論、語言、框架或協議在多核環境下或雲環境中可以提供怎樣的性能有過任何測試或評估。

而 Anna 的推出正好印證了他們以前的研究成果。Anna 的論文顯示，在單個 AWS 實例上，Anna 的速度是 Redis 的 10 倍。而在一個標準的交互式基準測試中，也以 10 倍的速度戰勝了 Cassandra。爲了得到更多的比較結果，他們還拿 Anna 與其餘主流的鍵值系統進行了性能對比：比 Masstree 快 700 倍，比英特爾的「無鎖」TBB 哈希錶快 800 倍。固然，Anna 並無提供相似其餘鍵值系統那樣的線性一致性。不過，Anna 使用了本地緩存存放私有狀態，仍然提供了極佳的無協調一致性，比「hogwild」風格的 C++ 哈希表要快上 126 倍。並且一旦到了雲端，Anna 更是獨領風騷，其餘的系統沒法真正提供線性伸縮，但 Anna 卻能夠。

Anna 的性能和伸縮性主要歸功於它的徹底無協調機制，節點工做進程有 90% 的工做負載是在處理請求，而其餘大部分系統（如 Masstree 和英特爾的 TBB）只有不到 10% 的時間在處理請求，它們其他的 90% 時間花在了等待協調上。不只如此，其餘系統由於使用了共享內存，還會出現處理器緩存擊穿問題。

Anna 不只速度快，在一致性方面也達到了很高的水準。多年前，他們發佈的事務協議 HATs 就已代表，無協調的分佈式一致性和事務隔離性存在很大的提高空間，包括級聯一致性和讀提交事務級別。Anna 將 Bloom 的單格子組合設計模式移植到了 C++ 中，是第一個實現了上述全部級別一致性的系統。固然，也是由於設計上的簡潔，才能達到如此快的速度。

RISE 的研究員們在設計 Anna 的過程當中學到了不少，它們已經遠遠超出了一個鍵值數據庫的範疇，能夠被應用在任何一個分佈式系統上。他們正基於 Anna 開發一個新的擴展系統，叫做 Bedrock。Bedrock 運行在雲端，提供了無需人工干預、低成本的鍵值存儲方案，並且是開源的。

Anna 架構簡析

圖 1：Anna 架構

上圖是 Anna 單節點的架構圖。Anna 服務器由一系列獨立的線程組成，每一個線程運行無協調的 actor。每一個線程對應一個 CPU 核心，線程數量不超過 CPU 的總核數。客戶端代理負責將遠程請求分發給 actor，每一個 actor 都有一個私有的哈希表，這些哈希表存放在共享內存中。線程間的變動經過內存廣播進行交換，而服務器間的變動則經過 protobuf 進行交換。

這種線程和 CPU 核心一對一的模型避免了上下文切換開銷。actor 之間不共享鍵值狀態，經過一致性哈希對鍵空間進行分區，並使用多主複製機制在 actor 之間複製數據分區，並且複製係數是可配置的。actor 基於時間戳將鍵的更新通知給其餘 actor 副本，每一個 actor 有本身的私有狀態，這個狀態保存在一個叫做「格子」的數據結構中，確保在消息發生延遲、重排或重複時仍然可以保證一致性。

Anna 性能評測

下面就 Anna 的無協調 actor 模型在多核 CPU 上的並行能力、多服務器伸縮能力進行評測，並將它與其餘流行的鍵值數據庫進行對比。

無協調 actor 模型的伸縮性

在無協調 actor 模型中，每一個 actor 對應一個線程，對任何一個共享狀態都有本身的一份私有拷貝，並經過異步廣播將更新通知給其餘 actor。在多核服務器上，這種模型比傳統的共享內存模型的性能要高出一個數量級。

爲此，RISE 研究員設計了一個對比實驗，將 Anna 與其餘基於共享內存的 TBB、Masstree 和本身實現的一個鍵值存儲系統（姑且把它叫做「Ideal」）進行了對比。他們在 AWS 的 m4.16xlarge 實例上運行實驗，每一個實例配備了 32 核的 CPU。實驗中使用了 1 百萬個鍵值對，鍵的大小爲 8 字節，值的大小爲 1KB。在實驗過程當中，他們基於 zipfian 分佈和各類係數生成不一樣的壓力負載，模擬不一樣層次的衝突。

在第一次實驗中，他們對比了 Anna 與 TBB、Masstree 和 Ideal 在單臺服務器上的吞吐量。他們逐漸增長線程數量，直到達到服務器 CPU 核數的上限，並觀察它們的吞吐量。

圖 2

圖 3

圖 2 是在高併發狀況下，線程數與吞吐量的變化關係，其中 zipf 係數爲 4。圖 3 是在高併發狀況下，CPU 時間的使用狀況。CPU 時間被分爲 5 類：處理請求（RH）、原子指令（AI）、合併格子（LM）、廣播（M）和其餘。最右邊一欄是 L1 緩存擊穿數量（CM）。

從圖中能夠看出，在這樣的負載壓力下，TBB 和 Masstree 幾乎失去了並行能力。由於大部分是更新操做，針對同一個鍵值的並行更新操做會被串行化，它們須要同步機制來防止多個線程同時更新同一個鍵值。所以，隨着線程數量的增長，它們性能也只能趨於平緩。Ideal 雖然比 TBB 和 Masstree 的性能高出 6 倍，但相比 Anna，仍是差了不少。儘管它沒有使用同步機制，但在多個線程修改共享內存地址時，仍然存在緩存一致性方面的開銷。

相反，在 Anna 中，更新操做是針對本地狀態進行的，不須要進行同步，並定時經過廣播進行變動交換。在高併發狀況下，儘管它的性能仍然受限於其複製係數，但比基於共享內存的系統要好不少。Anna 有 90% 的 CPU 時間用於處理請求，花在其餘方面的時間則不多。可見，Anna 的無協調 actor 模型解決了鍵值存儲系統在多核環境裏的伸縮性難題。

圖 4

圖 5

圖 4 是在低併發狀況下，線程數與吞吐量的變化關係，其中 zipf 係數爲 0.5。圖 5 是在低併發狀況下，CPU 時間的使用狀況，其中最右邊一列表示內存佔用（MF）。

當複製係數爲 1 時，Anna 由於內存佔用率極低而得到了更好的伸縮性。不過，隨着複製係數的增長（增長到 3），吞吐量出現了明顯降低（降低了四分之三）。這裏有兩個緣由。首先，增長複製係數會佔用更多的內存，並且在低併發的狀況下，惟一鍵的更新操做大量增長，因此沒法經過合併的方式進行變動交換。圖 5 顯示，當複製係數爲 3 時，Anna 有 69% 的 CPU 時間用於處理廣播變動。而在使用完整的複製係數時，Anna 也中止了伸縮，由於此時至關於每一個線程只能處理一個請求。不過，儘管 TBB 和 Masstree 沒有廣播開銷，但在內存佔用和同步操做方面仍然存在大量開銷。所以，從這個實驗中能夠得出這樣的結論：對於一個支持多主複製的系統來講，在低併發量狀況下使用高複製係數對性能是一種傷害。

圖 6

圖 6 是在多個服務器上增長線程數時的吞吐量變化狀況。Anna 的複製係數設置爲 3，先是啓動第一臺服務器的 32 個線程，而後是第二臺服務器的 32 個線程，最後是第三臺服務器的全部剩餘線程。從圖中能夠看出，Anna 的吞吐量隨着線程數量的增長呈線性增加。在啓動第 33 個線程時吞吐量有輕微降低，不過那是由於第 33 個線程是屬於第二臺服務器的。但從總體來看，吞吐量的增加是很穩定的。可見，藉助 Anna 的無協調 actor 模型，是能夠實現吞吐量線性增加的。

與其餘系統的比較

爲對比 Anna 與其餘流行鍵值系統之間的性能差別，RISE 研究員設計了兩次實驗，第一次在單節點上與 Redis 進行對比，第二次在一個大型的分佈式系統上與 Cassandra 進行對比。

Anna 具備多線程並行能力，而 Redis 使用的是單線程模型。因此，在第一次實驗中，他們在同一臺服務器上搭建了一個 Redis 集羣，讓 Anna 與這個集羣進行比較。實驗是在 AWS 的的 EC2 實例上運行的，其中 Redis 集羣使用了儘量多的線程。

圖 7

從圖 7(a) 能夠看出，在高併發狀況下，Redis 集羣的總體吞吐量幾乎保持不變，而 Anna 能夠在副本之間分散熱鍵。Anna 的吞吐量隨着複製係數的增長而增加，直到達到平緩。若是熱鍵徹底被複制，吞吐量還會隨着線程的增長繼續增加。從圖 7(b) 能夠看出，在低併發狀況下，Anna 和 Redis 集羣都得到了不錯的並行能力，它們的吞吐量都隨着線程數的增長而增加。

從此次實驗能夠看出，在高併發狀況下，Anna 經過複製熱鍵的方式在性能方面吊打 Redis 集羣，而在低併發狀況下，Anna 能夠與 Redis 集羣達到類似的性能。

在第二次實驗中，RISE 研究員將 Cassandra 的一致性設置爲最低級別（ONE），也就是說，只要一個節點確認就表示更新操做成功。他們在 AWS 的四個 EC2 可用區域（奧爾良、北弗吉尼亞、愛爾蘭和東京）上運行該實驗，並經過調整可用區域的節點數量來評測它們的伸縮性。它們的複製係數都被設置爲 3。

圖 8

從圖 8 能夠看出，隨着節點的增長，Anna 和 Cassandra 的性能都呈現出線性增加。不過，Anna 比 Cassandra 的性能高出一大截。事實上，在每一個節點使用 4 個線程時，Anna 就能夠戰勝 Cassandra，而當把全部的線程都用上，Anna 比 Cassandra 的性能高出 10 倍以上。

參考資料：

https://rise.cs.berkeley.edu/blog/anna-kvs/?twitter=@bigdata

論文原文：

http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf

更多幹貨內容，可關注AI前線，ID：ai-front，後臺回覆「AI」、「TF」、「大數據」可得到《AI前線》系列PDF迷你書和技能圖譜。