【論文】BtrDB:Design for Timeseried Processing

BtrDB:Optimizing Storage System Design for Timeseried Processing

• 應用場景：
  適用於 telemetry time-correlated data 。數據可亂序和重複
• 背景
  druid等專一於複雜多維度數據，樣本量相對於監控數據少的場景，讀寫1mps如下，精度1ms，只能有序追加；cassandra 吞吐量遠小於1ms。以上精度和吞吐不能同時知足。Gorilla(facebook內存數據庫)和BTRDB性能接近，但s精度且不能亂序。
• 核心技術點
  time-partitioning,multi-resolution,version-annotated,copy-on-write tree
• 提供核心指標
  高精度（ns），高樣本吞吐。 53Mps插入，2.9x壓縮率一年數據分析查詢 <200ms
• 缺點
  不支持跨分佈式樣本聚合

數據抽象

uuid
version：這裏是延時數據會對舊數據作更改，但扔提供就查詢一致性。每一個新插入都是一個新version
k:2^resolution

copy-on-write：這個是說不須要鎖，新插入單首創建樹節點，舊數據不變，
version-annotated：若是下層節點有多個version，上層用最大的version。
預聚合
聚合非IO，寫磁盤時須要依賴下一層的地址返回，中間節點是對存儲的浪費。

系統設計

架構：seda。（分階段觸發，解耦，可異步並行，去鎖，隊列+線程池+處理事件+觸發下一階段）
請求階段：讀相對寫不多，單線程，寫用session managers控制流量，分發到線程隊列，累積超時或16kponits後觸發寫階段。
寫階段：對寫入數據進行線段樹的聚合（從free pool中獲取mem），構造時臨時地址，
block在落盤前有壓縮和chache,
壓縮 由於傳統的delta coding是對每一個value計算差別，但ns時間value太長了，對於noise也不友好，delta-delta根據上一個窗口的平均delta values和如今的差別，基於huffman coding using a fixed tree.
每層依賴下一層地址，在正常落盤數據須要把mem的地址轉爲真的無力地址，爲了儘可能不阻塞，提早分配free addr,
root map，記錄uuid_version對應存儲的地址。用mongodb（由於這部分數據和正常的時序數據差別太大了）

性能結果

略