为什么分布式存储系统中获取条目计数是高成本操作？

开发者常倾向于在列表查询结果中附带条目总数，该设计虽能方便UI侧展示匹配结果的总数量，但随着列表条目规模增长超出初始预期，会带来更多额外负担。这一问题在分布式存储系统中尤为突出，这类系统本身并未针对特定查询的匹配计数快速返回做设计优化。简言之，通常不建议在标准List方法的响应中返回条目计数。
—— JJ Geewax《API Design Patterns》第102页

核心技术原因 #

• 全量扫描带来的指数级性能开销：常规分页List接口只需要扫描当前页的少量数据即可返回结果，一旦需要返回总计数，就必须对符合查询条件的全量数据做遍历扫描，数据量越大耗时增长越明显，极端场景下单次计数查询的耗时是普通分页查询的百倍以上。
• 分布式存储的设计局限性：主流分布式存储（如BigTable、Cassandra、对象存储等）为了实现弹性横向扩展，默认没有对特定过滤条件下的全局计数做优化，要获取准确计数需要跨多个分片拉取数据后聚合计算，不仅IO开销极高，还容易出现跨节点延迟导致的结果偏差。
• 计数缓存的投入产出比极低：列表数据通常增删改频率较高，总计数的缓存会频繁失效，几乎无法通过缓存降低查询压力，相当于每次请求都要重新执行一次全量计数逻辑，持续占用大量CPU、IO资源。
• 一致性难以保障：如果分页数据和总计数是分两个逻辑计算的，高并发读写场景下很容易出现「分页数据已经更新、但总计数还是旧值」的不一致问题，业务侧很难做兼容处理。
• 集群资源易被抢占：大量带计数的List请求会占用存储集群的多数资源，挤压其他正常业务的请求资源，严重时甚至会引发集群雪崩。

可用于搜索学习的关键词 #

• API列表接口设计最佳实践
• 分布式数据库count查询优化
• API分页设计模式
• 分布式系统一致性
• 面向资源的API设计

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