考虑在何处存储文档 - 在文件服务器上还是在DB中?

时间:2010-02-04 16:59:29

标签: sql-server blob fileserver

我有一个关于上传到我的网站的文件的设计决定:我可以将它们存储在我的文件服务器上,或者我可以将它们存储在我的数据库中的blob(MSSQL 2005)。如果它对设计决定有任何影响,这些文件是保密的,必须有一定程度的保护。

我想到的考虑因素是:

  1. 存储在文件服务器上会使HUUUUUUUGE文件数量全部转储到一个目录中,因此访问速度较慢,除非我能为目录树结构制定合理的语义定义
  2. OTOH,我猜测文件服务器可以比DB更好地处理压缩...或者我错了吗?
  3. 我的直觉告诉我,DB的安全性比文件服务器强,但我不确定这是否一定是真的。
  4. 不知道我的数据库中有多TB的blob会影响性能。
  5. 我非常感谢这里的一些建议。谢谢!

3 个答案:

答案 0 :(得分:7)

在SQL Server 2005中,您只能选择使用VARBINARY(MAX)将文件存储在数据库表中,或者将它们保留在外部。

将它们留在数据库之外的明显缺点是数据库无法真正控制它们发生的情况;他们可以被移动,重命名,删除.....

SQL Server 2008 FILESTERAM类型上引入VARBINARY(MAX)属性,允许您将文件保留在数据库表之外,但仍处于数据库的事务控制之下 - 例如你不能只是从磁盘中删除文件,这些文件是数据库的组成部分,因此可以复制并备份。很棒,如果你需要它,但它可以做一些巨大的备份! : - )

SQL Server 2008的发布提供了一些关于何时直接在数据库中存储内容以及何时使用FILESTREAM的“最佳实践”。这些是:

  • 如果文件的大小通常小于256 KB,则数据库表是最佳选择
  • 如果文件大小通常超过1 MB,或者大小超过2 GB,则FILESTREAM(或者在您的情况下:普通旧文件系统)是您的最佳选择
  • 这两个边距之间没有文件建议

另外,为了不对查询的性能产生负面影响,将大文件放在一个单独的表中通常是个好主意 - 不要让巨大的blob成为您查询的常规表的一部分 - 但是而是创建一个单独的表,如果你真的需要兆字节的文档或图像,你只能查询它。

这样可以让你知道从哪里开始!

答案 1 :(得分:3)

我强烈建议您考虑文件系统解决方案。原因是:

  • 您可以更好地访问这些文件(在调试时很珍贵),这意味着您可以使用常规的基于控制台的工具
  • 您可以快速轻松地利用操作系统来分配负载,例如使用分布式文件系统,通过硬件RAID等添加冗余。
  • 您可以利用操作系统访问控制列表来强制执行权限。
  • 您不会阻塞数据库

如果您担心目录中存在大量条目,则始终可以创建分支架构。例如:

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt

答案 2 :(得分:1)

这个受欢迎的主题背后有很多“它取决于”。既然你说这些文件是敏感和保密的,那么我会把它存放在数据库中。原因如下:

  • 可能更好的安全性。攻击文件系统通常比数据库更容易。
  • 更好的音量控制。一个文件夹中的数千个文件可能会使操作系统紧张,数据库可能会在一个表中占用数百万行而不会闪烁。
  • 更好的搜索和扫描。在加载数据时添加分类列,或尝试使用全文索引来扫描实际文档。
  • 备份可能更有效 - 只需将另一个数据库添加到您的备份计划中,您就可以了解(当然,一旦您计算出空间详细信息)。这些备份文件是任何试图获取敏感文档的人的另一层混淆。
  • SQL Server 2008具有可能对此有帮助的数据压缩选项。那,还是应用程序呢? (或许通过混淆提高安全性)

SQL Server 2008也有文件流数据类型,这在这里可能会有所帮助,但我对它不够熟悉,无法根据您的情况提供建议。