为什么要/应该在应用层缓存 DBMS？

Question

该文章描述了DBMS作为在应用层，这就是为什么他们经常使用直接IO绕过文件缓存缓存数据。

我的问题是：DBMS在应用层缓存信息有什么好处？当 DBMS 位于远离应用程序的服务器上时，这些优势会受到怎样的影响？

Answer 1

数据库通常自己实现许多操作系统风格的功能。在较高级别上，这样做是为了提高性能和可伸缩性。

给你一些例子：

操作系统文件缓存是通用的、最不常用的样式缓存。数据库需要对进入缓存的内容和不进入缓存的内容进行更精细的控制。例如，当您为查询计算哈希表时，您希望在查询运行时让它们优先于文件数据（引入一些新文件数据比页出哈希表更便宜）。数据库还需要非常小心地控制内存分配器，以避免堆碎片化。大多数操作系统根本无法完成处理数据库所需的高速分配的任务，并且数据库通常实现自己的内存管理器，为数据库引擎专门构建。

除非您flush在 Linux 中调用或在 Windows 中要求无缓冲 I/O，否则操作系统缓存也不能保证持久性。为了保证一致性和 ACID 属性，数据库需要对数据何时在磁盘上以及何时缓存进行更精细的控制。因此，使用同步缓冲 I/O 几乎没有什么好处。

此外，大多数操作系统缓存的实现相对较差。Windows 文件系统缓存仅在 Windows 2008 周围获得了非常好的 NUMA 样式规模支持，而 Linux 在高内核数下的文件系统性能仍然很差。FreeBSD 甚至不知道 NUMA 是什么。由于数据库需要在非常大的服务器上运行（在某些情况下多达 32 个 CPU 插槽），数据库供应商通常会实现自己的缓存数据结构，这些结构比操作系统默认提供的可扩展性强得多。

最后但并非最不重要的一点：数据库非常需要 I/O，并且可以比典型的文件服务器更难驱动文件系统。对于大多数数据库来说，依赖传统的同步 I/O 实在是太慢了，而他们使用积极的、核心关联的、异步 I/O 完成来获得规模。数据库的 I/O 子系统往往比标准操作系统提供的更先进。

一般来说，与操作系统内核相比，您会在数据库源代码中发现对机器资源的更高级控制。事实上，大多数大规模数据库都实现了自己的用户空间内核，以避免使用操作系统内核原语。如果您看到数据库进行了大量内核转换，请开始四处寻找更好的产品。

好问题！