殷偉鳳

摘 要：云計算是通過互聯(lián)網(wǎng)以服務的形式為客戶提供企業(yè)級計算資源的技術。最普遍使用的服務是軟件即服務（SaaS）。許多SaaS提供者利用多租戶模式來托管應用。多租戶是一種架構方法，軟件應用程序的單實例服務多個租戶，因此多租戶設計關鍵要解決的是租戶數(shù)據(jù)的共享與隔離。文章論述了多租戶架構中數(shù)據(jù)存儲管理的三種方式，詳細描述了共享表時多租戶數(shù)據(jù)庫的具體實現(xiàn)策略，指出了各種模式映射技術的優(yōu)缺點，最后給出了將來的研究目標。

關鍵詞：多租戶；模式映射技術；軟件即服務；數(shù)據(jù)管理

中圖分類號：TP391 文獻標識碼：A

1 引言（Introduction）

云計算已經(jīng)成為最重要的計算技術。云計算是一個能夠方便地按需對可配置計算資源（例如網(wǎng)絡、服務器、存儲、應用程序和服務）的共享池進行網(wǎng)絡訪問的模型[1]。目前在云計算范式中最重要的服務是軟件即服務（SaaS），SaaS是軟件的一種新型的云計算服務交付模式，可通過互聯(lián)網(wǎng)以“按需服務”的形式為多個用戶提供應用程序。企業(yè)通過訂購SaaS服務，無需購買和維護自己的IT設施就可使用各類IT服務，減少了軟硬件、網(wǎng)絡、系統(tǒng)維護的費用。而對于服務提供商，則通過發(fā)揮SaaS的規(guī)模效應來降低綜合使用成本。如Saleforce.com、Goole.com、Alisoft.com等都是SaaS應用的典型成功案例。SaaS應用程序最重要的需求是多租戶的支持[2]，為了最大化SaaS的規(guī)模效應，一般采用的都是多個租戶共享一個運行實例的架構（Multi-Tenant架構，即多租戶架構）。

多租戶是SAAS業(yè)務模型領域一種較新的軟件架構，在此架構模式中，允許多個租戶共享硬件資源以及應用程序和數(shù)據(jù)庫，并可根據(jù)租戶需求配置應用程序[3]。可配置性是多租戶模式的重要特征。在多租戶應用中，所有的租戶都使用同一個數(shù)據(jù)庫實例，因此必須確保每個租戶只能訪問它們各自的數(shù)據(jù)，因此數(shù)據(jù)隔離成為多租戶應用中最為關鍵的問題[4]。

2 多租戶數(shù)據(jù)存儲方案（Data storage schema for

muti-tenant）

SaaS區(qū)別于傳統(tǒng)技術的重要差別就是多租戶模式，多租戶架構是SaaS應用的基本特性，也是實現(xiàn)SaaS規(guī)模效應的基本要素。多租戶就是多個租戶共用一個實例，租戶的數(shù)據(jù)既有隔離又有共享，因此多租戶設計的關鍵是如何解決數(shù)據(jù)存儲問題。

2.1 多租戶數(shù)據(jù)存儲方案

目前管理多租戶數(shù)據(jù)主要有三種方法[5]：獨立數(shù)據(jù)庫、共享數(shù)據(jù)庫和獨立數(shù)據(jù)模式、共享數(shù)據(jù)庫和共享數(shù)據(jù)模式。

獨立數(shù)據(jù)庫方式是指一個租戶一個數(shù)據(jù)庫，如圖1所示，這是進行數(shù)據(jù)隔離最簡單的方法，該方案用戶數(shù)據(jù)隔離級別最高，安全性最好，但成本也高。該方案的優(yōu)點是：為不同的租戶提供獨立的數(shù)據(jù)庫，有助于簡化數(shù)據(jù)模型的擴展設計，滿足不同租戶的獨特需求；如果出現(xiàn)故障，恢復數(shù)據(jù)比較簡單。該方案的缺點是：增大了數(shù)據(jù)庫的安裝數(shù)量，隨之帶來維護成本和購置成本的增加。

圖1 獨立數(shù)據(jù)庫

Fig.1 Separate database

共享數(shù)據(jù)庫和獨立數(shù)據(jù)模式是指多個或所有租戶共享數(shù)據(jù)庫，但一個租戶一個數(shù)據(jù)模式。如圖2所示。該方案的優(yōu)點是：為安全性要求較高的租戶提供了一定程度的邏輯數(shù)據(jù)隔離；每個數(shù)據(jù)庫可以支持更多的租戶數(shù)量。缺點是：如果出現(xiàn)故障，數(shù)據(jù)恢復比較困難，因為恢復數(shù)據(jù)庫將牽扯到其他租戶的數(shù)據(jù)；如果需要跨租戶統(tǒng)計數(shù)據(jù)，存在一定困難。

圖2 共享數(shù)據(jù)庫，獨立模式

Fig.2 Shared database，separate schema

