上周五我介绍了一种软件质量评估模型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的优势就更明显了。数据库对比评估,对于不同的客户而言,其评估结论比如会有所差异。不能说哪种评估就是对的或者更为准确的。而只要你真正的科学的去根据自己的特点与需求做出的评估才是对你有用的。是否对你的选择有用,才是数据库对比评估的最终目的,不用过于看重别人的看法,这是我个人对数据库对比评估的一贯观点。