从文件系统而不是数据库提供我的文本？答案

【问题标题】：serve my text from the filesystem instead of a database?从文件系统而不是数据库提供我的文本？
【发布时间】：2009-07-08 07:38:52
【问题描述】：

我正在开发一个内容管理应用程序，其中存储在数据库中的数据非常通用。在这个特定的例子中，一个容器有很多资源，这些资源映射到某种数字资产，无论是图片、电影、上传的文件还是纯文本。

我已经和一位同事争论了一个星期了，因为除了存储图片等之外，他们还希望将文本资产存储在文件系统上并让应用程序查找文件位置（从数据库中）并在提供给客户端应用程序之前读入文本文件（从文件系统）。

常识似乎对我大喊，这太荒谬了，如果我们费心从数据库中查找某些内容，我们不妨将文本存储在数据库列中，并将其与行查找一起提供。数据库查找 + 文件 IO 听起来比数据库查找慢得多。来来回回了一段时间后，我决定运行一些基准测试，发现结果有点令人惊讶。在基准时间方面似乎几乎没有一致性。基准测试中唯一明显的赢家是从数据库中提取一个大型数据集并迭代结果以显示文本资产，但是从数据库中一次提取一个对象并显示其文本内容似乎并驾齐驱。

现在我知道了运行基准测试的局限性，我什至不确定我是否在运行“测试”的正确概念（例如，文件系统写入比数据库写入快得离谱，我不知道！）。我想我的问题是为了确认。文件 I/O 是否可与数据库文本存储/查找相媲美？我在这里遗漏了部分论点吗？提前感谢您的意见/建议！

快速了解我正在使用的内容：这是一个 Ruby on Rails 应用程序，使用 Ruby 1.8.6 和 Sqlite3。我打算将相同的代码库移至 MySQL 明天看看基准是否一样的。

【问题讨论】：

我自己没有做过这样的测试，但我想知道文件系统在存在大量文件的情况下如何运行。归根结底，文件系统也只是一种数据库。我喜欢“真实”数据库的是事务处理/原子插入。不知何故，我对文件系统感到偏执，并担心写入可能会在操作过程中崩溃，从而使整个文件处于损坏状态。也就是说，我认为将大型“哑”文件（如图像）放在文件系统上并将它们的文件名存储在数据库中是一种常见的方法。不过，请尝试让 Web 服务器直接为其提供服务。

标签： ruby-on-rails ruby database file-io

【解决方案1】：

不使用文件系统的主要好处是数据库可以正确管理并发访问。假设 2 个进程需要同时修改相同的文本，与文件系统同步可能会导致竞争条件，而数据库中的所有内容都没有问题。

【讨论】：

【解决方案2】：

我认为您的基准测试结果将取决于您在数据库中存储文本数据的方式。如果将其存储为 LOB，则在幕后将其存储在普通文件中。无论如何，对于任何类型的 LOB，您都需要支付数据库查找 + 文件 IO。

VARCHAR 存储在表空间中

在典型的关系数据库系统中，普通文本数据类型（VARCHAR 等）的大小非常有限。像 2000 或 4000 (Oracle) 有时是 8000 甚至 65536 个字符。一些数据库支持长文本但是 these have serious drawbacks and are not recommended。

LOB 是对文件系统对象的引用

如果您的文本较大，则必须使用 LOB 数据类型（例如 Oracle 中的 CLOB）。

LOB 通常是这样工作的：数据库仅存储对文件系统对象的引用。文件系统对象包含数据（例如文本数据）。这与您的同事的建议非常相似，只是 DBMS 承担了繁重的工作管理参考资料和文件。

底线是： 如果您可以将文本存储在 VARCHAR 中，那就去吧。如果不能，您有两个选择：使用 LOB 或将数据存储在从数据库引用的文件中。两者在技术上相似，但都比使用 VARCHAR 慢。

【讨论】：

因为我们将使用的数据库是 mysql5，这是我倾注的文档。此页面：dev.mysql.com/doc/refman/5.1/en/char.html 似乎表明理论上可以将最大字符长度设置为 65,535 ...这听起来远远超出了您指定的危险长度...尽管这 65,535 是字节，我不确定转换是什么时候涉及到 unicode，我需要研究一下。您认为非 LOB（MySQL 中的文本字段）中这么长的字符串会很危险吗？
我想知道自己是如何对待 unicode 的。如果存储为 utf-8，则一个字符最多为 4 个字节，英文文本通常为每个字符 1 个字节。我在 MySQL 中看到非常大的 VARCHARS 的一个危险是它可以填满最大行大小（65,535 字节，在所有列之间共享）。有关 MySQL 中 TEXT 和 VARCHAR 之间的性能比较，请参阅forums.mysql.com/read.php?24,105964,105964

【解决方案3】：

我以前做过。它一团糟，您需要始终保持文件系统和数据库同步，这会使编程更加复杂，正如您所猜测的那样。我的建议是要么采用全文件系统解决方案，要么采用全数据库解决方案，具体取决于数据。值得注意的是，如果您需要大量搜索、条件数据检索，则使用数据库，否则使用 fs。请注意，数据库可能未针对大型二进制文件的存储进行优化。不过，请记住，如果您同时使用两者，则必须使它们保持同步，并且它不会提供优雅或令人愉快的（编程）解决方案。祝你好运！

【讨论】：

【解决方案4】：

至少，如果您的问题来自“性能方面”，您可以使用“no SQL”存储解决方案，例如 Redis（例如通过 Ohm）或 CouchDB...

【讨论】：