第一章 緒論
1.5 論文大綱
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
7
3. 探討影響本系統工具效能的因素，另外，實際測試本系統工具在效能上 所造成的影響並根據其測試結果評估此作法的可行性。
1.5 論文大綱
本論文分成五個章節，第一章為緒論，主要對研究的動機、目的進行解說，
同時，簡單地對系統工具的實作設計、研究結果作概略性說明。第二章主要 介紹三種多租戶應用程式之資料層級設計，另外，介紹 SQL 語句結構剖析之 工具－JSqlParser 的相關技術。第三章則完整地從設計層面到實作層面對本 系統工具的核心架構進行詳細地解說。第四章將實際使用本系統工具協助多 租戶應用程式之資料層級設計以展示採用本系統工具的優點。另外，進行一 連串的實驗，藉著實驗結果推斷影響本系統工具執行時間的因素。最後，進 行多項測試去更進一步地了解實際使用本系統工具在效能上會造成哪些影響 並根據其結果進行可行性評估。在最後第五章的部分，提出結論並探討未來 值得深入研究的發展方向以及相關議題。
‧
節的 Extension Table Layout 提出了共有欄位、私有欄位的觀念，除了滿足租 戶客製化欄位的需求外，亦可以提升軟體開發人員對租戶共有欄位以及其資料 進行統一管理的能力，藉此可以讓軟體開發人員更容易開發多租戶應用程式。Extension Table Layout 的資料存放方式會讓軟體開發人員無法沿用一租
‧ 國
立 政 治 大 學
‧
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
2.2 多租戶應用程式之資料表綱要類型
目前實作多租戶應用程式之資料層級設計有兩種方式。一租戶一資料庫的方式 在成本上極為浪費，無法達到資源共享的理念；多租戶共享一資料庫的方式雖 然符合資源共享的理念，但缺乏擴充性，所有的租戶都必需使用同一種資料表 綱要(Schema)，無法達到客製化的理想。所以，在接下來的各個小節中，將在 上述二種方式中找到一個平衡點，從資料表綱要設計的面向，提供多種既可讓 租戶共享資料庫又可滿足租戶適度地客製化欄位需求的資料表綱要類型。
2.2.1 Private Table Layout
假設目前有三間學校(租戶)： Nccu、Fju、Tku，圖 2.6 是每間學校都要使用的 一個資料表：CourseInfo。所有學校的 CourseInfo 資料表都有 CourseId、
CourseName、Instructors、Credit、Days、Time 這六個共有欄位，但也有各間 學校各自擁有的私有欄位(即客製化欄位)以表達客製化欄位的需求。
圖 2.6 基礎範例(Private Table Layout 示意圖)：
三間學校(租戶)各別擁有不同的 CourseInfo 資料表，有共有欄位，
同時，也有各別租戶所需要的私有欄位以表達客製化欄位需求
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
16
Private Table Layout [Aulbach et al.08]，此種方法是將不同租戶的資 料放置在不同的資料表，這是最常見、最簡單的多租戶應用程式之資料表綱要 設計。主要優點是租戶客製化資料表綱要的程度高，缺點是當租戶的數量一增 加，其資料表的數量也隨之增加，且無法達到資源共享的理想。後面的章節將 以此範例為基礎，介紹其他三種多租戶資料表綱要的設計技巧。
2.2.2 Universal Table Layout
Universal Table Layout [Aulbach et al.08]，此種方法是將所有租戶的資料
Universal Table Layout [Aulbach et al.08]，此種方法是將所有租戶的資料