database - 为什么操作系统（Windows、Linux）不使用关系数据库（RDBMS）而不是文件系统？

tl;博士：多样性。

首先，如果您查看原始 FAT 文件系统和原始 Unix 文件系统，它们都是键值存储，它们没有目录层次结构。

其次，此链接表明存在使用 RDBMS 后端实现的文件系统，这与您的问题无关。

话虽如此，将 RDBMS 与作为操作系统存储的文件系统进行比较，使用 RDBMS 有几个缺点：

首先，RDBMS 通过锁定以牺牲性能为代价提供了非常强的保证（ACID）。但是，大多数程序不需要这样的保证（例如，想想每个使用 NoSQL DB 的程序）。相比之下，POSIX 对元数据做出了强有力的保证，但对 I/O 几乎没有任何保证。您可以在 POSIX 之上构建 RDBMS 并添加锁定，但您不能在 RDBMS 之上构建文件系统并移除锁定。

其次，RDBMS 需要模式。想象一下，您为操作系统创建了一个新的存储卷。您需要决定模式，而不是格式化文件系统。什么模式最有用？

对于文件系统，“模式”基本上是一个表，其中包含“路径”、“数据”列，以及每个文件属性（如修改时间、类型和大小）的列。为该模式使用 RDBMS 允许您以原子方式执行诸如批量截断、批量重命名、批量访问控制等操作。但是，它不允许您同时修改同一记录（文件）的数据。它也不允许您实现硬链接。扩展属性或备用数据流仍然必须像现在一样实现，而不是利用 RDBMS 功能以及路径列的特殊索引逻辑，以实现更改目录、列出目录、检查每个目录的权限等功能文件的路径等，以及数据列的特殊逻辑，因为文件的大小可以是 TB。那时，您添加的功能越多，RDBMS 的投资回报率就会下降。

或者，您可以将模式设置为每个程序（即每个程序都可以执行CREATE TABLE等），但是您的功能再次受到 RDBMS 可以执行的操作的限制。例如，你如何得到等价的find / -size +1GBor md5sum，甚至cator ls？这些程序将读取哪些列？您会发现所有通用程序现在都需要获取一组感兴趣的列。它也使编写脚本变得更加困难。

第三，分层系统通常更容易扩展。

一个示例是当您想要添加存储时。在分层文件系统中，即使没有任何花哨的文件系统功能，您也可以简单地将另一个文件系统挂载到一个目录上，并且您拥有新的存储空间。与增加当前文件系统的存储容量的权衡是硬链接和重命名在文件系统中不起作用，并且它们不共享存储容量。但是，在 RDBMS 上，您的选择是创建一个新表并让您的程序/脚本管理这两个表，或者添加更多存储卷，您可能需要为此执行更高级的操作，例如分区。

另一个例子是生态系统要求。作为一个最终用户，他们想要整理他们的 60,000 张图片、5000 首歌曲、数百个工作电子表格、10,000 个模因、数百个电子书、视频等 - 便于按层次排列的东西 - 您目前只需要两个程序 -文件管理器（Explorer、bash、Nautilus 等）和搜索功能（例如find(1)）。在 RDBMS 上，您要么拥有具有不同列的不同表，要么拥有一个具有通用列的表。无论哪种方式，您都必须有一组 SQL 脚本来处理这些特定的集合，这相当于为每种类型的集合都有一个 shell 脚本或一个程序。这意味着，管理大型集合需要更多的编程。

由于分层系统在通用上下文（这是主要操作系统运行的上下文）中很有用，并且因为在分层系统之上构建非分层系统比做其他方式更容易（分层文件系统缓存甚至使libsqlfs的工作更容易），操作系统支持一流的分层系统是很有价值的。

执行摘要是：操作系统服务于许多用例，存储访问是其中的主要部分。操作系统构建尽可能少的存储访问机制是明智的，但它允许应用程序在操作系统之上构建更专业的存储访问机制。

这意味着提供一组小而有用的功能（如权限、锁定、挂载和符号链接），但不会强制要求太多（如锁定或指定操作系统的数据格式）。

RDBMS 太具体了。

database - 为什么操作系统（Windows、Linux）不使用关系数据库（RDBMS）而不是文件系统？

问题描述

解决方案

推荐阅读