本文分享自天翼云开发者社区《如何计算真实的数据库成本》

作者:王****乾

       在云计算占主导地位之前，计算数据库的成本是一个非常简单的等式：软件成本+硬件成本=数据库成本。如果你选择了一个开源产品，软件成本可能会消失。虽然云计算已经从根本上改变了我们使用和部署软件的方式，但仍有太多人在使用这种过时的计算方法。

       事实上，在为数据库的总成本定价时，需要考虑的事情还有很多。硬件和软件成本仍然存在，但您还需要考虑扩展数据库、与现有和未来系统集成以及计划内或计划外停机的成本。 

       在为云数据库的成本定价时，预先询问这些问题至关重要。在The Cockroach Hour的一个在线研讨会中，我们提出了一个完整的大纲，列出了在计算数据库的真实成本时要问的所有问题。费用分为三大类：硬成本、运营成本和软成本。

       如果你想看到一个完全详尽的报告，可以看看这份50页的报告。该报告评估了七家不同的公司，收集的见解将帮助您降低成本，提高正常运行时间，并加快创新步伐。

       在我们的原始数据库成本网络研讨会的回顾中，我们将提到各个成本项，并提供使您可以在自己的计算中应用的模板。

数据库的硬成本

       从表面上看，这个等式的这一部分自云出现以来没有太大变化。数据库的硬成本分为两类：软件许可证和硬件。

云数据库软成本

       市场上有许多软件许可证，可分为三类：  

       1、传统企业：在云之前，这已经是企业软件领域三十多年的模式。您需要为企业软件许可证支付一大笔预付费（通常为数十万美元，外加支持和维护费）。购买后，您需要为添加的功能和升级支付额外的费用。

        2、完全开源：完全免费的 Apache 许可证。然而，与自由软件许可证相关的成本并非不存在。你需要支付维护、支持和降低风险的费用。我们稍后会讨论这些费用。 

        3、商业开源：这种模式出现在大约 10-15 年前，作为一种可行的解决方案，可以解决公司在完全开源许可证中遇到的一些问题，如赔偿和支持。

云数据库硬成本

       今天的硬件成本看起来与 30 年前不同。但是，这些硬件成本并没有消失，只是因为不用安装巨大服务器在机房嗡嗡作响。当然，也有不同之处：你可能会与供应商谈判价格，或者利用规模经济（不要贬低这一点），但这是你需要考虑的成本。 

       您还需要管理和操作所有这些。运营成本不会就这么消失。在这些云提供商的界面上花费了相当多的时间来实际管理这些事情，并从操作的角度进行理解，因此易用性非常重要。

业务数据库费用

       除了硬件和软件成本之外，还有运行数据库所产生的日常成本。根据您选择的供应商（及其定价结构），这些差异很大，但源于同一个问题：当我们将来要做某项任务时会发生什么？ 

       在使用数据库的过程中，您将不得不处理灾难恢复、扩展以及将系统与其他工具集成。人们很容易认为“船到桥头自然直”。但是，在计算数据库的真实成本时，您需要考虑这些不可避免性，并计算出当您需要跨越这些桥梁时所需的成本。

灾难恢复：数据库失败的代价是什么？

       无论你在硬件上放置多少抽象层，最终，我们都是在处理机械设备。这些设备总会发生故障。在选择数据库来部署应用程序时，需要考虑临时或灾难性挑战的成本。虽然应用程序可能失败的原因有很多，但数据库是许多停机的主要原因。旧版本、写入瓶颈、内存问题、锁定事务、错误配置、硬件故障。你需要为这些不可避免的事情做好准备，因为它们会在某个时候发生。

       计划内和计划外的停机时间都可能导致巨大的成本，虽然这一支出可能不容易计算，但仍应将其视为数据库选择的一部分。每个企业都是不同的，停机时间的影响也各不相同，但在计算企业的停机成本时，需要考虑以下几项： 

· 收入损失：错失开展在线商务或与前景接洽的机会

· 声誉影响：消费者可能转向你的竞争对手

· 客户满意度：由于观察到的问题而对您的产品或服务失去信任

· 监管成本：司法法规有时会因数据问题对组织进行罚款

· 法律的责任：在极端情况下，可能会提起与数据丢失相关的诉讼

       有一些非常简单和更直接的技术原因可以解释为什么数据丢失和停机会成为一个问题。我们经常发现自己需要处理延长的 RPO（恢复点目标）/RTO（恢复时间目标），并将承受高昂的技术成本。

扩展：分片的成本是多少？

       对于大多数云数据库，扩展是通过增加实例的大小来实现的。但是，使用这种方法，您将受到可用的最大大小的限制。当你想超越这个规模，或者需要全球规模时，会发生什么？ 

       某些数据库（如 AWS Aurora）允许您扩展到单个实例（RDS）之外，并允许多个实例。但是，这仅用于读取，并且限制了您可以处理的事务量，因为没有扩展写入节点的功能。你仍然面临着容量限制。此外，这种单写节点配置限制了您跨广泛地理区域扩展访问的可用性，因为您总是会遇到写访问的物理延迟。  

       如果您选择扩展 PostgreSQL 或 MySQL 等开源数据库，则最终需要对数据库进行分片。与这种方法相关的成本很高。首先，您需要修改应用程序，这会带来风险。您还需要配置一个新实例，并在某个时候切换到这个新配置，通常是在半夜。您将有与硬件相关的额外成本以及它给团队带来的痛苦...而这都是最好的情况。如果在此过程中出现问题，您将面临计划外停机。此外，分片数据库的管理成本随着每个新分片呈指数级增加。

整合：使用其他工具的成本是多少？

       您的数据库并不存在于真空中。它将被集成到您的 IT 平台的其他部分。您不会在 OLTP 数据库中运行 OLAP。数据仓库的出现是有原因的。因此，数据库和其他工具（如数据仓库）之间的集成非常重要。根据您的数据库，它可能会很昂贵。你的用例是否需要 Kafka 或某种流处理？你在使用数据湖吗？

购买前评估隐藏的数据库成本

       除了运营成本之外，还有一些更难量化的问题，这些问题构成了云数据库的隐藏成本。其中包括合规成本、竞争风险、供应商锁定的可能性以及吸引人才的能力。考虑部署、管理和扩展传统关系数据库的所有隐藏成本的最佳方法是使用此报告进行评估。

原文链接：https://www.cockroachlabs.com/blog/true-cost-cloud-database/

作者：Dan Kelly，如需转载，请联系作者。