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

Question

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

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

常识似乎在尖叫我，这太荒谬了，如果我们想要从数据库中查找某些内容，我们不妨将文本存储在数据库列中，并将其与行查找一起提供。数据库查找+文件IO似乎听起来无法控制地比数据库查找慢。经过一段时间的来回，我决定运行一些基准，发现结果有点令人惊讶。在基准测试时间方面似乎很少有一致性。基准测试中唯一明显的赢家是从数据库中提取大型数据集并迭代结果以显示文本资产，但是从数据库中一次拉出一个对象并显示其文本内容似乎是优先考虑的问题。

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

  

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

Answer 1

不使用文件系统可以获得的主要优势是数据库将正确管理并发访问。 假设2个进程需要同时修改相同的文本，与文件系统的同步可能会导致竞争条件，而对数据库中的每个进程都没有任何问题。

Answer 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慢。

Answer 3

我之前做过这个。它很麻烦，你需要一直保持文件系统和数据库的同步，这样就可以让编程变得更复杂，就像你猜想的那样。 我的建议是根据数据选择所有文件系统解决方案或所有数据库解决方案。值得注意的是，如果您需要大量搜索，条件数据检索，那么请转到数据库，否则返回fs。 请注意，数据库可能未针对大型二进制文件的存储进行优化。但是，请记住，如果你同时使用它们，你将不得不让它们保持同步，并且它不会成为一个优雅的，也不是令人愉快的（编程）解决方案。 祝你好运！

Answer 4

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