【技術e專欄】SaaS之多租戶資料綱要設計技巧 - 叡揚資訊

乍聽之下，SaaS跟10多年前曾經也風行一時應用軟體服務商（Application Service Provider, ASP）的模式好像是一樣的，難道只是新方式，提供多租戶服務，而不是一租戶一套 ... 首頁 叡揚e論壇 EIS65 【技術e專欄】SaaS之多租戶資料綱要設計技巧 論壇文章【技術e專欄】SaaS之多租戶資料綱要設計技巧 下一篇-【海外交流戰】知識管理食品王國頂新「不二過」法寶 【撰稿：政大資科系　陳恭教授】 隨著雲端運算環境的興起，軟體即服務（SoftwareasaService,SaaS）的營運模式也開始受到軟體開發商的注意，紛紛投入資源，將一些既有的應用軟體以及新開發的軟體採用此種模式推向市場。

不同於以往到客戶端安裝（on-premises），供單一用戶使用的模式，SaaS的一個特色是在資料中心安裝，以多租戶（multi-tenants）方式營運：每個租戶的使用者透過網路使用該應用軟體，其運作所需的軟硬體設施由資料中心與應用軟體開發商負責維運，租戶只需按使用量與服務品質等因素依合約付費。

SaaS、ASP（ApplicationServiceProvider）觀念大釐清 乍聽之下，SaaS跟10多年前曾經也風行一時應用軟體服務商（ApplicationServiceProvider,ASP）的模式好像是一樣的，難道只是新方式，提供多租戶服務，而不是一租戶一套設備的方式運作，那種模式只能稱得上是網路應用程式寄存服務（Webapplicationshosting）。

在資源共享方面，除了關鍵的虛擬化（virtualization）技術外，如何讓各個租戶之間可以共享資料庫也是一個重要技術指標。

五種多租戶資料綱要的設計技巧 如果說一租戶一資料庫的寄存服務是一個極端狀況（圖一），另一個極端就是所有的租戶都共用一資料庫（圖二）。

顯然的，這兩種情況都不理想，第一種完全沒有資源共享，第二種則缺乏擴充性，所有租戶都必須使用同一種資料綱要（dataschema），不易提供租戶客製化的服務。

兩者之間，應該有一些比較彈性的作法存在。

本文的目的就是要介紹幾種介於二者之間的資料綱要設計技巧。

以下我們將用資料庫表格（table）搭配SQL查詢指令的方式，介紹五種可用於多租戶資料綱要的設計技巧。

首先，我們以一租戶一資料庫的情境(沒有共享資料表格)當作基礎範例，再逐一介紹有共享且具擴充性的五種作法。

假設我們有三個租戶：Tenant31,32,33，以下（圖三）是他們都要使用的一個資料庫表格：學生資料。

三個表格都有AccountID與Name這兩個共同欄位，但也有個別的欄位，以表達客製化的需求。

根據以上的表格設計，如果我們要查詢Tenant31裡AccountID為1的Major欄位資料，可用SQL指令「SELECTMajorFROMTenant31WHEREAccountID=1」來完成。

接著我們以此範例為基礎，介紹五種多租戶資料綱要的設計技巧。

ExtensionTable ExtensionTable這個作法是將租戶共有的欄位抽出放置於一個資料庫表格，並以新增的TenantID欄位與Row欄位來區分不同租戶的資料。

其它個別租戶專有的資料欄位（usercolumn）則分別寫入不同的表格中。

圖四以上述的基礎範例來展示這種作法，其中欄位Row是用來標記表格內資料紀錄(record)的編號。

SQL指令範例：(以查詢Tenant31表格裡AccountID為1的Major欄位資料) SELECTTenant31.MajorFROMTenantExtLEFTJOINTenant31ONTenantExt.TenantID=Tenant31.TenantIDANDTenantExt.Row=Tenant31.RowWHERETenantExt.AccountID=1 這種作法的主要優點是可以透過將共有欄位集中存放，達到較好的資料整合性。

但也有一些缺點：（1）共有表格中需額外增加一些詮釋欄位（meta-data）來區分不同的租戶，圖四中紅色框框即代表此表格的詮釋欄位。

（2）讀取某些資料的時候，需要執行較費時的join的指令。

（3）跟一租戶一資料庫的作法一樣，仍然有表格數量隨租戶數增加而增加的問題。

UniversalTable UniversalTable這個作法也是將所有租戶的資料放置於一個共用的資料庫表格，但為支援租戶之間資料欄位的差異性，它是採稀疏矩陣的方式來存放資料。

具體而言，共用表格的資料欄位是所有租戶的聯集，簡單以流水號命名（Col1,Clo2,…），並以新增的TenantID欄位與Table欄位來區分不同租戶的資料。

圖五以上述的基礎範例來展示這種作法。

SQL指令範例:(以查詢Tenant31Table裡AccountID為1的Major欄位資料) SELECTCol3FROMTenantUniversalWHERECol1=1ANDTenantID=31ANDTable=0 這種作法的主要優點是減少表格的數量，無論多少個租戶都只需要一個表格。

