Facebook開源時間序列內存數據庫Beringei，追求極致壓縮率——若是是int根據大多數時間序列中的值與相鄰數據點相比並無顯著的變化，只要使用XOR將當前值與先前值進行比較，而後存儲發生變化

轉自：http://www.infoq.com/cn/news/2017/02/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%。

使用場景及特色

Facebook團隊預計Beringei主要有兩種使用場合：

1. 建立一個簡單的共享服務和客戶端，後者能夠存儲和處理時間序列查詢請求。

2. Beringei能夠用做一個嵌入庫，處理高效存儲時間序列數據的底層細節。以這種方式使用Beringei相似RocksDB，Beringei有望成爲支持其餘性能監控解決方案的高性能存儲系統。

Beringei做爲庫的使用具備下列特色：

1. 支持速度很是快的內存存儲，並由硬盤保證數據持久性。存儲引擎的查詢老是在內存張處理，提供了極高的查詢性能，除非須要到磁盤查詢，不然通常不進行磁盤操做，因此能夠在停機時間極短、數據沒有丟失的狀況下重啓或遷移進程。

2. 極其高效的數據流壓縮算法。採用的數據流壓縮算法可以將實際的時間序列數據壓縮90%以上。Beringei使用的delta of delta壓縮算法也很高效，單個機器每秒就可以壓縮150多萬個數據點。

雖然將Beringei直接嵌入到另外一個TSDB裏面也是一種方案，可是Facebook更加推薦採用一體化實現方案，這種一體化實現讓用戶能夠擴建可擴展的分片服務。

1. 參考分片服務實現。Beringei項目同時包括時間序列存儲數據庫和相關的客戶端實現。

2. 可視化集成。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的原型系統。

另外，阿里雲數據庫高級專家葉翔藉着源代碼和論文，對Beringei原理進行了解讀，同時也介紹了它在Facebook的應用狀況，讀者能夠參考瞭解。