TL;DR：保持数据层简单，当预算紧张时，您需要它提供的敏捷性。
在过去 12 年帮助人们为他们的企业运行数据库的过程中，我发现在数据库的生命周期中只有两个财务阶段：
- 阶段 1：绝对成本低，因此边际成本无关紧要。
- 阶段 2：绝对成本很高，因此边际成本才是最重要的。
我将第 1 阶段和第 2 阶段之间的这种差异称为“数据库财务缺口”。
存在问题的第一个提示来自关于优化的问题。开发人员和 DBA 对索引、RAM、连接管理、模式设计、分片以及更多技术想法有疑问。许多人认为他们正在解决技术问题，但他们正在解决资金问题。
为什么是钱的问题？如果钱不是问题，那就把硬件放在问题上。然而，由于他们寻求优化，这表明他们选择不将硬件用于解决问题。
第一阶段：绝对成本低
这是运行数据库的蜜月期。运行数据库的成本对企业来说是微不足道的1。这一阶段的情况是：
- 少量应用程序和后台进程
- 数据量小
- 每秒查询和写入峰值处于低两位数
- 硬件压倒了用例
- 单个节点可以处理使用情况
这个阶段的错误不是最终的。常见的错误包括：
- 查询可以在没有索引的情况下运行。
- 数据结构的错误优化无关紧要
- 表扫描不会影响 iOPS，因为行数相对有限。
- 连接池无关紧要，因为应用程序进程有限。
- ORM 并未因次优查询而误入歧途
在这个阶段，很少有事情可以将成本提高到太高而不会引起痛苦。
我已经看到这个阶段以 1GB 数据的 50 美元服务器和 150GB 数据的 5 万美元服务器结束。一旦这个阶段结束，它就会像一吨砖一样撞击。
第二阶段：绝对成本太高
数据库决策的应计技术债务有可能成为实际债务。现在，这是数据库交互知识 、硬件克服不良选择的能力和金钱之间的竞赛。知识、硬件和金钱是三个杠杆。
知识
优化有多种形式，从查询到连接池到模式设计再到分片。知识执行起来通常比硬件或金钱慢——尤其是内部知识。该过程通过迭代以下内容来绑定：
- 理解问题并形成假设所需的时间
- 实施更改所需的时间
- 确认执行的更改所需的时间
- 变化的影响。它解决了整个问题吗？可能的答案是“不”，因为它绝不仅仅是一个问题。更糟糕的情况是，这是一个不利影响5。
所有 Crunchy Data 客户都可以获得专家支持来增强这些决策。我们已经看到足够多的数据库可以让您更快地找到正确答案。
硬件克服不良选择的能力
到 2022 年，我们将提供大量价格合理的硬件选项，以克服错误的决策。SSD 具有令人难以置信的性能和合理的价格。RAM 和以往一样便宜。CPU 拥有比以往更多的内核，这有助于读取，但不利于写入。
因此，当所有其他方法都失败时，将硬件扔到数据库中。投入更多硬件的最终结果是：
- 争取时间来实施优化更改
- 硬件对企业来说太贵了
- 没有单个硬件大到足以支持数据库6的规模
硬件始终是一种选择。第一次升级硬件，大概是正确的选择。硬件升级几次后没有优化，最好看看有没有什么明显的优化可以做。查看 面向开发人员的揭秘数据库性能 或 面向新手的 Postgres 索引。
钱
金钱被用来购买硬件和知识。更大的硬件正在争取时间。聘请顾问指出代码库的潜在变化是购买知识。
如果你只有 1 美元可以花，你会把它花在硬件还是知识上？使用 Crunchy Bridge，我们托管的 Postgres，并获得两者。
3个杠杆的警告
在这个阶段解决一个问题通常会暴露下一个问题。有些人把它比作“wack-a-mole”，但我把它比作在水流中玩耍。当从一个堵塞中释放水时，增加的水流会给下一个堵塞带来压力。在完全满足需求之前，系统的某些部分可能看起来很健康。
原生 SQL 的销售宣传
从阶段 1 转移到阶段 2 时，最大的工具将是快速且低成本地进行更改的能力。我们将其称为“数据敏捷性”。
为什么要_保持简单愚蠢_？技术变化最快的就是从简单到复杂。我见过许多公司从第 1 阶段跳到第 2 阶段。那些行动最快的是那些开始时筹码最简单的公司。
原生 SQL 敏捷性如何？
1.改变数据的存储方式
SQL包中的工具：添加/删除/组合字段，优化字段，分区表，非规范化字段，跨数据库主机分片应用程序分片，将用例拆分为更好地处理工作的数据库，如缓存/排队
2. 改变数据的检索方式
SQL 包中的工具：添加/删除/组合索引、重建查询以更好地使用索引 (EXPLAIN)、将昂贵的查询从 ORM 重构为原生 SQL
3. 测量和可观察性
SQL 包中的工具：慢查询日志记录、CPU / iOPS / RAM 使用情况、应用程序级别监控7
4. 应用程序与数据库的交互
工具包：批量插入、PGBouncer、序列化后台进程、特定任务的专用 API
当跨越这个差距时，Crunchy 有你的支持
Crunchy 的团队是成本扩展方面的专家。我们是专家，因为我们自己完成了跳跃，并帮助许多公司从阶段 1 跳跃到阶段 2。我们的产品（Bridge、 Kubernetes和 Postgres HA）将这些知识封装到工具集中，从而避免或避免问题迅速缓解。
Crunchy 堆栈旨在帮助您最大限度地提高性能成本比。
脚注
- 不同的企业对“微不足道”有不同的衡量标准，因此可能是每月 50 美元、500 美元或 5,000 美元。“微不足道”通常绝不意味着 5 万美元以上（如果是的话，我们很乐意与您交谈）。
- 数据结构的错误优化就像在非关系数据库中使用关系模式一样，在缓存之前实现缓存是非常必要的，在理解正确的分片结构之前进行分片。
- 实际上，在几乎所有情况下，我都是 ORM 的粉丝，但这是另一篇博文。
- 我说“数据库交互优化”是因为数据库从不天生慢，也不快。就是这样。“慢”或“快”来自应用程序与数据库的能力和约束的交互。
- Δ的影响是一个完全无界的负数或正数。我已经看到“改进”使数据库陷入停顿。这种改进通常是“增加应用程序运行者的数量”或“为每个字段添加索引”。
- 没有单个硬件大到足以支持数据库的规模。该短语仅限于非常小的数据库集。如果它与您的公司匹配，我们很乐意为您提供帮助！
- 我应该如何衡量我的数据库性能？衡量数据库性能的首要指标是衡量您的应用程序性能。每个应用程序都有不同的 SLA（已声明和未声明），接近该 SLA 是对堆栈性能的最佳理解。
原文标题：Phases of Database Growth and Cost
原文作者：Christopher Winslett
原文地址：https://www.crunchydata.com/blog/phases-of-database-growth-and-cost
