哎呀，论文总结的越来越应付了，要看的太多，基本都是总结点了，合在一起吧。第一个是little table，第二个是mesa
LittleTable: A Time-Series Database and Its Uses
（2017 cisco meraki）

### 架构

  • in-memory tablet

（balanced binary tree??）=>加入list to flush,allocat another

  • 索引全内存
  • merge table
    假设磁盘读速度是120M/s,至少要让seek时间少于1半才有收益，每次至少要读1M，因此buff的量：1000个不同tablets有1G。=》merge table(不按照timespans固定新的是旧的一半大小，就按照tablets size，把新加的和相邻的都聚合在一起)
  • 插入分4phour，7 dayps，其他pweeks聚合的方式. roll up
  • 带时间，为了保证有序，有flush dependency的tablet有向依赖图，
  • unique primary keys
    检查timestamp是否更新，primar key是否更大，否则需要去磁盘查，在查的时候其他插入到同table的先写到一个小的in-memorytable中，不阻碍这次查询，
  • lasted row
    bloom filter(duplicate kets也可以用)
  • schema 版本
    table descriptor file存当前schema，旧版的随footer。读取组合或者设置默认值
  • aggreation
    写入时聚合（rrdtool）？后台线程ageregation，选择后者，在aggregation schema变化时轻松应对，就是更灵活吧

性能

纯写内存时300M(cpu)，写入文件70M(disk)，遇到merge 40M（disk brandwidth）

Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing(google 2014)

data model

每个table有table schema 和aggregation func
updates，分钟级产生，带版本，查询所有版本前的updates聚合返回。版本会roll up。比如base 0-60, 61-70/61-80/61-90，原始61~90
rows blocks。每个block按照column调整顺序压缩，

架构

无状态（controller+update workers/compaction workers/schema chaneg workers/checksum workers）
metadata存在bigtable中
数据存在colossus中

查询：pre-fetching and cache colossus中的数据
写入：基于paxos全局的version number和version对应file的位置。version database.controller监听versions database,commiter确保所有相关tables都更新，
返回分成streaming fashion,有resume key，查询中断后切机器继续上次的resume key(查询有这么大？)

来自google的建议

分布式，并行，云计算（pre_fetch+并行来补偿colossum对于local disk的性能影响，利用云计算的性能计算），越简单性能越好。
不要做任何应用层假设（比如meta不会经常变更）。
容错，这个可能一个active的computer只是浮点运算除了问题但是没有发现等等
人员交叉培训