平面文件数据库有什么好处吗？

关于平面文件数据库的优点需要知情选项.我正在考虑使用平面文件数据库方案来管理自定义博客的数据.它将部署在Linux OS变体上并用Java编写.

关于阅读和撰写文章和评论的表现可能有什么负面或正面的？

文章检索会因为它是一个平面文件而不是RDBMS而被删除吗？(妄想)

我并不反对使用RDBMS,只是向社群询问他们对这种软件架构方案的可行性的看法.

跟进: 在这个问题的情况下,我会看到"平面文件==基于文件系统"例如每个博客条目及其附带的元数据将在一个文件中.根据文件夹的日期结构组织许多文件(blogs\testblog2\2008\12\01)== 12/01/2008

平面文件数据库有它们的位置,并且对于正确的域非常有用.

过去的邮件服务器和NNTP服务器真正推动了你可以真正掌握这些东西的极限(这实际上相当远 - 文件系统可以拥有数百万个文件和目录).

平面文件DB两个最大的弱点是索引和原子更新,但如果域是合适的,这些可能不是问题.

但是,例如,您可以使用正确的锁定,使用基本文件系统命令进行"原子"索引更新,至少在Unix上.

一个简单的例子是让索引进程在数据中运行,以便在临时名称下创建新的索引文件.然后,完成后,只需在新文件上重命名(系统调用rename(2)或shell mv命令)旧文件.重命名和mv是Unix系统上的原子操作(即它可以工作,也可以不工作,并且在状态之间永远不会丢失").

与创建新条目相同.基本上将文件完全写入临时文件,然后将其重命名或mv到最终位置.然后你永远不会在"DB"中有一个"中间"文件.否则,您可能会遇到竞争条件(例如正在读取仍在写入的文件的进程,并且可能在写入过程完成之前结束 - 丑陋的竞争条件).

如果您的主索引与目录名称一起使用,那么它可以正常工作.例如,您可以使用散列方案来创建目录和子目录以查找新文件.

使用文件名和目录结构查找文件的速度非常快,因为现在大多数文件系统都会将其目录编入索引.

如果您在一个目录中放置了一百万个文件,那么您可能希望查看调整问题,但是在该框中,大多数文件可以轻松处理数十万个文件.请记住,如果您需要扫描目录,那么将会有大量要扫描的文件.通过目录进行分区有助于防止这种情况.

但这一切都取决于您的索引和搜索技术.

实际上,提供静态内容的现成Web服务器是一个大型的平面文件数据库,该模型运行良好.

最后,当然,您可以使用大量免费的Unix文件系统级工具,但是它们都有数以万计的文件存在问题(分析grep 1000000次以查找文件中的某些内容会产生性能折衷 - 开销只会增加向上).

如果您的所有文件都在同一个文件系统上,那么硬链接也会为您提供选项(因为它们也是原子的)就将相同的文件放在不同的位置(主要用于索引).

例如,您可以拥有"today"目录,"yesterday"目录,"java"目录和实际的消息目录.

因此,帖子可以链接到"今天"目录,"java"目录(因为帖子标有"java",比方说),并且在最后的位置(比如/ articles/2008/12/01/my_java_post) .文本).然后,在午夜,您运行两个进程.第一个获取"今天"目录中的所有文件,检查其创建日期以确保它们不是"今天"(因为该过程可能需要几秒钟而新文件可能会潜入),并将这些文件重命名为"昨天".接下来,您对"昨天"目录执行相同操作,只有在这里您只是删除它们,如果它们已过期.

同时,该文件仍在"java"和".../12/01"目录中.由于你使用的是Unix文件系统和硬链接,"文件"只存在一次,这些只是指向文件的指针.它们都不是"文件",它们都是一样的.

您可以看到,虽然每个单独的文件移动都是原子的,但批量却不是.例如,当"今天"脚本运行时,"昨天"目录很可能包含"昨天"和"前一天"的文件,因为"昨天"脚本尚未运行.

在事务DB中,您可以一次完成所有操作.

但是,简单地说,这是一种经过验证的方法.特别是Unix,非常适合这种习惯用法,现代文件系统也可以很好地支持它.

(从这里复制和修改答案)

我建议不要使用平面文件进行除只读访问之外的任何操作,因为这样你就必须处理并发问题,例如确保只有一个进程一次写入文件.相反,我推荐SQLite,一个存储在文件中的全功能SQL数据库.SQLite已经具有内置并发性,因此您不必担心文件锁定等问题,并且读取速度非常快.

但是,如果您正在进行大量数据库更改,则最好在事务中一次完成所有这些更改.这只会将更改写入文件一次,而不是每次发出更改查询.这大大提高了进行多项更改的速度.

当发出更改查询时,无论它是否在一个tranasction内,整个数据库都会被锁定,直到该查询完成.这意味着极大的事务可能会对其他进程的性能产生负面影响,因为它们必须等待事务完成才能访问数据库.在实践中,我没有发现这是显而易见的,但尝试最小化您发出的数据库修改查询的数量总是好的做法,并且它肯定比尝试使用平面文件更快.