多租戶 SaaS 實作
4.3 多租戶 SaaS 效能測試
中的 CustomFields 來處理未來租戶所客製的欄位。客製商品欄位使用案例經由以 上的步驟並搭配 CustomizationHandler 的新增、修改、刪除自訂欄位方法得以實 現。以下程式碼片段為購物商城 SaaS 開發人員如何取得未來租戶自訂的商品欄 位資料，首先使用 JDOQL 取得 ProductId 為 3 的商品，接著將其轉型為
CustomObject 後，再利用迴圈來處理未來租戶所自訂的欄位：
PersistenceManagerFactory pmf =
JDOHelper.getPersistenceManagerFactory(DataNucleusHelper.createProperties());
Query q = pmf.getPersistenceManager().newQuery(
"select from com.arthur.shoppingmall.domain.Product where productId=='3');
List<Product> result = (List<Product>)q.execute();
Product p = result.get(0);
CustomObject co = (CustomObject)p;
List<CustomField> cfs = co.getCustomFields();
for (CustomField customField : cfs) { //取得租戶自定義CustomField
… }
圖 4.9：開發人員如何取得租戶自定義欄位範例。
至於維護自定義物件使用案例，主要為實現租戶客製自有領域物件增刪修查 詢之功能。因此可利用中介軟體框架所提供的 CustomizationHandler 來建立、儲 存 CustomObject 與 CustomField 以及刪除 CustomObject 的資料，此外查詢的功 能也可透過 CustomizationHandler 中的 find 開頭的相關方法來查詢 CustomObject 的資料與 Metadata。維護自定義物件使用案例所包含的建立自定義物件關聯與查 詢自定義物件 By 索引欄位這兩個使用案例，分別透過 CustomizationHandler 的 saveCustomObjectRelationship 與 findCustomObjectsByIndexes 這兩個方法即可實 現。
4.3 多租戶 SaaS 效能測試
基於中介軟框架所實作的購物商城 SaaS 為了實現租戶虛擬資料庫採用了
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Universal Table 資料架構。不同於傳統的 Private Table 資料綱要，Universal Table 資料架構將所有租戶的資料都保存於同一個資料表中，因此本小節將針對購物商 城 SaaS 所使用的 Universal Table 資料架構與傳統的 Private Table 進行效能上的比 較測試。
測試情境為購物商城 SaaS 擁有 100 個租戶，每個租戶擁有 10 萬筆資料於 Universal Table 的 Data 資料表中，與 Data 資料表搭配的 Specialized Pivot 資料表 Indexes、UniqueFields、Relationships 分別有 1000 萬、1000 萬、500 萬筆資料；
對照的 Private Table 資料表內含有 10 萬筆資料。
由於購物商城 SaaS 的測試資料量已達一定程度，因此必須在資料上建立 Index，才能有效地進行資料操作。以下為購物商城 Universal Table 資料架構所建 立的 Index：
圖 4.10：購物商城 SaaS 資料綱要 Index 圖。
購物商城 SaaS 資料綱要 Index 的建立準則為依據經常使用的 Where 條件欄 位來建立。Data 資料表中建立兩組 Index 分別為 TenantId 與 TenantId、ObjectId；
Indexes 與 UniqueFields 資料表的 Index 為 TenantId、ObjectId、FieldNum 以及根 據 Data 資料表 Value 欄位實際資料型別所建立的欄位；Relationships 資料表 Index
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
為 TenantId、DataGuid 以及 TenantId、ObjectId、AssociationId、TargetObjectId 這兩組 Index。
測試環境的建置方式為在區域網路中佈署了一台伺服器，此伺服器同時擔負 了應用程式與資料伺服器的角色，其硬體規格採用四核心 3.10 GHz 的 CPU、記 憶體為 4GB、硬碟為 256 GB 的固態硬碟。測試的客戶端為一般桌上型個人電腦，
硬體規格採用了雙核心 2.53GHz 的 CPU、記憶體為 4GB、硬碟為 256 GB 的固 態硬碟，此桌上型個人電腦將透過區域網路存取伺服器端。
圖 4.11：測試環境佈署圖。
測試方式為伺服器提供可執行 Private Table 的 SQL 指令、符合 Universal Table 的 SQL 指令以及中介軟體框架 ORM 的 JDOQL 的 RESTful 服務，客戶端 透過執行測試程式存取 RESTful 服務並測量其反應時間。測試項目則為執行相同 邏輯之 Select、Insert、Delete、Update 資料存取指令的 RESTful 服務，測量方式 為各執行十次，去除最高與最低量測結果算出平均反應時間。以下為測試結果：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 4.12：效能測試結果。
表 4.1：效能測試結果。
Private Table Universal Table (SQL Command)
Universal Table (JDOQL) Select 0.446945 5.179383 14.006657 Insert 1.382374 13.715416 14.424608 Delete 0.526487 10.256461 16.09107 Update 0.523854 9.102869 15.365716 單位 ms
從表 4.1 的測試結果中可看出四個測試項目 Private Table 的反應時間都是最 快，使用 Universal Table 資料架構的 SQL 指令反應時間大約慢了 Private Table 5~13 ms，中介軟體框架 ORM 又比單純使用 Universal Table 資料架構的 SQL 指 令慢了約 1~9ms，其主要原因為中介軟體框架 ORM 需將 JDOQL 轉成符合 Universal Table 資料架構的 SQL 指令，以及將查詢結果對映至領域物件。不過使 用 Universal Table 資料架構的測試結果仍在可接受範圍內，因為使用 Universal Table 資料架構必須搭配其 Metadata 與 Specialized Pivot 資料表；以查詢為例，
使用 Universal Table 資料架構比單純使用 Private Table 要多了 3~6 次的存取資料
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
庫，不過反應時間都未超過 20ms。根據此測試情境有 100 個租戶，如果是使用 Private Table 資料綱要的設計模式，那就會有 100 套租戶的私有資料綱要，對於 購物商城 SaaS 開發人員這樣的資料綱要維護起來會相當的辛苦；但使用
Universal Table 就只需要維護一套資料綱要，並搭配中介軟體框架的 ORM，不論 是開發或是維護都大大減輕了 SaaS 開發人員的負擔，進而降低開發與維護的成 本。