【論文】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。