【论文】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（因为这部分数据和正常的时序数据差异太大了）

性能结果

略