SaaS數(shù)據(jù)模型設(shè)計(jì)三種基本方案

申請免費(fèi)試用、咨詢電話：400-8352-114

SaaS數(shù)據(jù)模型設(shè)計(jì)有三種基本方案?？紤]到技術(shù)和商業(yè)的因素。三種方案各有優(yōu)劣。

SaaS系統(tǒng)的數(shù)據(jù)模型設(shè)計(jì)是一個(gè)復(fù)雜的工作，它不僅要考慮到技術(shù)因素，同時(shí)也必須將商業(yè)因素納入考慮范圍之中。

SaaS系統(tǒng)常見數(shù)據(jù)模型獨(dú)立數(shù)據(jù)庫

將每個(gè)客戶的數(shù)據(jù)單獨(dú)存放在一個(gè)獨(dú)立數(shù)據(jù)庫是實(shí)現(xiàn)數(shù)據(jù)隔離的一種最為簡便的解決方案。

在應(yīng)用這種數(shù)據(jù)模型的SaaS系統(tǒng)中，大部分系統(tǒng)資源和應(yīng)用代碼還是由所有的客戶所共享使用，但物理上每個(gè)客戶有自己的一整套數(shù)據(jù)，而且單獨(dú)存放。系統(tǒng)將借由元數(shù)據(jù)（Metadata）來記錄哪一個(gè)數(shù)據(jù)庫屬于哪一個(gè)特定客戶，與此同時(shí)也可以部署一定的數(shù)據(jù)庫訪問策略來確保即使系統(tǒng)處于異常狀況下，客戶數(shù)據(jù)也不會被其它客戶意外訪問到。

顯而易見的是，一旦每個(gè)客戶擁有其獨(dú)立數(shù)據(jù)庫，那他將可以輕易對其做個(gè)性化的修改來符合實(shí)際業(yè)務(wù)需求，而且如果系統(tǒng)出現(xiàn)異常情況需要將歷史備份數(shù)據(jù)重新恢復(fù)的話，也將是一項(xiàng)輕而易舉的工作。

但是，這種數(shù)據(jù)模型的最大問題是對應(yīng)的部署和維護(hù)成本非常高，硬件資源的消耗將明顯高于其它兩種方案，一臺服務(wù)器將只能支持有限數(shù)量的客戶。

共享數(shù)據(jù)庫單獨(dú)模式

第二種方式則是所有客戶使用同一數(shù)據(jù)庫，但各自擁有一套不同的數(shù)據(jù)表組合存在于其單獨(dú)的模式之內(nèi)。

這種客戶獨(dú)立模式的方式相對比較容易實(shí)現(xiàn)，而且從數(shù)據(jù)擴(kuò)展性而言，這種解決方案和獨(dú)立數(shù)據(jù)庫一樣，客戶可以相對自由地對其中的數(shù)據(jù)結(jié)構(gòu)進(jìn)行新增和修改。

這種客戶獨(dú)立模式的方式在數(shù)據(jù)共享和隔離之間獲得了一定的平衡，它既借由數(shù)據(jù)庫共享使得一臺服務(wù)器就可以支持更多的客戶，又在物理上實(shí)現(xiàn)了一定程度的數(shù)據(jù)隔離以確保數(shù)據(jù)安全。

但這種解決方案的一個(gè)不利之處就是當(dāng)系統(tǒng)出現(xiàn)異常情況需要將歷史備份數(shù)據(jù)重新恢復(fù)的話，流程將變得相對復(fù)雜。因?yàn)槿绻總€(gè)客戶擁有獨(dú)立數(shù)據(jù)庫的話，那么只需恢復(fù)該客戶最近的數(shù)據(jù)庫備份即可。但在單獨(dú)模式下，如果簡單的恢復(fù)數(shù)據(jù)庫備份，那就意味著數(shù)據(jù)庫內(nèi)所有客戶的數(shù)據(jù)將一同被恢復(fù)，無論該客戶是否數(shù)據(jù)受損或需要做數(shù)據(jù)恢復(fù)與否。

因此，在獨(dú)立模式下，如果系統(tǒng)管理員希望恢復(fù)某個(gè)特定客戶的數(shù)據(jù)，需要將數(shù)據(jù)庫的備份解壓到某臨時(shí)服務(wù)器空間內(nèi)，然后選定特定客戶的表數(shù)據(jù)將其覆蓋到系統(tǒng)主數(shù)據(jù)庫內(nèi)，一般來說，這將是一項(xiàng)非常復(fù)雜且耗時(shí)的工作。

這種客戶獨(dú)立模式的方式比較適合應(yīng)用在每個(gè)客戶擁有比較少的表數(shù)量的情況下，比如每個(gè)客戶只有100張表或更少。這種方式毫無疑問可以在每臺服務(wù)器上支持比獨(dú)立數(shù)據(jù)庫方式更多的客戶數(shù)量，減低了服務(wù)供應(yīng)商的運(yùn)營成本。

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

第三種方式是用一個(gè)數(shù)據(jù)庫和一套數(shù)據(jù)表來存放所有客戶的數(shù)據(jù)。在這種模式下一個(gè)數(shù)據(jù)表內(nèi)可以包含了多個(gè)客戶的記錄，由一個(gè)客戶ID字段來確認(rèn)哪條記錄是屬于哪個(gè)客戶的。

在所有這三種數(shù)據(jù)模型中，這種共享模式的方式具有最低的硬件成本和維護(hù)成本，而且每臺服務(wù)器可以支持最大數(shù)量的客戶。但是由于所有客戶使用同一套數(shù)據(jù)表，因此可能需要在保證數(shù)據(jù)安全性上花費(fèi)更多額外的開發(fā)成本，以確保一個(gè)客戶永遠(yuǎn)不會因系統(tǒng)異常而訪問到其它客戶的數(shù)據(jù)。

