乐趣区

论文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 只是浮点运算除了问题但是没有发现等等
人员交叉培训

退出移动版