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

Question

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

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

文章检索会因为它是一个平面文件而不是RDBMS而被删除吗？ （一厢情愿）

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

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

Answer 1

平面文件数据库占有一席之地，并且适用于正确的域。

过去的邮件服务器和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.txt）。然后，在午夜，您运行两个进程。第一个获取“今天”目录中的所有文件，检查其创建日期以确保它们不是“今天”（因为该过程可能需要几秒钟而新文件可能会潜入），并将这些文件重命名为“昨天”。接下来，您对“昨天”目录执行相同的操作，只有在这里您只是删除它们，如果它们已过期。

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

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

在交易数据库中，您可以一次性完成所有操作。

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

Answer 2

（从here复制和修改的答案）

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

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

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

Answer 3

这是通过asp.net与Dasblog完成的。它使用基于文件的存储。

此旧链接中列出了一些详细信息。 http://www.hanselman.com/blog/UpcomingDasBlog19.aspx

您还可以获得有关http://dasblog.info/Features.aspx

的更多详情

我听到了一些关于表现的不同意见。我建议你研究一下，看看那种类型的系统是否适合你。这是我听到的最接近的事情。

Answer 4

在本机代码中编写自己的引擎可以胜过通用数据库。

但是，引擎的质量和功能级别永远不会接近。数据库为您提供的所有功能 - 索引，事务，参照完整性 - 您必须自己实现所有这些功能。

重新发明轮子没什么不对（毕竟Linux就是这样），但要记住你的期望和时间承诺。

Answer 5

我回答这个问题并不是为了回答为什么平面文件数据库好坏，其他人已经做了充分的工作。

然而，有些人一直指着SQLite，它的工作做得很好。由于您使用的是Java，因此最好的选择是使用HSQLDB，它与SQLite完全相同，但是用Java实现并嵌入到您的应用程序中。

Answer 6

大多数情况下，平面文件数据库足够现在。但是，如果您使用数据库启动项目，那么您将感谢年轻的自己。如果您不想设置像SQLite这样的整个数据库系统，则可以是PostgreSQL。

Answer 7

可怕的主意。追加将涉及在每次要添加内容时寻找文件的末尾。更新需要每次都重写整个文件。读取涉及表扫描（或维护单独的索引，这将与写入/更新具有相同的问题）。只需使用数据库，除非您重新实现RDBMS已经提供的所有内容，以使您的解决方案具有适度的可扩展性。

Answer 8

它们似乎适用于高写入，低读取，无更新数据库，其中附加了新数据。

Web服务器及其表兄弟严重依赖它们来处理日志文件。

DBMS软件也将它们用于日志。

如果您的设计符合这些限制，那么您似乎很好。您可能希望在数据库中保留元数据和指针，并设置某种快速异步队列编写器来缓冲注释，但文件系统已经非常擅长缓冲和写锁定。

Answer 9

平面文件数据库是可能的，但请考虑以下内容。

数据库需要获得所有ACID元素（原子性，一致性，隔离性，持久性），如果您要确保所有内容都在平面文件中完成（特别是并发访问），那么您基本上已经写完了 - 吹DBMS。

那么为什么不首先使用成熟的DBMS呢？

如果您只使用其中一个免费选项（SQLite，MySQL，PostgresSQL等），您将节省自己编写时间和金钱（并重写多次，我保证）。

Answer 10

如果文件数据库足够小并且没有丢失随机访问权限，则可以使用该文件数据库。具有大量随机访问权限的大文件将非常慢。而且没有复杂的查询。没有连接，没有总和，分组等。您也不能指望从平面文件中获取分层数据。对于复杂的结构，XML格式要好得多。

Answer 11

检查出http://jsondb.io一个基于Java的开源数据库拥有您正在寻找的大部分内容。 将数据保存为平面.json文件，多线程支持，加密支持，ORM支持，原子支持，基于XPATH的高级查询支持。

免责声明：我创建了这个数据库。