但也有一些缺點：（1）表格中的欄位數量會增多；此外，因為不同租戶間的資料差異，造成部份的欄位會有浪費的情況發生，圖五中綠色框框即為此類欄位。

（2）因租戶間同時也共用欄位，所以某些資料欄位的資料會有異質性型別的情況(例如，Col3有字串也有數字)，從而可能有輸入錯誤的型別資料到表格的情況發生。

（3）缺乏索引(index)的支援，無法利用TenantID欄位與Table欄位來指定任一所需資料。

PivotTable PivotTable這個作法是將所有租戶的資料依資料的型別來分別存放在不同的表格，即同一型別的資料放置於同一個資料庫表格，並以新增的TenantID欄位、Table欄位、Col欄位以及Row欄位來區分不同租戶的資料。

其餘的欄位用來放置租戶的資料。

圖六以上述的基礎範例來展示這種作法。

SQL指令範例:(以查詢Tenant31Table裡AccountID為1的Major欄位資料) SELECTStrFROMPivotStrWHERETenantID=31ANDTable=0ANDCol=2ANDRowIN(SELECTRowFROMPivotIntWHERETenantID=31ANDTable=0ANDCol=0ANDInt=1) 這種作法的主要優點是加入了資料型別的處理，同時也不會有欄位浪費的情況發生。

但共有表格中需額外增加不少的詮釋欄位（meta-data）來區分不同的租戶，圖六中紅色框框即代表此表格的詮釋欄位。

ChunkTable ChunkTable這個作法參考Pivot與Universaltable的方式而有所改良。

首先，也是將所有租戶的資料放置於同一個資料庫表格，但它改良Universaltable，加入了資料型別的考量，將租戶資料依其型別存放於不同的欄位內，一欄位一型別，稱之為chunk，而不是像Pivottable，一型別一表格的作法。

並以新增的TenantID欄位、Table欄位、ChunkNo欄位以及Row欄位來區分不同租戶的資料。

其餘的欄位用來放置該租戶的資料。

圖七以上述的基礎範例來展示這種作法，在本例中，有整數與字串兩種資料型別，所以有Int1與Str1兩個Chunks，同一筆資料紀錄的相同型別的資料以ChunkNo來區別。

例如，Tenant31的AccountId與Grade欄位皆為整數型別，但它們的資料可以透過ChunkNo的值來區別。

SQL指令範例:(以查詢Tenant31Table裡AccountID為1的Major欄位資料) SELECTStr1FROMChunkTableWHERETenantID=31ANDTable=0ANDChunkNo=1ANDRowIN(SELECTRowFROMChunkTableWHERETenantID=31ANDTable=0ANDChunkNo=0ANDInt1=1) 這種作法的相對於PivotTable的作法有下列優點：（1）減少詮釋欄位與實際資料的比例。

（2）由於只使用一個表格，所以方便還原建立各租戶的原始資料。

除此之外，還有一些相對於UniversalTable的優點：（1）可以透過詮釋欄位來建立索引。

（2）減少欄位的數量。

（3）加入資料型別的概念。

但同時也潛藏一些資料欄位有浪費現象發生的可能，圖七中綠色框框即為部份欄位浪費的情況。

ChunkFolding ChunkFolding這個作法修改Chunktable的方式，將租戶共有的欄位抽出放置於一個資料庫表格，並以新增的TenantID欄位與Row欄位來區分不同租戶的資料。

其它個別租戶專有的資料欄位則分別寫入另一個ChunkRowTable中。

圖八以上述的基礎範例來展示這種作法。

SQL指令範例:(以查詢Tenant31Table裡AccountID為1的Major欄位資料) SELECTStr1FROMChunkRowWHERETenantID=31ANDTable=0ANDChunk=0ANDRowIN(SELECTRowFROMTenantCommonWHERETenantID=31ANDAccountID=1) 這種作法除了保有ChunkTable的主要優點外，還可以透過將共有欄位集中存放，達到較好的資料整合性。

【技術e專欄】SaaS之多租戶資料綱要設計技巧 目錄 發行人的話 準備接招瞬息萬變的大時代 內頁 【交流園地】做好績效管理實現企業策略 【交流園地】前進新竹科學園區大成功 【交流園地】誰是接班人？企業組織最大隱憂 【交流園地】企業下一步：贏在IT力 【技術e專欄】SaaS之多租戶資料綱要設計技巧 【海外交流戰】知識管理食品王國頂新「不二過」法寶 【導航e紀元】電子公務政府執行力關鍵趨勢 【導航e紀元】你的交辦又石沉大海了嗎？ 【決策e話題】健保局程式碼相信FortifySCA把關力 【決策e話題】勤業眾信副總經理楊承修：「User策略搖擺是致命傷！」 【決策e話題】三商美邦穩根基扎扎實實面對三修No.34公報 【決策e話題】鹽選轉型60年老店突圍飛越藍海 【特別企劃】業務報告暗藏玄機「愛報告」扭轉不景氣 【特別企劃】叡揚與資策會合作攜手打進全球私有雲市場