共享database獨立Schema構建SAAS平臺
從數(shù)據(jù)模型設計的角度來分析，使用Oracle10g數(shù)據(jù)庫，以共享database獨立Schema的模式來構建SAAS平臺，以下是這一實現(xiàn)過程：
Oracle中的實現(xiàn)方式：
1、共享一個數(shù)據(jù)庫實例，免費的使用Tenant_Free實例，收費的使用Tenant_VIP實例，平臺的數(shù)據(jù)使用Tenant_Platform實例。
2、獨立Schema，通過建立每個Tenant的數(shù)據(jù)庫用戶來實現(xiàn)，每個用戶使用的數(shù)據(jù)表根據(jù)用戶導入的數(shù)據(jù)進行初始化。配置數(shù)據(jù)自動生成的方式。通過測試一個實例生成幾萬個數(shù)據(jù)庫用戶是很正常的，如果按照一臺普通的服務器可以支撐1萬個Tenant的話，那發(fā)展到10萬用戶可能只需要10臺服務器的規(guī)模，是我可以接受的范圍。
3、原先考慮讓每個Tenant分配一個表空間，然后定義數(shù)據(jù)文件的大小來實現(xiàn)對每個Tenant數(shù)據(jù)空間的限制，但經(jīng)過測試發(fā)現(xiàn)Oracle中添加表空間是有限個數(shù)的，我測試的時候加到200個左右就報錯，提示超過表空間的最大數(shù)量。看來這種方法行不能。
如上圖所示，所有的Tenant User都在用戶管理庫中進行管理，然后數(shù)據(jù)訪問控制器通過Tenant User的信息自動選擇Tenant對應的數(shù)據(jù)結構。可能我覺得這種模式是MVC的改進版本，即SAAS平臺下要使用MVCD的模式（Model-View-Controller-DataAccess），數(shù)據(jù)管理層將模型層與控制層對數(shù)據(jù)管理方面的內(nèi)容獨立出來，負責數(shù)據(jù)庫結構的管理、數(shù)據(jù)存取等功能……
選擇的理由：
1、在oracle里要使用獨立的database對于服務器的內(nèi)存要求實在太高了，一個實例分配的資源如果是200M的話，4G的服務器只能支持20個租戶，這個成本我想沒有什么人可以承受，所以第一種最簡單的方式我不采用。
2、選擇獨立schema是非常重要的，對于程序與性能都會有很大的提升，而且業(yè)務要求所有企業(yè)相關的數(shù)據(jù)表字段都允許Tenant用戶自定義，所以我覺得是必要條件，所以只能選擇第二種模式。如果使用預留字段或者通過字段擴展表來存儲存在比較多的問題，比如檢索速度、字段的限制、數(shù)據(jù)冗余等缺點。而且對于用戶來說不太直觀。
3、從維護管理的角度考慮，備份的時候可以對每個數(shù)據(jù)庫用戶的數(shù)據(jù)進行單獨的備份，有利于對無效用戶的數(shù)據(jù)刪除與恢復的操作。同時也保證了用戶數(shù)據(jù)的安全性。
對SAAS程序的要求：
1、要求可以通過配置自動實現(xiàn)Tenant Schema中數(shù)據(jù)的CRUD操作。
2、數(shù)據(jù)報表及相關的查詢都要允許自定義，需要提供相關的功能。
3、API接口服務需要提供配置功能。
本文就說到這里，歡迎大家批評指導！
【編輯推薦】
