多租戶架構

您可以對多個用戶組織提供各自獨立的資料區段,以做到「多租戶架構」的功能,也就是所謂的用戶群。您可以在維持相同「資料結構定義」的情況下,自訂各個用戶群的「資料值」。這可讓佈建新用戶群變得有更有效率,您新增用戶群時不需要變更資料結構。

多租戶架構的好處

Datastore 模式 的 Cloud Firestore 允許多租戶架構應用程式,在有下列使用情形時仍能為每個用戶群取用各自獨立的資料孤島:

  • 單一專案
  • 單一邏輯的種類結構
  • 具備索引定義的單一集合,因為邏輯上每個用戶群的種類將是相同的

Datastore 模式透過提供「命名空間」來實現多租戶架構。多租戶架構也適用於其他具備命名空間功能的 Google App Engine API (GoJavaPython)。

多租戶架構與分區資料

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 Platform Console 中的 Datastore 資訊主頁頁面。若要利用程式決定專案中所用的命名空間,請參閱查詢命名空間

若您有需要將某個用戶群「內」的資料分組,您可以使用種類來分類您的資料,也可以使用實體群組將高度關聯的資料加以組織。

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Datastore 說明文件