【論文】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只是浮點運算除了問題可是沒有發現等等
人員交叉培訓