20

SQL Server 2008 是用作电子商务网站图像存储的好选择吗？它将用于存储各种尺寸和角度的产品图像。Web 服务器将输出这些图像，通过集群 ID 读取表格。总图像大小约为 10 GB，但需要扩展。我看到使用文件系统有很多好处，但我担心没有 O(1) 查找的 SQL 服务器不是最佳解决方案，因为该站点有大量流量。这甚至会成为瓶颈吗？有什么想法或其他选择？

4

6 回答 6

27

10 Gb 的数据量不是很大，因此您可能可以使用数据库来存储它并且没有什么大问题，但是使用文件系统当然是最好的性能明智的，并且在安全管理方面最好使用数据库（备份和一致性）。

令人高兴的是，Sql Server 2008 允许您吃蛋糕和吃蛋糕，其中：

FILESTREAM 属性

在 SQL Server 2008 中，您可以将 FILESTREAM 属性应用于 varbinary 列，然后 SQL Server 将该列的数据存储在本地 NTFS 文件系统上。将数据存储在文件系统上带来两个主要好处：

  • 性能与文件系统的流性能相匹配。
  • BLOB 大小仅受文件系统卷大小的限制。

但是，该列可以像 SQL Server 中的任何其他 BLOB 列一样进行管理，因此管理员可以使用 SQL Server 的可管理性和安全功能将 BLOB 数据管理与关系数据库中的其余数据集成在一起，而无需管理文件系统数据分开。

在 SQL Server 中将数据定义为 FILESTREAM 列还可以确保数据库中的关系数据与物理存储在文件系统上的非结构化数据之间的数据级一致性。FILESTREAM 列的行为与 BLOB 列完全相同，这意味着备份和还原等维护操作的完全集成、与 SQL Server 安全模型的完全集成以及完整的事务支持。

应用程序开发人员可以通过两种编程模型之一处理 FILESTREAM 数据；他们可以像标准 BLOB 列一样使用 Transact-SQL 访问和操作数据，或者他们可以使用带有 Transact-SQL 事务语义的 Win32 流式 API 来确保一致性，这意味着他们可以使用标准 Win32 读/写调用 FILESTREAM BLOB 就像与文件系统上的文件进行交互一样。

在 SQL Server 2008 中，FILESTREAM 列只能将数据存储在本地磁盘卷上，并且 FILESTREAM 列不支持透明加密和表值参数等某些功能。此外，您不能在数据库快照或数据库镜像会话中使用包含 FILESTREAM 列的表，尽管支持日志传送。

于 2008-12-02T20:43:04.957 回答
3

查看 MS Research 的这份白皮书 ( http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45 )

他们详细说明了您正在寻找的内容。简短的版本是，与将数据保存在文件系统上相比，任何超过 1 MB 的文件都会开始降低性能。

于 2008-12-02T20:46:37.617 回答
1

我怀疑O(log n)查找会是一个问题。你说你有 10GB 的图像。假设平均图像大小为 50KB，即 200,000 张图像。在表中对 200K 行进行索引查找不是问题。与实际从磁盘读取图像并将其通过您的应用程序传输到客户端所需的时间相比，它会很小。

仍然值得考虑将图像存储在数据库中与将路径存储在数据库中到文件系统上的文件的通常优缺点。例如：

  • 数据库中的图片遵循事务隔离，删除行时自动删除等。
  • 具有 10GB 图像的数据库当然比仅存储图像文件路径名的数据库要大。备份速度和其他因素是相关的。
  • 当您通过应用程序从数据库提供图像时，您需要在响应中设置 MIME 标头。
  • 文件系统上的图像更容易被 Web 服务器（例如 Apache mod_mmap）缓存，或者可以由更精简的 Web 服务器（如 lighttpd）提供服务。这实际上是一个相当大的好处。
于 2008-12-02T20:46:41.160 回答
0

对于电子商务网站之类的东西，我很可能会将图像存储在数据库上的 blob 存储中。虽然您不想进行过早的优化，但让我的图像与我的数据一起轻松组织以及非常便携的好处是电子商务之类的自动好处。

于 2008-12-02T20:41:38.940 回答
0

如果图像被索引，那么查找将不是一个大问题。我不确定，但我认为文件系统的查找不是 O(1)，更像是 O(n)（我认为文件没有被文件系统索引）。

在这个设置中让我担心的是数据库的大小，但如果管理得当，这不会是一个大问题，一个很大的优势是你只有一件事要备份（数据库）而不用担心磁盘上的文件.

于 2008-12-02T20:41:55.490 回答
0

通常，一个好的解决方案是将图像本身存储在文件系统中，并将元数据（文件名、尺寸、上次更新时间、您需要的任何其他内容）存储在数据库中。

话虽如此，对此没有“正确”的解决方案。

于 2008-12-02T20:43:32.290 回答