大規模瞭解即時查詢

閱讀這份文件，瞭解如何擴充無伺服器應用程式的規模，將規模擴展至數千個 每秒可執行的作業數量或數十萬 並行使用者比例這份文件包含進階主題，可協助您 您會深入瞭解這套系統如果您剛開始使用 Cloud Firestore，請改為參閱快速入門指南。

Cloud Firestore 和 Firebase 行動版/網頁 SDK 提供強大的模型 開發無伺服器應用程式，在用戶端程式碼直接存取 資料庫SDK 可讓用戶端即時監聽資料更新。個人中心 可使用即時更新功能打造不需要伺服器的回應式應用程式 基礎架構雖然設定和執行非常容易，但 瞭解 Cloud Firestore 的組成系統限制 ，讓您的無伺服器應用程式能在流量增加時擴充並順暢運作。

如需擴充應用程式的建議，請參閱以下各節。

選擇靠近使用者的資料庫位置

下圖說明即時應用程式的架構：

在使用者的裝置 (行動網路或網頁) 上執行的應用程式會產生 則該連線會轉送至 Cloud Firestore 將 Cloud Firestore 前端伺服器 region。例如： 如果資料庫位於 us-east1，連線也會傳送至 這個 Cloud Firestore 前端也位於「us-east1」。這些連線 並保持開啟狀態，直到應用程式明確關閉為止。 前端讀取基礎 Cloud Firestore 儲存系統中的資料。

使用者實體位置與 Cloud Firestore 之間的距離 資料庫位置會影響使用者經歷的延遲時間。舉例來說 使用者的應用程式與北美洲 Google Cloud 區域的資料庫通訊 相較於資料庫 更改地點，例如印度或亞洲另一部分

將可靠性納入設計考量

以下主題可以改善或影響應用程式的可靠性：

啟用離線模式

Firebase SDK 提供離線資料持續性。如果 使用者裝置上的應用程式無法連線至 Cloud Firestore 應用程式仍可使用本機快取資料，仍可繼續存取應用程式。這可以確保 即使使用者遇到網際網路連線不穩或有不穩情形，也能存取應用程式 將完全喪失存取權數小時或數天。如要進一步瞭解 請參閱啟用離線資料一文。

瞭解自動重試

Firebase SDK 會負責重試作業並重新建立 連線中斷這有助於解決造成的暫時性錯誤 重新啟動用戶端和用戶端之間的伺服器或網路問題 資料庫

選擇區域或多區域位置

選擇區域性和 多區域位置主要差異在於資料的複製方式。這個 提高應用程式的可用性保證多區域執行個體 大幅提高服務可靠性及資料的耐用性 權衡利弊得失。

瞭解即時查詢系統

即時查詢 (也稱為快照監聽器) 可讓應用程式監聽 更新資料庫，並在資料更新後立即取得低延遲通知 並輸入變更內容應用程式會定期輪詢資料庫來取得相同結果 但通常速度較慢、成本較高，並需要更多程式碼。適用對象 如何設定及使用即時查詢的範例，請參閱 即時取得最新資訊。後續章節 深入瞭解快照事件監聽器的運作方式，並描述 ，在不犧牲效能的情況下，擴充即時查詢規模的最佳做法。

假設兩位使用者透過訊息連線至 Cloud Firestore 使用其中一個行動 SDK 建立的應用程式。

用戶端 A 寫入資料庫，以新增和更新集合中的文件 名稱為 chatroom：

collection chatroom:
    document message1:
      from: 'Sparky'
      message: 'Welcome to Cloud Firestore!'

    document message2:
      from: 'Santa'
      message: 'Presents are coming'

用戶端 B 使用快照事件監聽器，在同一個集合中監聽更新。 每當有人建立新訊息時，用戶端 B 會立即收到通知。 下圖顯示快照事件監聽器背後的架構：

用戶端 B 連結快照時，會發生下列事件順序 接聽到資料庫：

