Pinterest從OpenTSDB切換到他們自己的時間序列資料庫

從2014年開始，Pinterest工程團隊就一直使用ofollow,noindex" target="_blank">OpenTSDB 儲存和查詢指標。由於指標資料量的增長導致了各種效能問題，所以他們使用C++開發了自己的時間序列資料庫Goku ，並且相容OpenTSDB API。

Pinterest開發團隊使用一個名為Statsboard的系統——這是一個儀表板，使用YAML中的宣告式配置集成了來自Graphite、Ganglia 和OpenTSDB的指標。早在2012年，Pinterest的監控使用了Ganglia，它只收集系統指標而不收集任何應用程式指標。那年年底，他們部署了Graphite 以及statsd，用於收集應用程式指標，然後部署了一個Graphite叢集。2014年，他們部署了OpenTSDB以及一個自定義指標代理，把資料推送到Kafka叢集，然後從那裡通過一個處理管道推送到OpenTSDB和Graphite 。幾年前，他們在OpenTSDB中已經達到了每秒150萬點的吞吐量。Pinterest的團隊面臨著Java垃圾收集問題以及HBase頻繁崩潰，OpenTSDB把它作為後端儲存。這裡有一點需要注意，Pinterest有一個規模很大的HBase部署 ，供他們的許多服務使用。

他們自主開發的時間序列資料庫引擎Goku試圖改進OpenTSDB中的某些具體方面，其中包括使用一個反向索引代替HBase掃描、更好的資料點壓縮、叢集聚合查詢以及更快的序列化格式。Goku使用Facebook Gorilla 記憶體儲存引擎儲存最新資料，持久儲存在NFS上。Pinterest託管在EC2上 ，但是，文中並沒有清楚說明，他們是否使用了AWS EFS或自託管解決方案。作者提到，Goku會在重新啟動時把資料從磁碟讀回到記憶體中。

Goku的查詢模型和OpenTSDB的完全一樣。其團隊編寫了自己的查詢聚合層，向分片扇出查詢或聚合分片查詢。Goku使用了一種兩層分片策略——基於指標名稱，然後是標籤鍵-值對。這些查詢由Goku代理處理，它會把查詢傳送給單個的Goku分片。這些分片使用反向索引取得請求的時間序列的ID，並獲取資料，執行單個的聚合器（下采樣、求和等），然後發回代理。該代理會在第二輪聚合之後把它發給客戶端。Goku的另一項改進是使用Apache Thrift的二進位制資料型別 代替了OpenTSDB的JSON格式。

Pinterest使用Goku降低了延遲、資源需求以及資料集規模。Goku是用C++編寫的，相容OpenTSDB API 。Goku和Pinterest另外一個名為Yuvi 的專案非常類似，那個專案是用Java編寫的。其他工程團隊也編寫或定製了他們自己的時間序列指標集和查詢系統，包括Vivint、Uber 、Improbable 和Criteo 。

檢視英文原文：Pinterest Switches From OpenTSDB to Their Own Time Series Database