最佳做法
建構使用 Firestore 的應用程式時，您可以快速參考本文章所列的最佳做法。
資料庫位置
建立資料庫執行個體時，請選取最靠近使用者和運算資源的資料庫位置。網路躍點越遠就越容易發生錯誤，且會增加查詢延遲時間。
如要盡可能提高應用程式的可用性和耐用性，請選取多地區位置，並將重要的運算資源至少放置在兩個地區。
選取單一地區位置，即可降低費用、減少寫入延遲 (如果應用程式對延遲時間很敏感)，或與其他 GCP 資源共置。
文件 ID
- 請避開文件 ID
.和..。 - 請勿在文件 ID 中使用
/斜線。 請勿使用單調遞增的文件 ID，例如：
Customer1、Customer2、Customer3...Product 1、Product 2、Product 3...
這類連續 ID 可能會導致資源使用率不均，進而影響延遲時間。
欄位名稱
請避免在欄位名稱中使用下列字元，因為這些字元需要額外逸出：
.句號[左方括號]右方括號*星號`倒引號
索引
縮短寫入延遲時間
造成寫入延遲的主要原因是索引扇出。減少索引扇出的最佳做法如下：
索引豁免
對於大多數應用程式，您可以依賴自動建立索引，以及任何錯誤訊息連結來管理索引。但在下列情況下，您可能會希望新增單一欄位豁免：
| 案件 | 說明 |
|---|---|
| 大型字串欄位 | 如果字串欄位經常保存您不查詢的長字串值，您可以免除該欄位的索引，藉此節省儲存空間費用。 |
| 對含有序列值的文件集合進行高速寫入 | 如果您為集合中文件之間依序遞增或遞減的欄位建立索引 (例如時間戳記)，則該集合的寫入頻率上限為每秒 500 次寫入。如果不是根據具有連續值的欄位查詢，可以將該欄位從索引中排除，藉此略過這項限制。 舉例來說，在寫入頻率較高的 IoT 用途，如果集合中的文件含有時間戳記欄位，可能會接近每秒 500 次寫入的上限。 |
| 存留時間欄位 |
如果使用 TTL (存留時間) 政策，請注意 TTL 欄位必須是時間戳記。系統預設會對存留時間欄位建立索引，但這可能會在高流量時影響效能。最佳做法是為存留時間欄位新增單一欄位豁免項目。 |
| 大型陣列或對應欄位 | 大型陣列或對應欄位可能會接近每個文件 40,000 個索引項目的上限。如果不是根據大型陣列或對應欄位查詢，則應將其排除在索引之外。 |
讀取和寫入作業
應用程式更新單一文件的確切最大速率，取決於工作負載。詳情請參閱「更新單一文件」。
盡可能以非同步呼叫取代同步呼叫。 非同步呼叫可以盡可能降低延遲造成的衝擊。以需要文件查詢結果和查詢結果才能顯示回應的應用程式為例。如果查詢和查詢沒有資料相依性，就不需要同步等待查詢完成，再開始查詢。
不可使用位移，請改用游標。使用位移只能避免將略過的文件傳回應用程式中，但是系統仍會在內部擷取這些文件。略過的檔案會影響查詢延遲時間，而且應用程式在擷取這類檔案時所須進行的讀取作業也要計費。
交易重試
Firestore SDK 和用戶端程式庫會自動重試失敗的交易，以處理暫時性錯誤。如果應用程式是透過 REST 或 RPC API 直接存取 Firestore，而非透過 SDK，應用程式應實作交易重試機制，以提高可靠性。
即時更新
如要瞭解即時更新的最佳做法，請參閱「大規模瞭解即時查詢」。
資源調度設計
以下最佳做法說明如何避免造成爭用問題的情況。
更新單一文件
設計應用程式時，請考慮應用程式更新單一文件的速度。如要瞭解工作負載的效能，最好的方法是執行負載測試。應用程式更新單一文件的確切速率上限，取決於工作負載。這些因素包括寫入速率、要求之間的爭用，以及受影響的索引數量。
文件寫入作業會更新文件和所有相關聯的索引，Firestore 則會同步將寫入作業套用至多數副本。如果寫入速率過高，資料庫就會開始遇到爭用、延遲時間變長或其他錯誤。
高速讀取、寫入及刪除小範圍文件
請避免高速讀取或寫入字母順序接近的文件，否則應用程式會發生爭用錯誤。此問題稱為資源使用率不均，如果您的應用程式執行以下任一操作，就可能會發生此問題：
以極高的速率建立新文件，並自行分配單純增加的 ID。
Firestore 會使用分散式演算法來分配文件 ID。如使用自動文件 ID 建立新文件，則應該不會在寫入時遇到資源使用率不均的問題。
在文件數量較少的集合中，以極高的速度建立新文件。
以極高的速度建立新文件，並使用單純增加的欄位 (如時間戳記)。
高速刪除集合中的文件。
以極高的速度寫入資料庫，但不逐漸增加流量。
避免略過已刪除的資料
避免查詢時略過最近刪除的資料。如果最近刪除了大量索引項目，查詢可能必須略過這些項目。
舉例來說，如果工作負載嘗試尋找佇列中最舊的工作項目，可能就必須略過大量已刪除的資料。查詢可能如下所示：
docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
finish_work(doc)
delete_batch.delete(doc.reference)
delete_batch.commit()
每次執行這項查詢時，系統都會掃描最近刪除文件中的 created 欄位索引項目。這會減緩查詢速度。
如要提升效能，請使用 start_at 方法找出最佳起點。例如：
completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
{'created': completed_items.get('last_completed')}).order_by(
'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
finish_work(doc)
delete_batch.delete(doc.reference)
last_completed = doc.get('created')
if last_completed:
delete_batch.update(completed_items.reference,
{'last_completed': last_completed})
delete_batch.commit()
注意：上述範例使用單調遞增的欄位，這對於高寫入率而言是反模式。
增加流量
為了讓 Firestore 有足夠的時間為流量增加做準備，您應該逐漸增加傳送至新集合或字典順序相近文件的流量。建議傳送至新集合的流量不要超過每秒 500 項作業，接著每 5 分鐘增加 50% 的流量。您也可以同樣提高寫入流量，但請注意 Firestore 標準限制。整個索引鍵範圍內的作業一定要相當均勻。這就是所謂的「500/50/5」規則。
將流量遷移至新集合
如果您要將應用程式流量從一個集合遷移至另一個集合，就特別需要逐步增加流量。處理這項遷移作業的簡單方法是從舊集合讀取資料，如果文件不存在，則從新集合讀取資料。不過，這可能會導致新集合中字彙順序相近的文件流量突然增加。Firestore 可能無法有效準備新集合，以因應流量增加的情況，尤其是當集合內的文件很少時。
如果您變更同一個集合中許多文件的文件 ID，也可能發生類似問題。
將流量遷移至新集合的最佳策略取決於您的資料模型。以下所舉的策略範例稱為「平行讀取」。您需要判斷這項策略是否適用於您的資料，而平行作業在移轉階段對成本造成的影響會是相當重要的考量因素。
平行讀取
如要在將流量遷移至新集合時實作平行讀取，請先從舊集合讀取資料。如果缺少文件，請從新集合讀取。高速讀取不存在的文件可能會造成資源使用率不均現象，因此請務必逐漸增加新集合的負載。先將舊文件複製到新集合，再刪除舊文件，會是比較好的策略。逐漸增加平行讀取，確保 Firestore 可以處理新集合的流量。
要逐漸增加新集合的讀取或寫入，可行策略之一是使用決定性的使用者 ID 雜湊，隨機選取嘗試寫入新文件的使用者百分比。請務必避免函式或使用者行為扭曲使用者 ID 雜湊結果。
同時，請執行批次工作，將舊文件中的資料全數複製到新集合。批次工作應避免寫入連續文件 ID，以避免資源使用率不均。批次工作完成後，您就只能讀取新的集合。
這個策略的進階版是一次只移轉一小批使用者。在使用者文件中新增一個欄位，用於追蹤該名使用者的移轉狀態。根據使用者 ID 的雜湊碼選取一批使用者。使用批次工作遷移該批使用者的文件，並對正在遷移的使用者進行平行讀取。
請注意，除非您在移轉階段同時寫入新舊實體，否則無法輕易復原。這會增加 Firestore 費用。
隱私權
- 避免將機密資訊儲存在 Cloud 專案 ID 中。專案結束後，專案 ID 仍有可能保留下來。
- 為遵守資料法規，建議您不要在文件名稱和文件欄位名稱中儲存私密資訊。