api - 为什么在分布式存储中获取项目计数是一项昂贵的操作？

Question

我正在阅读 JJ Geewax 的那本关于 API 的书，称为“API 设计模式”，其中有一节谈到了获取项目的数量，他说这不是一个好主意，尤其是在分布式存储系统中。

第 102 页

接下来，通常会在列表中包含项目的数量。虽然这对于用户界面消费者来说可能很好地显示匹配结果的总数，但随着时间的推移，它通常会增加更多的麻烦，并且列表中的项目数量会超出最初的预期。这对于并非旨在提供对匹配特定查询的计数的快速访问而设计的分布式存储系统尤其复杂。简而言之，在对标准 List 方法的响应中包含项目计数通常是一个坏主意。

任何人都知道为什么会这样，或者至少给了我要搜索的关键字。

标签： apidistributeddistributed-system

Answer 1

在一个典型的数据库中（例如，一个 MySQL 数据库，里面有一些数据），计算行数非常容易。如果这就是您要处理的全部内容，那么提供匹配结果的计数并不是什么大不了的事——当事情变得更大时，就会出现问题。

随着数据量开始增长（例如... 10T？），动态计算匹配行的准确计数可能会开始变得非常昂贵（您必须扫描并保持所有匹配数据的运行计数）。即使使用分布式存储系统，这也可能很快，但仍然很昂贵。这意味着您的 API 将花费大量计算资源来计算结果总数，而它可能会做其他重要的事情。在我看来，这是一种浪费（对于 API 上的“不错”来说，这是一笔巨大的开支）。如果计数对 API 至关重要，那么这会改变计算。

此外，随着对数据的更改变得更加频繁（更多的创建、更新和删除），计数变得越来越不准确，因为它可能会从一秒到下一秒发生巨大变化。在这种情况下，不仅需要做更多的工作来得出一个数字，而且这个数字甚至都不是那么准确（并且可能在那时并不是超级有用）。

所以总的来说......更大数据集的结果计数往往是：

1. 昂贵的
2. 比业务关键更值得拥有
3. 不准确

而且由于 API 的寿命往往比我们预期的要长得多，并且可以增长到比我们想象的要大得多的规模，我不鼓励在 API 响应中包含结果计数。

虽然每个 API 都不同，所以在你的 API 中计数可能是有意义的，尽管我仍然建议使用粗略的估计而不是精确的计数来保证 API 的未来发展。

包含计数的一些充分理由：

1. 您的数据大小将保持相当小（即，能够由单个 MySQL 数据库提供服务）。
2. 结果计数对您的 API 至关重要（不仅仅是“不错”）。
3. 无论您想出什么数字，对于您的用例来说都足够准确（即，小数据集的准确数字或“良好估计”，而不是无用的估计）。