【论文】chronicleDB-2017

这个对读写性能要求都高（so，竟然和以前想的一样，如果读写要都高，要用B-TREE类似的，SLM只对写友好，不过应用场景有这么大差异吗，gorrila对读的性能要求巨高吞吐和我们一样，这个对读写的吞吐要求一样，在线业务？我们的读很少）。文章中的索引比较新，不过我没研究，基本论文里写啥这里总结了啥，其他的用到的再去看

第二章 背景对比

datastore:datadepot;nosql:cassandra,hbase.性能不行
写log的KV :logbase base on hdfs,index B+tree,key/timestamp,in-memory multi-version。性能低100倍
时序库:tsdb(假设数据在every tick到来，就是有空洞的树)，gorrilla（main-memory,hbase，对query速度要求太高）,opentsdb,kairosdb(基于hbase,cassandra）。定位于influxdb，比他性能好。
索引：SB-tree，CR-index

 TAB+-tree（二级索引只有一个，对写影响低，高峰期不写二级索引）

这个时间是application time，不是自己带好时间的，假设：只insert和delete一次，no update，支持乱序。

架构

event queue:聚合/对乱序补偿
work:写磁盘
对读写要求都高，压缩后的数据大小不确定，需要地址映射，logicalIDs,映射到物理地址，与数据存到一起，否则需要多一次随机写，Logicalblock大小固定，=》C-block，压缩更好的是列，读写更好的是行，一行的在一个L-block，一个L-block中的按列压缩，C-blocks组合为一个macro block,固定物理大小，是保证磁盘院子操作的最小单位，是L-Block的倍数，乱序会导致V-block的大小变化，采用预留空闲方式。
映射：id->(mbc,pc),id是连续整数，不用存，CSB+-tree。缓存和可计算。夸多个macro读取需要random，需要下一个预期的缓存。

index

这个和我们不一样的是，类似mysql的结构，索引指向全部数据，修改直接更改数据，不是SLM，index非常重要。
有个时间相关度的概念，当前时间差，能看出来当前负载
TAB+-tree，元素（max,in,sum|……|count）
二级索引用的只写SLM类似的，但是，用的是COLA+bloom filter。在高峰期不写
乱序保存在单独的sorted queue，写入WAL，不直接到TAB-tree中，
保持二级索引一致性：二级索引在split时，有标识，直接取读primary index

recovery

先恢复地址映射，TLB增加前后索引，从最后一个向前恢复
恢复TAB-tree。从后-》前兄弟-》parent到root
对log里的乱序数据恢复，直接改TAB-tree,

性能

读1.7M，写1.1M。