在云计算成为主流之前，计算数据库成本只需要使用一个简单的公式：软件成本+硬件成本=数据库成本。如果你使用的是开源产品，那么软件成本可能会有所降低。虽然云计算已经从根本上改变了使用和部署软件的方式，但很多人仍然在使用这种过时的计算方法来计算数据库成本。
事实上，在计算数据库的总体成本时，还有很多东西需要考虑。除了硬件和软件成本，你还需要考虑数据库的伸缩成本、与现有或未来系统集成的成本，以及计划中（或计划外）的停机时间成本。
在计算云数据库的成本时，需要事先考虑到这些问题。在The Cockroach Hour的一期 Webinar 中，我们给出了在计算数据库真实成本时需要考虑的问题。成本主要分为三类：硬成本、运维成本和软成本。
如果你想看完整的报告，可以看看这份50页的报告。该报告评估了七家不同的公司，其中的见解可以帮你降低成本，改进正常运行时间，并加快创新的步伐。
在本文中，我们将回顾 Webinar 中提到的各个成本项，并提供一个模板，你可以用它来计算自己的数据库成本。
数据库的硬成本
从表面上看，在云计算开始流行之前，等式的这一部分并没有太大变化。数据库的硬成本分为两类：软件许可和硬件。云计算的崛起为我们带来了一些关于硬件和软件成本的新问题。
云数据库软件成本
市场上有很多种软件许可，可以分为三类：
传统企业：在云计算出现之前，这种模式在企业软件领域已经存在了 30 多年。你需要提前为企业软件许可支付一大笔费用（通常是数十万美元，再加上支持和维护费用）。购买之后，你还要为额外的功能和升级支付额外的费用。
完全开源：完全免费的 Apache 许可。不过，与自由软件许可相关的成本并非不存在。你需要花钱维护它，支持它，降低它的风险。我们稍后会讨论这些成本。
商业开源：这种模式大约是在 10 到 15 年前出现的，作为一种可行的解决方案，可以解决完全开源许可中存在的一些问题，比如补偿和支持方面的问题。
云数据库硬件成本
如今的硬件成本与 30 年前有所不同，但它们并没有消失，尽管你不再需要在机房里安装嗡嗡作响的巨型机器。不同的地方在于，你可能会与供应商协商价格，或利用规模来降低成本，但这些成本仍然存在。
你还需要管理和运维，所以运维成本不会凭空消失。你需要花时间在云供应商提供的管理接口上，并从运维的角度来理解它们，因此接口的易用性就变得非常重要。
数据库的运维成本
除了硬件和软件成本之外，还有日常运行数据库所产生的成本。根据你所选择的供应商（及其定价结构）的不同，这方面的成本变化很大，但都存在同一个问题：如果在未来需要执行 X 个任务该怎么办？
在使用数据库的过程中，你将不得不进行灾难恢复、水平伸缩以及将系统与其他工具集成，等等。我们可能会想“船到桥头自然直”，但在计算数据库的真实成本时，你需要考虑这些不可避免的情况，并在需要处理这些情况时将其纳入到成本计算当中。
灾难恢复：数据库故障成本
不管硬件之上有多少个抽象层，归根结底，我们都是在跟机械设备打交道，而机械设备总归会发生故障。在为你的应用程序部署数据库时，你还需要考虑临时或灾难性故障所带来的成本。虽然导致应用程序发生故障的原因有很多，但数据库是导致停机的主要原因：版本太旧、写入性能瓶颈、内存问题、事务被锁定、配置错误、硬件故障。你需要为这些不可避免的情况做好准备，因为它们总有一天会发生。
计划中和计划外的停机都可能带来巨大的成本，虽然这种成本可能不容易计算，但仍然需要将其作为数据库成本的一部分来考虑。业务不同，停机时间的影响也不相同，但在计算停机时间对业务的影响成本时，可以考虑以下几个方面：
收入损失：错失进行在线交易或吸引潜在用户的机会；
声誉影响：消费者可能会转而购买竞争对手的产品；
客户满意度：由于看到了问题的发生而对你的产品或服务失去信任；
监管成本：监管机构有时会因数据问题对组织处以罚款；
法律责任：在极端情况下，可能会因与数据丢失相关的问题遭到诉讼。
有一些非常简单和直接的技术原因可以说明为什么数据丢失和停机可能会是一个问题。我们经常发现自己在处理较长时间的 RPO（恢复点目标）/RTO（恢复时间目标），并承受高昂的技术成本。
水平伸缩：分片的成本
大多数云数据库的伸缩是通过加大实例的大小来实现的，但这种方法会受到可用最大大小的限制。如果你想要更大的规模或者需要全球规模时该怎么办？
有些数据库，如 AWS Aurora，允许扩展到单个实例（RDS）以外，并支持多个实例。但这仅用于读取，并且限制了可处理的事务数量，因为没有扩展写节点的能力。因此，你仍然面临规模的限制。此外，这种单一的写节点配置限制了跨地理区域访问的可用性，因为总是存在写访问的物理延迟。
如果你选择对开源数据库（如 PostgreSQL 或 MySQL）进行伸缩，就需要对数据库进行分片。这种方法会带来巨大的成本。首先，你需要修改应用程序，这会带来风险。你还需要配置一个新的实例，并在某个时刻（通常是在半夜）将流量切换到这个新的实例上。这会带来与硬件相关的额外成本，以及它给团队带来的痛苦……这还是最好的情况，如果在这个过程中出了问题，就会导致计划外的停机。此外，分片数据库的管理成本随着每个新分片的增加而呈指数级增长。
集成成本
你的数据库并不是孤立存在的，它将被集成到 IT 平台的其他部分。你不会在 OLTP 数据库中运行 OLAP，数据仓库的出现是有原因的。因此，数据库与其他工具（如数据仓库）之间的集成就变得非常重要。根据数据库的不同，集成成本可能会很高。你需要使用 Kafka 或某种流式处理吗？你在使用数据湖吗？
在购买前评估数据库的隐性成本
除了运维成本之外，还有一些难以量化的问题，这些问题构成了云数据库的隐性成本，包括合规成本、竞争风险、供应商锁定的可能性以及吸引人才的能力。评估部署、管理和伸缩传统关系数据库隐性成本最好的方法是使用这个报告：
https://www.cockroachlabs.com/guides/do-more-with-less-with-distributed-sql/
原文链接：
https://www.cockroachlabs.com/blog/true-cost-cloud-database/
相关阅读：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论