查询的规模随着结果集的大小而变化，而不是数据集的大小。
查询的规模随着结果集的大小而变化，而不是数据集的大小。
这是一个关于最新的Firebase Cloud Firestore的问题。在这篇文档中，它描述如下：
它还允许使用表达性查询。查询的性能与结果集的大小相关，而不是数据集的大小，因此从100个或1亿个结果集中获取1个结果的性能是相同的。
这个陈述对我来说不够清晰。你能再详细解释一下这个用例吗？
Firestore的性能与结果集的大小相关，而与数据集的大小无关。这个问题的出现是因为在使用Firestore时，不管是从100个数据中请求1个数据，还是从1亿个数据中请求1个数据，速度都是相同的。这里的1代表结果集，而100或1亿代表数据集。因此，从1亿个数据中请求1个数据要比从100个数据中请求50个数据更快。
希望这样更清楚一些！
好了，那么这个Queries scale with the size of your result set, not the size of your data set是什么意思呢？
这就是我上一句话要解释的。如果你请求的数据越多（结果集），查询的代价就会越高，但如果可用的数据集更大，并不会导致查询变得更耗时。只要你始终请求相同数量的数据，不管数据集有多大，查询的性能始终是相同的。
在大多数数据库中（包括Firebase的实时数据库），查询性能取决于您请求的项数和您请求的集合的大小的组合。
所以在大多数数据库中：
1. 如果您从100万个项中请求10个项，那么比起从100万个项中请求1000个项，速度会更快。
2. 如果您从1亿个项中请求10个项，那么比起从100万个项中请求10个项，速度会更快。
第一种情况的性能差异是可以预期的，单单数据传输本身就是一件难以忽视的事情。由于第二种情况取决于服务器端的处理，开发者有时会忽略第二种情况。许多关系型数据库管理系统（DBMS）具有良好的优化性能，这意味着性能差异通常是一个对数性能差异。但是对于足够大的集合大小，即使是对数性能差异也会明显可见。
Cloud Firestore采用横向扩展的方式，因此不适用于上述规则第二条：
- 如果您从100万个项中请求10个项，所花费的时间与从1亿个项中请求10个项所花费的时间相同。
这是因为Firestore的查询系统的设计方式。虽然您可能无法直接将每个查询从关系数据模型直接建模到Firestore数据模型中，但是如果您可以将您的用例定义为一个Firestore查询，它将保证只执行与您请求的结果数量相关的时间。（引用对Gil的评论的改述）
换句话说，Firestore的查询设计旨在避免服务器上的多余工作。其他数据库系统，特别是基于SQL的系统，允许执行更复杂的查询，但可能会导致查询崩溃并且性能下降。这个说法是一种承诺：如果您能够表达查询，Firestore只会执行与结果集大小成比例的工作量。
非常好的解释，Gil。我在我的回答中添加了一个段落来解释这一点。