您可以對多個用戶組織提供各自獨立的資料區段，以做到「多租戶架構」的功能，也就是所謂的用戶群。您可以在維持相同「資料結構定義」的情況下，自訂各個用戶群的「資料值」。這可讓佈建新用戶群變得有更有效率，您新增用戶群時不需要變更資料結構。
多租戶架構的好處
Datastore 模式的 Firestore 允許多租戶架構應用程式，在有下列使用情形時仍能為每個用戶群取用各自獨立的資料孤島：
- 單一專案
- 單一邏輯的種類結構
- 具備索引定義的單一集合，因為邏輯上每個用戶群的種類將是相同的
Datastore 模式透過提供「命名空間」來實現多租戶架構。
多租戶架構與分區資料
Datastore 模式使用「分區」來分別每個用戶群的資料。專案 ID 和命名空間 ID 組合形成可以識別各分區的「分區 ID」。實體為單一分區所屬，並且查詢範圍也限定在單一分區內。
指定實體的命名空間
您需要於建立實體時為其指定命名空間：在您成功建立實體之後，即無法變更命名空間。若您沒有明確指定命名空間，系統將會自動指定「預設的命名空間」，這代表該實體將無字串識別碼。
命名空間與父系實體搭配使用
實體與其所有的祖系僅屬於唯一的命名空間。這代表當您建立一個實體，且存在另一個被指定的父實體時，子實體與其父實體同屬於相同命名空間內：您無法將其指定到其他命名空間。
應用實例範本
多租戶架構的主要優勢，是可由同一個應用程式服務多個用戶組織。為了實現這個優勢，既定種類應用程式要具備相同的行為，無論命名空間為何。比如說，從應用程式的角度來看，某個命名空間中歸屬於 Task 類的實體，其邏輯應該要跟所有其他命名空間中同屬 Task 類的實體相同。如此一來，您的應用程式便可用一組索引定義支援 Task 查詢，而不用理會 Task 實體位在哪些命名空間裡。
舉例來說，假設某個 Task List 應用程式會獨立存放各使用者的資料，那麼此應用程式可參考用戶名稱來定義命名空間，就會形成下列這樣的區塊：
Partition ID: project:"my_project_id"/namespace:"Joe" Partition ID: project:"my_project_id"/namespace:"Alice" Partition ID: project:"my_project_id"/namespace:"Charlie"
應用程式就能定義一個 Task 類的邏輯架構，供所有命名空間使用，如下所示：
kind: Task properties: - "done", Boolean - "created", DateTime - "description", String, excluded from index
當使用者建立了一個 Task 類的實體，這個實體就會儲存在該使用者自己的區塊裡，成為獨立資料。應用程式會一致的處理命名空間中的 Task 實體，因為 Task 類的實體一次只能有一種模式。擁有獨立資料及單一特性的應用程式就會被多租戶化。
如果依命名空間來區分不同的 Task 類的邏輯結構，那麼應用程式就無法被多租戶化了，因為在命名空間中 Task 實體的處理方式也會是不同的。舉例來說，假設 Task 類依命名空間區分不同的模式：
- 在命名空間 Joe 裡的
Task實體，索引中「不包含」description屬性。 - 在命名空間 Alice 裡的
Task實體，索引中「包含」description屬性。
該應用程式可以查詢 Alice 的 Task 實體上的 description 屬性，但無法查詢 Joe 的 Task 實體的 description 屬性，所以該應用程式不會成為多租戶架構。
在主控台中查看命名空間
如要查看專案中使用的命名空間統計資料，請前往 Google Cloud 控制台的「Datastore 資訊主頁」頁面。如要利用程式決定專案中所用的命名空間，請參閱「查詢命名空間」。
若您有需要將某個用戶群「內」的資料分組，您可以使用種類來分類您的資料，也可以使用實體群組將高度關聯的資料加以組織。