sql-server-2008 - SQL Server 2008 的文件流位置

Question

我有大约 7 TB 的各种媒体文件(pdf、jpg、tiff)，它们目前驻留在一个非常强大的文件服务器上。我正在考虑将数据移动到 SQL Server 2008 并使用 Filestream 属性来帮助我管理数据。我想这样做是因为我有管理此媒体的网页，并且随着每天向文件服务器添加更多媒体，它们(网页)变得越来越慢。

编辑:网页很慢，因为它们中的许多会生成反射(reflect)文件服务器的各种详细信息及其上存储的内容的报告。从本质上讲，这些网页梳理了数千个文件夹和文件，以生成有关其中包含内容的报告。一些网页允许用户操作文件夹和文件并将它们移动到不同的位置。所以，简而言之，我正在寻找一种更快的方式来管理这些文件。它还允许我在数据库中维护有关这些文件的元数据，从而允许我查询数据库以获取此信息，而不是通过文件服务器对其进行梳理。

我的问题:

1) 我已经完成了概念验证并验证我可以在 SQL Server 2008 数据库的本地创建文件流，并且我已经成功地读取和写入媒体。 但是，我还没有弄清楚如何使用 UNC 作为文件流。 换句话说，数据库托管在 MySQLDB08 上，而我的文件存储在 TheFileServer01 上。我读过它是可能的，但我还没有到那里。对此的任何帮助将不胜感激!

2) 由于我有 7 TB 的媒体(并且还在不断增加)，我的备份是否会因为它们的大小而无法管理？这会阻止我使用 Filestream 吗？

任何建议或帮助将不胜感激!

Answer 1

你不能。 Afaik 文件流数据存储在本地，SQL 将拒绝从/向 UNC 读/写。

您的完整备份将包含整个文件流数据。难以驾驭？无疑是一个非常严峻的挑战。

我的问题是您想从文件流中提取的好处是什么？通常的好处来自 BLOB 与数据库操作的集成，同时保持基于 Win32 文件句柄的操作的可用性:

Even though FILESTREAM technology has many attractive features, it may not be the optimal choice in all situations. As mentioned earlier, the size of the BLOB data and the access patterns are the most significant factors when deciding whether to store the BLOB data wholly within the database or by using FILESTREAM.

Size affects the following:

• Efficiency with which the BLOB data can be accessed using either storage mechanism. As mentioned earlier, streaming access of large BLOB data is more efficient using FILESTREAM, but partial updates are (potentially much) slower.
• Efficiency of backing up the combined structured and BLOB data using either storage mechanism. A backup that combines SQL Server database files and a large number of FILESTREAM files will be slower than a backup of just SQL Server database files of an equivalent total size. This is because of the extra overhead of backing up each NTFS file (one per FILESTREAM data value). This overhead becomes more noticeable when the FILESTREAM files are smaller (as the time overhead becomes a larger percentage of the total time to backup per MB of data).

从纯粹的性能角度来看，您可以在文件系统级别执行许多步骤来提高性能。您当前的问题是什么，为什么您的系统吞吐量受媒体大小的影响？这意味着您在某处有一个争用的阻塞点，可能是目录枚举，或其他一些障碍，导致您根据媒体大小调整响应时间。您对媒体的访问应该是 O(1)，也许是 O(logn)，但绝对不是 O(n)。

我建议您阅读 SQL 白皮书 FILESTREAM Storage in SQL Server 2008 ，从那里我找到了关于用例的报价。