1. 用戶端 B 開啟 Cloud Firestore 連線，並註冊 透過呼叫 onSnapshot(collection("chatroom")) Firebase SDK這個事件監聽器可持續數小時。
2. Cloud Firestore 前端查詢基礎儲存系統 啟動資料集。載入整個 文件。我們稱這種情況為「輪詢查詢」。接著，系統會 會評估資料庫的 Firebase 安全性規則： 驗證使用者是否能存取這類資料如果使用者已獲授權， 資料庫會將資料傳回給使用者。
3. 接著，用戶端 B 的查詢會進入「聆聽模式」。監聽器會註冊 ，並等待資料更新。
4. 用戶端 A 現在會傳送寫入作業來修改文件。
5. 資料庫會將文件變更提交至 以及儲存空間系統
6. 透過交易方式，系統會將相同的更新檔案修訂到內部 變更記錄變更記錄將嚴格的異動順序 他們的作品。
7. 變更記錄會將更新的資料擴散到一個訂閱項目集區 處理常式中的指示操作。
8. 執行「反向查詢比對工具」，檢查更新過的文件是否相符。 目前註冊的任何快照事件監聽器。在這個範例中 符合用戶端 B 快照事件監聽器。顧名思義 反向查詢比對器做為一般資料庫查詢，但反向查詢。 不必透過文件搜尋，找出與查詢相符的內容，還能有效率地搜尋 是否符合收到文件的查詢。找到相符內容時 系統會將有問題的文件轉寄給快照事件監聽器。 接著，系統會評估資料庫的 Firebase 安全性規則 確保只有獲得授權的使用者會收到資料。
9. 系統將文件更新轉送至用戶端 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 的資料分割演算法會嘗試將 納入相同的集合或集合群組到相同的變更記錄伺服器。 系統會嘗試將可能的寫入總處理量最大化 盡可能降低查詢處理查詢作業的伺服器數量。

不過，特定模式仍可能導致快照行為欠佳 接聽程式。舉例來說，如果應用程式將大部分資料儲存在單一大型應用程式中 事件監聽器可能需要連線至多個伺服器 所需的資料即使套用查詢篩選器也是如此。轉機航班 會增加回應速度較慢的風險。

為了避免回應速度較慢，請在設計結構定義和應用程式時，確保系統能正確運作 則不需前往多個不同的伺服器，就能提供事件監聽器。也許可以運作 最好能以較低寫入速率將資料分成多個小型集合。

這就像是思考成效查詢 寫入需要完整資料表的關聯資料庫關聯式中 需要完整掃描資料表的查詢，就等同 可查看大量流失集合的快照事件監聽器。可能會執行緩慢 相比之下，資料庫可以使用更明確索引來提供查詢。 具有特定索引的查詢，就如同快照監聽器一樣，可監控 單一文件或較不常變更的集合應載入 測試您的應用程式，充分瞭解使用情境和用途。

加快輪詢查詢的速度

回應式即時查詢的另一個關鍵環節就是確保 輪詢查詢啟動資料的速度和效率。 首次連線新的快照事件監聽器時，事件監聽器必須載入 整個結果集，並傳送到使用者的裝置。執行速度緩慢的查詢 反應速度會下降。包括 試著讀取許多未使用適當索引的文件或查詢。

事件監聽器也可能從監聽狀態移回以下的輪詢狀態： 在某些情況下。這個過程會自動發生，而且在 和自家應用程式下列情況可能會觸發輪詢狀態：

• 系統因負載變更而重新平衡變更記錄。
• 無線基地台會導致資料庫寫入失敗或延遲。
• 暫時的伺服器重新啟動會暫時影響事件監聽器。

如果您的輪詢查詢速度夠快，輪詢狀態就會是透明的 宣傳應用程式的使用者

喜歡長效型聽眾

盡可能開啟並維持聽眾的存留時間，通常是 以符合成本效益的方式建構使用 Cloud Firestore 的應用程式。使用 Cloud Firestore，您必須為傳回應用程式的文件支付費用 而非維持開放連線長效快照事件監聽器讀取 在查詢生命週期內提供查詢所需的資料這個 包含初始輪詢作業，然後是在資料出現時通知 實際的變化另一方面，一次性查詢會重新讀取 自應用程式上次執行查詢以來皆無變更。

如果應用程式必須耗用大量資料，請設定快照事件監聽器。 可能不適合舉例來說，如果您的用途需要推送大量文件 長時間透過連線運作 則適合採用低頻率執行的單一查詢。

後續步驟

• 瞭解如何使用快照事件監聽器。
• 進一步瞭解最佳做法。