Multi-Tenant Data Architecture 分享 (多租戶的資料設計架構) part1

最近同事分享了一篇好文章：Multi-Tenant Data Architecture，在這裡紀錄一下自己閱讀的感想。在這一篇中，先針對三種架構進行介紹，比較其優缺點和適用環境，下一篇再來描述如何針對不同的需求，選擇一個最適合你的設計架構。

• 什麼是多租戶(Multi-Tenant)？

從字面上來看，就是有多個租用的客戶。在SaaS的雲端平台架構中，多租戶技術指的是大量的用戶共同使用、分享一組軟硬體資源。這這裡要分享的是在多租戶技術中，資料隔離的架構設計。



在Multi-Tenant Data Architecture的設計中，資料隔離共有三種架構：

• Separate Database
• Shared Database, Separate Schemas
• Shared Database, Shared Schema

• Separate Database

第一個架構是Separate Database，對於每一個租戶(tenant)，其所存取的資料庫是分離(Separate)的。即使運算資源或程式碼可能是多個租戶共用，但在資料的儲存或取得上，是完全分離(isolate)的狀態。

1. 優點：
   容易根據用戶的需求來擴展Data Model。
   備份和回復資料相對容易。
   
2. 缺點：
   每一租戶需提供一個完整的資料庫，維護成本高。
   硬體成本較其他兩種solutions高。
   
3. 適用範圍：
   
   當租戶願意為了安全性和資料隔離性付出較高成本時，則可採用此方案；例如銀行或醫療單位經常需要高安全性，用戶的資料也需要做到完全隔離時，就適合採用Separate Database的Solution。

• Shared Database, Separate Schemas

第二個架構是Shared Database, Separate Schemas。顧名思義，這種架構是多個租戶(Multi-Tenant)共用一個資料庫，但每個租戶的資料會存在一個屬於自己的Schema中，裡面包含了數個tables。

1. 優點：
   硬體成本上相較於separate database來的低，每一台伺服器可以承受的租戶也比較多。
   
2. 缺點：
   資料庫出問題時較難回復。當使用Separate Schemas的方法時，當你要復原整個database，代表著你要將其他tenant的schemas都覆蓋掉。
   
3. 適用範圍：
   每一個租戶所需要的table數量不會很多(文中建議小於100個)時，可以採用此方法。
   

• Shared Database, Shared Schemas

第三個架構是所有的租戶使用相同的database，同時用同一組tables來維護其資料。在此方法中，會用tenant ID來當作每個tenant的識別。

1. 優點：
   每一台server可以負擔的tenant數量最多，單位成本最低。
   
2. 缺點：
   由於所有的租戶都共用同一個資料庫，在安全維護和資料隔離程度上最差。
   單一租戶的資料在復原時，需要在所有的table中尋找相同的tenant ID，數量多時，會造成其他租戶的效能降低。
   
3. 適用範圍：
   當你需要服務大量的租戶，同時硬體上有所受限時，才採用這種方法。
   

【相關閱讀】
Multi-Tenant Data Architecture