【发布时间】：2010-11-15 19:51:02
【问题描述】：
最近，我和我的同事正在讨论如何构建一个可以存储数十亿张图片的巨大存储系统，可以快速搜索和下载。
类似于 fickr 的东西，但不适用于在线画廊。这意味着，这些图片中的大部分将永远不会被下载。
我的同事建议我们应该将所有这些文件直接保存在数据库中。我真的觉得这不是一个好主意，我认为数据库不是为恢复大量二进制文件而设计的。但我有充分的理由说明这不是一个好主意。
你怎么看。
【问题讨论】：
标签： database
【发布时间】：2010-11-15 19:51:02
【问题描述】：
在处理二进制对象时，遵循以文档为中心的架构方法，而不是将 pdf 和图像等文档存储在数据库中，当您开始看到数据库的各种性能问题时，您最终将不得不对其进行重构。只需将文件存储在文件系统上，并将路径放在数据库表中即可。用于序列化并将其保存在数据库中的数据类型的大小也存在物理限制。只需将其存储在文件系统上并访问即可。
【讨论】：
-
有趣的是，SQL Server 2008 使用 FILESTREAM 存储选项为您做到了这一点-msdn.microsoft.com/en-us/library/cc949109.aspx
-
虽然我同意这一点，但 SharePoint 不是将几乎所有内容都存储在数据库中吗？如果是这样，我认为 SharePoint 人员可能不会认为将文件存储在数据库中是一个坏主意。我相信它在某些方面（例如查询）是有益的，但这些方式可能并不能完全抵消您在此处提到的内容。
-
@RichardOD，我阅读了这篇论文，它主要讨论了存储结构化内容与非结构化内容的相同挑战，并推荐 NTFS。 “FILESTREAM 是 SQL Server 2008 版本中的一项新功能。它允许将结构化数据存储在数据库中，并将关联的非结构化（即 BLOB）数据直接存储在 NTFS 文件系统中。然后您可以通过以下方式访问 BLOB 数据高性能 Win32® 流式 API，而不必支付通过 SQL Server 访问 BLOB 数据的性能损失。”
如果您真的在谈论数十亿张图像，我会将它们存储在文件系统中，因为检索将比序列化和反序列化图像更快
【讨论】：
-
是的，我说的是数十亿张图片。奇迹每天都在发生。
上面的答案似乎假设 数据库 是一个 RDBMS。如果您的数据库是面向文档的数据库，并且支持您期望大小的二进制文档，那么将它们存储在数据库中可能是非常明智的。
【讨论】：
-
你能说出几个这样的数据库吗？
-
MarkLogic (developer.marklogic.com) 支持存储 XML、JSON、文本和二进制文档。 github.com/marklogic/Corona 有一个 REST API 可以让您快速上手，还有一个原生查询语言 (XQuery)。
这不是一个好主意。数据库的重点是您可以快速解决复杂的查询以检索文本数据。虽然二进制数据可以存储在数据库中，但它会减慢事务处理速度。当数据库位于与正在运行的应用程序不同的服务器上时，尤其如此。在数据库中，存储元数据和图像的位置/文件名。图片本身应该在静态服务器上。
【讨论】：