5

我正在尝试开始使用纯文本文件将数据存储在服务器上，而不是将它们全部存储在大型 MySQL 数据库中。问题是我可能会生成数千个文件夹和数十万个文件（如果我必须扩展的话）。这样做有什么问题？真的变慢了吗？它与使用数据库的性能大致相同吗？

我的意思是：不是有一个存储博客表的数据库，而是有一行包含“作者”、“消息”和“日期”的行，而是：一个特定帖子的文件夹，然后是里面的 *.txt 文件该文件夹中存储了“作者”、“消息”和“日期”。

4

9 回答 9

5

这将比数据库读取速度慢得多（文件写入都以大致相同的速度发生——你不能将写入存储在内存中）。

数据库经过优化，旨在处理如此大量的结构化数据。文件系统不是。尝试使用文件系统复制数据库是错误的。毕竟，您可以索引您的数据库列，但是如果没有其他工具就很难索引文件系统。

数据库是为快速数据访问和检索而构建的。文件系统是为数据存储而构建的。为工作使用正确的工具。在这种情况下，它绝对是一个数据库。

话虽如此，如果您想为帖子创建 HTML 文件，然后将这些语言环境存储在数据库中以便您可以轻松获取它们，那么这绝对是一个很好的解决方案（la Movable Type）。

但是如果你把这些东西存储在一个文件系统上，你怎么能找到你最新的帖子呢？最多产的作者？最有争议的作者？所有这些对于数据库来说都是微不足道的，而对于文件系统来说则非常困难。坚持使用数据库，你会很高兴你做到了。

于 2009-08-03T06:58:27.553 回答
4

这真的取决于：

  • 什么是文件大小
  • 您有什么耐用性要求？
  • 您执行多少次更新？
  • 什么是文件系统？

MySQL 会更快并不明显：

我曾经对小对象进行过这样的比较，以便将其用作CppCMS的会话存储。具有一个索引（仅键）和两个索引（主键和辅助超时）。

File System:   XFS     ext3 
-----------------------------
Writes/s:      322     20,000

Data Base \  Indexes:    Key Only   Key+Timeout
-----------------------------------------------
Berkeley DB              34,400      1,450
Sqlite No Sync            4,600      3,400
Sqlite Delayed Commit    20,800     11,700

如您所见，使用简单的 Ext3 文件系统更快或与 Sqlite3 一样快来存储数据，因为它不给您 (D) ACID。

另一方面... DB 为您提供了许多您可能需要的重要功能，因此我不建议您使用文件作为存储，除非您真的需要它。

请记住，DB并不总是系统的瓶颈

于 2009-08-03T07:11:56.553 回答
4

忘记冗长的答案，以下是为什么将数据存储在纯文本文件中是一个坏主意的最简单原因：

  1. 查询几乎是不可能的。您将如何按日期对博客文章进行排序？您必须阅读所有文件并比较它们的日期，或者维护自己的索引文件（基本上，编写自己的数据库系统。）

  2. 备份是一场噩梦。 tar cjf不会削减它，如果你尝试，你可能会得到一个不一致的快照。

不使用文件可能还有其他十几个充分的理由，很难监控性能，很难调试，在发生错误时几乎不可能恢复，没有工具来处理它们等等......

于 2009-08-03T08:19:09.950 回答
2

我认为这里的关键是您的数据不会有索引。因此，与索引数据库相比，检索任何内容的速度都非常慢。此外，IO 操作成本高昂，数据库可能（部分）在内存中，这使得数据可用更快。

于 2009-08-03T07:15:49.273 回答
1

您并没有真正说明为什么您自己不会使用数据库......但是在您描述的场景中，出于几个原因，我肯定会在任何一天使用数据库而不是文件夹。首先，博客场景看起来很简单，但很容易想象，有一天你会想用更多的功能来扩展它，比如搜索、更多的帖子细节、类别等。

我认为在文件夹结构中增长模型比在数据库中更难。

此外，由于索引和内存缓存，数据库通常比文件访问快得多。

于 2009-08-03T07:14:16.127 回答
1

IIRC Fudforum 出于速度原因使用文件存储，抓取文件比搜索数据库索引、从数据库中检索数据并将其发送给用户要快得多。您正在将文件系统接口与 DB 和 DB-library 接口进行交易。

但是，这并不意味着它会更快或更慢。我认为您会发现在文件系统上写入更快，但在数据库上读取一般问题更快。如果像 fudforum 一样，您有相对不可变的数据想要在一个帖子中显示多个帖子，那么基于文件的方法可能会快得多：例如，他们不必搜索每个相关的帖子，他们将所有内容都放入1个文本文件并显示一次。如果您可以采用这种优化，那么您的基于文件的方法将起作用。

此外，邮件服务器也以基于文件的方法工作，Maildir 格式将每封电子邮件作为文件存储在目录中，而不是在数据库中。

不过我要说的一件事是，您最好将所有内容存储在 1 个文件中，而不是 3 个文件中。文件系统在读取（和缓存）单个文件方面比在多个文件中更好。因此，如果您想将每条消息存储为 3 个部分，请将它们全部保存在一个文件中，读取它以获取任何部分，然后只显示您要显示的部分。

于 2009-08-03T07:21:35.250 回答
0

...然后您想搜索作者的所有帖子，并且您可以阅读一百万个文件而不是简单的 SQL 查询...

于 2009-08-04T10:30:09.330 回答
-1

数据库并不快。想一想：最后他们也将数据存储在文件系统中。因此，数据库是否更快的问题很大程度上取决于访问路径。

如果您只有一个与您的文件结构相关的访问路径，则文件系统可能比数据库快得多。只要确保您有一些可用于文件系统的缓存即可。

当然，您确实失去了数据库的所有优点： - 事务 - 索引数据的灵活方式，因此以相当快的灵活方式访问数据。- 灵活（虽然丑陋）的查询语言 - 高可恢复性。

缩放实际上取决于使用的文件系统。AFAIK 大多数文件系统对文件数量（全部或每个目录）都有某种上限，尽管在新文件上这通常非常高。对于具有某种目录结构的成百上千个文件以将目录保持在合理的大小，应该可以找到性能良好的文件系统。

@Eric 的评论：这取决于你需要什么。如果您只需要每个查询的确切文件内容，并且您可以确定性地确定文件的位置和名称，则直接访问比数据库更快，大致是：

  • 访问一堆索引条目，以便
  • 访问一堆表行（rdbms 通常读取包含多行的块），以便
  • 从块中选择一行。

如果你看一下：你在内存中有索引和额外的行，这使得你的缓存效率低下，数据库的加速应该来自哪里？

数据库非常适合一般情况。但如果你有一个特殊情况，几乎总有一个特殊的解决方案在某种意义上更好。

于 2009-08-03T07:10:12.783 回答
-1

如果您更喜欢使用 RDBMS，为什么不尝试其他开源键值或文档数据库（非关系数据库）..

从您的帖子中，我了解到您不会遵循关系数据库的任何 ACID 属性。最好采用其他键值数据库（mongodb、coutchdb 或 hyphertable）而不是您自己的文件系统实现。它会提供更好的性能比现有的方法..

注意：我也不是这方面的专家。刚开始研究 MongoDB 并发现在类似场景中很有用。只是想分享一下，以防你不知道这些方法

于 2009-08-04T09:40:12.817 回答