本文件說明在 Cloud Spanner 中實作多用戶群的方式。另外還會討論資料管理模式和用戶群生命週期管理。
軟體用戶群是指軟體應用程式的單一執行個體或數個執行個體，可包含多個用戶群或客戶。此軟體模式可從單一用戶群或客戶擴充成數百或數千位。此方法是雲端運算平台的基礎，其基礎基礎架構在多個機構之間共用。
從多重用戶群想像為根據共用運算資源 (例如資料庫) 的分區。關聯是位在公寓結構中的用戶群：共用基礎架構，而是專屬用戶群空間。 在大多數情況下，多用戶群架構是軟體式服務 (SaaS) 應用程式的一部分。
本文件適用於使用 Spanner 實作多用戶群應用程式做為關聯資料庫的資料庫架構師、資料架構師和工程師。使用該背景資訊，概述了儲存多用戶群資料的各種方法。文章中的「用戶群」、「客戶」與「機構」這兩個字詞可交互使用，以指出存取多用戶群應用程式的實體。
本文使用人力資源 (HR) 軟體式服務 (SaaS) 供應商，在 Google Cloud 上實作其多用戶群應用程式。在此範例中，人力資源 (SaaS) 供應商的客戶必須存取多用戶群應用程式。這些客戶稱為用戶群。
Spanner 是 Google Cloud 的全代管、企業級、分散式和一致資料庫，結合關聯資料庫模型的優點在於具有非關聯水平擴充能力。Spanner 具有關聯語意，其中包含結構定義、強制執行資料類型、同步一致性、多重 ACID 交易，以及實作 ANSI 2011 SQL 的 SQL 查詢語言。
Spanner 可針對停機或地區故障提供停機時間，並提供99.999%的可用性服務水準協議。它支援高可用性和擴充性，藉此支援現代化的多用戶群應用程式。本文討論使用 Spanner 實作多用戶群的不同架構方法。
用戶群資料對應條件的條件
在多用戶群應用程式中，每個用戶群的資料都隔離於基礎 Spanner 資料庫中的多個架構方法中。以下清單列出將用戶群資料對應至 Spanner 的不同架構方法：
- 執行個體：用戶群執行個體位於單一 Spanner 執行個體中，且為該用戶群有一個資料庫。
- 資料庫：用戶群位於內含多個資料庫的單一 Spanner 執行個體中的資料庫中。
- 結構定義：用戶群位於資料庫內的專屬資料表，而多個用戶群可以位於同一個資料庫。
- 資料表：這些資料是資料庫資料表中的資料列。這些資料表會與其他用戶群共用。
前述條件稱為資料管理模式，詳細說明請參閱多用戶群資料管理模式一節。此討論是以下列條件為基礎：
- 隔離：多用戶群對資料隔離程度的主要考量在於多用戶群架構。隔離則取決於根據其他類別標準所設定的選項，例如，某些法規和法規遵循要求可以影響程度較高的隔離措施。
- 敏捷度：用戶群 (執行個體) 執行個體的建立、資料庫或資料表啟用和停用活動變得更容易。
- 作業：實作一般、特定用戶群、資料庫作業和管理管理活動的可用性或複雜性，例如定期維護、記錄、備份或災難復原作業。
- 規模：能夠流暢調度資源，以因應未來的成長情況。每個模式的說明都包含該模式可以支援的用戶群數量。
- 效能：將個別資源分配給各個用戶群，處理 noisy neighborhood (相鄰相鄰) 的情形，並為每個玩家提供可預測的讀取和寫入效能用戶群。
- 合規與法規遵循：能夠滿足高度管制產業的要求，以及需要完整維護資源及維護維護作業的國家/地區，例如：法國要求廣告客戶必須確切保存個人識別資訊。
下節將詳細說明每種資料管理模式，下節將詳細說明。為特定用戶群選取資料管理模式時，請使用相同的條件。
多用戶群資料管理模式
以下各節說明四個主要資料管理模式：執行個體、資料庫、結構定義和資料表。
執行個體
為了提供完整區隔，執行個體資料管理模式會將每個用戶群的資料儲存在專屬的 Spanner 執行個體和資料庫中。Spanner 執行個體可擁有一或多個資料庫。在這個模式下，只會建立一個資料庫。如先前討論的 HR 應用程式，每個客戶機構都會建立一個單獨的資料庫。
如下圖所示，資料管理模式每個執行個體都有一個用戶群。
只要為每個用戶群分別設置不同的執行個體，就能使用不同的 Google Cloud 專案來達到不同用戶群的獨立信任界線。還有一個優點是，可以為每個用戶群位置 (單一地區或多地區) 選擇每個執行個體設定，藉此提高位置的彈性與效能。
這個架構可輕鬆擴充至任意數量的用戶群。SaaS 供應商可在所需的地區中建立任意數量的執行個體，而不受任何限制。
下表概略說明執行個體資料管理模式對不同條件的影響。
| 條件 | 執行個體：每個執行個體資料管理模式一個用戶群 |
|---|---|
| 隔離 |
|
| 敏捷度 |
|
| 作業 |
|
| 規模 |
|
| 效能 |
|
| 法律規定和法規遵循要求 |
|
簡單來說，要點如下：
- 優點：隔離程度最高
- 缺點：作業負擔最高
執行個體資料管理模式最適合符合下列情境：
- 不同的用戶群會分散在各式各樣的地區，需要使用本地化解決方案。
- 某些用戶群的需求和稽核通訊協定要求較高，更為安全。
- 用戶群規模大小有很大的差異，因為在高容量的用戶群之間共用資源，可能會導致爭用情況和雙向降級。
資料庫
在資料庫資料管理模式中，每個用戶群都位於單一 Spanner 執行個體內的資料庫中。多個資料庫可以儲存在單一執行個體中。如果執行個體只有一個用戶群的資料量不足，請建立多個執行個體。這個模式表示有多個用戶群共用一個 Spanner 執行個體。
Spanner 對每個執行個體的資料庫有 100 個硬性限制。這項限製表示如果軟體式服務 (SaaS) 供應商需要擴充超過 100 位客戶，他們就必須建立和使用多個 Spanner 執行個體。
對於 HR 應用程式，SaaS 供應商會在 Spanner 執行個體中使用不同的資料庫建立及管理每個用戶群。
如下圖所示，資料管理模式的每個資料庫都有一個用戶群。
資料庫資料管理模式可在不同的用戶群資料中，達到資料庫層級的邏輯隔離。不過，由於是單一 Spanner 執行個體，因此所有用戶群資料庫都會共用相同的地區設定，以及基礎運算和儲存空間設定。
下表概略說明資料庫資料管理模式對不同條件的影響。
| 條件 | 資料庫：每個資料庫資料管理模式一個用戶群 |
|---|---|
| 隔離 |
|
| 敏捷度 |
|
| 作業 |
|
| 規模 |
|
| 效能 |
|
| 法律規定和法規遵循要求 |
|
簡單來說，要點如下：
- 優點：隔離等級更高
- 缺點：每個執行個體的用戶群人數有限；地點缺乏彈性
資料庫資料管理模式最適合下列情境：
- 多個客戶位於同一個資料住戶 (例如法國或英國)，且/或隸屬於相同法規授權。
- 用戶群需要以系統為基礎的資料區隔和備份/還原，但適合共用基礎架構資源。
結構定義
在結構定義資料管理模式中，單一資料庫 (實作單一結構定義) 就會用於多個用戶群，每個用戶群的資料則使用一組獨立的資料表。這些資料表的名稱可在前置字串中加入 tenant ID 或前置字串，藉此區分資料表。
相較於上述選項 (執行個體與資料庫管理模式)，對於每個用戶群使用單獨的資料表組合，這種資料管理模式可提供的隔離程度相當低。此外，這個模式也簡化了新手上路流程，方法包括建立新的資料表，以及相關的參照完整性與索引。
值得注意的是，透過身分與存取權管理 (IAM) 方式存取 Spanner 的權限只會在執行個體或資料庫層級提供。您無法透過表格層級取得存取權限。每個資料庫也有 5,000 個資料表的上限。許多客戶都會限制其應用程式使用。
此外，針對每個客戶使用獨立的資料表，可能會導致結構定義更新作業的待處理作業。此類待處理作業需要長時間解決。
針對 HR 應用程式，SaaS 供應商可以為每個客戶建立一組資料表，並在資料表中以 tenant ID 做為前置字串，例如：customer1_employee、customer1_payroll、customer1_department。
如下圖所示，結構定義資料管理模式的每個用戶群都會有一組資料表。
下表概略說明結構定義資料管理模式對不同條件的影響。
| 條件 | 結構定義：每個用戶群資料管理模式的一組資料表 |
|---|---|
| 隔離 |
|
| 敏捷度 |
|
| 作業 |
|
| 擴充 |
|
| 效能 |
|
| 法律規定和法規遵循要求 |
|
簡單來說，要點如下：
- 優點：新手上路流程十分簡單
- 缺點：作業負擔增加；沒有資料表層級的安全控管機制
結構定義資料管理模式最適合下列情境：
- 相較於提供較簡單的維護作業，可對嚴格的資料隔離隔離的各部門區分內部應用程式。
- 多租戶架構應用程式，根據法規或法規要求不需要嚴格隔離。
儘管可以在資料庫中建立多組資料表 (每個資料集代表一個用戶群)，但從資料庫的角度來看，這是最理想中的模式。主要原因是表格必須遵循命名慣例。應用程式和任何資料庫工具 (例如 IDE 和結構定義遷移工具) 都必須瞭解命名慣例。此外，如果每個用戶群的資料表數量相當大，則結構定義資料管理模式就無法提供顯著的資源調度。
比較好的方法是，為每個用戶群移至一個資料庫並增加執行個體數量，或移至資料表資料管理模式。
資料表
最終的資料管理模式為具有多個常用資料表的多個用戶群提供。每個資料表都包含多個用戶群的資料。這個資料管理模式代表要在多個用戶群中共用，從基礎架構、結構定義到資料模型等各種內容的多用戶群管理機制。在資料表中，資料列是根據主鍵進行分區，其中 tenant ID 是金鑰的第一個元素。從資源調度的角度來看，BigQuery 支援這個模式，因為它能以無限制的方式調度資料表資源。
如果是 HR 應用程式，薪資表的主鍵可以是 customerID 和 payrollID 的組合。
如下圖所示，資料表資料管理模式有多個用戶群。
與結構定義模式類似，您無法為不同用戶群分別控制資料表模式中的資料存取權。使用較少資料表代表，每個用戶群都有自己的資料庫資料表，所以結構定義更新作業速度更快。其中的影響很大，可簡化新手上路、新手上路和作業。
下表概略說明資料表資料管理模式對不同條件的影響。
| 條件 | 資料表：多個用戶群資料管理模式的資料表 |
|---|---|
| 隔離 |
|
| 敏捷度 |
|
| 作業 |
|
| 規模 |
|
| 效能 |
|
| 法律規定和法規遵循要求 |
|
簡單來說，要點如下：
- 優點：具備高擴充性。作業負擔較低
- 缺點：資源爭用缺少個別用戶群的安全控管機制
這個模式最適合在下列情況中使用：
- 相較於對於維護較容易，嚴格的資料安全性隔離的各部門而言，內部應用程式並不會特別重要。
- 共用用戶群的資源時，如果使用資源層級同時將資源佈建縮到最小，就會優先使用用戶群資源。
資料管理模式和用戶群生命週期管理
下表比較了所有不同標準的各種資料管理模式。
| 執行個體 | 資料庫 | 結構定義 | 資料表 | |
|---|---|---|---|---|
| 隔離 | 完成 | 完成 | 低 | 最低 |
| 敏捷度 | 低 | 中等 | 中等 | 最高 |
| 使用便利度 | 高 | 高 | 低 | 低 |
| 規模 | 高 | 有限 | 可能限制 | 高 |
| 效能* | 高 | 中等 | 中等 | 可能性較高 |
| 法規與法規遵循 | 最高 | 高 | 低 | 低 |
* 效能主要取決於結構定義設計和查詢最佳做法。這裡的值只是平均值。
根據特定條件，大部分的特定用戶群應用程式最適合滿足下列資料管理模式。如果特定條件不需要，您可忽略該資料列所在的資料列。
合併資料管理模式
通常，單一資料管理模式就足以滿足多用戶群應用程式的需求。在這種情況下，設計可採用單一資料管理模式。
但是，有些多用戶群應用程式會需要同時管理數個資料，例如一個支援免費方案、一般層級和企業層級的多用戶群應用程式。
免費方案：
- 必須符合成本效益
- 必須設定高數據用量
- 通常僅支援部分功能
- 資料表資料管理模式是免費方案的適用者
- 用戶群管理作業相當簡單
- 不需要建立特定或專屬用戶群資源
一般級別：
- 適用於沒有明確資源調度或隔離需求的付款客戶
- 結構定義資料管理模式或資料庫資料管理模式都是不錯的標準
-
候選人
- 用戶群資料表和索引沒有專屬資料
- 在資料庫資料管理模式中輕鬆進行備份
- 結構定義資料管理模式不支援備份資料
- 用戶群備份實作必須在公用程式之外實作公用程式
企業級：
- 整體而言，通常客戶方面已具備所有自主權
- 用戶群擁有專屬的資源，其中包含專屬的資源調度和完整隔離功能
- 執行個體資料管理模式很適合企業級別
最佳做法是在不同資料資料庫中保留不同的資料管理模式。儘管您可以在 Spanner 資料庫中整合不同的資料管理模式，卻難以實作應用程式的存取邏輯和生命週期作業。
應用程式設計一節說明使用單一資料管理模式或數個資料管理模式時，適用的多用戶群應用程式設計注意事項。
管理用戶群的生命週期
用戶群具有生命週期。因此，您必須在多用戶群應用程式中實作相應的管理作業。除了建立、更新及刪除用戶群的基本作業之外，您還可以考量下列資料相關作業：
匯出用戶群資料：
- 刪除用戶群時，最好是先匯出資料，然後再提供資料集。
- 使用資料表或結構定義資料管理模式時，多用戶群應用程式系統必須實作匯出或對應至資料庫功能 (資料庫匯出)。
備份用戶群資料：
- 使用執行個體或資料庫的資料管理模式並備份個別用戶群的資料時，請使用資料庫的匯出或備份函式。
- 使用個別結構定義或資料表資料管理模式並備份個別用戶群的資料時，多用戶群應用程式必須實作這個作業。Spanner 資料庫無法判斷哪些資料屬於哪個用戶群。
移動用戶群資料：
將用戶群從一個資料管理模式移動到另一個資料管理模式 (或在執行個體或資料庫之間移動相同資料管理模式中的用戶群) 需要從資料表資料管理模式擷取資料，並將資料插入資料庫資料管理模式。
- 在可能的情況下，請執行匯出/匯入。
- 若無法停機，請執行零停機時間資料庫遷移。
緩解親密的情境，是降低親密關係的另一個原因。
應用程式設計
設計多用戶群應用程式時，實作用戶群感知商業邏輯。因此，每次應用程式執行商業邏輯時，都必須位於已知的用戶群內容中。
從資料庫的角度來看，應用程式設計是指必須根據用戶群所在的資料管理模式執行每個查詢。以下各節將介紹多用戶群應用程式設計的中央概念。
動態用戶群連線與查詢設定
使用用戶群設定，以動態方式將用戶群資料對應至用戶群應用程式要求：
- 就資料庫資料管理模式或執行個體資料管理模式而言，連線字串足以存取用戶群的資料。
- 對於結構定義資料管理模式，必須決定正確的資料表名稱。
- 對於資料表資料管理模式，您必須對資料庫執行查詢。使用適當的述詞來擷取特定用戶群的資料。
用戶群可以四種四種資料管理模式之一。以下對應實作可處理多機構應用程式 (分別為所有資料管理模式) 一般用途的連線設定。當特定用戶群處於某種模式時，有些多用戶群應用程式就會針對所有用戶群使用單一資料管理模式。而是以下列對應方式間接說明。
如果用戶群執行業務邏輯 (例如，使用用戶群 ID 登入的員工)，則應用程式邏輯必須判斷用戶群的資料管理模式、特定用戶群 ID 的資料位置，以及您也可以選擇是否使用資料表命名慣例 (針對結構定義模式)。
這個應用程式邏輯需要用戶群的資料管理模式對應。在下列程式碼範例中，connection string 是指用戶群資料所在的資料庫。這個範例會辨識 Spanner 執行個體和資料庫。針對資料管理模式執行個體和資料庫，下列程式碼適用於應用程式連線和執行查詢：
tenant id -> (data management pattern,
database connection string,
[table_prefix])
結構定義和資料表資料管理模式需要額外的設計。
結構定義資料管理模式
就結構定義資料管理模式而言，同一個資料庫中有多個用戶群。每個用戶群都有專屬的資料表。資料表會依名稱命名。哪個資料表屬於確切的用戶群。
方法之一就是在資料表名稱前加上用戶群 ID，例如：EMPLOYEE資料表T356_EMPLOYEE使用 ID 的用戶群356，才能使用 Android 手機或平板電腦尋找另一部裝置。應用程式必須先將每個前置字串前面加上前置字串 Ttenant ID，才能將查詢傳送至對應傳回的資料庫。
另一個方法是將 table_prefix 附加至查詢所使用的對應，以便找出用戶群的正確資料表。
您也可以使用混合方法：如果資料管理模式是結構定義模式，而資料表前置字串為空白，則預設對應會 (具有用戶群 ID 的前置資料表名稱)。
資料表資料管理模式
資料表資料管理模式也必須具備類似的設計。在此模式中會有一個結構定義。用戶群資料會以資料列的形式儲存。為正確存取資料，請為每項查詢附加述詞，以選取合適的用戶群。
要找到適合的用戶群，其中一個表格在每個資料欄都包含名為 TENANT 的資料欄。資料欄值為 tenant ID。每個查詢都必須附加述詞AND TENANT = tenant ID新增到現有的WHERE子句或新增
WHERE子句與述詞AND TENANT = tenant ID，才能使用 Android 手機或平板電腦尋找另一部裝置。
如要連線到資料庫並建立正確的查詢，用戶群 ID 必須存在於應用程式邏輯中。可以當做參數傳送，或是儲存為執行緒結構定義。
某些生命週期作業會要求您修改用戶群資料管理模式對應設定。舉例來說，在資料管理模式之間移動用戶群時，您必須更新資料管理模式，以及資料庫連線字串。您可能也需要更新資料表前置字串。
查詢產生和歸因
多用戶群應用程式的基本原則是，多用戶群可以共用單一雲端資源。上述資料管理模式就屬於這個類別。不過，單一用戶群分配到單一 Spanner 執行個體時除外。
資源共用不侷限於共用資料。監控和記錄也會共用，例如，在資料表資料管理模式和結構定義資料管理模式中，所有用戶群的查詢都會記錄在同一個稽核記錄中。
如果記錄了查詢，則查詢文字必須檢查到執行查詢的用戶群。在資料表資料管理模式中，您必須剖析述詞。在結構定義資料管理模式中，您必須剖析其中一個資料表名稱。
在資料庫資料管理模式或執行個體資料管理模式中，查詢文字沒有任何用戶群資訊。如要取得這些模式的用戶群資訊，您必須查詢用戶群資料管理模式對應表。
判斷特定查詢的用戶群在不剖析查詢文字時，能更輕鬆地分析記錄和查詢。如要統一識別所有資料查詢的用戶群，其中一種方法是為含有 tenant ID 的查詢文字新增註解，以及 (選用) 指定 label。
以下查詢會針對 TENANT 356 識別的用戶群選取所有員工資料。為避免剖析 SQL 語法並從述詞擷取用戶群 ID，用戶群 ID 會新增為註解。而無須剖析 SQL 語法，即可擷取註解。
select * from EMPLOYEE
-- TENANT 356
where TENANT = 'T356';
或
select * from T356_EMPLOYEE;
-- TENANT 356
使用此設計時，每項用戶群執行的查詢都會歸給該用戶群，不受資料管理模式影響。如果用戶群在另一種資料管理模式之間移動，查詢文字可能會變更，但屬性仍保留在查詢文字中。
上述程式碼範例只有一個方法。另一個方法是插入 JSON 物件做為註解，而非標籤和值：
select * from T356_EMPLOYEE;
-- {"TENANT": 356}
用戶群存取生命週期作業
視您的設計原理而定，多用戶群應用程式可以直接實作前述的資料生命週期作業，也可以建立獨立的用戶群管理工具。
視實作策略而定，生命週期運算可能在不執行應用程式邏輯的情況下執行，例如將用戶群從資料管理模式移到另一個資料模式時，應用程式邏輯資料不在單一資料庫中，因此無法執行。若資料不在單一資料庫中，則需要從應用程式的角度另外執行兩項作業：
- 停止用戶群：停用資料生命週期作業時，停用所有應用程式邏輯存取權。
- 啟動用戶群：應用程式邏輯可存取用戶群的資料，而會幹擾應用程式邏輯的生命週期作業則遭到停用。
雖然不會經常使用，關閉緊急用戶群可能是另一個重要的生命週期作業。當您懷疑違規行為時，請使用此關閉程序，並且必須禁止存取用戶群資料 (不只是應用程式邏輯) 的存取權，也要封鎖生命週期作業。漏洞可能來自資料庫內部或外部。
此外，也必須提供能移除緊急狀態的生命週期作業。這類作業可能會要求兩個以上的管理員同時登入，以執行明確控制。
應用程式隔離
各種資料管理模式支援不同用戶群的資料隔離程度。從最高隔離層級 (執行個體) 到最低隔離等級 (資料表)，最多可有不同程度的隔離。
在多用戶群應用程式的情況下，必須進行類似的部署決策：所有用戶群都會使用相同的應用程式部署存取其資料 (可能有不同的資料管理模式)？例如，單一 Kubernetes 叢集可能支援所有用戶群，當用戶群存取其資料時，同一個叢集會執行商業邏輯。
或者，如同資料管理模式，不同的用戶群可能會導向至不同的應用程式部署。大型用戶群可能會存取專用應用程式部署作業，而免費層級的小型用戶群或用戶群可以共用應用程式部署作業。
您不必直接採用本文提到的資料管理模式，而是採用與應用程式資料管理模式一致的模式，即可使用資料庫資料管理模式，讓所有用戶群都能共用單一應用程式部署作業。您可以讓資料庫資料管理模式和所有用戶群共用單一應用程式部署作業。
多用戶群架構是應用程式架構資料的重要管理模式，特別是當資源效率出現重要作用時。Spanner 支援數種資料管理模式，可以用來實作多用戶群應用程式。具備 Spanner 的極高擴充性和嚴格的服務水準協議，適合大型多用戶群應用程式部署作業使用。
後續步驟
- 探索 Google Cloud 的參考架構、圖表、教學課程和最佳做法。 查看 Cloud 架構中心。