操纵托管数据库的隐性成本

李漠煜 2024-03-16 09:34 755

"操纵托管数据库的隐性成本,这篇新闻报道详尽，内容丰富，非常值得一读。这篇报道的内容很有深度，让人看了之后有很多的感悟。作者对于这个话题做了深入的调查和研究，呈现了很多有价值的信息。 " 账号设置我的关注我的收藏申请的报道退出登录登录搜索36氪Auto数字时氪将来消费智能涌现将来城市启动Power on36氪出海36氪研究院潮生TIDE36氪企服点评36氪财经(Finance)职场bonus36碳后浪研究所暗涌Waves硬氪媒体品牌企业号企服点评36Kr研究院36Kr创新咨询企业服务核心服务城市之窗行政部门服务创投发布LP源计划VClubVClub投资机构库投资机构职位推介投资人认证投资人服务寻求报道36氪Pro创投氪堂企业入驻创业者服务创投平台首页快讯资讯推荐财经(Finance)科技(Technology)创新城市最新创投汽车(Car)企服专精特新直播视频专题活动搜索寻求报道我要入驻城市合作使用托管数据库的隐性成本极客邦科技(Technology)InfoQ·2024-03-15 17:41关注托管数据库隐藏成本高，需慎重决策使用。

本文要点

托管关系型数据库有代管、可扩展和成本方面的优势，其使用量近来急剧上升。用户需要监控服务成本，其中包括出口费，并修改其工作负载的默认设置。用户应该了解使用托管服务时所涉及的运营成本。用户必须更多地了解其局限性，例如缺乏灵活性、可体坛性等。用户必须对何时使用托管数据库解决方案做出明智的决定。

2024 年，云计算无处不在，但很多时候并不引人注意（如 iCloud 和 Google Docs）。云计算已经变得像真正的云一样无处不在。云计算的许多优点，如弹性、可扩展性和易用性，现在都得到了很好的理解。它们(They)缩短了新产品上市的时间，并解决了现有产品的扩展挑战，而且无需经历艰辛的计划和采购过程。

由于存在这些优势，我们(We)看到，人们对数据库、消息队列、应用程序运行时等托管服务有着巨大的需求。然而，本文要讨论(Discuss)的是云计算较少讨论(Discuss)的一面：使用托管服务（特别是托管关系型数据库）的隐性成本。

作为 Cloudflare 数据库从业者和 Omnigres 构建人员，我有在纯内部部署、公有云和混合等环境中开发、管理和操作数据库的经验。从业务角度来看，每种模式各有其优缺点。一旦公司采用了公有云，使用任何托管服务都变得相当简单，数据库只是一次点击而已。

一项服务想要吸引用户使用首先得具备易用性。如果它在大多数情况下都有效，那还有什么理由不继续使用，甚至更进一步呢？为什么不创造更多这样的东西呢？

成本——实实在在的美元

来自云提供商的托管数据库在运行、备份和监控等方面提供了很多价值。它们(They)还提供了高可用性。在 SCaLE20x 大会上，我介绍了构建自托管数据库服务的挑战：将这项工作转移给提供商可以减少运营成本，缩短上市时间，并带来更多的灵活性。当然，提供商提供了这些好处，就得向用户收费。

首先，计算托管数据库的成本并不简单。成本取决于多种因素，例如：

实例大小和类型（小、大、超大）定价模型（按需、预留）存储（通用、预配置 IOPS、实际 IOPS）数据传输成本（VPC 内 /VPC 外、区域间 / 区域内）实例引擎（PostgreSQL、MySQL、SQL Server 等）备份存储频率和保留时限部署类型（单 / 多 AZ、无服务器）

尽管很复杂，但还是可以量化的。有些第三方工具可以简化价格计算。此外，诸如禁用多可用区域、停用开发环境实例等也是很常见的成本优化措施。沃尔玛等公司开始转向混合云。与此同时，像 Basecamp 这样小一些的公司出于成本考虑，已经将他们(They)的大部分服务从云上迁移了出去。

要了解托管服务的成本是否值得，就必须了解其使用模式。云计算的主要优点是灵活性；如果不需要这个，也可以在自己的硬件上运行数据库。让我们(We)看一些成本更主观、更难以度量的领域。

负载失控，无谓支出

云计算独有的价值主张之一是可扩展性。如果网站可能产品一夜成名，也不需要购买基础设施来支撑暴涨的工作负载。这很好，但有一个问题，如果不谨慎使用，也可能会造成意外。想象一下，数据库上有一个失控的可能恶意的工作负载，由于许多云提供商都是根据 IOPS 可能 CPU 时间等收费，所以这些工作负载可能会无谓地产生一笔数额巨大的账单。

