COLDSTORE：冷数据归档存储

目标

积累下来的东西分两类：还在被读的，和”必须留着但一年读不到几次”的。第二类目前散在几台机器的本地盘上，既没有冗余，也没有校验， 它的安全性完全依赖于”没人动它”。

这个项目要给这一类数据一个明确的归属。它要满足三个条件：

便宜。 单位容量的成本必须明显低于主存储，否则归档没有意义。
可校验。 “文件还在”和”文件能读出来”必须能被区分，且校验要定期自动做。
可检索。 归档不等于失联，找到一份三年前的配置文件应当不需要人翻目录。

条带布局

上图是设计目标：每个对象切成四个数据块，加两个校验块，分布在六个节点上。 任一节点失效，剩下的五块足够重建，且重建期间不降低读取可用性—— 这是 4+2 而不是 3+1 的主要理由。

校验是主要成本，不是附带功能

纠删码只保证”块丢得起”，不保证”块是好的”。静默损坏（位翻转）对归档数据来说比节点失效更常见，所以校验排期是必做项而不是可选项：

# 季度全量校验：读一遍所有块，比对校验和
coldstore verify --scope all --report /var/log/coldstore/verify-$(date +%F).json

# 月度抽样：对最近写入的 5% 做一次
coldstore verify --scope recent --ratio 0.05

读一遍全量数据就是这个方案的代价，必须提前接受，而不是等到第一次校验时才发现它有成本。

部署

尚未部署。 上图画的是设计目标，不是现状。当前的进展是：

条带与校验的逻辑在本地验证完成，可以完整模拟一个节点失效。
节点选型未定：容量与功耗的取舍还没做决定。
与主存储之间的数据搬迁策略没有定，这一块大概率需要人工确认每一批。

已知限制

容量开销 1.5x。 4+2 的代价写在明处：六块盘只能当四块用。
不适合热数据。 纠删码的读放大意味着随机的单对象读很慢，这个项目只接归档，不接任何需要低延迟访问的数据。
写入是整条带提交的。 小文件会被合并进一个条带，读取时要先定位再解条带，这条路径的性能取决于索引表，索引表的可靠性还没有验证。