.net - .Net:将压缩文件保存到SQL Server？

Question

我们有很多.Net应用程序可将文件上传到SQL Server（2008）并从中检索文件。在大多数地方，我们将文件存储为varbinary（max）。

当然，这是一种常见的做法，但是我想知道是否有人在保存之前就花了很多功夫并压缩了他们的文件（即zip），并在检索时解压缩了（解压缩）？我们的某些数据库在.mdf文件大小方面达到40-100gb的范围，我知道可以对其进行一些调整。

这是一个好习惯吗？有人知道性能影响，或者有任何示例代码吗？

谢谢
汤姆

Answer 1

首先，我们需要查看有关问题和答案的注释中揭示的其他详细信息：

由于企业存储成本高，因此需要节省空间
文件类型为：“大多数是pdf，word文档，excel文件...例如Office文件，但也有一些大型工程文件，例如cad's”
有数千个文件
许多文件为1-3 Mb

我测试了从1 MB到17 MB的PDF文件，压缩率最高为25％，而大多数似乎在10％-15％左右。就Microsoft Office文件而言，如果您谈论的是Office 2007之前的格式（即，扩展名不以“ x”结尾）或较新的格式（即，扩展名以“ x”结尾），则差异很大。较新的格式（例如“ .docx”，“。xlsx”等）已经是压缩文件，因此您在这里不会节省很多钱（亲自看看：使用扩展名复制/粘贴任何Office文档）以“ x”结尾的文件，将副本重命名为具有“ zip”的扩展名，而不是“ docx”或其扩展名，然后双击它）。我不记得有多少CAD工程图压缩，但是我怀疑至少与PDF一样多。
因此，假设2000个文件（每个3 MB）为6 GB。 10％的平均压缩将节省600 MB。最好对文件（尤其是CAD文件）进行一些采样，以更清晰地了解您将要真正保存的内容。知道您实际上希望节省多少钱，应该有助于确定在可用的时间/资源下，以下哪个选项最有意义。
您的选择似乎是：

压缩：就重构现有代码而言，这似乎是最少的工作量。压缩和解压缩Web服务器上的文件应该很简单（.Net框架随附了用于进行Deflate / Inflate以及Gzip / Ungzip的库），并且在DB层上不需要进行任何更改（您只需要将现有数据一次性迁移为压缩格式）。在对这个问题的评论中，JonSkeet询问这样做是否值得。考虑到仅此选项的工作量很小，我认为这是肯定的。开发人员时间为每小时50美元（或左右），而这样的项目可能需要10个小时（包括质量检查），即500美元的已付（按预算）的员工时间。获得新的SAN空间的成本将远远超过500美元（如果出于某种原因需要20个小时才能实施，甚至会超过1000美元），并且通常来自其他预算且需要申请等。
除了立即减小MDF文件大小之外，还有其他好处，即：

从磁盘读取和写入磁盘的所有数据都通过缓冲池。您需要读取和写入这些文件的8k数据页面越多，实际应用程序数据被压出并需要从磁盘再次读取的频率就越高（这很慢，否则我们将没有读/写缓存！ ）。这会降低您的页面寿命。
备份较小！数据越小，备份文件越小。而且，要备份和还原的数据越小，两个操作就越快。
更快的访问（通常不是）。磁盘是系统中最慢的部分，因此，如果您访问磁盘的次数较少，则通常会获得净收益，因为CPU通常可以以比磁盘可以读写的速度快的方式压缩/解压缩数据。当然，只有在您的系统上使用数据和文件进行测试才能说明问题，但是Microsoft充分有理由在ROW或PAGE级别为SQL Server 2008开始对索引包括内置数据压缩）。


文件流：http://technet.microsoft.com/en-us/library/bb933993(v=sql.100).aspx这会花费更多的精力，但是会将文件移出MDF文件。如果本地文件共享也在SAN上，则可以考虑将文件的压缩与使用FILESTREAM结合使用，以使它们脱离MDF文件。

远程Blob存储（RBS）：http://msdn.microsoft.com/en-us/library/gg316768.aspx这是一个附加功能，您需要单独下载，但似乎正是针对这种情况而设计的（将外部文件存储在便宜的存储中）。与上述两个选项不同，该选项在备份数据库时可能不会备份外部文件，并且需要进行辅助备份（某些情况下并非不可能）。在RBS主页面的底部有一个white paper链接（从第40页的底部开始）解释了备份选项。 MSDN文档显示了从SQL Server 2008 R2开始的功能，但我没有看到任何迹象表明该功能在SQL Server 2008中不起作用。


编辑：
一些附加说明：

如文档中所述，FILESTREAM选项的一个非常不错的好处是它跳过了缓冲池，因此数据的大小对于性能（即页面预期寿命）而言不是问题。

如果进行压缩（无论将其与其他选项结合使用，似乎都是一个好主意），那么选择一种更通用的方法可能是最佳选择。意思是，如果使用.Net框架选项-Inflate / Deflate或Gzip / Ungzip，则使用Gzip / Ungzip可能更好，因为它更容易找到处理该格式的工具。

如果将压缩数据存储在数据库中，则是一次性迁移数据，还是通常只需要访问数据库层的“原始”数据（而不需要将某些内容移至应用程序层即可）访问“实际”数据），则可以为Gzip / Ungzip实现SQL CLR函数。如果不确定如何完成此操作，那么在各个站点上都有大量示例，或者您可以下载并使用SQL#中的[Util_Gzip]和[Util_GUnzip]函数（或[Util_Deflate]和[Util_Inflate]），作者，但这些功能在免费版本中可用）。在简单的级别上，一次性数据迁移可以通过执行以下操作来完成：

UPDATE tbl
SET    tbl.VarBinaryField = SQL#.Util_GZip(tbl.VarBinaryField)
FROM   SchemaName.TableName tbl
WHERE  tbl.ID BETWEEN @StartID AND @EndID -- do small batches at a time