與查詢結果集的規模的增加，而不是你的數據集的大小

它還允許表現查詢。查詢按照您的結果集大小爲進行縮放，而不是數據集的大小，因此您將獲得相同的性能，從一組100或100,000,000中獲取1個結果。

此聲明並不適用於我。你能稍微解釋一下這個用例嗎？

2017-10-06 Sampath

這可能會寫得有點混亂。它並不是傳統意義上的用例，它只是關於Firestore性能的一個聲明。

它基本上說，如果你從100.000.000中的100個或1個項目中請求1個項目並不重要，它將同樣快。這裏1是你的結果集和100/100.000.000是你的數據集。因此，要求100.000.000中的1項將比請求100項中的50項要快。

我希望這可以使它更清晰一些！

2017-10-06 12:18:07 David

這部分是確定的。但是這個「查詢與結果集的大小成比例，而不是數據集的大小」呢？ – Sampath

這就是我最後一句話應該解釋的。如果您請求更多項目（結果集），那麼您的查詢會變得更加昂貴，但如果有更大的數據集可用，則不會。只要您總是請求相同數量的項目，無論您的數據集有多大，查詢總是同樣具有高性能。 – David

這裏

在大多數數據庫（包括火力地堡自己的實時數據庫）firebaser，查詢性能取決於你要求的項目數量和你要求從項目集合的大小的組合。

所以：

預期＃1的性能差異，單靠數據傳輸是一件難以忘記的事情。由於＃2取決於服務器端處理，開發者有時會忘記＃2。許多關係數據庫管理系統的優化非常好，意味着性能差異往往是對數性能差異。但是具有足夠大的收藏尺寸，即使log(n)的表現也會變得明顯。

雲公司的FireStore水平縮放，這意味着規則＃2從上面不適：

這是因爲Firestore查詢系統的設計方式。儘管您可能無法將每個查詢從關係數據模型直接建模到Firestore數據模型，但是如果您可以根據Firestore查詢定義您的用例，則它將保證在相對於你要求的結果。（在此解釋Gil的評論）

2017-10-06 14:29:51

另一種說法是，Firestore查詢旨在避免服務器上的額外工作。其他數據庫系統，尤其是基於SQL的數據庫系統允許更復雜的查詢，但可能會導致查詢爆炸並且性能會下降。這個陳述是一種承諾：如果您可以表達查詢，Firestore只會按照結果集的大小進行工作。 –

好吉爾。我在我的回答中添加了一段來解釋。 –

回答