关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
4年前关闭。
Improve this question
需要有关平面文件数据库优点的知情选项。我正在考虑使用平面文件数据库方案来管理自定义博客的数据。它将部署在 Linux 操作系统变体上并用 Java 编写。
文章和评论的阅读和写作表现可能存在哪些负面或正面影响？
文章检索是否会因为它是一个平面文件而不是 RDBMS 而失败，如果它被斜杠化了？ (一厢情愿)
我不反对使用 RDBMS，只是询问社区他们对这种软件架构方案的可行性的看法。
跟进:
在这个问题的情况下，我会看到“Flat file == file system-based” 例如，每个博客条目及其随附的元数据将在一个文件中。按文件夹的日期结构组织许多文件 (blogs\testblog2\2008\12\01) == 12/01/2008
最佳答案
平面文件数据库有其一席之地，并且非常适用于正确的域。
过去的邮件服务器和 NNTP 服务器确实插入了您可以真正使用这些东西的极限(实际上相当远——文件系统可以拥有数百万个文件和目录)。
平面文件数据库的两个最大弱点是索引和原子更新，但如果域合适，这些可能不是问题。
但是，例如，通过适当的锁定，您可以使用基本文件系统命令进行“原子”索引更新，至少在 Unix 上是这样。
一个简单的情况是让索引过程遍历数据以在临时名称下创建新的索引文件。然后，当您完成后，您只需将旧文件重命名(系统调用 rename(2) 或 shell mv 命令)覆盖新文件。重命名和 mv 是 Unix 系统上的原子操作(即它要么有效，要么无效，而且永远不会缺少“状态之间”)。
与创建新条目相同。基本上将文件完全写入临时文件，然后将其重命名或 mv 到其最终位置。那么你在“DB”中永远不会有“中间”文件。否则，您可能会遇到竞争条件(例如一个进程正在读取仍在写入的文件，并且可能在写入过程完成之前就结束——丑陋的竞争条件)。
如果您的主索引与目录名称配合良好，则效果很好。例如，您可以使用散列方案来创建目录和子目录以定位新文件。
使用文件名和目录结构查找文件的速度非常快，因为当今大多数文件系统都会对它们的目录进行索引。
如果您将一百万个文件放在一个目录中，则很可能存在您想要查看的调整问题，但开箱即用的大多数文件都可以轻松处理成千上百的文件。请记住，如果您需要扫描目录，将会有很多文件需要扫描。通过目录进行分区有助于防止这种情况。
但这一切都取决于您的索引和搜索技术。
实际上，提供静态内容的现成 Web 服务器是一个大型平面文件数据库，并且该模型运行良好。
最后，当然，您可以使用大量免费的 Unix 文件系统级工具，但所有这些工具都存在大量文件的问题( fork grep 1000000 次以在文件中查找某些内容会导致性能权衡——开销只会增加上)。
如果您的所有文件都在同一个文件系统上，那么硬链接(hard link)还为您提供了将相同文件放在不同位置(主要用于索引)方面的选项(因为它们也是原子的)。
例如，您可以有一个“today”目录、一个“yesterday”目录、一个“java”目录和实际的消息目录。
因此，可以将帖子链接到“今天”目录、“java”目录(因为帖子被标记为“java”)和最终位置(例如/articles/2008/12/01/my_java_post .txt)。然后，在午夜，您运行两个进程。第一个获取“今天”目录中的所有文件，检查它们的创建日期以确保它们不是“今天”(因为该过程可能需要几秒钟并且可能会潜入一个新文件)，并将这些文件重命名为“昨天”。接下来，您对“昨天”目录执行相同的操作，只是在这里您只需删除它们，如果它们已过期。
同时，该文件仍在“java”和“.../12/01”目录中。由于您使用的是 Unix 文件系统和硬链接(hard link)，"file"只存在一次，这些都只是指向文件的指针。它们都不是“那个”文件，它们都是一样的。
您可以看到，虽然每个单独的文件移动都是原子的，但批量不是。例如，当“today”脚本正在运行时，“yesterday”目录很可能包含来自“yesterday”和“the day before”的文件，因为“yesterday”脚本尚未运行。
在事务性数据库中，您可以一次性完成所有这些操作。
但是，简单地说，这是一种久经考验的方法。尤其是 Unix，可以很好地使用这种习惯用法，而且现代文件系统也可以很好地支持它。
关于java - 平面文件数据库好用吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/332825/