在這種共享模式下，恢復(fù)備份數(shù)據(jù)的流程類似上文提到的共享數(shù)據(jù)庫但獨(dú)立模式的方式，系統(tǒng)管理員解壓備份數(shù)據(jù)至臨時(shí)服務(wù)器空，間，選定需要恢復(fù)的數(shù)據(jù)表，而且還需要額外的選定所需要恢復(fù)的客戶記錄，再導(dǎo)入到系統(tǒng)主數(shù)據(jù)庫內(nèi)。如果此時(shí)有大量記錄需要導(dǎo)人，則系統(tǒng)的數(shù)據(jù)庫服務(wù)的性能將受到很大影響，而且所有正在使用系統(tǒng)的客戶也將受到影響。

開發(fā)商的抉擇

上述三種SaaS系統(tǒng)的數(shù)據(jù)模型各有其利弊，因此在為特定的SaaS應(yīng)用選擇適合的數(shù)據(jù)模型時(shí)，必須考慮到下列因素。

成本因素

基于數(shù)據(jù)共享設(shè)計(jì)的SaaS系統(tǒng)要求較高的開發(fā)成本（因?yàn)榛跀?shù)據(jù)共享的系統(tǒng)架構(gòu)相對比較復(fù)雜），因此初始投入較大，但長期來看運(yùn)營維護(hù)成本則相對較少。

而基于數(shù)據(jù)隔離設(shè)計(jì)的SaaS系統(tǒng)則由于所需要硬件會隨著支持客戶數(shù)的上升而快速上升，因此相對初始投入尚可，但長期來看會有一個(gè)比較高的運(yùn)營維護(hù)成本。

總體而言，選擇數(shù)據(jù)共享的方式從長遠(yuǎn)角度可以為SaaS服務(wù)供應(yīng)商節(jié)省大量的金錢。但遠(yuǎn)在其最終開始盈利之前，該類系統(tǒng)在開發(fā)中就已經(jīng)需要大量的初期投入。如果無法投入所需的開發(fā)資源，或者由于商業(yè)原因需要將所開發(fā)的SaaS系統(tǒng)盡可能快地投放到市場，則選擇數(shù)據(jù)隔離的設(shè)計(jì)模式更為恰當(dāng)。

安全因素

通常在SaaS系統(tǒng)中會存放有很多敏感的客戶業(yè)務(wù)數(shù)據(jù)，因此客戶會對確保數(shù)據(jù)的安全性有很高的期望，SaaS服務(wù)供應(yīng)商與客戶簽署的服務(wù)條款中會需要包含很多數(shù)據(jù)安全保障條款。當(dāng)然，一般客戶常見誤解是只有采取數(shù)據(jù)隔離方式設(shè)計(jì)的SaaS系統(tǒng)才能完全確保數(shù)據(jù)的安全性；事實(shí)上，采取數(shù)據(jù)共享方式設(shè)計(jì)的SaaS系統(tǒng)一樣可以。在使用了一些成熟的設(shè)計(jì)模式之后，也可以為客戶提供很強(qiáng)的數(shù)據(jù)安全保障。

客戶因素

一個(gè)SaaS系統(tǒng)將來所服務(wù)的潛在客戶的數(shù)量、商業(yè)背景乃至其業(yè)務(wù)需求都將在很大程度上影響數(shù)據(jù)模型的選擇，下面就是一些常見的可能會影響到?jīng)Q定的一些因素。

估算該SaaS系統(tǒng)所期待的潛在客戶數(shù)。到底是為數(shù)以百計(jì)的客戶設(shè)計(jì)這一系統(tǒng)還是數(shù)以千計(jì)，又或者更多數(shù)量。簡單地說，如果計(jì)劃支持的客戶數(shù)目越大，就應(yīng)當(dāng)越多地考慮使用數(shù)據(jù)共享的模式。

估算每個(gè)客戶平均使用的數(shù)據(jù)存儲空間。如果使用該SaaS系統(tǒng)的客戶可能會存儲海量數(shù)據(jù)，則獨(dú)立數(shù)據(jù)庫模式毫無疑問是最佳選擇。

估算每個(gè)客戶平均所需要支持的終端用戶數(shù)。如果這個(gè)數(shù)字越大，則越應(yīng)當(dāng)考慮采用數(shù)據(jù)隔離的模式來滿足終端用戶的需求。

決定是否為每個(gè)客戶提供類似于數(shù)據(jù)備份之類的增值服務(wù)。一般而言，采用數(shù)據(jù)隔離的模式比較便于實(shí)現(xiàn)這類服務(wù)。

技能因素

對SaaS系統(tǒng)開發(fā)商而言，設(shè)計(jì)一個(gè)單實(shí)例多用戶支持的系統(tǒng)架構(gòu)仍然是一個(gè)很大的挑戰(zhàn)，要想熟悉對應(yīng)的開發(fā)工具，掌握相應(yīng)的開發(fā)環(huán)境，也需要一支具有相當(dāng)技術(shù)實(shí)力的開發(fā)團(tuán)隊(duì)。相對來說，選擇數(shù)據(jù)隔離的模式來開發(fā)SaaS系統(tǒng)允許開發(fā)人員更多的從以往的開發(fā)傳統(tǒng)架構(gòu)的軟件的經(jīng)驗(yàn)中受益，對于技術(shù)力量不強(qiáng)的開發(fā)商而言不失為一個(gè)明智的選擇。（萬方數(shù)據(jù)）