代码之家 › 专栏 › 技术社区 › BushyMark

从文件系统而不是数据库提供文本?

file-io database ruby ruby-on-rails

BushyMark · 技术社区 · 15 年前

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

我已经和一位同事争论了一周了,因为除了存储图片等之外,他们还希望将文本资产存储在文件系统上,并让应用程序在向客户机应用程序提供服务之前查找文件位置(从数据库)并读取文本文件(从文件系统)。

常识似乎在对我大喊大叫,说这太荒谬了,如果我们正费心从数据库中查找某些内容,我们不妨将文本存储在数据库列中,并将其与行查找一起使用。数据库查找+文件IO似乎比数据库查找慢得无法控制。在来回奔波了一段时间后,我决定运行一些基准测试,发现结果有点令人吃惊。在基准时间方面,似乎没有多少一致性。基准测试中唯一明显的赢家是从数据库中提取一个大的数据集,并对结果进行迭代以显示文本资产,但是从数据库中一次提取一个对象,并显示它们的文本内容,这似乎是非常困难的。

现在我知道了运行基准的局限性,我甚至不确定我是否运行了“测试”的正确想法(例如,文件系统的写入速度比数据库的写入速度快得离谱,我不知道!)我想我的问题是确认一下。文件I/O是否与数据库文本存储/查找相当?我是不是错过了辩论的一部分?提前感谢您的意见/建议!

关于我正在使用的内容的快速工作: 这是Ruby on Rails应用程序, 使用Ruby1.8.6和sqlite3。我计划关于将相同的代码库移动到MySQL 明天,看看基准是不是相同的。

4 回复 | 直到 15 年前

Ludwig Weinzierl 15 年前

我认为您的基准测试结果将取决于您如何在数据库中存储文本数据。如果将其存储为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慢。

Arnaud 15 年前

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

rolfen 15 年前

我以前做过。这很糟糕,您需要一直保持文件系统和数据库的同步,以便使编程更加复杂,正如您所猜测的那样。我的建议是要么采用全文件系统解决方案,要么采用全数据库解决方案,具体取决于数据。值得注意的是,如果您需要大量的搜索、条件数据检索,那么就使用数据库,否则就使用fs。请注意,数据库可能没有针对大型二进制文件的存储进行优化。不过,请记住,如果同时使用这两种方法,就必须使它们保持同步,而且这不会产生优雅或令人愉快(编程)的解决方案。祝你好运!

Carlo Pecchia 15 年前

至少,如果您的问题来自“性能方面”,您可以使用 无SQL “存储解决方案,如Redis(例如通过Ohm)或CouchDB…”