“真不敢相信！”她大声说道，自言自语道，“真不敢相信！上面写得清清楚楚——公司的首要目标是为股东创造利润。想想看！他们什么都不怕！”
尤利·杜波夫，《两害相权取其轻》
看到这样的标题，你可能已经认定这篇文章要么愚蠢，要么哗众取宠。但别急着下结论：大型企业的员工，尤其是那些有国有资产的企业的员工，经常需要比较不同的平台，包括标题中提到的那些截然不同的平台。
当然，没有人会这样比较数据库管理系统（DBMS），因为它们的优缺点众所周知。通常情况下，人们会比较那些能够解决特定应用问题的平台。在本文中，我将以数据库为例，演示用于此目的的方法，数据库是Habr读者熟悉的领域。那么，
动机
当你开始一个学习或兴趣项目时，选择平台的动机可能多种多样：“我最了解这个平台”、“我对了解这个平台很感兴趣”、“它的文档最好”……而对于商业公司来说，选择标准只有一个：我需要支付多少钱，以及我能用这些钱得到什么。
当然，您肯定希望花更少的钱获得更多。但是，您需要决定哪个更重要——是花更少的钱还是获得更多——并为每个节点分配权重。假设我们更看重高质量的解决方案而不是便宜的方案，那么我们就给“成本”节点分配 40% 的权重，给“功能”节点分配 60% 的权重。
在大型企业中，情况通常恰恰相反：成本权重永远不会低于 50%，而且可能超过 60%。在模型示例中，唯一重要的是任何父节点的所有子节点的总权重必须为 100%。
截止条件
网站 目前已知的数据库管理系统大约有500种。显然，从如此众多的选项中选择目标平台，或许能写出一篇综述文章，但很难转化为商业项目。为了缩小选择范围，我们制定了筛选标准，如果某个平台不符合这些标准，则不予考虑。
筛选标准可能与技术特性有关，例如：
- ACID保证；
- 关系数据模型；
- SQL 语言支持（请注意，这与“关系模型”不同）；
- 水平扩展能力。
可能存在一些通用标准：
- 俄罗斯商业支持的可用性；
- 开源；
- 平台已在通信部注册登记；
- 平台在某些排名中的出现（例如，在 db-engines.com 排名的前一百名中）；
- 市场上的专家数量（例如，根据在 hh.ru 网站上简历中搜索平台名称的结果）。
最后，可能还有一些公司特有的标准：
- 是否有专业人员在岗；
- 与监控系统 X 或备份系统 Y 的兼容性，所有支持都依赖于此……
最重要的是要有一套筛选标准。否则，某些专家（或“专家”），尤其是一些受管理层信任的专家，肯定会跳出来说：“你们为什么不选择Z平台？我知道它是最好的。”
成本估计
该解决方案的成本显然包括许可证成本、支持成本和设备成本。
如果系统大致属于同一类别（例如，Microsoft SQL Server 和 PostgreSQL），为了简化起见，您可以假设两种解决方案的硬件要求大致相同。这样就无需评估硬件，从而节省大量时间和精力。但是，如果您要比较完全不同的系统（例如，Oracle 与 Redis），那么显然需要进行容量规划（计算硬件要求）才能进行正确的评估。对一个不存在的系统进行容量规划是一项吃力不讨好的工作，因此通常会被避免。这可以通过指定以下条件轻松实现：零数据丢失和关系模型，或者反过来，每秒 50 笔事务的工作负载。
要评估许可证，只需向供应商或其合作伙伴索取包含固定核心数和固定期限支持的许可证价格即可。公司通常与软件供应商建立了良好的合作关系，如果数据库运维部门无法独立回答价格问题，只需发送一封电子邮件即可获取相关信息。
不同的供应商可能采用不同的许可标准：例如基于核心数、数据量或节点数。备用数据库可能是免费的，也可能与主数据库采用相同的许可方式。如果发现任何许可标准上的差异，您需要详细描述模型配置并计算其许可成本。
公平比较的关键因素在于相同的支持条款。例如，Oracle 的支持费用占年度许可价格的 22%，而 PostgreSQL 的支持是免费的。这样的比较公平吗？不公平，因为无法自行解决的错误会造成截然不同的后果：前者，支持专家会迅速解决问题；而后者，则可能导致项目延期，甚至造成系统无限期停机。
有三种方法可以使计算条件趋于一致：
- 使用没有技术支持的Oracle产品（实际上这种情况不会发生）。
- 例如，您可以从 Postgres Professional 购买 PostgreSQL 支持服务。
- 计算时应考虑缺乏支持所带来的风险。
例如，风险计算可能如下所示：如果数据库发生不可恢复的故障，系统停机时间为一天。预计使用该系统每年可获得 400 亿蒙古图格里克的利润，故障率估计为 1/400，因此，缺乏维护的风险估计约为每年 1 亿蒙古图格里克。显然，“计划利润”和“预计故障率”都是虚拟值，但拥有这样的模型总比没有模型要好得多。
实际上，该系统可能至关重要，长时间停机造成的声誉损失是不可接受的，因此需要技术支持。如果停机时间可以接受，那么放弃技术支持有时反而能节省成本。
假设经过所有计算，平台 A 五年的运营成本为 8 亿蒙古图格里克，平台 B 的运营成本为 6.5 亿图格里克，平台 C 的运营成本为 6 亿图格里克。平台 C 作为成本最低的平台，获得满分，而平台 A 和平台 B 的得分略低，与其成本高出的比例成正比。在本例中，平台 A 和平台 B 分别获得 0.75 分和 0.92 分。
机会评估
能力评估被划分为许多组，组数仅受评估者的想象力限制。最佳方案似乎是根据使用能力的团队来划分能力；在我们的示例中，这些团队包括开发人员、管理员和信息安全官。假设这些职能的权重分配为 40:40:20。
开发功能包括：
- 数据操作的便捷性；
- 缩放；
- 存在次要指标。
这些标准及其权重都具有很强的主观性。即使解决的是同一个问题，这些标准列表、权重和最终答案也会因团队构成不同而存在显著差异。例如，Facebook 使用 MySQL 进行数据存储，而 Instagram 则基于 Cassandra。这些应用程序的开发者不太可能亲自填充过这样的表。我们只能猜测，马克·扎克伯格选择了功能齐全的关系型数据库模型，为此付出了应用分片技术的代价；而凯文·斯特罗姆则在平台中构建了可扩展性，牺牲了数据访问的便捷性。
行政职能包括：
- 备份系统功能；
- 易于监控；
- 容量管理的便捷性——磁盘和节点；
- 数据复制功能。
请注意，问题的措辞应允许进行量化评估。你们甚至可以就如何评价某个特定功能达成一致。例如，让我们以 Oracle 数据库管理系统自带的工具为例，来评价备份工具：
工具
备注
评估
进口/出口
数据上传和下载
0.1
开始/结束备份
复制文件
0.3
远程管理
增量复制能力
0.7
ZDLRA
仅增量备份，最快还原点
1.0
如果没有明确的评价标准，可以请几位专家进行评分，然后取平均值。
最后，我们来列举一下信息安全职能：
- 密码管理策略的可用性；
- 能够连接外部身份验证工具（LDAP、Kerberos）；
- 基于角色的访问控制模型；
- 审计能力；
- 磁盘数据加密；
- 传输层安全协议（TLS）；
- 来自管理员的数据保护。
性能测试
我还要提醒您，不要将任何非您本人执行的负载测试结果用作论据。
首先，被测应用程序的数据结构和负载情况可能与您尝试解决的任务存在显著差异。十到十五年前，数据库厂商热衷于吹嘘他们的 TPC 基准测试结果，但现在似乎没人把这些结果当回事了。
其次，系统性能很大程度上取决于代码最初编写的平台以及测试运行的硬件。我见过许多比较 Oracle 和 PostgreSQL 的基准测试结果。结果有的显示其中一个系统完胜，有的则显示另一个系统同样完胜。
第三，也是最后一点，你对测试人员的身份一无所知。测试人员的资质（影响操作系统和平台配置的质量）和测试动机（其对测试结果的影响远超其他所有因素的总和）都至关重要。
如果性能至关重要，请自行进行测试，最好在负责配置和支持生产系统的专家的帮助下进行。
导致
最后，所有工作的成果应该是一个电子表格，其中所有成绩都经过汇总、相乘和求和：
正如你所想，通过改变权重和调整分数，你可以达到任何想要的结果，但这又是另一个故事了……
来源： habr.com
