4

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

我想到的考虑是：

  1. 存储在文件服务器上会使 HUUUUUUUGE 数量的文件全部转储到单个目录中，因此访问速度较慢，除非我可以为目录树结构制定合理的语义定义
  2. OTOH，我猜文件服务器可以比数据库更好地处理压缩......还是我错了？
  3. 我的直觉告诉我，数据库的安全性比文件服务器的强，但我不确定这是否一定是真的。
  4. 不知道在我的数据库中有 TB 的 blob 会如何影响性能。

我非常感谢这里的一些建议。谢谢！

4

3 回答 3

7

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

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

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

SQL Server 2008 的发布提出了一些“最佳实践”，即何时将内容直接存储在数据库中，以及何时使用 FILESTREAM。这些都是：

  • 如果文件的大小通常小于 256 KB，则数据库表是最佳选择
  • 如果文件的大小通常超过 1 MB，或者大小可能超过 2 GB，那么 FILESTREAM（或在您的情况下：普通旧文件系统）是您的最佳选择
  • 不推荐这两个边距之间的文件

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

所以这可能会让你知道从哪里开始！

于 2010-02-04T17:07:18.500 回答
3

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

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

如果您担心目录中有大量条目，您可以随时创建分支模式。例如：

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt
于 2010-02-04T17:17:29.320 回答
1

这个受欢迎的主题背后有很多“取决于”。既然您说这些文件是敏感和机密的，那么我会立即将其存储在数据库中。这里有几个原因：

  • 可能更好的安全性。破解文件系统通常比破解数据库更容易。
  • 更好的音量控制。一个文件夹中的数千个文件会给操作系统带来压力，其中一个数据库可以在一个表中存储数百万行而不会闪烁。
  • 更好的搜索和扫描。在加载数据时添加分类列，或尝试全文索引以扫描实际文档。
  • 备份可能更有效——只需将另一个数据库添加到您的备份计划中，您就会被覆盖（当然，一旦您计算出空间详细信息）。这些备份文件是对试图获取您敏感文档的任何人的另一层混淆。
  • SQL Server 2008 的数据压缩选项可能会有所帮助。那，还是让应用程序这样做？（也许通过混淆提高安全性）

SQL Server 2008 也有 filestream 数据类型，这在这里可能会有所帮助，但我对它还不够熟悉，无法针对您的情况给出建议。

于 2010-02-04T17:17:27.007 回答