第二章 技術背景與相關研究
2.1 多租戶應用程式之資料層級設計
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
9
戶一資料表的寫法撰寫 SQL 語句。為了讓軟體開發人員雖以 Extension Table Layout 的概念進行多租戶應用程式之資料層級設計，卻可以沿用一租戶一資料 表的 SQL 語句邏輯對資料進行增刪修改，所以，本研究實作一套系統工具將 SQL 語句從一租戶一資料表寫法轉換成以 Extension Table Layout 邏輯表達的 SQL 語句。在進行實際的語句轉換之前，本系統工具必需對 SQL 語句進行結構剖析 以獲得語句轉換過程中所需的語句元素，2.3 小節所介紹的 SQL 語句結構剖析工 具-JSqlParser 則可以協助系統工具進行語句結構剖析並提供語句元素以利後 續的語句轉換動作。
2.1 多租戶應用程式之資料層級設計
進行多租戶應用程式之資料層級設計時，如何提高租戶間資料存放的共享程 度是很重要的議題。下列各小節中，將探討三種不同共享程度的多租戶應用程 式之資料層級設計(圖 2.1)，並在後續的各個小節中，針對每一種技術在開發上 所面臨的問題進行探討並作出經濟效益上的評估，最末節提出在多租戶應用程 式之資料層級設計時所需要考量的因素。
2.1.1 多租戶應用程式之資料層級設計分類
圖 2.1 三種多租戶應用程式之資料層級技術
(Separate Databases、Separate Schemas、 Shared Schema)共享程度示意圖 共享程度
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
10
多租戶應用程式之資料層級設計依租戶資料存放的共享程度，如圖 2.1 所示，
可以簡單地分成三類，從租戶資料存放的共享程度由低到高，分別是 : Separate Databases、Separate Schemas 以及 Shared Schema[Chong et al.06]。採用 Separate Databases 的開發過程較容易且租戶的資料安全性也較高，但是，由 於每個租戶都要負擔費用去建置、維護硬體設備，所以，在經濟效益上相對於 其它兩種技術來得低；採用 Separate Schemas 以及 Shared Schema 雖在初期的 開發過程需要較長的時間且需提供額外的機制去加強租戶資料的隔離性，但是，
由於租戶間資源共享程度較高，所以，可以降低每個租戶所需負擔的費用。
2.1.2 Separate Databases
Separate Databases 主要是將每個租戶的資料存在放在各自的獨立資料庫中，
以圖 2.2 為例，假定有三間學校(租戶)，分別為 Nccu、Fju 以及 Tku，每間學校 皆有三個資料表，分別是 StudentInfo(儲存該校學生資料)、SelectCourse(儲 存該校學生選課記錄)以及 CourseInfo(儲存該校課程資料)，每間學校提供一個 獨立的資料庫，讓每間學校可以各自將自己的資料存放在各自的獨立資料庫。
圖 2.2 Separate Databases 示意圖:各個 Tenant 的資料存放在各自獨立的 Database
‧
(restore data)的程序也比較容易，只需要獲得該租戶的備份資料(back-up data)來進行還原資料(restore data)的動作。但相對地，以經濟效益的層面看 小節，將提出兩種方法(Separate Schemas、Shared Schema)可以透過技術來突 破有限的硬體環境，實現多租戶的理想。2.1.3 Separate Schemas
Separate Schemas 主要是將每個租戶的資料存放在同一個的資料庫中，同時，
每個租戶又各自擁有各自的資料表集合，不同的租戶之間，資料表綱要(schema) 也不完全相同。以圖 2.3 為例，假定有三間學校(租戶)，分別為 Nccu、Fju 以 及 Tku，每間學校可以根據自己的需求去制訂屬於自己的資料表綱要(schema) 以及資料表集合存放在同一個資料庫裡。從圖 2.3 的紅色方框部份可以發現 Nccu 的 CourseInfo 資料表綱要和另外兩間學校的 CourseInfo 資料表綱要有明顯的 不同，這就是本研究一直提到的重點：租戶可以擁有客製化欄位的能力。
由於各個租戶都擁有各自的資料表集合，所以，仍然可以根據自己的需求 制定資料表綱要(schema)。但還是有一些缺點，一旦有一個租戶的資料表毀損 或是資料遺失，還原資料(restore data)的程序就會比採用 Separate Databases
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
12
來得複雜，必須利用備份資料(back-up data)對整個資料庫進行還原資料 (restore data)的動作才能解決問題[Chong et al.06]。
圖 2.3 Separate Schemas 示意圖:各個租戶將各自不同的資料表綱要 以及資料表集合存放在同一個資料庫
此外，這種方法將所有租戶的資料都存放在同一個資料庫中，因此，不同 租戶間的資料隔離程度降低，同時，資料的安全性也相對降低，所以，”如何 設計好的隔離機制以防止租戶的資料遭到攻擊”變成了一個很重要的議題。
在有限的硬體設備下，和採用 Separate Databases 方法相比，這種方法能 夠提供服務給較多的租戶，相對地，每個租戶所需要負擔的費用也大幅降低，
但有一個重要的前提是租戶要能夠了解並且同意它的資料和其它租戶的資料是 放在同一個資料庫中；軟體開發人員也要事先將一些安全上的顧慮告知租戶並 且提供相對應的隔離機制來有效地提升資料的安全性。
2.1.4 Shared Schema
Nccu
Nccu Nccu
Nccu
Fju Tku
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
13
這種方法是利用資料庫裡面的單一資料表去存放所有租戶的資料，並將資料依 序存放在共用表格欄位 (Col1、Col2、Col3、Col4…) 中，利用 TenantId 以及 Table 這兩個欄位作為依據去區分不同的租戶的資料(record)。以圖 2.4 為例，
假定有三間學校(租戶)，分別為 Nccu、Fju 以及 Tku，其相對應的 TenantId 即 以其學校英文代號表示(即 Nccu、Fju 以及 Tku)，利用 Table 欄位(1、2、3…) 去區分不同的資料表，例如：同樣 TenantId 為 Nccu，但 Table 欄位不同(1、2) 則代表兩個同租戶但存放不同資料的資料表(圖 2.4 中綠色及藍色方框)。共用 欄位(Col1、Col2、Col3、Col4…)則依照每個租戶自訂的資料表綱要(schema) 去依序存放每一筆紀錄(record)。
圖 2.4 Shared Schema 示意圖:各個租戶將各自的資料表存放在同一個資料庫的單一資料表中
由於所有的租戶資料都存放在同一個資料表中，所以，可支援的租戶數目 增加了，因此，和上述兩種方法相比，租戶所需負擔的費用更低。但同時，資 料的安全性就降低許多，如果沒有好的隔離機制去區分租戶，很容易會讓租戶 的資料遭受攻擊。除此之外，還需要額外提供資料表去紀錄每個租戶所有資料 表的詮釋欄位(meta-data)，以協助之後執行資料庫存取動作。另外，還原資料 (restore data)的部份，一旦有資料毀損或是遺失，則需要將整個資料庫進行 還原資料(restore data)的動作才能解決問題[Chong et al.06]。
相對於前兩種方法，採用 Shared Schema 方法更能充分地利用硬體設備，
簡單來說，也就是在有限的硬體設備下，提供給相較於上述所有方法中最多的
‧
Shared Schema 可以提供服務給最多數量的租戶，但是，軟體開發人員必需 事先將一些安全上的顧慮告知租戶並且提供相對應的隔離機制來有效地提 升資料的安全性。2. 資料的安全性：當租戶資料是屬於需要較高的安全性(例如:醫療紀錄、銀行 交易資料)的資料，則採用 Separate Databases 會較為適當。但事實上，如 果採用 Shared Schema、Separate Schemas，額外搭配一些隔離機制，也是 可以提供高度的資料安全性。
3. 租戶的數量以及需求：租戶的數量、每個租戶的資料量大小都會影響到多租 戶應用程式之資料層級設計。如圖 2.5 所示，若租戶的數量很多，則採用 Shared Schema 會比較節省成本；若每個租戶所存放的資料量很大，則採用 Separate Databases 的方式或許比較合適。
圖 2.5 租戶的數量以及每個租戶的資料量大小影響圖 Separate Databases Separate Schemas Shared Schema
租戶的數量
每個租戶的資料量大小
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
15