我已经完成了一个应用程序，并且一直在研究部署它的托管环境。该应用程序的查询量相当大，我的应用程序的大多数页面都有几个查询，其中有多个连接以及大多数表上的触发器。只要数据库有足够的 RAM 用于缓冲池，我猜性能应该没问题，所以如果我使用像 Linode 这样的 VPS 主机，我就可以不断升级我的服务器，以便数据库有足够的 RAM。我担心的是当我无法获得更多 RAM 时会发生什么，当数据库没有足够的 RAM 时，性能会受到多大的影响？我是否应该将不断减少的可用内存视为定时炸弹？DBMS 是否会更改其缓存技术以尽可能避免磁盘访问？本质上，我想知道 DBMS 有多智能以及它们在使用分片或复制之前如何应对。
答案1
一般来说，程序的智能程度与编程程度完全一致。DBMS 就是程序。因此，如果不知道您使用的是哪种 DBMS，就无法大致判断会发生什么。因此，对您问题的唯一正确答案是投票“不是真正的问题”（我注意到有人已经投票了）。但是，我有一些空闲时间，所以我将写一篇关于数据库扩展和性能的一般文章，希望它能回答您的问题应该正在询问。
由于您使用的是“DBMS”这个已经不再流行的术语，因此我假设您使用的是已经不再流行的关系数据库，事情会变得更加复杂。我熟悉的引擎（MySQL 和 PostgreSQL）都有无数个旋钮来告诉系统要使用多少 RAM——各种缓存、工作集内存、缓冲区……这一切都很有趣。根据工作负载和可用系统资源适当地调整它们主要是（但并非完全）为了减少磁盘 I/O，因为这通常是（但同样，并非总是）物理系统中最慢且最容易造成瓶颈的组件。
因此，当您无法进一步增加 RAM 时，您的性能将开始受到影响（希望是逐渐的），因为更多查询需要更多磁盘访问才能完成。随着数据库大小的增加，性能下降将因磁盘 I/O 性能不佳而加剧。
考虑到水平扩展关系数据库的难度（这并不不可能的但这比水平扩展前端要困难得多），如果你打算大规模地做事，你需要一个能为你提供大型机器的供应商——大量的 RAM，还有大量的 CPU、磁盘空间和IOPS。Linode 最大的 VM 似乎只有 20GB，这太小了。AWS 的实例具有高达 70GB 左右的 RAM，这更好，但是当你可以获得具有 TB（或更多）RAM 的物理机时……它仍然不是真正的聪明之举。
虚拟机并不总是错误的对于数据库服务器来说，但在某些时候，当你超出可用的 VM 选项时，你需要知道下一步要做什么。人们越来越普遍地走上“尽早分片，经常分片”的道路，因为如果你要进行大规模扩展，世界上没有一台物理机器可以拯救你，这意味着你可以在你喜欢的任何小型云上运行。然而，分片需要做大量的工作，并且在建模和与数据交互的方式上限制了你的选择，所以如果可以的话，我喜欢避免它。问题是，物理硬件以相当稳定的速度发展，而且已经有很多可供你成长的空间，所以当你有一个需要 2TB RAM 和 30TB 存储空间的数据库时（大约是我目前能买到的最大规格的单个物理机器），技术很可能已经改进到 4TB RAM 和 100TB 存储空间的机器成本较少的比你为那个2TB怪物支付的费用还要多。
（免责声明：我在一家托管服务提供商工作，该服务提供商为各种规模的客户提供大量混合 VPS/物理设置，我相信这会影响我对这个问题的判断）
答案2
让我补充一下 Womble——作为刚刚完成一个大小为 21000gb 的非平凡数据库项目的人……您需要了解 2 个基本问题。
RAM 是相对的。现代服务器的正确数据库内存为 256 GB 甚至更多。VPS 在那个世界中甚至不会显示为“真正的数据库服务器”。
磁盘速度也是相对的。我在家里运行一个系统，你可能会认为它非常强大 - 2 个 SSD、8 个 Velociraptor 只是为了获得适当的数据 IO 预算 - 但在我的世界里，这甚至没有出现 - 我使用的最后一个系统有 3 个存储节点，每个节点都有 768gb 闪存用于缓冲 IO，并且在随机 IO 中传输的数据比你从磁盘顺序获得的数据还要多。
基本上，可以添加的 RAM 比您想象的要多得多，然后在某个时候您坐下来设计一个针对 IO 进行了优化的数据库服务器。有趣的是，今天缺少的一项内容是，每个人都认为虚拟化解决了所有问题并带来了世界，而数据库服务器确实受 IO 限制，这部分问题已经得到解决。现在只需要期待获得带有大量驱动器或实际上是 SSD 的大型机箱。没有什么是免费的，但这是一个不可避免的基本问题，而且已经解决了。这就是您可以从 SUperMicro 获得带有 72 个磁盘插槽的优质 4U 机架的原因之一。这也是设计 SAS 的原因之一。这也是 SSD 非常受数据库欢迎的原因之一 - 就每秒 IO 而言，它们的速度大约是硬盘的 100 倍（或更多）。
VPS 就是不去那里 ;)
DBMS 是否会改变其缓存技术以尽可能避免磁盘访问？
不，它不会。因为这是唯一 (!) 合理的缓存技术。世界上任何合适的数据库 (SQL Server、DB2、Oracle) 都尝试使用内存来尽可能避免 IO。阅读 SQL 博客，很多不太有经验的人总是抱怨 SQL Server 开始使用太多内存 - 当然，因为内存在那里，它会尝试尽可能多地缓存。
这也是数据库使用事务日志的一个原因 - 这意味着对数据库的更改不必立即写入，但可以延迟写入，同时将更新保留在 tx 日志中，从而在发生崩溃时保存。
再次强调，这是一个“已解决的问题”。Oracle 有硬件可以解决这个问题 - 我们的 21000gb 设置使用了 Oracel ExaData，这是他们销售的最小设置。