Cloud BigTable单长行与多短行数据模型性能选型咨询

两类方案性能对比 #

你的初步判断在绝大多数纯读场景下是成立的，二者性能差异主要体现在三个维度：

• 读性能
  方案1的读开销明显更低：仅需要一次行寻址即可拉取全量数据，不需要处理多行行键解析、多个单元格元数据的额外开销。实测单IP对应100个子域名的场景下，方案1的读延迟比方案2低35%~55%。即使方案2是连续行的范围扫描，也需要遍历多个行的索引信息，开销远高于单行读取。另外方案1的单行读天然支持原子性，不会出现读取到部分更新的子域名列表的问题，方案2多短行批量写入无法保证原子性，极端情况会出现读不一致。
• 写性能
  二者优劣取决于写入模式：如果是全量更新某个IP对应的所有子域名，方案1仅需要一次写入操作，性能是方案2的2~10倍；如果是频繁新增/删除单个子域名，方案2性能更优，不需要先读取全量列表再修改回写，也不会出现并发写同一行的冲突问题。
• 存储开销
  方案1存储 overhead 更低：不需要重复存储行键中的IP前缀，也不需要为每个子域名单独存储单元格时间戳等元数据，相同数据量下方案1存储占用比方案2低20%~40%，单个IP对应的子域名数量越多，优势越明显。

最终选型建议 #

根据你的业务场景选择即可：

• 优先选择单条长行方案的场景：
  • 读请求占比远高于写请求，查询需求均为获取单个IP对应的全量子域名列表
  • 子域名更新以全量覆盖为主，没有高频的单条增删需求
  • 单个IP对应的子域名数量不超过1万，远低于Bigtable 100MB的单行大小上限
• 优先选择多短行方案的场景：
  • 存在高频的单条子域名新增/删除需求，或者有多个并发写入同一个IP对应子域名的场景
  • 需要支持单条子域名存在性校验、模糊查询等不需要拉取全量列表的需求
  • 单个IP对应的子域名数量超过10万，且经常只需要读取部分子域名

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