共享數(shù)據(jù)庫和共享數(shù)據(jù)模式是指租戶共享同一個數(shù)據(jù)庫，同一個模式，但在表中通過租戶ID區(qū)分租戶的數(shù)據(jù)，如圖3所示。這是共享程度最高、隔離級別最低的模式。該方案的優(yōu)點是：維護和購置成本最低，允許每個數(shù)據(jù)庫支持的租戶數(shù)量最多。缺點是：隔離級別最低，安全性最低，需要在設計開發(fā)時加大對安全的開發(fā)量；數(shù)據(jù)備份和恢復最困難，需要逐表逐條備份和還原。

圖3 共享數(shù)據(jù)庫，共享模式

Fig.3 Shared database，shared schema

2.2 三種方案的比較及選擇

從隔離和共享兩個相反的方向比較，依次是獨立數(shù)據(jù)庫、共享數(shù)據(jù)庫和獨立數(shù)據(jù)庫、共享數(shù)據(jù)庫和共享數(shù)據(jù)模式，三種方案比較如圖4所示，三種方法都有各自的優(yōu)缺點。選用時可以從經(jīng)濟性、安全性、租戶以及技能等因素去考慮。

圖4 三種數(shù)據(jù)存儲模式比較

Fig.4 Compare for three kinds of dada storage schema

因為開發(fā)共享結構相對比較復雜，在初始開發(fā)時需比使用獨立方法設計應用程序付出更大的開發(fā)工作，但每個服務器可支持更多的租戶，持續(xù)的運營成本更低。因此如果無法為構建一個共享模式應用提供足夠的開發(fā)支持或需要盡快使應用上市而不能進行大規(guī)模開發(fā)，那么必須更多的考慮獨立的方法。

如果應用程序存儲了敏感的租戶數(shù)據(jù)，客戶都會對安全性有較高的預期，需要提供強大的數(shù)據(jù)安全性保障服務水平協(xié)議（SLA）。通常依靠物理隔離可以提供較好的安全級別。使用共享方法存儲數(shù)據(jù)也可以提供強大的數(shù)據(jù)安全，但需要使用更復雜的設計模式。

服務的租戶數(shù)量、屬性和需求也是確定不同方式數(shù)據(jù)架構的因素。租戶越多越要多考慮共享方法。如果各租戶需存儲大量的數(shù)據(jù)，獨立數(shù)據(jù)庫方法可能會更好。需要支持每個租戶的并發(fā)終端用戶數(shù)量越大，獨立方法將越適合滿足終端用戶的需求。如果希望為每個租戶提供增值服務，如每個租戶的備份和恢復能力，這樣的服務通過獨立的方法更容易提供。

設計單實例多租戶架構仍然是很新的技能，缺乏現(xiàn)成的專業(yè)技能。如果設計師和職員沒有足夠的構建SaaS應用的經(jīng)驗，他們需要獲得必要的知識，或者必須雇傭有經(jīng)驗的人員。在某些情況下，獨立方法比共享方法可更多地利用傳統(tǒng)軟件開發(fā)的現(xiàn)有知識。

3 多租戶數(shù)據(jù)庫實現(xiàn)（Realizing multi-tenant

database）

與上述三種數(shù)據(jù)存儲管理相對應的有三種實現(xiàn)多租戶數(shù)據(jù)庫的方法[6]：共享主機、共享進程和共享表。

在共享機器的方法中，每個客戶都有自己的數(shù)據(jù)庫進程并且多個客戶共享同一個主機。此方法無需修改數(shù)據(jù)庫的實現(xiàn)，基本上不會降低客戶隔離度。但該方法不是池式內(nèi)存，每個數(shù)據(jù)庫在每個應用服務器上都需要有自己的連接池，套接字無法在客戶間共享。

在共享進程方法中，每個客戶都有自己的表并且多個客戶共享同一個數(shù)據(jù)庫進程。此方法更有利于池式內(nèi)存，可方便進行每個服務器的客戶數(shù)擴展?？蛻糸g可以共享連接池。

共享表方法對于池式資源是最合適的。擴展能力僅受限于數(shù)據(jù)庫支持的行的數(shù)目，比共享進程方法要提高幾個數(shù)量級?？蛻裟芄蚕磉B接池，可以成批執(zhí)行管理操作。但該方法由于在磁盤上的文件是來自多個租戶的混合數(shù)據(jù)，遷移比較困難。另外混合數(shù)據(jù)分布在許多頁會影響訪問客戶數(shù)據(jù)的性能，共享連接池和數(shù)據(jù)使安全性成為最關鍵的問題。

為了實現(xiàn)多租戶，大多數(shù)托管服務使用查詢變換把應用程序中的多個單租戶邏輯模式映射到數(shù)據(jù)庫中一個多租戶物理模式。這種方法會降低服務器的性能，改進的方法是在租戶間共享表，但這種技術可能會影響租戶擴展應用程序的能力。最靈活的解決方案是將邏輯表映射到固定的通用結構，如通用表和透視表。

