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

Question

我读了JJ关于API的一本叫做"API设计模式“的书，其中有一节谈到了获取项目的数量，他说这不是一个好主意，特别是在分布式存储系统中。

第102页

--其次，在清单中包含一个项目的计数常常是一种诱惑。虽然这可能对用户界面使用者显示总数量的匹配结果很好，但随着时间的推移，这常常会增加更多的麻烦，列表中的项目数量也会超过原先的预测。对于分布式存储系统来说，这尤其复杂，因为分布式存储系统不是为了快速访问计数匹配的特定查询而设计的。简而言之，在对标准List方法的响应中包含项目计数通常是个坏主意。

任何人都知道为什么会这样，或者至少给我一些关键词来搜索。

Answer 1

在一个典型的数据库中(例如，一个包含少量数据的MySQL数据库)，计算行数是相当容易的。如果这是你要处理的所有事情，那么提供一个匹配结果的计数并不是什么大问题--当事情变得更大的时候，问题就出现了。

当数量数据开始增长(例如，比如说.( 10T?)，动态计算匹配行的精确计数可能会变得非常昂贵(您必须扫描并保持所有匹配数据的运行计数)。即使使用分布式存储系统，这也可能是快速的，但仍然很昂贵。这意味着您的API将花费大量的计算资源来计算结果的总数，当它可能做其他重要的事情时。在我看来，这是一种浪费(对于API上的“好东西”来说，这是一笔很大的开销)。如果计数对API至关重要，则会更改计算。

此外，随着对数据的更改变得更频繁(更多的创建、更新和删除)，计数变得越来越不准确，因为它可能在一秒之间发生急剧变化。在这种情况下，不仅需要做更多的工作才能得出一个数字，而且这个数字甚至没有那么精确(而且可能在那个时候并不是非常有用)。

所以总的来说..。结果依赖于较大的数据集往往是：

1. Expensive
2. More‘critical
3. Inaccurate

’critical

• Inaccurate

‘.

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

但是每个API都是不同的，所以也许在API中使用计数是有意义的，尽管我仍然建议使用粗略的估计而不是精确的计数来验证API。

有一些很好的理由包括一个计数：

您的数据大小将保持相当小(即，能够由单个database).

• Result计数提供服务对于您的API至关重要(不仅"nice-to-have").

• Whatever数字对您的用例来说足够准确)(即对于小数据集或“好的估计”，而不是无用的估计)。