为何Cloud Bigtable会存在单节点存储限制？

核心疑问 #

Google Cloud Bigtable的数据存储在Colossus分布式文件系统，文档也明确节点仅保存tablet的指针，那为什么单节点会有5TB（SSD集群）/16TB（HDD集群）的存储限制？能不能用单节点访问100TB冷数据？这个限制是不是和节点缓存有关？

答案解析 #

这个限制和Colossus的存储能力无关，核心是Bigtable节点的tablet管理与后台维护的资源开销：

1. 节点不只是"请求转发器"
   虽然数据存在Colossus，但Bigtable节点要承担多项核心工作：

   • 管理分配给自己的所有tablet的元数据（包括索引、版本、位置、状态等）
   • 处理读写请求的逻辑转换（比如行键到tablet的映射、事务处理、版本控制）
   • 执行后台维护任务：tablet的分裂/合并、过期数据清理、数据压缩、副本同步、Colossus文件碎片整理等

2. 数据量→tablet数量→资源开销的连锁反应
   Bigtable的tablet默认大小在10GB-100GB区间，数据量越大，集群内的tablet总数就越多。每个tablet无论冷热，节点都要持续维护其元数据，并执行必要的后台扫描任务。当单节点关联的tablet对应总数据量超过阈值时：

   • 节点CPU会被tablet管理和后台任务占满，无法及时处理用户读写请求，导致延迟飙升
   • 极端情况下，节点会因资源耗尽无法完成必要维护操作，触发Bigtable的保护机制，直接禁止所有写入操作

3. 冷数据的误区
   冷数据访问频率低，但对应的tablet依然需要节点管理，后台维护任务（比如定期清理过期数据、同步元数据）不会因数据冷而停止。哪怕只有少量读写请求，超过存储限制后，节点资源还是会被维护任务耗尽，最终触发写入失败。

4. 单节点能否访问100TB数据？
   不行。只要集群数据量超过单节点的存储硬限制，Bigtable就会触发保护机制，禁止该实例下所有集群的写入，直到添加足够节点分摊tablet管理负载。

5. 与节点缓存无关
   节点的缓存（如Block Cache）仅用于加速热点数据读取，缓存容量不足只会影响热点数据的读取延迟，不会触发存储限制的硬规则。这个限制完全基于节点管理tablet的CPU、内存资源上限设定。

内容的提问来源于stack exchange，提问作者stoper