为什么Windows / Linux不使用关系数据库（RDBMS）？

Windows / Linux为什么不使用关系数据库（RDBMS）？

我知道他们使用文件系统来存储所有数据，但是您不认为像在网站/ Web应用程序中那样使用数据库会更有效吗？

请详细说明如何通过数据库使用文件系统进行存储。

这与“ 何时应优先使用数据库而不是从文本文件中解析数据”相重复？我仅在操作系统上下文方面进行讨论，而这个问题是笼统的。

如今，大多数数据库管理系统（例如PostGreSQL，MongoDB等）在内部将其数据保留在OS文件中（过去，某些DBMS直接使用原始磁盘分区）。

^{在最近仍在使用旋转硬盘的计算机上，磁盘速度相对于CPU或RAM而言是如此之慢，以至于添加一些软件层并不重要。SSD技术可能会有所改变，并且某些文件系统已针对SSD进行了优化。}

通常，出于历史和社会原因，大多数操作系统中都存在文件（特别是C编译器和大多数工具-编辑器，链接器-想要文件，因此存在麻烦的问题），并且由于存在很多非常好的文件系统实现。

顺便说一句，一些必要的系统设施可以使用数据库。例如，在Linux上，可以将PAM配置为使用数据库中的信息（但实际上很少这样做）。同样，某些邮件服务器可能会将其部分或大部分数据存储在数据库中（例如Exim）。

文件的抽象程度略低于数据库，因此它们可以更轻松地实现（作为Linux内核中的文件系统和VFS层）并且使用起来更快。特别是，对文件的操作比对数据库的操作要严格得多。实际上，您可以将文件或文件系统视为某些非常受限制的数据库！

您可以设计一个不带任何文件的操作系统，但可以使用其他一些正交的持久性机制（例如，使每个进程都具有持久性，那么您就不必显式关心存储了，因为操作系统正在管理持久性资源）。这已经在几种学术操作系统^（1）（以及1980年代的Smalltalk和Lisp机器）中完成了，在IBM System i，aka / AS / 400中以及在与osdev链接的一些玩具项目中都已完成。），但以这种方式设计操作系统时，您将无法利用许多现有工具（例如，您还需要从头开始制作编译器和用户界面，这是很多工作）。

请注意，微内核操作系统可能不需要内核层提供的文件，因为文件系统只是应用程序服务器（例如，在用户区中运行的Hurd 转换器）。还要看看当今的MirageOS中的单内核方法

Linux（可能是Windows，其大部分灵感来自VMS和Unix）需要文件才能工作。至少，init程序（由内核启动的第一个程序）必须是存储在文件中的可执行文件（通常是/sbin/init，但现在可以将其系统化），并且（几乎）所有其他程序都由execve（2）启动。） syscall，因此必须存储在文件中。但是，FUSE使您可以为非文件内容提供类似文件的语义。

还请注意，在Linux（甚至可能是Windows，我不知道并且从未使用过）上，sqlite是一个库，用于管理文件中的某些SQL数据库并为此提供API。众所周知，Android（Linux变体）使用许多sqlite文件（但它仍然具有类似POSIX的文件系统）。

另请阅读有关应用程序检查点（在许多当前的OS上，该检查点已实现为将过程状态写入文件中）。推到了极点，这种方法不需要手动编写应用程序文件（而仅是使用检查点机制来保留整个过程状态）。

实际上，一个有趣的问题是为什么当前的操作系统仍然使用文件，而答案是遗留的，以及经济和文化上的原因（不幸的是，当今大多数编程语言和库仍然需要文件）。

注1：持久的学术OS包括Lisaac和Grasshopper，但是这些学术项目似乎并不活跃。也可以浏览http://tunes.org/ ; 它是不活跃的，但是已经围绕此类主题进行了很多讨论。

注2：文件的概念已经广为随时间的变化（看看这个回答我的第一个编程经验）：第一个MSDOS上世纪80年代的IBM个人电脑（！没有目录）中，VMS -on 1978年Vaxen - （有两个固定记录文件和顺序文件，以及原始版本控制系统），1970年代的大型机（带有OS / VS2 MVS的IBM / 370）对文件和文件系统的概念非常不同（特别是因为在那时它们的硬盘访问时间与核心存储器存取时间为几千-所以当时磁盘运行相对比今天更快，即使今天的磁盘绝对今天，CPU /磁盘速度之比大约比上个世纪快一百万；但我们现在有了SSD）。另外，当内存持久存在时（例如在1960年代的CAB500磁鼓上，或将来使用MRAM的计算机上），文件的用处就更少（甚至没有用）。

