查询随结果集的大小而不是数据集的大小而缩放答案

【问题标题】：Queries scale with the size of your result set, not the size of your data set查询随结果集的大小而不是数据集的大小而缩放
【发布时间】：2018-03-18 02:39:13
【问题描述】：

这是一个关于最新Firebase Cloud Firestore的问题。在这个文档中它是这样说的：

它还允许表达查询。查询规模与大小你的结果集，而不是你的数据集的大小，所以你会得到相同的从一组 100 个或 100,000,000 个结果中提取 1 个结果的性能。

这个陈述对我来说不是很清楚。你能稍微解释一下这个用例吗？

【问题讨论】：

标签： angular firebase ionic3 google-cloud-firestore

【解决方案1】：

这可能写得有点混乱。它不是经典意义上的用例，它只是关于 Firestore 性能的陈述。

它基本上说，如果您请求 100 件中的 1 件或 100.000.000 件中的 1 件，它都一样快。这里 1 是您的结果集，而 100/100.000.000 是您的数据集。因此，从 100.000.000 中请求 1 项将比从 100 项中请求 50 项更快。

我希望这能让它更清楚一点！

【讨论】：

那部分没问题。但是这个Queries scale with the size of your result set, not the size of your data set呢？
这就是我最后一句话应该解释的。如果您请求更多项目（结果集），您的查询会变得更加昂贵，但如果有更大的数据集可用，则不会。只要您始终请求相同数量的项目，无论您的数据集有多大，查询的性能都将始终相同。

【解决方案2】：

firebaser 在这里

在大多数数据库（包括 Firebase 自己的实时数据库）中，查询性能取决于您请求的项目数量和您从其中请求项目的集合的大小。

所以：

如果您请求 100 万件商品中的 10 件商品，这将比您从 100 万件商品中请求 1000 件商品要快。
如果您请求 100 万件商品中的 10 件商品，这将比您从 1 亿件商品中请求 10 件商品要快。

#1 的性能差异是意料之中的，仅数据传输就很难忘记。由于#2 依赖于服务器端处理，开发人员有时会忘记#2。许多关系型 DBMS 优化得非常好，这意味着性能差异通常是对数的性能差异。但是，如果集合大小足够大，即使 log(n) 的性能也会很显着。

Cloud Firestore 水平扩展，这意味着上面的规则 #2 不适用：

如果您请求 100 万件商品中的 10 件商品，则所需的时间与请求 1 亿件商品中的 10 件商品所用的时间相同。

这是因为 Firestore 的查询系统的设计方式。虽然您可能无法将每个查询直接从关系数据模型建模到 Firestore 数据模型，但如果您可以根据 Firestore 查询定义用例，则可以保证在仅相对于您要求的结果。（在这里转述吉尔的评论）

【讨论】：

另一种说法是，Firestore 查询旨在避免服务器上的过多工作。其他数据库系统，尤其是基于 SQL 的数据库系统，允许更复杂的查询，但可能会导致查询崩溃并且性能下降。该声明是一种承诺：如果您可以表达查询，Firestore 将仅按与结果集大小成比例的方式工作。
好一个吉尔。我在答案中添加了一段来解释。