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的應用情況，讀者可以參考了解。