以一个想要自行管理数据库集群的组织为例。出于本练习的目的，我们将数据库集群定义为具有多个节点的设置（例如，自我管理的分片 MySQL 集群）。大多数场景也适用于公共云中的自我管理数据库。

1. 硬件和许可成本

除了与硬件的规划、购买和部署相关的间接成本外，本地数据库还需要对服务器和存储磁盘等硬件进行前期投资。 

安装、配置和调整数据库软件所需的服务等初始成本也会增加前期成本。

集群/分片数据库增加了此过程的复杂性，尤其是当硬件和软件组件来自不同供应商时。

公共云中的自我管理数据库还需要根据峰值工作负载需求配置服务器机器和存储磁盘。因此，即使数据库负载较少，您也会承担更高的成本。

您将需要为某些数据库技术支付许可费用（例如 Microsoft SQL Server 许可费用）。

2.运营成本和效率 

操作和维护数据库:操作数据库会占用大量的时间和资源。您将需要计划和执行操作系统和数据库版本升级、升级前测试、持续调整和优化以及安全补丁。

根据您的数据库大小和数据库的可用性 SLO，成本可能会很高。例如，一家自行管理其扩展和分片 MySQL 数据库的公司最终可能会在运营和维护方面花费大量资源（在美元和人力成本方面）。 

放大和缩小:如果您自行管理数据库，您如何计划黑色星期五、新年前夜、超级碗或新产品发布等特殊活动?如果您过度配置硬件，那么在非高峰期就会产生不必要的成本。此外，过度配置硬件意味着过度配置许可证。如果供应不足，您将面临错失商机的风险。如果您的产品一夜成名（例如，推出手机游戏），您就不得不担心您的数据库跟不上需求。当您的数据库达到垂直扩展限制（例如，机器大小）时，您必须使用分片进行扩展，这意味着您会产生额外的成本，包括重新架构、更改您的应用程序、运营成本和可能的停机时间。即使不需要重新架构，非线性缩放仍然是一个问题。 

数据弹性:为了在服务器故障、网络故障或热浪或飓风等自然灾害期间防止数据丢失并确保业务连续性，您需要通过在物理上分离的位置/区域的数据中心之间设置数据复制来规划数据弹性。与此设置相关的成本很高（硬件、软件许可成本，以及可能的复制软件许可），以及持续的维护负担。 

地理扩展:随着您的业务增长到不同的地理位置，您可能需要复制数据库，原因包括数据驻留要求和减少客户端/应用程序的数据库交互延迟。设置复制、实现副本之间的数据同步、避免裂脑问题以及处理副本从故障中恢复都会带来巨大的运营成本。

效率:某些 SaaS 应用程序提供商（也是云客户）为每个客户提供一个数据库。管理大量客户转化为管理大量单独的数据库。这将导致效率低下，从而导致更高的运营成本。

3.人力成本

随着数据库维护任务和数据库管理复杂性的增加，您将需要更多的专家来维护您的数据库。有时，这些成本可能比您的整体基础设施（硬件）成本高得多。

4. 停电成本

直接收入损失:这一点很明显——如果您的业务没有正常运行，可能会导致直接收入损失。即使部分数据库中断也会导致收入损失。

运营工作:如果发生与数据库相关的中断，它会给您的组织带来多少工作?需要多少资源才能随叫随到、响应、缓解、进行事件事后分析并制定预防策略?

合同:一些业务关键型工作负载可能会对中断或应用程序停机产生合同和监管影响（例如，证券交易所、银行）。

品牌信任问题:如果您的业务因数据库维护窗口或数据库中断（可用性低）而宕机，您的品牌可能会与较低的可靠性和可用性相关联。

机会成本:您是否将资源仅用于管理数据库和相关基础架构，而不是利用它们来增强和构建新功能以支持核心业务?  

5.生产力成本

投产时间:您是否拥有合适的 CI/CD 管道来优化投产时间?您是否需要使用不同的数据库实例设置多个开发、预生产和暂存环境作为生产路径?与维护多个环境相关的时间和成本是多少，以及将变更推向生产的非优化（依赖于数据库）时间是多少?您需要花费多少精力来计划和准备应用架构更改?

性能不佳:您是否优化了数据库以获得最佳应用程序性能?调优不当的数据库会导致应用程序性能不佳和资源浪费。

应用程序开发速度较慢:您的数据库是否使您的组织能够快速开发和启动应用程序?您是否有数据库的本地副本，您可以将其下载到开发人员的机器（或笔记本电脑）上以进行快速开发?数据库是否具有熟悉的界面以加快开发速度? 

增加的复杂性:您的开发人员是否必须花费大量精力来解决数据库部署的复杂性?您是否需要分配您的摇滚明星开发人员来解决数据库扩展/可靠性挑战而不是核心业务差异化因素?

计算商业利益

在开发应用程序时，问问自己，你的数据库是否允许你快速迭代并将更改快速推送到生产环境?将代码部署到生产环境所需的时间将直接转化为您启动新应用程序或功能的速度以及创新的速度。

虽然我们假设一家公司运行他们自己的 MySQL 集群，但上面的列表也适用于许多其他情况。选择数据库时，重要的是要查看总拥有成本或 TCO。为了巩固上述观点，让我们看一下我们的一种托管数据库服务 Cloud Spanner 及其 TCO。

Cloud Spanner 简介

Cloud Spanner 是一种分布式、全球可扩展、高度一致的关系数据库服务，专为云而构建。它不仅提供关系数据库结构的 SQL 优势，还提供通常由非关系数据库提供的水平可伸缩性，以便用户充分利用两者。这种组合旨在提供高性能事务和跨行、数据中心、区域和大洲的强一致性，具有高达 99.999% 的可用性 SLA 和企业级安全性。用户可以专注于构建应用程序和交付创新，而 Spanner 则完全管理数据库基础设施、分片、复制和故障转移，没有计划内停机时间。 

扳手总拥有成本

一项关于 Cloud Spanner 经济效益的 ESG 研究得出结论，在 Cloud Spanner 上托管数据比使用本地服务器的成本低 78%，比使用其他云数据库的成本低 37% 。

金融服务、医疗保健、零售、游戏、电信和技术等不同行业的客户正在通过迁移到 Cloud Spanner 来降低他们的数据库 TCO。例如，ShareChat 通过将具有 17 个索引的 120 多个表从AWS DynamoDB 迁移到 Spanner，将其非关系工作负载的成本降低了 30% 。了解另一位客户 Kochava 如何通过将在数百个 MySQL 数据库上运行的关系工作负载整合到更少的自动缩放 Spanner 实例中来实现显着节省。 

Cloud Spanner 的总数据库成本

让我们看看使用 Cloud Spanner 运行时的典型数据库成本。

硬件和许可

无需过度配置硬件或支付高额许可费用即可使用 Spanner。您可以简单地按需支付数据库计算容量和 Spanner 中消耗的存储空间。您可以使用 Spanner autoscaler 灵活地扩展和缩减数据库计算容量，从而大大降低成本。

运营和人员成本

作为 Google Cloud 提供的一项完全托管的云数据库服务，Spanner 让您可以花更少的时间进行管理，而将更多的时间用于构建应用程序并为您的客户增加价值。创建备份和恢复非常容易;无需修补或升级。您可以在不停机的情况下推出架构更改，并且安全性是内置的。

Efficiency 

Spanner 允许您将多个自我管理的数据库整合到一个实例中并对其进行高效管理。

节点成本

Spanner 提供 90 天的免费试用。Spanner 还有一个可下载的 Emulator，可用于正确性测试和开发，完全免费。每月低至 65 美元起，购买承诺使用折扣可进一步降低高达 40% 的成本。

扩展

从 100 个处理单元（最小尺寸）开始，并增加到无限数量的节点。随着应用程序的增长， Spanner 可以按需扩展而无需停机，因此无需超额配置来提前预留容量。 

客户报告说，Cloud Spanner 使他们能够提高业务敏捷性，从而使他们能够利用数据的价值更好地服务现有客户并开辟新的收入流。Spanner 为您提供了完全的灵活性，让您可以将数据库放在一个区域或跨越全球的多个区域，并能够进行陈旧读取或强一致性读取。

默认情况下， Security

Spanner 通过其客户端库为传输中的数据提供加密，并使用 Google 管理的加密密钥为静态数据提供加密。CMEK 对 Spanner 的支持使您可以完全控制加密密钥。您还可以使用 CMEK 保护数据库备份。Spanner 提供 VPC 服务控制支持并拥有合规性认证和必要的批准，因此它可以用于需要 ISO 27001、27017、27018、PCI DSS、SOC1|2|3、HIPAA 和 FedRamp 的工作负载。

可用性

Spanner 多区域配置提供 99.999% 的可用性 SLA，没有维护窗口或计划停机时间。如果发生区域性或区域性故障，恢复是自动的（无需干预），具有 0-RPO（无数据丢失）并且不会损失业务连续性。

Replication

所有数据自动复制到spanner中的所有replicas，并包含在一个节点的cost中。

Consistency

Spanner 提供全球外部一致性保证。在传统的 RDBMS 环境中，开发人员构建应用程序逻辑来处理事务和/或最终一致性。由于 Spanner 提供了强一致性、规模和包括事务在内的关系语义，它可以让开发人员更容易地生成更清晰的代码。 

以更低的 TCO 改造您的应用程序 

简而言之，组织依靠复杂的数据库管理系统来确保访问他们赖以运行业务运营的数据和见解。但是，从总拥有成本 (TCO) 的角度来看，管理和维护这些数据库可能具有挑战性。金融服务、零售、游戏和医疗保健等行业的客户正在选择 Cloud Spanner 数据库，以更低的 TCO 实现应用程序的现代化和转型。