出口费——数据进来容易，要出去就不那么简单了

在多云可能混合云设置中，服务需要跨不同提供商的网站进行(Carry Out)通信。通常，将数据（入口）传入托管数据库不会产生数据传输成本。然而，将数据传出（出口）则是有成本的。对于需要从托管数据库服务传出数据的企业来说，出口费是一个重要的成本因素。从某种意义上说，这是为了限制用户迁出他们(They)的数据。

像 Cloudflare 这样的提供商非常清楚这一挑战，他们(They)创建了带宽联盟，旨在降低可能免除成员提供商之间的数据传输成本。最近，谷歌云取消了将数据迁移到另一家云提供商的数据传输费。这种做法是如此的不公平，以至于欧盟和英国(Britain)的监管机构正在积极进行(Carry Out)调查。

运营成本——还是有很多事情要做

虽然服务提供商负责第 0 天的操作，但用户还是要面对第 1 天和第 2 天的挑战。期望提供商解决所有的运营挑战是不合理的。不过，了解下需要做些什么操作以及涉及哪些成本还是好的。

a）二次备份

数据是业务的核心。我认为，如果数据完好无损，任何软件业务都可以重建。作为一名数据库工程师，数据丢失是我迄今为止最大的噩梦。执着于备份并不是一件坏事。完全依赖提供商进行(Carry Out)备份就像把所有鸡蛋放在一个篮子里。即使提供商提供了一个很好的 SLA/SLO，但是完全丢失备份的风险依然存在。

在大多数情况下，保护数据是企业对最终用户的责任。大多数成熟的组织在其主要服务提供商之外都有二次备份。要做到这一点，就得付出存储和计算、数据传输和工程成本。

b）备份恢复

备份的质量由恢复能力决定。如果备份无法恢复，那么它们(They)还有什么价值呢？遗憾的是，在这方面，许多提供商都没有做任何事情，而是把这部分工作留给了他们(They)的用户。这个问题很复杂，但也很容易理解，因为提供商无法知道每家企业的需求。因此，用户需要经常进行(Carry Out)自动可能手动测试，以验证备份及恢复过程的完整性。

服务停止——这是常有的事

遗憾的是，随着事情的发展，有些服务可能会停止。去年，Azure 上的 MariaDB 就退役了。Aurora ServerlessV1 在 2024 年后也将不再支持。如果数据库是闭源的，那么唯一的出路就是使用提供商提供的工具将其导出到其他地方。实际上，数据迁移的架构必须能够减少数据丢失和服务停机时间。如果服务是基于像 Postgres 这样的开源数据库，甚至是使用了开放协议（例如 Postgres Wire Protocol），那么迁移起来就更容易一些。然而，数据库 / 数据迁移总的来说是很痛苦的。

缺乏灵活性——无法完全控制

由于托管服务往往会专注于解决常见的问题，所以有时很有局限性。提供商必须为数千客户管理许多服务，因此很难甚至不可能提供充分的灵活性。可能开始的时候，这听起来并不是什么问题，但随着业务的发展，那可能会开始造成伤害。例如，Postgres 有一个庞大的扩展生态系统。

许多托管服务只允许安装其中的一部分扩展。例如，AWS 和 GCP 不支持 pg_ivm（增量视图维护）和 zombodb（简化 Postgres 中的搜索）等开源扩展，这可能严重限制你可以构建可能依赖的特性。

缺乏可见性——发生了什么？

作为一名工程师，没有什么比有工程问题无法解决更让我沮丧的了。在某种程度上，数据库可以看作是一个黑盒子。大多数数据库用户都把它们(They)作为存储和检索数据的地方。他们(They)不用太关心数据库里发生了什么。尽管如此，当某些东西出现故障时，用户仍然可以使用提供商提供的工具排除故障。

通常，提供商会使用一些虚拟化技术（虚拟机、容器）来运行数据库，有时甚至由编排器（如 k8）来操作。而且，对于运行数据库的服务器，它们(They)不一定会提供完整的访问权限。多层抽象并没有让事情变得更简单。

虽然提供商不提供完整的访问权限是为了防止用户“搬起石头砸自己的脚”，但可能会有高级用户需要更高的权限来了解不同栈上发生的事情并解决潜在的问题。这是我选择自托管软件时考虑的主要因素，目的是获得最大的控制权限。这可能涉及到托管在我本地的数据中心可能利用(Use)一些基本组件，如虚拟机和对象存储，让我可以创建和管理我的服务。

此外，在 Hacker News 等论坛上也有大量关于自托管与托管服务的讨论(Discuss)。其中一条评论总结道：

