SQL Server表结构用于存储大量图像

Question

在SQL Server 2008中存储大量图像数据的最佳做法是什么？我期待使用大约5演出的存储空间存储大约50,000张图像。目前我正在使用包含列的单个表来执行此操作：

ID: int/PK/identity
Picture: Image
Thumbnail: Image
UploadDate: DateTime

我很担心，因为在我预期的总容量的10％左右，插件似乎需要很长时间。典型的图像大约是20k-30k。是否有更好的逻辑结构来存储这些数据？或者我是否需要研究群集或其他IT解决方案以适应数据负载？

Answer 1

要DB还是DB，这就是问题。

你在这里用数据库中的图像开始宗教战争。

对于SQL 2000，该意见将被拆分，但2005年及以上版本在存储blob方面做得相当不错 - 只需查看使用MS SQL Server作为其存储的SharePoint安装数量。我只会采用这条路线进行小型图像存储。

如果您最终将它们放入数据库中，我会说您应该将图像与与其关联的数据分开，以便于查询和减少您的IO以及开发人员编写SELECT *时的实例（和是的，他们会）。

在SQL 2008中查看FILESTREAM - 它适用于这样的事情。

以下是您可能需要考虑的DB与文件系统的其他一些要点：

• 数据库存储，备份，还原，维护许可非常昂贵
• 数据库中的存储难以获取而不是磁盘
• 磁盘可以加速
• 您需要编写代码以在DB中获取/设置图像 - 磁盘不需要

Answer 2

Image是SQL Server 2008中不推荐使用的数据类型。自SQL Server 2005以来，它已被VARBINARY(MAX)替换。如果您决定将图像存储在数据库中，则应使用{{ 1}}字段并考虑添加VARBINARY(MAX)选项。

对于流媒体数据，例如图片，根据this white paper，FILESTREAM比单独FILESTREAM快得多：

_{（来源：microsoft.com）}

请注意，要实现此流式传输性能，您必须在设计中使用适当的API并获取Win32 handle of the BLOB。请注意，VARBINARY(MAX)列（包括FILESTREAM）的更新速度将慢于INSERTS。

Answer 3

查看SQL Server 2008中的新Filestream功能。本质上，它允许您在数据库中存储blob（读取：图像）数据，而不必在每次读取时将数据读入sql缓冲区。写。它无缝地使用filesytem来存储大文件而不是sql页面。这可以为更大的文件带来更快的读写时间，最重要的是，由于这一切都发生在幕后，您不需要更改任何现有的存储过程来处理文件流列。有关代码示例和一些性能分析，请参阅here。