Facebook開源記憶體資料庫Beringei，追求極緻壓縮率

2017年2月3日，facebook宣布将開源他們的高性能時序資料存儲引擎beringer。beringei是用來解決其内部監控資料存儲和查詢需求的資料庫，其特點是讀寫速度快，屬于記憶體資料庫的一種。本文将會詳細介紹beringei的來龍去脈以及它的設計思路、應用場景和特點。

beringei的誕生背景

運維大規模的分布式服務，通常需要對内部系統的運作狀況和性能名額進行實時并精确的監控，以便在第一時間發現、診斷、處理出現的問題。

facebook使用時間序列資料庫（tsdb）跟蹤和存儲系統度量名額，比如說産品的統計資訊（每分鐘發送多少消息）、服務的統計資訊（命中緩存層與mysql層的查詢速率），以及系統的統計資訊（cpu、記憶體和網絡的使用情況）等等，基于這些資料運維人員就可以看到基礎設施上的實時負載情況，并指定政策決定如何配置設定資源。

facebook的每個系統、服務每秒需要向存儲引擎寫入成百上千個資料名額，而負責進行資料分析的工程師可以實時查詢這些資料。

2013年初，随着公司和系統的不斷發展，facebook的存儲引擎監控團隊發現hbase使用的tsdb無法靈活擴充，導緻未來可能無法處理高并發的讀取負載。如果是分析少量資料，平均讀取延遲可以接受，但是試圖實時處理大量資料的需求無法滿足，使用者體驗很差。大批量資料查詢時間可能需要數秒鐘，這對于可能需要發出數百個或數千個查詢來執行分析的自動化工具來說是不可接受的。幾千個時間序列的查詢請求要花幾十秒的時間來執行，針對稀疏資料集執行的查詢可能會逾時，這是因為hbase資料存儲經過調整後，政策改為優先處理寫入操作。

由于查詢性能太差，監控系統無法實時處理大規模分析。facebook團隊在評估和否決了幾款基于磁盤的解決方案和現有的記憶體緩存解決方案後，存儲引擎開發團隊将注意力轉移到自行編寫記憶體tsdb方案，以支援facebook的運作狀況和性能監控系統。團隊在vldb2015大會上發表了一篇名為《gorilla：一種快速、可擴充的記憶體時間序列資料庫》的文章，beringei正是基于這項工作成果的進一步發展。

beringei的設計思路

beringei基于bsd協定，它不同于其他的記憶體系統（比如memcached），beringei通過優化，支援存儲專門用于運作狀況和性能監控的時間序列資料。設計beringei的初衷是為了更高的寫入速率和更低的讀取延遲，同時盡可能高效地使用記憶體來存儲時間序列資料。facebook團隊建立了一種系統，該系統可以存儲最近24小時内在facebook生成的所有性能和監控資料，以便facebook在生産環境中遇到問題後，可以極快地探究并調試系統和服務。

資料壓縮對于幫助降低存儲開銷必不可少。facebook考慮了現有的壓縮方案，僅适用于整數資料的方法、使用近似技術的方法，以及需要對整個資料集進行操作的方法都被facebook否決了。

beringei使用一種無損耗資料流壓縮算法，壓縮時間序列裡面的資料點，不進行跨時間序列的額外壓縮。每個資料點是一對64位值，表示當時計數器的時間戳和值。時間戳和值使用前一個值的資訊單獨壓縮。時間戳壓縮使用delta-of-dalta編碼方式，通過采用規則的時間序列在較少的記憶體記憶體儲時間戳。

facebook團隊分析了存儲的性能監控系統中的資料後發現，大多數時間序列中的值與相鄰資料點相比并沒有顯著的變化。此外，許多資料源隻存儲整數（盡管系統支援浮點值）。

知道這一點後，隻要使用xor将目前值與先前值進行比較，然後存儲發生變化的比特。最終，該算法将整個資料集至少壓縮了90%。

使用場景及特點

建立一個簡單的共享服務和用戶端，後者可以存儲和處理時間序列查詢請求。

beringei可以用作一個嵌入庫，處理高效存儲時間序列資料的底層細節。以這種方式使用beringei類似rocksdb，beringei有望成為支援其他性能監控解決方案的高性能存儲系統。

beringei作為庫的使用具有下列特點：

支援速度非常快的記憶體存儲，并由硬碟保證資料持久性。存儲引擎的查詢總是在記憶體張處理，提供了極高的查詢性能，除非需要到磁盤查詢，否則一般不進行磁盤操作，是以可以在停機時間極短、資料沒有丢失的情況下重新開機或遷移程序。

極其高效的資料流壓縮算法。采用的資料流壓縮算法能夠将實際的時間序列資料壓縮90%以上。beringei使用的delta of delta壓縮算法也很高效，單個機器每秒就能夠壓縮150多萬個資料點。

雖然将beringei直接嵌入到另一個tsdb裡面也是一種方案，但是facebook更加推薦采用一體化實作方案，這種一體化實作讓使用者可以擴建可擴充的分片服務。

參考分片服務實作。beringei項目同時包括時間序列存儲資料庫和相關的用戶端實作。

可視化內建。beringei提供一種http服務實作，能夠直接與grafana內建起來，并且易于橫向擴充。

beringei需要部署在ubuntu 16.10（其餘系統未做測試），較為嚴重的問題是外部代碼依賴較多，導緻部署環境不太容易，需要依賴fbthrift、folly、wangle、proxygen、gtest、gflags。

beringei在facebook的應用

beringei目前是facebook的監控基礎設施的一部分，它可以支援針對監控系統提供的實時響應機制。beringei收到請求後，立即可以提供查詢服務，資料寫入beringei與可供使用之間的延遲大約是300微秒，facebook的p95伺服器響應讀取請求的時間大約是65微秒。相比facebook原本基于磁盤的舊引擎設計方案，beringei的記憶體系統在讀取性能方面和寫入性能方面都高出幾個數量級。此外，beringei支援與facebook的自動檢測系統配合使用，該系統觀察數百萬個時間序列，以便檢測異常、發出警報。

beringei目前存儲多達100億個唯一的時間序列，每分鐘可處理1800萬次查詢，為facebook的大部分性能和運作狀況監控任務提供支援，同時讓工程師和分析員能夠借助準确的實時資料，快速做出決策。

gorilla：beringei的原型系統

gorilla是一種快速、可擴充的記憶體時間序列資料庫，是開源的beringei的原型系統。作為監控系統，它重點趕住資料集合分析，并且認為對于發現、診斷正在發生的問題時，最近的資料點的價值要大于舊的資料點，傳統的acid不是核心内容。gorilla主要針對高可用的讀寫做了優化，故障發生時，允許丢失少量寫資料。gorilla将資料儲存至多個資料中心，但不保證資料一緻性。

為了改善效率，時間戳壓縮算法使用了delta-of-delta編碼算法，資料值采用xor進行壓縮，存儲容量壓縮了近10倍。gorilla将資料放置于記憶體中，與基于hbase的傳統資料庫存儲時間序列資料方式相比，查詢延時縮短了73倍，吞吐量提高了14倍。

2015年資料，gorilla支援80台叢集規模，提供了富用戶端解決方案，需要用戶端配合完成機房容災、異常恢複。

gorilla實際上是一套混合存儲解決方案：

in-memory解決快速寫入，提供近期快速讀取

in-ssd提供星期級别的監控資料讀取

in-sata提供曆史資料永久歸檔

另外，阿裡雲資料庫進階專家葉翔借着源代碼和論文，對beringei原理進行了解讀，同時也介紹了它在facebook的應用情況，讀者可以參考了解。

本文轉自d1net（轉載）