这里（自托管）肯定有一些东西需要考虑。不过，我发现大多数人都大大高估了与之相关的工作量。

此外，他们(They)往往低估了使用托管解决方案时所需的工作量。例如，即使对于托管选项，你肯定也希望(Hope)进行(Carry Out)二次备份和恢复测试。

我注意到，还有一个副作用是，团队倾向于在遇到问题时投入更多的资金（增加实例大小），希望(Hope)借此在无法确定根本原因的情况下解决他们(They)的一些挑战。根据 Ottertune（一家专门从事数据库工作负载调优的公司）的说法，如果不经过专业的调优配置，即使是增加实例类型，也不会带来成比例地性能提升。

无论你的技能水平如何，这个挑战也都几乎是无法解决的。例如，Kyle Kingsbury 是分布式系统教授，也是 Jepsen test（用于验证分布式系统的安危性和一致性）的作者。在测试 MySQL 8.0 版本的正确性时，他遇到了一个数据库复制问题，并向服务提供商寻求了支持。

一个越来越明显的趋势是，服务提供商依赖于其他托管提供商来交付解决方案。然而，当基础提供商未能满足期望可能表现不佳时，他们(They)就会产生挫败感。关键是，即使支付了高昂的价格，并与供应商签订了业务 SLA，他们(They)也无能为力。

权衡

你可能已经注意到，本文有一个不变的主题，就是权衡。本文的目的不是阻止任何人使用云计算可能托管服务。本文主要是为了让人们意识到其中所涉及的成本、保持开放和提供商锁定之间的界限、有限的功能集、可见性的缺失以及必须进行(Carry Out)的 Day-2 操作。

当第一次开始使用托管数据库服务时，我并没有留意到这些方面。希望(Hope)本文能帮助开发商和运营商做出明智的决定。

原文链接：

https://www.infoq.com/articles/managed-relational-databases-costs/

本文来自微信公众号“InfoQ”（ID：infoqchina），作者：Ravichandran ，36氪经授权发布。

该文观点仅代表作者本人，36氪平台仅提供信息存储空间服务。

+14

好文章，需要你的鼓励

极客邦科技(Technology)InfoQ特邀作者0收藏+10评论打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮微博沉浸阅读返回顶部参与评论评论千万条，友善第一条登录后参与讨论(Discuss)提交评论0/1000你可能也喜欢这些文章云厂商2024：卷出天际，流血拼杀价格战，阿里云的中场战事读懂马斯克下云，就读懂私有云为什么崛起？价格战成了云大厂的舒适区？阿里云再次降价，云计算竞争进入深水区阿里云掀起价格战，2024云厂商们卷向何处？云计算，用价格让利换创新空间？阿里云为何又“掀桌子”了？史上最大规模降价难掩阿里云忧愁，云厂商的无奈可能只有AI能解最新文章推荐有PE想出460亿买下梅西百货瑜伽裤卖爆的2024：“她运动”消费力正在崛起打工人(Worker)和企业有多焦虑，BOSS直聘就有多赚钱“优异”的ESG实践，为何没能成为农夫山泉的“保护伞”？直播带货救不了所有人首批A50ETF“发行战”：两家“爆冷”出线，但后劲不足使用托管数据库的隐性成本攀登者何川：远征与守望｜氪金 · 行业风尚在技术无人区「敢为创新」，一场勇敢者的游戏(Game)星舰第三次发射不圆满，但马斯克没失败(Failure)

极客邦科技(Technology)InfoQ特邀作者

InfoQ、TGO鲲鹏会、极客时间App、QCon等都是我们(We)

发表文章394篇最近内容使用托管数据库的隐性成本18分钟前“微软已经沦落为 OpenAI 的一个 IT 部门”，资源倾斜引发微软内部员工不满、高管离职昨天(Yesterday)多模态+大模型会带来哪些“化学反应”？2024-03-12阅读更多内容，狠戳这里下一篇攀登者何川：远征与守望｜氪金 · 行业风尚

“比大山更难攀登的是生活(Life)”

28分钟前

热门标签鲷鱼天山雪量子态潮汕菜美食(Food)旅游(Travel)上海市统计局非上市公司股权激励非上市公司姜华软件授权会议纪要声波支付泡泡浴光伏签约电动扶梯明星(Star)婚礼脑瘫三公子6·21爆吧事件百度贴吧吧主制度阿尔卡特朗讯乳头猪脖子脓毒症爽子attention汪军无锡尚德大闲人皮下脂肪关于36氪城市合作寻求报道我要入驻投资者关系商务合作关于我们(We)联系我们(We)加入我们(We)网站谣言信息举报入口热门推荐热门资讯热门产品文章标签快讯标签合作伙伴