Windows文件系统的数据库操作速度有多快？

Question

我遇到了一个疯狂的想法，我想与你分享并询问它的可行性，尤其是表现明智：

我们的想法是通过以下方式管理对象数据库操作：

• 为每个以类名命名的类
创建一个文件夹
• 为以子类名称命名的每个子类创建子文件夹
• 为每个以其唯一ID命名的对象创建文件
• 为以索引字段名称命名的每个索引创建子文件夹
• 为每个引用原始目标文件的索引条目创建快捷方式文件
• 通过非常快速的串行器/解串器
读/写二进制对象
• 通过重命名对象和快捷方式文件来插入/更新/删除对象和索引条目
• 使用内存映射文件进行缓存/分页
• 查询将对已排序的文件名使用二进制搜索

更新：感谢大家的回复。我想这可以通过使用一些压缩/加密库（如7z）来改进，而不是处理OS文件系统。否则，到目前为止您提出的所有问题都是有效的。我想知道什么样的底层文件系统，例如，Oracle使用

Answer 1

缺点：

• 在大多数文件系统上，即使是1字节的文件也需要4kb的完整块。根据您想要存储在数据库中的对象类型，这可能是个大问题。
• 大多数文件系统的设计都不适用于包含数百万个文件的目录。
• 复杂查询需要打开/读取/反序列化/关闭数百万个文件，因此速度非常慢。

Answer 2

这是一个有趣的概念，关于你必须解决的直接问题的一些想法。

• Windows文件性能在几十万个文件后受到影响，您需要更改某些方面（关闭8.3和上次更新时间戳）以使其在读取文件系统时不会造成延迟。
• 锁定 - 锁定机制将是一个有趣的挑战，您需要能够锁定更新内容，但允许同时读取。
• ACID - 在针对这个'数据库'执行操作时，您将如何执行ACID原则 - 每个原则都是一个非常重要的问题。

Answer 3

作为一种练习来了解有关数据库的更多信息，但是对于一个应该做任何事情的真实世界的项目，没有。

除了你真正确切知道你在做什么之外，还有很多数据库，除非你确实知道你在做什么，在这种情况下你不会在这里问;），你最有可能永远不会匹配现有的解决方案。

转而使用现有的对象数据库，并专注于应用程序/ site /...

的细节