尽管这是基于观点的，但我认为这只是另一历史文物。早期的OS使用简单的文件系统设计来实现性能，该设计与当时可用硬件的特性密切相关，从那以后一直是相同的方式。建立事务处理查询/插入API后，很难更改旧文件的读取/写入API。

当前所有文件系统都要求与这些旧API向后兼容。

微软确实考虑过在Longhorn开发中用基于RDBMS的文件系统替换文件系统。对于他们来说，这是一个很大的改变，但是您确实看到他们以Windows搜索（使用RDBMS存储元数据副本）和SQL Server的Filestream系统（其中包含文件数据的数据库表作为普通目录向操作系统公开，允许Windows资源管理器访问该数据以及对相同数据进行SQL查询。

其他操作系统确实具有RDBMS文件系统。AS / 400曾经有这些，尽管我从没有对它们有足够的了解。我记得当时看起来很奇怪。我认为其他大型机系统具有相同的方法。

真正的原因是对它的缺乏。将数据库分层放置在文件之上，而不是合并它们，至少可以处理绝大多数情况，以及能够大大降低复杂性的合并解决方案。在某些情况下，其他人已经提到过，我们还将文件的某些部分放在数据库之上（例如权限结构）。在那种情况下，管理这些权限的数据库比商业RDBMS显着简单。

合并它们有​​很多优点，但是到目前为止，它们之间的距离太少了，以至于运动发展缓慢。考虑一下人们说“给我我自2010年以来收到的每张发票的第3列，并将它们汇总在一起”或“在我从Excel中删除该文件之前，不要让我删除此文件”是多么罕见的情况电子表格。”

与关系数据库相比，文件系统具有一些使其保持运转的优势：

• 它们要简单得多。引导计算机时，这很重要。即使在具有RDBMS进行存储的Android上，它们也具有用于管理初始引导加载过程的普通旧映像。
  • 定义它们的局限性比较容易。在无限制的机器中，RDBM提供了很多功能。但是，在文件系统世界中，有很多局限性是由于试图直接放在旋转磁盘顶部时要快而导致的。很难证明RDBMS查询没有超出那些限制，而不是为文件系统提供相同的保证。
• 他们更好地处理了层次结构。在许多情况下，人们仍然很自然地以分层形式存储文件。在RDBMSes中，这是一种特殊情况。文件系统针对这种特殊情况进行了优化，而RDBMS则没有。
• 可靠性。证明两层独立工作要比证明一个巨型系统工作正常要容易得多。RAID阵列，停电时的故障安全日志以及其他高级功能在处理ACID或外键约束之类的该层下的一层中更易于实现。

我认为其他答案提供了广泛的理由，说明为什么操作系统内部/外部不依赖关系数据库，因此我将只分享我曾经偶然发现的一条有趣的信息。

显然，有一些技术可以让您在有理由使用关系数据库时将关系数据库挂载为文件系统。Oracle DBFS（数据库文件系统）就是一个示例。文档中的以下代码片段很好地解释了其背后的原理：

数据库文件系统（DBFS）利用数据库的功能来存储文件，以及数据库在有效管理关系数据方面的优势，从而为存储在数据库中的文件实现标准的文件系统接口。使用此接口，将文件存储在数据库中不再局限于专门为使用BLOB而CLOB编写的程序和程序接口。现在可以使用对文件起作用的任何操作系统（OS）程序透明地访问数据库中的文件。

该解决方案为存储在数据库表中的LOB数据提供了一组接口（命令行客户端，代码库）。可以在Windows和Linux操作系统上使用它（尽管据我所知，它们之间的集成程度有所不同）

资料来源：docs.oracle.com

根据文档，文件系统应该可以在Linux上以透明方式使用

在Linux上，它dbfs_client也具有安装接口，该接口利用User Space（FUSE）内核模块中的文件系统来实现文件系统安装点，该文件提供对存储在数据库中的文件的透明访问，并且无需更改Linux内核。它从FUSE内核模块接收标准文件系统调用，并将其转换为对DBFS Content Store中PL / SQL过程的OCI调用。

因此，您的问题的答案是，通常来说，操作系统没有理由将关系数据库用作文件系统（对于OS的核心组件，这实际上很麻烦）。同时，当有一些问题需要时，也有可能这样做。

任何OS的主要功能是促进应用程序，硬件和用户之间的交互。

那么，为什么Windows / Linux OS不使用关系数据库（RDBMS）？这是一个关于圣经比例的问题，但是简短的答案是：使用诸如rdbms之类的复杂结构作为文件系统并不会获得任何真正的好处。

“关系”是“关系数据库”中的可操作词，存储在文件系统中的大多数数据与其他数据无关。文件系统通常实现为有限的数据库，而不是关系数据库。