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

Share this post!

Bookmark and Share

0 意見: