你的数据库是否在烧钱？

你的数据库应该为你服务，而不是反过来。然而，很多公司（有时甚至是无意间）每年因为数据库问题损失数百万美元。这是怎么回事？
数据库烧钱的三个主要原因：

停机时间（Downtime）
数据库管理（Database Management）
数据库运维（Database DevOps）

结果？由于技术和人为错误、延误以及停机时间，你的成本可能会显著增加。公司利润受到影响，用户失望不满，工程团队承受了不必要的压力。

数据库烧钱的三种主要方式

让我们详细看看数据库为何会变得如此昂贵。

1 – 数据库引发的停机时间

停机可能由人为错误、系统不成熟或应用问题导致。很多人可能觉得：“一个小时的停机时间不会那么糟吧？” 错了。即便只有几分钟的停机时间，也会造成各种损失：

直接的收入损失

例如，对于主要的在线零售商来说，仅一个小时的停机就可能导致数百万美元的销售额损失。

潜在的合同损失

对于 SaaS 服务提供商尤其如此——例如一家提供身份验证服务的公司。如果数据库停机，则该服务的所有客户也随之停机。当客户续约时，他们很可能会转向那些没有性能问题的竞争者。
研究表明，即使一小时的停机时间也可能造成 平均 30 万美元 的损失。这听起来或许很夸张，但我们确实见过真实数据。

停机案例分析

Costco 停机：2019 年节日购物季，Costco 网站出现问题，直接损失达 1100 万美元 销售额。
苹果（Apple）停机：2015 年 3 月，苹果发生 12 小时停机，损失达 **2500 万美元**。
Facebook 停机：2019 年 3 月，Facebook 的 14 小时故障直接损失了 **9000 万美元**。

停机的影响不仅是直接收入损失，还包括连锁反应。例如，Facebook 停机不仅让普通用户无法登录，还使那些品牌客户无法投放广告，这直接影响了这些品牌的销售收入。
停机时间的全面财务影响难以量化，但有一点很明确：**停机时间必须尽可能避免**。

用户信任的损失

除了财务损失，停机还会对用户信任造成巨大损害。现如今，用户对停机已经完全无法接受。你的网站必须做到全年无休、始终可访问。如果用户打开你的应用发现无法加载，或者因频繁维护窗口无法使用，他们最终会转向更可靠的竞争对手。

如何避免停机时间？

避免因错误删除表或索引导致的查询缓慢或失败；
使用 PlanetScale 的功能，提前警告即将删除的表是否被最近查询过；
如果发生错误，可通过 PlanetScale 回滚架构更改，而不会丢失数据。

PlanetScale 提供完全托管的 Vitess 集群 Vitess 是一款开源数据库集群系统，能够显著提升 MySQL 的可扩展性和可管理性。Vitess 在规模压力下已证明其可靠性，被超大规模公司广泛使用，例如 Slack、HubSpot 和 Etsy。在你读这篇文章的时间内，Vitess 集群可能已经服务了数千万用户、处理了数亿次查询，并管理着数百 PB 的数据。

2 – 数据库管理

谁负责管理你的数据库？他们每周花费多少时间在管理数据库上？
在中小型企业中，通常没有专职的数据库管理员（DBA）或专人负责数据库基础设施。随着企业规模增长，数据库的需求也在增长，如果没有专人管理，这一负担自然会落到你的工程师身上。

工程师的负担

通常，工程师并不是数据库领域的专家。他们需要学习如何处理扩展、运行时间、备份、监控、版本更新、安全性、合规性等问题，这将耗费大量时间，更不用说数据库必须始终保持在线状态。这意味着，管理数据库可能会让工程师保持全天候工作状态。
更重要的是，如果工程师的时间都花在数据库管理上，他们就没有时间进行关键的应用更新，而这些更新才是让你在竞争中脱颖而出的关键。你的竞争对手可能正在全速开发客户真正关注的新功能，而你的团队却在忙于基础设施维护。最终，客户只关注最终产品，而不是你花费了多少时间在数据库管理上。

解决方案？

当企业发展到需要主动扩展时，很多人会认为下一个合理步骤就是聘请一名 DBA 或组建一个团队，尤其是当数据库规模非常大且性能开始出现问题时。问题是：这会花费多少钱？
聘请 DBA 并不便宜。事实上，2022 年此职位的薪资上涨了 **6.9%**。与此同时，2022 年第三季度的风险投资资金同比下降了 **50%**。换言之，DBA 的薪资要求增加，而预算却在缩减。
高昂的薪资只是其中一部分，托管数据库本身的费用也是天文数字。为什么要接受这种现状？

PlanetScale 的解决方案

PlanetScale 提供平台支持，相当于让你拥有一个内置的 DBA：

类似 Git 的架构变更工作流
自动无停机版本更新
自动化并经过预测试的备份
每个生产分支包含副本
内置查询监控
一键回滚架构更改，无需停机
基于应用最小更改的横向分片
轻松配置只读区域、额外副本、备份等选项
世界级支持服务
内置缓存支持部分高频查询

PlanetScale 的客户 Barstool CTO Andrew Barba 表示，在快速扩展和提高开发速度方面，他们需要聘请更多工程师，但一个故障可能在短短 45 分钟内造成数百万美元的损失。最终，他们完全迁移到 PlanetScale 平台。 “最终，我们通过迁移到 PlanetScale 节省了 20%-30% 的成本。”

3 – 数据库 DevOps

安全地进行架构更改可能需要多步流程。如果没有任何保护措施，很容易出现错误甚至导致停机。
传统流程通常需要数小时、几天甚至几周，才能手动审查和验证每次架构变更。架构变更约占 57% 的应用变更，但这一繁琐的审查流程往往成为发布应用变更的巨大阻碍。开发人员花费在这项任务上的时间越多，就越少有时间继续创新应用。
不进行数据库更改并不是选项，公司需要一种快速、安全且经济的方法来实现这一目标。然而，要为此设计一个简单且通用的保障流程并不容易。