“这是必要的，”她大声说道，没有对任何人说。 - 这是必要的！ 这正是它所说的：公司的主要任务是为股东的利益赚取利润。 好吧，想想吧！ 他们什么都不怕！
尤利·杜波夫《小恶》
看到这样的标题，你可能已经认定这篇文章要么是愚蠢的，要么是挑衅的。 但不要急于下结论：大公司的员工，特别是有国家参与的公司，经常不得不比较不同的平台，包括完全不同的平台 - 例如标题中的平台。
当然，没有人以这种方式比较 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（实际上这不会发生）。
- 购买 PostgreSQL 支持 - 例如，从 Postgres Professional 购买。
- 考虑与缺乏支持相关的风险。
例如，风险计算可能如下所示：如果发生致命的数据库故障，系统停机时间将为 1 个工作日。 使用该系统的预计利润为每年 40 亿图格里克，事故率估计为 1/400，因此缺乏支持的风险估计每年约为 100 亿图格里克。 显然，“计划利润”和“预计事故频率”都是虚拟值，但有这样的模型总比没有好得多。
事实上，该系统可能太重要了，长期停机所带来的声誉成本是不可接受的，因此需要支持。 如果允许停机，那么拒绝支持有时可能是省钱的好方法。
假设经过全部计算，运营平台A 5年的成本为800亿MNT，运营平台B的成本为650亿MNT，运营平台C的成本为600亿MNT。 平台 C 作为获胜者，在价格上获得满分，而平台 A 和 B 获得的分数则少一些，与价格贵多少倍成正比。 在本例中，分别为 0.75 点和 0.92 点。
机会评估
对机会的评估被分为许多组，其数量仅受评估者的想象力的限制。 最佳选择似乎是将这些功能划分为将使用这些功能的团队； 在我们的示例中，这些人是开发人员、管理员和信息安全官员。 假设这些函数的权重分布为 40:40:20。
开发功能包括：
- 易于数据操作；
- 缩放；
- 存在二级索引。
标准列表及其权重非常主观。 即使解决相同的问题，这些列表、项目权重和答案也会根据团队的组成而有很大差异。 例如，Facebook 使用 MySQL 来存储数据，Instagram 则基于 Cassandra 构建。 这些应用程序的开发人员不太可能填写此类表格。 人们只能猜测马克·扎克伯格选择了成熟的关系模型，并为此付出了应用分片的需要，而凯文·斯特罗姆则使用该平台构建了扩展性，牺牲了数据访问的便利性。
管理职能包括：
- 备份系统功能；
- 易于监控；
- 易于容量管理——磁盘和节点；
- 数据复制能力。
请注意，问题必须以定量的方式提出。 您甚至可以就如何评估特定功能达成一致。 例如，我们尝试使用 Oracle DBMS 提供的工具示例对备份工具进行评级：
工具
备注
评估
进出口
上传和加载数据
0.1
开始/结束备份
复制文件
0.3
远程管理
增量复制能力
0.7
ZDLRA
仅增量复制，最快恢复到点
1.0
如果没有明确的评价标准，可以请几位专家给出评分，然后取平均值。
最后简单罗列一下信息安全功能：
- 密码管理策略的可用性；
- 连接外部身份验证工具（LDAP、Kerberos）的能力；
- 访问的角色模型；
- 审计能力；
- 磁盘上的数据加密；
- 网络传输过程中的加密 (TLS)；
- 来自管理员的数据保护。
性能测试
另外，我想警告不要使用任何不是由您进行的负载测试的结果作为参数。
首先，正在测试的应用程序的数据结构和负载配置文件可能与您要解决的问题有很大不同。 大约10-15年前，数据库供应商喜欢炫耀在TPC测试中取得的成果，但现在似乎没有人认真对待这些结果。
其次，系统性能在很大程度上取决于代码最初是为什么平台编写的以及测试是在什么设备上进行的。 我见过很多将 Oracle 与 PostgreSQL 进行比较的测试。 结果范围从一个系统的无条件优越性到另一个系统同样无条件的优越性。
最后，第三，你不知道谁做了测试。 这两个资格都很重要，会影响设置操作系统和平台的质量，以及动机，这对测试结果的影响比所有其他因素的总和还要大。
如果性能是一个关键因素，请自行进行测试，最好在配置和维护生产系统的专家的帮助下进行。
导致
最后，所有工作的结果应该是一个电子表格，其中所有估计值都被组合、相乘并相加：
如您所知，通过改变尺度和调整评级，您可以达到任何期望的结果，但这是一个完全不同的故事......
来源： habr.com