前言
在如今的中小企業(yè)管理軟件市場(chǎng)中，特別是在中國，應用企業(yè)管理軟件來(lái)優(yōu)化運營(yíng)及提升企業(yè)生產(chǎn)效率的需求一直在持續上升，而其中基于軟件即服務(wù)理念的SaaS模式也為很多企業(yè)所青睞，但由于目前市場(chǎng)上這一模式的解決方案所能覆蓋的范圍有限，而且有些開(kāi)發(fā)實(shí)施運營(yíng)中的關(guān)鍵問(wèn)題遲遲得不到很好的解決，導致這一市場(chǎng)還沒(méi)有能被真正被開(kāi)發(fā)起來(lái)。
本文嘗試通過(guò)對國內外對于基于SaaS模式的數據模型的幾種常見(jiàn)思路及其適用場(chǎng)景的研究，對這方面的若干關(guān)鍵問(wèn)題進(jìn)行初步的探討和分析。
一. SaaS系統常見(jiàn)數據模型
在設計SaaS系統的數據模型時(shí)出于服務(wù)客戶(hù)及減低開(kāi)發(fā)成本等考慮，在數據的共享和隔離之間求得一定的平衡是必須考慮的一個(gè)重要因素。
因此一般在設計對應數據模型時(shí)不僅要考慮到技術(shù)因素，例如怎樣構建一個(gè)彈性架構以支持數目不定的客戶(hù)、怎樣消除大容量并發(fā)訪(fǎng)問(wèn)數據庫對系統性能造成的壓力以及怎樣允許用戶(hù)按需擴展自定義數據等;同時(shí)也必須將商業(yè)因素納入考慮范圍之中，例如架構在該SaaS系統上的業(yè)務(wù)應用主要面向哪些行業(yè)的客戶(hù)、目標客戶(hù)對于數據存儲方式是否有基于一定法律法規的要求等等。一般而言，SaaS系統的數據模型有如下三種形式：
1.1獨立數據庫
將每個(gè)客戶(hù)的數據單獨存放在一個(gè)獨立數據庫是實(shí)現數據隔離的一種最為簡(jiǎn)便的解決方案。
在應用這種數據模型的SaaS系統中，大部分系統資源和應用代碼還是由所有的客戶(hù)所共享使用，但物理上每個(gè)客戶(hù)有自己的一整套數據，而且單獨存放。系統將借由元數據(Metadata)來(lái)記錄哪一個(gè)數據庫屬于哪一個(gè)特定客戶(hù)，與此同時(shí)也可以部署一定的數據庫訪(fǎng)問(wèn)策略來(lái)確保即使系統處于異常狀況下，客戶(hù)數據也不會(huì )被其它客戶(hù)意外訪(fǎng)問(wèn)到。
當客戶(hù)由于所處行業(yè)因素或其它商業(yè)因素的限制，愿意支付額外的費用來(lái)做到數據隔離，確保數據安全，這種獨立數據庫的數據模型將是最為適合的解決方案。舉例來(lái)說(shuō)，處于銀行業(yè)或醫療行業(yè)的客戶(hù)們經(jīng)常會(huì )有非常強的隔離數據的需求，這些客戶(hù)甚至可能根本不會(huì )考慮去使用任何不提供客戶(hù)獨立數據庫支持的SaaS系統。
1.2共享數據庫 單獨模式(Schema)
第二種方式則是所有客戶(hù)使用同一數據庫，但各自擁有一套不同的數據表組合存在于其單獨的模式之內。
在這種數據模型下，當客戶(hù)嘗試第一次使用該SaaS系統時(shí)，系統在創(chuàng )建用戶(hù)環(huán)境時(shí)會(huì )創(chuàng )建一整套默認的表結構，同時(shí)將其關(guān)聯(lián)到該客戶(hù)的獨立模式。此時(shí)一般使用SQL CREATE命令來(lái)創(chuàng )建模式，同時(shí)授權一個(gè)用戶(hù)賬號來(lái)訪(fǎng)問(wèn)該模式。舉例來(lái)說(shuō)，在SQL Server 2005 中可以使用如下命令：
| 以下是引用片段： CREATE SCHEMA ContosoSchema AUTHORIZATION Contoso |
| 以下是引用片段： CREATE TABLE ContosoSchema.Resumes (EmployeeID int identity primary key, Resume nvarchar(MAX)) |
| 以下是引用片段： ALTER USER Contoso WITH DEFAULT_SCHEMA = ContosoSchema |
| 以下是引用片段： SELECT * FROM Resumes |
這種客戶(hù)獨立模式的方式在數據共享和隔離之間獲得了一定的平衡，它既借由數據庫共享使得一臺服務(wù)器就可以支持更多的客戶(hù)，又在物理上實(shí)現了一定程度的數據隔離以確保數據安全。
但這種解決方案的一個(gè)不利之處就是當系統出現異常情況需要將歷史備份數據重新恢復的話(huà)，流程將變得相對復雜。因為如果每個(gè)客戶(hù)擁有獨立數據庫的話(huà)，那么只需恢復該客戶(hù)最近的數據庫備份即可。但在獨立模式的模式下，如果簡(jiǎn)單的恢復數據庫備份，那就意味著(zhù)數據庫內所有客戶(hù)的數據將一同被恢復，無(wú)論該客戶(hù)是否數據受損或需要做數據恢復與否。因此，在獨立模式下，如果系統管理員希望恢復某個(gè)特定客戶(hù)的數據，需要將數據庫的備份解壓到某臨時(shí)服務(wù)器空間內，然后選定特定客戶(hù)的表數據將其覆蓋到系統主數據庫內，一般來(lái)說(shuō)，這將是一項非常復雜且耗時(shí)的工作。
這種客戶(hù)獨立模式的方式比較適合應用在每個(gè)客戶(hù)擁有比較少的表數量的情況下，比如每個(gè)客戶(hù)只有100張表或更少。這種方式毫無(wú)疑問(wèn)可以在每臺服務(wù)器上支持比獨立數據庫方式更多的客戶(hù)數量，減低了服務(wù)供應商的運營(yíng)成本。因此一旦SaaS系統的潛在客戶(hù)們不介意其數據與其它客戶(hù)的數據物理上存放在同一數據庫內，這將是SaaS系統開(kāi)發(fā)商一種理想的選擇。
1.3共享數據庫 共享模式(Schema)
第三種方式是用一個(gè)數據庫和一套數據表來(lái)存放所有客戶(hù)的數據。在這種模式下一個(gè)數據表內可以包含了多個(gè)客戶(hù)的記錄，由一個(gè)客戶(hù)ID字段來(lái)確認哪條記錄是屬于哪個(gè)客戶(hù)的。
在所有這三種數據模型中，這種共享模式的方式具有最低的硬件成本和維護成本，而且每臺服務(wù)器可以支持最大數量的客戶(hù)。但是由于所有客戶(hù)使用同一套數據表，因此可能需要在保證數據安全性上花費更多額外的開(kāi)發(fā)成本，以確保一個(gè)客戶(hù)永遠不會(huì )因系統異常而訪(fǎng)問(wèn)到其它客戶(hù)的數據。
在這種共享模式的方式下，恢復備份數據的流程類(lèi)似上文提到的共享數據庫但獨立模式的方式，系統管理員解壓備份數據至臨時(shí)服務(wù)器空間，選定需要恢復的數據表，而且還需要額外的選定所需要恢復的客戶(hù)記錄，再導入到系統主數據庫內。如果此時(shí)有大量記錄需要導入，則系統的數據庫服務(wù)的性能將受到很大影響，而且所有正在使用系統的客戶(hù)也將受到影響。
如果SaaS服務(wù)供應商需要使用盡量少的服務(wù)器資源來(lái)服務(wù)盡可能多的客戶(hù)，而且潛在客戶(hù)們愿意在一定程度上放棄對數據隔離的需求來(lái)獲得盡可能低廉的服務(wù)價(jià)格，則這種共享模式的方式是非常適合的。
二. 開(kāi)發(fā)商如何選擇合適的數據模型
上述三種SaaS系統的數據模型各有其利弊，因此在為特定的SaaS應用選擇適合的數據模型時(shí)，必須考慮到下列因素：
2.1 成本因素
基于數據共享設計的SaaS系統要求較高的開(kāi)發(fā)成本(因為基于數據共享的系統架構相對比較復雜)，因此初始投入較大，到長(cháng)期來(lái)看運營(yíng)維護成本則相對較少。
而基于數據隔離設計的SaaS系統則由于所需要硬件會(huì )隨著(zhù)支持客戶(hù)數的上升而快速上升，因此相對初始投入尚可，但長(cháng)期來(lái)看會(huì )有一個(gè)比較高的運營(yíng)維護成本。
總體而言，選擇數據共享的方式從長(cháng)遠角度可以為SaaS服務(wù)供應商節省大量的金錢(qián)。但遠在其最終開(kāi)始盈利之前，該類(lèi)系統在開(kāi)發(fā)中就已經(jīng)需要大量的初期投入。如果無(wú)法投入所需的開(kāi)發(fā)資源，或者由于商業(yè)原因需要將所開(kāi)發(fā)的SaaS系統盡可能快的投放到市場(chǎng)，則選擇數據隔離的設計模式更為恰當。
2.2安全因素
通常在SaaS系統中會(huì )存放有很多敏感的客戶(hù)業(yè)務(wù)數據，因此客戶(hù)會(huì )對確保數據的安全性有很高的期望，SaaS服務(wù)供應商與客戶(hù)簽署的服務(wù)條款中會(huì )需要包含很多數據安全保障條款。當然，一般客戶(hù)常見(jiàn)誤解是只有采取數據隔離方式設計的SaaS系統才能完全確保數據的安全性;事實(shí)上，采取數據共享方式設計的SaaS系統一樣可以在使用了一些成熟的設計模式之后，為客戶(hù)提供很強的數據安全保障。
2.3客戶(hù)因素
一個(gè)SaaS系統將來(lái)所服務(wù)的潛在客戶(hù)的數量、商業(yè)背景乃至其業(yè)務(wù)需求都將在很大程度上影響數據模型的選擇，下面就是一些常見(jiàn)的可能會(huì )影響到?jīng)Q定的一些因素。
估算該SaaS系統所期待的潛在客戶(hù)數。到底是為數以百計的客戶(hù)設計這一系統還是數以千計，又或者更多數量。簡(jiǎn)單的說(shuō)，如果計劃支持的客戶(hù)數目越大，就應當越多地考慮使用數據共享的模式。
估算每個(gè)客戶(hù)平均使用的數據存儲空間。如果使用該SaaS系統的客戶(hù)可能會(huì )存儲海量數據，則獨立數據庫模式毫無(wú)疑問(wèn)是最佳選擇。
估算每個(gè)客戶(hù)平均所需要支持的終端用戶(hù)數。如果這個(gè)數字越大，則越應當考慮采用數據隔離的模式來(lái)滿(mǎn)足終端用戶(hù)的需求。
決定是否為每個(gè)客戶(hù)提供類(lèi)似于數據備份之類(lèi)的增值服務(wù)。一般而言，采用數據隔離的模式比較便于實(shí)現這類(lèi)服務(wù)。
2.4法律法規因素
公司、組織和政府機關(guān)經(jīng)常需要遵守特定的法律法規的要求從而影響其選擇使用哪一類(lèi)的SaaS系統，而這種影響一般體現在對數據安全性的關(guān)注上。因此在設計一個(gè)SaaS系統之初，就必須對可能會(huì )影響潛在客戶(hù)的法律法規做一定的調研，尤其是開(kāi)發(fā)企業(yè)管理軟件時(shí)，由于諸如財務(wù)、雇員管理、生產(chǎn)等諸多模塊都會(huì )受特定地域或行業(yè)法律法規的影響，因此這些因素必須在系統設計之初就納入考慮范圍。
2.5技能因素
對SaaS系統開(kāi)發(fā)商而言，設計一個(gè)單實(shí)例多用戶(hù)支持的系統架構仍然是一個(gè)很大的挑戰，要想熟悉對應的開(kāi)發(fā)工具，掌握相應的開(kāi)發(fā)環(huán)境，也需要一支具有相當技術(shù)實(shí)力的開(kāi)發(fā)團隊。相對來(lái)說(shuō)，選擇數據隔離的模式來(lái)開(kāi)發(fā)SaaS系統允許開(kāi)發(fā)人員更多的從以往的開(kāi)發(fā)傳統架構的軟件的經(jīng)驗中受益，對于技術(shù)力量不強的開(kāi)發(fā)商而言不失為一個(gè)明智的選擇。
聯(lián)系客服
