共计 1470 个字符，预计需要花费 4 分钟才能阅读完成。
哎呀，论文总结的越来越应付了，要看的太多，基本都是总结点了，合在一起吧。第一个是 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 只是浮点运算除了问题但是没有发现等等
人员交叉培训
