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

性能结果

略