什么存储位置（SQL Server 或文件系统）可以提高保存 tiff 图像的性能？
我们的系统需要存储大小约为 3k 的 tiff 图像。 我们在给定时间收到约 300 张图像，需要快速处理它们。 一旦收到约 100,000 张图像，这些图像就会从我们的系统转移到另一个存档系统或被清除。
我正在寻找图像文件初始保存的最佳性能。 传输图像进行存档的任务对性能的要求较低。
什么存储位置（SQL Server 或文件系统）可以提高保存 tiff 图像的性能？
还有其他注意事项或陷阱需要注意吗？
Our system needs to store tiff images of ~3k in size. We receive ~300 images at a given time and need to quickly process them. Once ~100,000 images are received, the images are transferred off our system to another archival system or purged.
I am looking for best performance in regards to the initial save of the image files. The task of transferring the images for archival is less performance critical.
What storage location, SQL Server or file system, would result in better performance in saving tiff images?
Are there any other considerations or gotchas to be aware of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
巴西 INPE 的卫星目录系统存储文件系统中存储的 tiff 图像的引用。 但图像有点大 - +/- 100 MB。 如果文件必须在浏览器上显示，则 php 代码会读取磁盘上的 tiff 内容并绘制它。
The satellite catalog system at INPE/Brazil stores a reference of tiff images stored in filesystem. But the images are a little bigger - +/- 100 MB. If the file must be displayed at browser, the php code reads the tiff content at disk and draw it.
SQL Server 2008版本有一个新功能，称为FILESTREAM。 他们的部分文档还包含关于最佳实践的部分，其中MS 人员表示，如果 BLOB 对象通常大于 1 MB，则 FILESTREAM 应该发挥作用。
该 MSDN 页面指出：
因此，我猜想，使用 3 KB 的 TIFF，您可以将其很好地存储在 SQL Server 2005 表的 VARBINARY(MAX) 字段中。 由于它比 SQL Server 的 8k 页面大小还要小，因此非常适合！
您可能还需要考虑将 BLOB 放入它们自己的表中，并从那里引用您的“基本”数据行。 这样，如果您只需要查询基础数据（您的 int、varchar 等），您的查询就不会因 BLOB 与其他内容混合存储而陷入困境。
马克
The SQL Server 2008 version has a new feature called FILESTREAM. Part of their documentation also has a section on best practices, in which the MS folks state that FILESTREAM should come into play if the BLOB objects are typically larger 1 MB.
That MSDN page states:
So I guess with a 3 KB TIFF, you could store that nicely inside a VARBINARY(MAX) field in your SQL Server 2005 table. Since it's even smaller than the 8k page size for SQL Server, that'll fit nicely!
You might also want to consider putting your BLOBs into their own table and reference your "base" data row from there. That way, if you only need to query the base data (your ints, varchars etc.), your query won't be bogged down by BLOBs being stored intermingled with other stuff.
Marc
根据我的经验，SQL Server 在将 blob 存储到数据库方面做得很好。 只要我遵循与查询、规范化等相关的最佳实践，我发现它们工作得很好。
出于某种原因，我个人不想在我的数据库中存储巨大的 PDF、DOC 和 JPG 文件，但这正是 Microsoft SharePoint 所做的，而且做得很好。
我肯定会考虑将 blob 放入我的数据库中。
In my experience SQL Server has been decent with storing blobs into the database. As long as I follow Best Practices related to queries, normalization, etc. I have found them to work well.
For some reason, I personally do not want to store huge PDF and DOC and JPG files in my database, but then, that is exactly what Microsoft SharePoint does, and does well.
I'd definitely consider putting blobs in my db.
将图像存储在文件系统中将为您提供更好的性能。 您只需将一个条目放入 tiff 图像附件的相关数据库表中 - 并使用它来获取文件系统上图像的路径。
您可能希望通过将图像托管在 Web 服务器 - IIS（如果相关）上来进一步提高性能，并让您的客户端应用程序（再次如果相关）直接从那里检索它们。
Storing the images in the filesystem will give you better performance. You just need to put an entry into a relevant database table for the tiff image attachments - and use that to get the path of the image on the filesystem.
You might want to further boost performance by hosting the images on a web server - IIS (if relevant) and have your client applications (again if relevant) retrieve them directly frmo there instead.