2

我们的系统需要存储大约 3k 大小的 tiff 图像。我们在给定时间收到约 300 张图像，需要快速处理它们。一旦收到大约 100,000 张图像，这些图像就会从我们的系统转移到另一个存档系统或被清除。

我正在寻找关于图像文件的初始保存的最佳性能。传输图像以进行存档的任务对性能的要求较低。

什么存储位置（SQL Server 或文件系统）会在保存 tiff 图像时产生更好的性能？

是否有任何其他注意事项或陷阱需要注意？

4

4 回答 4

3

将图像存储在文件系统中将为您提供更好的性能。您只需将一个条目放入 tiff 图像附件的相关数据库表中 - 并使用它来获取文件系统上图像的路径。

您可能希望通过将图像托管在 Web 服务器上来进一步提高性能 - IIS（如果相关）并让您的客户端应用程序（如果相关）直接从那里检索它们。

于 2009-08-05T17:12:47.653 回答
2

以我的经验，SQL Server 在将 blob 存储到数据库方面做得很好。只要我遵循与查询、规范化等相关的最佳实践。我发现它们运行良好。

出于某种原因，我个人不想在我的数据库中存储巨大的 PDF、DOC 和 JPG 文件，但是，这正是 Microsoft SharePoint 所做的，并且做得很好。

我肯定会考虑将 blob 放入我的数据库中。

于 2009-08-05T17:17:32.560 回答
2

SQL Server 2008 版本有一个名为 FILESTREAM 的新功能。他们的部分文档还有一个关于最佳实践的部分，MS 人员在其中指出，如果 BLOB 对象通常大于 1 MB，则 FILESTREAM 应该发挥作用。

该 MSDN 页面指出：

何时使用 FILESTREAM 如果满足以下条件，则应考虑使用 FILESTREAM： - 正在存储的对象平均大于 1 MB。对于较小的对象，将 varbinary(max) BLOB 存储在数据库中通常可以提供更好的流式传输性能。

所以我猜想使用 3 KB 的 TIFF，您可以将它很好地存储在 SQL Server 2005 表中的 VARBINARY(MAX) 字段中。由于它甚至比 SQL Server 的 8k 页面大小还要小，因此非常适合！

您可能还想考虑将您的 BLOB 放入它们自己的表中，并从那里引用您的“基本”数据行。这样，如果您只需要查询基本数据（您的 int、varchars 等），您的查询将不会因 BLOB 与其他内容混合存储而陷入困境。

马克

于 2009-08-05T17:25:09.610 回答
0

INPE/Brazil 的卫星目录系统存储了存储在文件系统中的 tiff 图像的参考。但图像有点大 - +/- 100 MB。如果文件必须在浏览器中显示，则 php 代码读取磁盘上的 tiff 内容并绘制它。

于 2009-08-05T17:29:53.393 回答