前几天朋友提的一个问题我一直在想。现在OS越来越强大了，能不能把数据库该做的部分工作交出来？OS来做，这样数据库的内核就可以大大简化。这个观点让我想起十多年前关于Linux是否需要向开发者提供o_direct文件IO选项的讨论。当时，LinusTorvalds说了一句非常有名的话——“简而言之，整个‘让我们绕过操作系统’的概念只是从根本上被打破了。听起来很简单，但只对一个写数据库的白痴来说听起来很简单，甚至连数据库都不会了解操作系统的用途”。他甚至认为绕过操作系统强大的VMM设计来处理IO是傻子才会做的事，因为Linux已经为数据库应用提供了强大的能力。其实早期的数据库也非常依赖操作系统。我大学毕业后使用的第一个数据库RMS是一个基于openVMS的记录管理系统，其底层依赖于操作系统的基本IPC能力。后来，随着数据库越来越复杂，需要支持的底层OS平台也越来越多，数据库产品也逐渐承担了一些以前OS自己做的事情。2012年的一次测试，让我深刻体会到了数据库和OS融合的能力。当时在一台OracleT4-8上，服务器+Solaris操作系统+Oracle11g的组合跑出了惊人的高性能。不需要做复杂的调优，只需要安装数据库，简单的调整数据库参数，就已经达到了那次测试的最好成绩。后来和参加考试的老外聊天。他表示，在这个组合中，Oracle的一些与并发控制相关的底层调用得到了充分的优化，操作系统大大提高了Oracle的latch和lock操作的并发性。.其实开头提到的问题应该不是问题。现在的Linux与1990年代刚进入我们视野时已经不一样了。当时Linux可以很好的支持WEB应用，但是对数据库的底层支持还很欠缺。比较弱。现在，Linux的能力得到了极大的增强。无论是Redis、MongoDB还是ClickHose，这些新一代的数据库产品无一例外地充分利用了操作系统的底层能力，从而简化了很多传统数据库的复杂性。控制。此外，在存储引擎上大量使用了开源技术，大大降低了数据库开发的门槛。包括大家熟悉的开源数据库MySQL和Postgresql，也充分利用了操作系统在存储引擎上的能力。充分利用OSFILECACHE缓冲数据的能力，从而提高IO性能，通过使用带日志的文件系统消除数据库双写的开销。所有这些都是数据库向操作系统借用能力的有效例子。然而，通用关系型数据库面临的场景非常复杂。在一些特殊的高负载场景下，OS的自动优化能力仍然不能满足数据库的要求。2007年引发的关于o_direct的讨论就是一个很典型的例子。当时数据库厂商需要自己控制IO，而不是使用OS提供的能力。在一个DBA看来，Linus的这番话显得有些武断。对于复杂的通用关系数据库，数据库管理自己的缓冲，这有时比完全依赖操作系统提供的文件缓冲能力更有效。许多。数据库有自己比较复杂的判断热点数据的方法，所以数据库管理系统可能更清楚sharedbuffer中合适的AGEOUTpages，哪些pages需要清理。但是，对于大多数业务应用来说，OS提供的FILECACHE已经可以帮助我们提升性能了。在目前的Postgresql官方文档中，建议只使用20-30%的sharedbuffer，其余的内存应该交给OS。一些PG用户觉得这个建议很好，按照这个建议设置后他们的数据库性能很稳定。但是，一些用户认为将物理内存尽可能多地分配给共享缓冲区具有更好的性能。这是由于业务应用场景的复杂性，在某些场景下可能会导致两种策略的效果相反。对于一个数据库应用系统来说，它的优化是自上而下的。对于一个复杂的应用系统，优化器越高，效果越好，但是优化越高，对前期建设团队的能力要求越高，前期的投入也越大。对于一些规模较小、复杂度较低的应用系统，只需要从底层做优化，其实现成本也很低。负载越高，系统越复杂，需要更高级别的优化。对于某些系统，仅仅依靠操作系统提供的优化能力是不够的。就像开手动档的车和开自动档的车一样。一般路况下，自动挡车就足够了，但在一些特殊的室外陡坡上，手动挡车可能胜任，自动挡车就完全无能为力了。因为自动化的处理能力还是有限的。但是随着操作系统的不断发展，它的能力越来越强，操作系统对数据库的支持能力也越来越强。一些以前依赖数据库核心代码优化的工作，现在仍然可以由操作系统来承担。针对一些特殊场景的数据库产品将率先受益。有时数据库不需要升级，升级OS后数据库的性能自然会提高。不过针对某个数据库定制优化操作系统也是一个思路，在一些云原生数据库或者公有云RDS上可能更容易实现。
