【论文】little table / mesa

哎呀，论文总结的愈来愈应付了，要看的太多，基本都是总结点了，合在一块儿吧。第一个是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只是浮点运算除了问题可是没有发现等等
人员交叉培训