上周五我介紹了一種軟件質量評估模型FURPS,國外的一些企業使用該模型來對數據庫產品做對比評估。實際上近些時候,很多國內的用戶也在做一些類似的研究工作。如何客觀的做數據庫選型對比是一件十分具有挑戰性的事情。有朋友說既然有了模型,那么評估數據庫不是很簡單的事情了嗎?實際上并非如此簡單。哪怕在同一個模型下,不同的人來做對比評估,也會得出截然相反的評估結論來。因為模型只是一個大體的評估框架,而模型的各種參數都是可調整的,另外對于每一個問題,不同的企業,不同的使用者,不同的運維人員與研發人員,面對不同的運維場景,對同一個問題,給出的評估結果可能相去甚遠。比如在易用性上,熟悉MySQL的人肯定不會給MYSQL打低分,而對于不熟悉的Postgresql,肯定給出低分,反過來也是如此。并不是說Mysql和Postgresql本身就在這個對比項上就一定有這樣的差距,所處地位的不同造成了實質性的評估差異。
在使用FURPS評估模型做數據庫選型對比的時候,首先需要調整的是各個維度的權重。我讓ChatGPT做一個Oracle、Mysql、Postgresql的FURPS評估,它給出了下面的答案。
評估因素 |
指標 |
Oracle |
MySQL |
PostgreSQL |
功能性 |
數據存儲和管理功能 |
5 |
4 |
4 |
|
數據查詢和報表功能 |
5 |
4 |
4 |
|
安全和權限管理功能 |
5 |
4 |
4 |
可用性 |
用戶界面和操作性 |
4 |
3 |
3 |
|
學習曲線和易用性 |
3 |
4 |
4 |
可靠性 |
可用性和可恢復性 |
5 |
4 |
4 |
|
容錯性和安全性 |
5 |
4 |
4 |
|
可維護性和擴展性 |
4 |
3 |
4 |
性能 |
數據庫的響應時間和吞吐量 |
5 |
4 |
4 |
|
數據庫的容量和負載能力 |
5 |
4 |
4 |
支持性 |
文檔和API |
5 |
4 |
4 |
|
開發者和管理員文檔 |
4 |
4 |
4 |
|
支持和維護服務 |
5 |
3 |
3 |
總分 |
- |
58 |
46 |
45 |
CHATGPT的答案實際上是一種十分常見的評估模型的結論。主要注重功能性、支持性和可靠性。性能與可用性的占比略低。而實際上當你做選型的時候,可能這些比例關系可能需要根據你自己的應用特點和需求去做調整。比如你特別看中性能,那么性能在模型的占比可能會超過30%,這種情況下,評估結果可能截然不同。
而性能評估也并不是十分簡單而單一的,如果你的應用特別看中高并發的單條數據寫入,那么Oracle的總分可能還不一定能比得上Mysql而如果你比較看中復雜的大表多表關聯,Mysql的評估結果可能會最低。而如果你把易于運維作為最為重要的評估項,那么Mysql很可能因為其簡單而一騎絕塵,把Oracle都遠遠甩在身后。
哪怕是對于可用性這個評估項,不同的用戶給出的評估結論也會因為他們自己的知識結構與傳統經驗而有所不同。一個對Mysql擁有十分豐富的開發與運維經驗的企業,在選擇分布式數據庫的時候,肯定會給予Oceanbase、Tidb、HotDB、TDSQL等Mysql生態的分布式數據庫產品在可用性、支持性上較高的評價。實際上這一點也給做數據庫選型評價的朋友提了一個醒,不要總想著去參考別人的評估結論,否則東施效顰的故事很可能發生在你身上。別人的評估方法你可以參考,模型也可以借鑒,不過根據自己的情況,一定要認真調整好模型,否則可能得出截然相反的結論來。
除此之外,評估的粒度對于模型的影響也十分大,越細致的維度分析,越容易做出更為準確的判斷。比如上面那個CHATGPT的對比分析案例,如果把指標維度再分得更細致一些,并保持剛才各個維度的比例相同,我們看到了一個略有不同的結果。
評估因素 |
指標 |
Oracle |
MySQL |
PostgreSQL |
功能性 |
數據庫管理 |
3 |
2.4 |
2.4 |
|
數據建模和設計 |
3 |
2.4 |
2.4 |
|
數據庫查詢 |
3 |
2.4 |
2.4 |
|
數據庫報表 |
3 |
2.4 |
2.4 |
|
數據庫安全 |
3 |
2.4 |
2.4 |
可用性 |
用戶界面設計 |
2.67 |
2 |
2 |
|
系統易用性 |
2 |
2.67 |
2.67 |
|
用戶培訓和文檔 |
2.67 |
2.67 |
2.67 |
可靠性 |
故障處理和恢復 |
3 |
2.4 |
2.4 |
|
數據一致性和完整性 |
3 |
2.4 |
2.4 |
|
數據庫備份和恢復 |
3 |
2.4 |
2.4 |
|
數據庫容錯性 |
3 |
2.4 |
2.4 |
|
數據庫可維護性 |
2.4 |
1.8 |
2.4 |
性能 |
數據庫響應時間 |
2 |
1.6 |
1.6 |
|
數據庫吞吐量 |
2 |
1.6 |
1.6 |
|
數據庫并發性 |
2 |
1.6 |
1.6 |
|
數據庫擴展性 |
1.6 |
1.2 |
1.6 |
|
數據庫容量和負載能力 |
2 |
1.2 |
1.6 |
支持性 |
開發者文檔和API |
5 |
4 |
4 |
|
管理員文檔和API |
5 |
3 |
3 |
|
支持服務 |
5 |
3 |
3 |
|
社區支持和資源 |
5 |
4 |
4 |
總分 |
- |
66.34 |
51.94 |
53.34 |
這依然是CHATGPT的回答,在這個評估表中Mysql和PostgresqlSQL分數出現了一些逆轉。
評估因素 |
指標 |
Oracle |
MySQL |
PostgreSQL |
功能性 |
數據庫管理 |
5 |
4 |
4 |
|
數據建模和設計 |
5 |
4 |
4 |
|
數據庫查詢 |
5 |
4 |
4 |
|
數據庫報表 |
5 |
4 |
4 |
|
數據庫安全 |
5 |
4 |
4 |
可用性 |
用戶界面設計 |
4 |
3 |
3 |
|
系統易用性 |
3 |
4 |
4 |
|
用戶培訓和文檔 |
5 |
3 |
3 |
可靠性 |
故障處理和恢復 |
5 |
3 |
3 |
|
數據一致性和完整性 |
5 |
4 |
4 |
|
數據庫備份和恢復 |
5 |
3 |
3 |
|
數據庫容錯性 |
5 |
4 |
4 |
|
數據庫可維護性 |
4 |
3 |
4 |
性能 |
數據庫響應時間 |
5 |
4 |
4 |
|
數據庫吞吐量 |
5 |
3 |
4 |
|
數據庫并發性 |
5 |
3 |
3 |
|
數據庫擴展性 |
4 |
3 |
4 |
|
數據庫容量和負載能力 |
5 |
4 |
4 |
支持性 |
開發者文檔和API |
5 |
4 |
4 |
|
管理員文檔和API |
5 |
3 |
3 |
|
支持服務 |
5 |
4 |
4 |
|
社區支持和資源 |
5 |
3 |
3 |
總分 |
- |
105 |
78 |
81 |
而如果采用不同的分值模型,得到的結果又會不同,Oracle的優勢就更明顯了。數據庫對比評估,對于不同的客戶而言,其評估結論比如會有所差異。不能說哪種評估就是對的或者更為準確的。而只要你真正的科學的去根據自己的特點與需求做出的評估才是對你有用的。是否對你的選擇有用,才是數據庫對比評估的最終目的,不用過于看重別人的看法,這是我個人對數據庫對比評估的一貫觀點。