要用SQL存储图像吗？

Question

通常，我认为将文件存储在文件系统中并通过数据库条目链接到文件系统总是更好。但是，我正在尝试优化我的数据库设计，并且有一些问题。

我的图像都是非常小的黑白拇指（不是灰度，但真正的B＆amp; W），尺寸为70x70。如果我们拍摄图像（基本上是1和0的2D数组），它可以存储为二进制数据，每个数据大约600字节。

所以我的问题是，查询存储在数据库中的600字节是否比查询链接然后访问文件系统要快;假设有很多“图像”查询。

有没有人有这个领域的经验？

如果重要的话，我正在使用MySQL和MonetDB（单独使用，但两者都有相同的问题）。

非常感谢， 布雷特

Answer 1

如果它只有600字节，那么我不会太担心，并将它们作为blob存储在数据库中

在High Scalablilty上有一篇关于如何构建Flickr的有趣文章。这可能对您有用。

Answer 2

由于你标记了sql-server这个问题，我建议你阅读To Blob or Not To Blob，这是遗憾的吉姆格雷的研究论文。关于在文件系统（NTFS）与数据库（SQL Server）中存储BLOB的主题，本文进入了很多的细节，你会惊讶地发现有多少角度被考虑。这是必读的。但结论是：

  

研究表明，如果是对象   大于1兆字节   平均而言，NTFS具有明显的优势   在SQL Server上。如果对象是   数据库有256千字节以下   明显的优势。在里面   范围，这取决于如何写   密集的工作量是，和   一个典型的复制品的存储年龄   系统。

您的案件明显属于“To BLOB”案件。

Answer 3

据我所知，如果您没有无理由使用SELECT *，那么在数据库中存储更大的文件是没有问题的（坦率地说，没有理由使用SELECT *在所有）。

BLOB和TEXT与其他数据分开存储，如果没有明确查询，则不会影响性能。

Answer 4

如果您正在谈论Web应用程序，那么将数据库存储在数据库中就是愚蠢的。因为桌面应用程序可能没有任何好处，但只有困难。

Answer 5

这不仅与文件大小有关，而且与数据库工作时预期的最大记录数有关。较旧的时候，我们曾经为任何类型的领域进行这种数学运算。只需将600字节乘以最大记录数量，如果结果是可管理的，则不必担心速度。

正如@codeholic所说，如果你没有使用SELECT *，一切都会顺利。

Answer 6

将图像存储在数据库中（并在每个请求中提供服务）可以防止您在代理服务器中缓存这些图像（或者更确切地说 - 使任务复杂化并且几乎禁止所有开箱即用的解决方案） 。问题在于衡量您需要以不同方式查看它所需的影响 - 而不是“获取图像的单个查询需要多长时间”自问“一系列（在此处放置一个合理的数字）查询的时间获得相同的图像集“。也许还会问自己“我必须支付往返DB的成本吗？”。

并非这个想法没有价值 - 在一个位置更新图像可能是一个重要因素。此外，如果高可用性是一个因素，则将DB配置为数据的中心点要容易得多（将图像放在文件系统上意味着在更新时在节点之间同步它们）。更改跟踪，权限，其他数据，避免“断开链接” - 这些也可能起到一定作用。

除了上述所有内容外，我在使用“文件系统”技术时遇到了不好的经历。目前我们正在考虑转向“数据库”技术。