請參閱本文件，瞭解如何擴充無伺服器應用程式，擴充至每秒數千項作業，或擴充至數十萬個並行使用者。本文提供進階主題，可協助您深入瞭解系統。如果您剛開始使用 Cloud Firestore，請改為參閱快速入門指南。
Cloud Firestore 和 Firebase 行動裝置/網路 SDK 針對開發無伺服器應用程式提供了強大的模型，其中用戶端程式碼可直接存取資料庫。SDK 可讓用戶端即時監聽資料更新。您可以使用即時更新功能建構不需要伺服器基礎架構的回應式應用程式。雖然啟動及執行項目非常簡單，但瞭解組成 Cloud Firestore 的系統限制相當有幫助，這樣您的無伺服器應用程式就能在流量增加時調度資源並順利運作。
如需擴充應用程式的建議，請參閱以下各節。
選擇靠近使用者的資料庫位置
下圖說明即時應用程式的架構：
在使用者裝置 (行動或網頁) 上執行的應用程式與 Cloud Firestore 建立連線時，系統會將連線轉送至資料庫位於相同區域的 Cloud Firestore 前端伺服器。舉例來說，如果您的資料庫位於 us-east1，則連線也會連至位於 us-east1 的 Cloud Firestore 前端。這些連線效期很長，會保持開啟狀態，直到應用程式明確關閉為止。前端會從基礎 Cloud Firestore 儲存系統讀取資料。
使用者實體位置與 Cloud Firestore 資料庫位置之間的距離會影響使用者經歷的延遲時間。舉例來說，如果印度使用者的應用程式與位於北美洲 Google Cloud 區域的資料庫通訊，則相較於改用較靠近資料庫 (例如在印度或其他亞洲地區)，應用程式速度較慢，應用程式也較不流暢。
將可靠性納入設計考量
以下主題可以改善或影響應用程式的可靠性：
啟用離線模式
Firebase SDK 提供離線資料持續性。如果使用者裝置上的應用程式無法連線到 Cloud Firestore，則可使用本機快取資料，繼續使用該應用程式。如此一來，即使使用者遇到網際網路連線不穩，或會因為數小時或數天而完全失去存取權，也能夠存取資料。如要進一步瞭解離線模式，請參閱「啟用離線資料」。
瞭解自動重試
Firebase SDK 會負責重試作業並重新建立中斷的連線。這樣可解決因重新啟動伺服器或用戶端與資料庫之間的網路問題而造成的暫時性錯誤。
選擇區域或多區域位置
選擇單一區域或多地區位置時，需要權衡優缺點。主要差異在於資料的複製方式。這使得應用程式的可用性保證提高。多地區執行個體可提高提供穩定性和資料的耐用性，但權衡需要取捨。
瞭解即時查詢系統
即時查詢 (也稱為快照事件監聽器)，可讓應用程式監聽資料庫中的變更，並在資料變更時立即取得低延遲通知。應用程式可定期輪詢資料庫來進行更新，取得相同結果，但通常速度較慢、成本較高，且需要更多程式碼。如需瞭解如何設定和使用即時查詢的範例，請參閱「取得即時更新」。以下各節將詳細介紹快照事件監聽器的運作方式，並說明在維持效能的情況下擴充即時查詢的部分最佳做法。
想像一下，兩位使用者透過其中一個行動 SDK 建構的訊息應用程式連線至 Cloud Firestore。
用戶端 A 寫入資料庫，以便在名為 chatroom 的集合中新增和更新文件：
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
用戶端 B 使用快照事件監聽器，在相同的集合中監聽更新。 每當有人建立新訊息時，用戶端 B 會立即收到通知。 下圖顯示快照事件監聽器背後的架構：
用戶端 B 將快照事件監聽器連線至資料庫時，會發生下列事件順序：
- 用戶端 B 透過 Firebase SDK 呼叫
onSnapshot(collection("chatroom"))來開啟 Cloud Firestore 連線，並註冊事件監聽器。這個事件監聽器可持續數小時。 - Cloud Firestore 前端會查詢基礎儲存系統來啟動資料集。它會載入整個相符文件的結果集。我們稱這種情況為「輪詢查詢」。接著，系統會評估資料庫的 Firebase 安全性規則，確認使用者是否可存取這類資料。如果使用者獲得授權，資料庫就會將資料傳回給使用者。
- 接著，用戶端 B 的查詢會進入「聆聽模式」。事件監聽器會註冊訂閱處理常式，並等待資料更新。
- 用戶端 A 現在會傳送寫入作業來修改文件。
- 資料庫會將文件變更提交至其儲存系統。
- 在交易過程中，系統會將相同的更新提交至內部變更記錄。變更記錄會在變更發生時以嚴格的順序排列。
- 變更記錄會將更新的資料擴散給一組訂閱處理常式。
- 系統會執行「反向查詢比對工具」，檢查更新後的文件是否與任何目前註冊的快照事件監聽器相符。在此範例中，文件符合用戶端 B 快照事件監聽器。顧名思義，您可以將反向查詢比對器視為一般資料庫查詢，但會以反向的方式執行。與其搜尋文件來找出與查詢相符的內容，前者可以有效率地透過查詢進行搜尋，找出與傳入文件相符的項目。找到相符項目時，系統會將相關文件轉送至快照事件監聽器。接著系統會評估資料庫的 Firebase 安全性規則，確保只有獲得授權的使用者會收到資料。
- 系統會將文件更新轉送至用戶端 B 裝置上的 SDK，進而觸發
onSnapshot回呼。如果啟用了本機永久保存功能，SDK 也會將更新套用至本機快取。
Cloud Firestore 擴充性的關鍵部分取決於從變更記錄排出、訂閱處理常式和前端伺服器。擴散功能可讓單一資料變更有效率地傳播，以便為數百萬個即時查詢和已連結的使用者提供服務。藉由在多個區域 (或多區域部署的情況下) 的多個地區執行所有這些元件的許多備用資源，Cloud Firestore 就能實現高可用性和擴充性。
值得注意的是，從行動裝置和網頁 SDK 發出的所有讀取作業都會遵循上述模型。藉由執行輪詢查詢，接著使用監聽模式來維持一致性保證。這也適用於即時事件監聽器、用來擷取文件的呼叫，以及單一查詢。您可以將單一文件擷取和單一查詢視為短期快照事件監聽器，這些監聽器也有類似的效能限制。
運用最佳做法處理即時查詢
運用下列最佳做法設計可擴充的即時查詢。
瞭解系統中高寫入流量
本節有助於瞭解系統如何回應與日俱增的寫入要求。
驅動即時查詢的 Cloud Firestore 變更記錄會在寫入流量增加時自動水平調度資源。隨著資料庫的寫入速率增加，超過單一伺服器能夠處理的量，變更記錄會拆分到多個伺服器，而查詢處理程序也會開始從多個訂閱處理常式 (而非單一處理常式) 取得資料。從用戶端和 SDK 的角度來看，這全部都是透明狀態，而且在進行分割時不需要在應用程式中採取任何行動。下圖說明即時查詢如何調度資源：
自動調整資源配置功能可讓您在不限制的情況下提高寫入流量，但隨著流量增加，系統可能需要一段時間才能回應。請遵循 5 至 5 至 5 規則的建議，以免建立寫入無線基地台。Key Visualizer 可用於分析寫入熱點，
許多應用程式都有可預測的自然成長，Cloud Firestore 則可在毫無預防措施的情況下派上用場。不過，批次工作負載 (例如匯入大型資料集) 可能會導致寫入速度過快。設計應用程式時，請留意寫入流量的來源。
瞭解寫入與讀取如何互動
您可以將即時查詢系統視為與讀取者連結寫入作業的管道。每次建立、更新或刪除文件時，變更就會從儲存系統傳播到目前註冊的監聽器。Cloud Firestore 的變更記錄結構可保證同步一致性，也就是說，與資料庫提交資料變更的時間相比，應用程式絕對不會收到順序異常的更新通知。這能夠移除與資料一致性有關的邊緣案例，藉此簡化應用程式開發作業。
此連線的管道意味著導致資源使用率不均或鎖定爭用的寫入作業可能會對讀取作業造成負面影響。當寫入作業失敗或發生節流問題時，讀取作業可能會停滯，等待變更記錄中的資料保持一致。如果應用程式發生這種情形，您可能會看到寫入作業速度緩慢，以及查詢的回應時間緩慢。避免資源使用率不均是避免這個問題的關鍵。
精簡文件和寫入作業
使用快照事件監聽器建構應用程式時，通常會希望使用者能快速瞭解資料異動。為了達到這個目標，請試著保持精簡。系統可以很快地透過系統推送含有數十個欄位的小型文件。大型文件含有數百個欄位和大型資料，處理時間會較長。
同樣地，請盡量使用簡短、快速的修訂和寫入作業來縮短延遲時間。大型批次可從寫入者的角度取得較高的處理量，但實際上可能會增加快照事件監聽器的通知時間。相較於使用批次處理來改善效能的其他資料庫系統，這通常不符合直覺。
使用有效率的事件監聽器
隨著資料庫的寫入速率增加，Cloud Firestore 會將資料處理範圍拆分到許多伺服器。Cloud Firestore 的資料分割演算法會嘗試將來自相同集合或集合群組的資料，置於同一個變更記錄伺服器。系統會嘗試盡可能提高寫入總處理量，同時盡可能減少與查詢處理相關的伺服器數量。
不過，特定模式仍可能導致快照監聽器的效能不佳。舉例來說，如果應用程式將大部分資料儲存在一個大型集合中，事件監聽器可能需要連線至多個伺服器，才能接收所需的所有資料。即使套用查詢篩選器也是如此。連線至多個伺服器會增加回應速度較慢的風險。
為了避免回應速度較慢，請設計結構定義和應用程式，讓系統能夠在不前往多個不同伺服器的情況下提供事件監聽器。最好的方式是將資料拆分為寫入速率較小的集合。
這類似於考量需要完整掃描資料表的關聯資料庫中的效能查詢。在關聯資料庫中，需要完整掃描資料表的查詢，相當於監看大量流失集合的快照事件監聽器。相較於資料庫可以使用更明確索引的查詢，查詢執行速度可能會比較慢。具有特定索引的查詢，就如同快照監聽器，能監控單一文件或較不常變更的集合。您應載入測試應用程式，以便進一步瞭解用途和用途需求。
加快輪詢查詢作業
回應式即時查詢的另一個關鍵部分，在於確保輪詢查詢能夠快速且高效率地啟動資料。當新的快照事件監聽器首次連線時，事件監聽器必須載入整個結果集，並將結果傳送至使用者的裝置。緩慢查詢會使應用程式的回應速度變慢。這包括嘗試讀取許多文件或查詢，卻未使用適當索引的查詢。
在某些情況下，事件監聽器也可能會從監聽狀態移回輪詢狀態。這種情況會自動發生，且對 SDK 和應用程式公開透明。下列情況可能會觸發輪詢狀態：
- 系統因負載變更而重新平衡變更記錄。
- 無線基地台會導致資料庫寫入失敗或延遲。
- 暫時的伺服器重新啟動會暫時影響事件監聽器。
如果您的輪詢查詢速度夠快，輪詢狀態就會對應用程式使用者公開。
喜歡長效型聽眾
想要建構使用 Cloud Firestore 的應用程式，開啟並保持監聽器的持續時間，往往是最符合成本效益的方法。使用 Cloud Firestore 時，您必須為傳回應用程式的文件支付費用，而非維持開放連線。長期快照監聽器只會讀取處理查詢作業所需的資料。這包含初始輪詢作業，隨後在資料實際變更時發出通知。另一方面，單一查詢會重新讀取自應用程式上次執行查詢後，可能不會變更的資料。
如果應用程式必須耗用大量資料，快照事件監聽器可能就不適用。例如，如果您的用途需要長時間透過連線每秒推送多份文件，則建議選擇以較低的頻率執行單一查詢。
後續步驟
- 瞭解如何使用快照事件監聽器。
- 進一步瞭解最佳做法。