實現(xiàn)共享表的多租戶數(shù)據(jù)庫可采用多種存儲模型，這些模型稱為模式映射技術[7]，主要有基本布局、私有表布局、擴展表布局以及通用表布局、透視表布局、Chunk表布局等通用結構。

（1）基本布局

實現(xiàn)多租戶的最基本的技術是每個表增加一個租戶ID列（Tenant），所有的租戶共享此表。這種方法是從服務提供者的角度而不是租戶角度來看待數(shù)據(jù)，提供了較好的合并但不具有擴展性，傳統(tǒng)Web應用程序大都采用此方法。

（2）私有表布局

支持擴展性最基本的方法是每個租戶設置各自的私有表。在此方法中，查詢轉換層只需要重命名表名，非常簡單。此方法每個租戶都有不同的業(yè)務需求，需要有大量的表來滿足每個租戶的需求，因此該技術適用于較少數(shù)量的租戶。

（3）擴展表布局

可以結合上述兩種方法，擴展成不同的表。將源表分成基表和擴展表兩部分，多個租戶可以使用同樣的基表，擴展表和基表都需要一個Tenant列，還要增加一個Row列。這種方法比私有表提供了更好的合并性，但表的數(shù)量也會與租戶數(shù)成比例增加。

（4）通用表布局

通用結構允許創(chuàng)建任意形狀任意數(shù)量的表。通用表是一個有Tenant列、table列和許多通用數(shù)據(jù)列的通用結構表。數(shù)據(jù)列設置成一個靈活的類型，如VARCHAR類型，其他的類型可轉換為該類型。每個租戶的每個邏輯源表的第n列映射到通用表的第n個數(shù)據(jù)列，因此不同的租戶可以以不同的方式擴展同一個表。該種方法的缺點是數(shù)據(jù)表較寬，數(shù)據(jù)庫必須要處理許多空值，另外對索引支持不是太方便。

（5）透視表布局

透視表是一個可選的通用結構，在透視表中，邏輯源表中的每一行的每個字段都對應著一行。除了上述描述的Tenant、Table和Row列，透視表還有一個Col列指明了這一行所表示的是源表中的哪個字段以及一個數(shù)據(jù)列表示出那個字段的值。數(shù)據(jù)列可以給定一個靈活的類型，如VARCHAR，其他類型也可以轉換為此類型。此方法無需處理許多空值，可以較好地支持索引，但增加了元數(shù)據(jù)，增加了運行開銷，連接操作較費時。

（6）Chunk表布局

第三類通用表稱之為Chunk表。Chunk表類似于透視表，但有一組不同類型的數(shù)據(jù)列，col列被Chunk列取代，一個邏輯源表被劃分為多組列，每組設置一個chunk_ID，將一組列映射到一個Chunk表中。相比透視表，該方法減少了存儲元數(shù)據(jù)，降低了重構邏輯源表的開銷。

（7）Chunk Folding

這是一種將源表垂直劃分成塊放入不同物理多租戶表的一種技術，在需要的時候可進行連接。該技術將最常使用的租戶列映射到傳統(tǒng)表中，而其他列放在Chunk表中，數(shù)據(jù)庫的“元數(shù)據(jù)開銷”分攤給了專用的傳統(tǒng)表和一組稱為CHunk表的通用結構。應用Chunk Folding方法，參考文獻[8]中提出了基于Chunk Folding的自適應多租戶緩存管理機制，該機制以租戶的SLA需求作為驅(qū)動，依據(jù)租戶當前訪問模式，動態(tài)生成緩存單元集并計算緩存單元集的I/O效益，通過貪婪算法來選擇緩存單元集，使得租戶SLA得到滿足的同時最小化緩存資源的消耗。

4 XML支持實現(xiàn)多租戶數(shù)據(jù)庫（XML for realizing

multi-tenant database）

XML和關系數(shù)據(jù)庫是兩種完全不同的技術集，XML支持層次數(shù)據(jù)模型，而數(shù)據(jù)庫支持關系數(shù)據(jù)模型。關系數(shù)據(jù)庫的缺點是在數(shù)據(jù)庫層缺乏對租戶概念的支持，因此，必須在通用表的行存儲租戶ID。在參考文獻[9]中提出了一種針對多租戶應用的混合模式共享技術，該方法由兩張表組成，一張用于租戶的通用內(nèi)容，如ID、名稱、聯(lián)系方式等，如表1所示。

表1 通用表

Tab.1 Universal table

Manager ID

INT Username

VARCHAR Full Name

VARCHAR Contact

INT County ID

INT

1 Ramachan Ramachandra Nayak 0831456721 2

2 Ashutosh AshutoshAgarwal 084178654 1

3 priya123 Priyanka Choudary 0832567842 3

另一張擴展表針對每一個租戶。擴展表由兩行組成：一是租戶的ID，另一行包含了一個描述某一個租戶的其他信息的XML文檔，如表2所示。每個租戶都有其存儲空間存儲私有數(shù)據(jù)。該方法采用了將擴展表與XML文檔相結合的基本思想。

表2 XML擴展表

Tab.2 XML extension table

Manager ID Extension XML

1

120