請參閱這份文件，瞭解如何將無伺服器應用程式擴充至每秒超過數千次作業，或數十萬名並行使用者。本文包含進階主題，可協助您深入瞭解系統。如果您才剛開始使用 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 開啟與 Cloud Firestore 的連線，並透過 Firebase SDK 呼叫
onSnapshot(collection("chatroom"))來註冊事件監聽器。這個事件監聽器可持續運作數小時。 - 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 的 sharding 演算法會嘗試將相同集合或集合群組的資料，集中在同一個異動記錄伺服器。系統會盡可能提高寫入處理量，同時盡量減少參與處理查詢的伺服器數量。
不過，某些模式仍可能導致快照監聽器行為不佳。舉例來說，如果應用程式將大部分資料儲存在一個大型集合中，監聽器可能需要連線至多個伺服器，才能接收所需的所有資料。即使套用查詢篩選器，這項規則仍適用。連線至多個伺服器會增加回應速度變慢的風險。
為避免回應速度變慢，請設計結構定義和應用程式，讓系統不必前往多個不同的伺服器，就能為監聽器提供服務。建議將資料拆成較小的集合，並降低寫入速率。
這與考量關聯式資料庫中需要完整資料表掃描的查詢效能類似。在關聯式資料庫中，需要完整資料表掃描的查詢，相當於監控高流失率集合的快照事件監聽器。與資料庫可使用更具體索引提供的查詢相比，執行速度可能較慢。如果查詢的索引更具體，就像快照監聽器監聽單一文件或不常變更的集合。您應對應用程式進行負載測試，充分瞭解用途的行為和需求。
快速執行輪詢查詢
即時查詢回應的另一個關鍵部分，是確保用於啟動資料的輪詢查詢快速且有效率。新的快照事件監聽器首次連線時，必須載入整個結果集，並傳送至使用者的裝置。查詢速度緩慢會降低應用程式的回應速度。例如嘗試讀取多份文件的查詢，或未使用適當索引的查詢。
在某些情況下，監聽器也可能從監聽狀態返回輪詢狀態。這項作業會自動執行，且不會影響 SDK 和應用程式。下列情況可能會觸發輪詢狀態：
- 系統會因負載變更而重新平衡變更記錄。
- 熱點會導致寫入資料庫失敗或延遲。
- 伺服器暫時重新啟動，會暫時影響事件監聽器。
如果輪詢查詢速度夠快，應用程式使用者就不會察覺到輪詢狀態。
優先使用長效事件監聽器
開啟監聽器並盡可能保持運作，通常是建構使用 Cloud Firestore 的應用程式時，最具成本效益的方法。使用 Cloud Firestore 時，系統會根據傳回應用程式的文件數量計費，而非根據維持連線的時間計費。長期存在的快照監聽器，只會讀取在生命週期內提供查詢所需的資料。這包括初始輪詢作業，以及資料實際變更時的通知。另一方面，單次查詢會重新讀取資料，但這些資料自應用程式上次執行查詢以來可能未曾變更。
如果應用程式必須耗用大量資料，則可能不適合使用快照監聽器。舉例來說，如果您的用途是長時間透過連線每秒推送多份文件，建議您選擇執行頻率較低的一次性查詢。
後續步驟
- 瞭解如何使用快照事件監聽器。
- 進一步瞭解其他最佳做法。