Расположение файлового потока в SQL Server 2008 - PullRequest
Новая
       11

Расположение файлового потока в SQL Server 2008

5 голосов
/ 09 февраля 2010

У меня есть приблизительно 7 терабайт различных медиафайлов (pdf, jpg, tiff), которые в настоящее время находятся на очень загруженном файловом сервере. Я смотрю на перемещение данных в SQL Server 2008 и использование атрибута Filestream, чтобы помочь мне управлять данными. Я хочу сделать это, потому что у меня есть веб-страницы, которые управляют этим носителем, и они (веб-страницы) становятся все медленнее и медленнее, поскольку ежедневно на файловый сервер добавляется все больше носителей.

РЕДАКТИРОВАТЬ: Веб-страницы работают медленно, потому что многие из них создают отчеты, которые отражают различные сведения о файловом сервере и о том, что хранится на нем. По сути, веб-страницы прочесывают тысячи папок и файлов для создания отчетов о том, что в них содержится. Некоторые веб-страницы позволяют пользователям манипулировать папками и файлами и перемещать их в разные места. Итак, в двух словах, я ищу более быстрый способ управления этими файлами. Это также позволило бы мне хранить метаданные об этих файлах в базе данных, что позволило бы мне запрашивать эту информацию в базе данных, а не просматривать ее через файловый сервер.

Мои проблемы:

1) Я выполнил проверку концепции и подтвердил, что могу создать файловый поток, локальный для базы данных SQL Server 2008, и успешно прочитал и записал на нее носители. Однако мне еще предстоит выяснить, как использовать UNC в качестве файлового потока. Другими словами, база данных размещается на MySQLDB08, а мои файлы хранятся на TheFileServer01. Я читал, что это возможно, но я еще не добрался там. Любая помощь по этому вопросу будет принята с благодарностью!

2) Так как у меня есть 7 терабайт (и растет) носителей, будут ли мои резервные копии неуправляемыми из-за их размера? Может ли это отговорить меня от использования Filestream?

Любые предложения или помощь будет принята с благодарностью!

Ответы [ 2 ]

5 голосов
/ 09 февраля 2010
  1. Ты не можешь. Данные файлового потока Afaik хранятся локально, и SQL откажется от чтения / записи из / в UNC.
  2. Ваши полные резервные копии будут содержать все данные файлового потока. Неуправляемый? Определенно очень серьезный вызов.

Мой вопрос: какую выгоду вы хотите извлечь из файлового потока? Обычные преимущества связаны с интеграцией BLOB с операциями с базами данных при сохранении доступности для операций на основе дескрипторов файлов Win32:

Хотя технология FILESTREAM имеет много привлекательных функций, это не может быть оптимальным выбором во всех ситуации. Как упоминалось ранее, размер данных BLOB и доступ шаблоны являются наиболее значительными факторы при принятии решения о хранении данные BLOB полностью в пределах базы данных или с помощью FILESTREAM.

Размер влияет на следующее:

  • Эффективность, с которой данные BLOB можно получить доступ с помощью любого хранилища механизм. Как упоминалось ранее, потоковый доступ к большим BLOB-данным более эффективно, используя FILESTREAM, но частичные обновления (потенциально много) медленнее.
  • Эффективность резервного копирования объединенные структурированные и BLOB-данные используя любой механизм хранения. резервное копирование, которое объединяет SQL Server файлы базы данных и большое количество Файлы FILESTREAM будут работать медленнее резервное копирование только базы данных SQL Server файлы эквивалентного общего размера. Это из-за дополнительных накладных расходов резервного копирования каждого файла NTFS (по одному на Значение данных FILESTREAM). Это накладные расходы становится более заметным, когда Файлы FILESTREAM меньше (как время накладных расходов становится больше процент от общего времени резервного копирования за МБ данных).

С точки зрения чистой производительности, существует множество шагов, которые вы можете сделать на уровне файловой системы для повышения производительности. В чем ваша текущая проблема, почему пропускная способность вашей системы зависит от размера носителя? Это означает, что у вас есть где-то засорение, возможно, перечисление каталогов или какой-то другой барьер, который заставляет вас масштабировать время отклика в зависимости от размера носителя. Ваш доступ к медиа должен быть O (1), может быть O (logn), но определенно не O (n).

Я бы порекомендовал вам ознакомиться с «Белой книгой» SQL Хранилище FILESTREAM в SQL Server 2008 , где я нашел цитату о вариантах использования.

1 голос
/ 06 октября 2010

Я собираюсь не согласиться с @RemusRusanu по вопросу UNC. Хотя @RemusRusanu делает несколько хороших замечаний по поводу , почему вы бы выбрали файловый поток.

В любом случае, вы можете использовать UNC для файловых потоков - в противном случае это было бы бесполезно. В настоящее время я создаю сайт, который использует функцию UNC для серверов в веб-ферме для чтения файлов из потока файлов SQL.

Несколько замечаний по использованию файловых потоков UNC ...

  • Доступ к UNC осуществляется с помощью SQL-сервера. WTF? Задача файлового потока - объединить преимущества файловой системы (хорошая потоковая передача) и преимущества SQL Server (хорошие метаданные, транзакции и возможность запросов). Как SQL обеспечивает транзакционный доступ к файлу? Вы должны открыть транзакцию и внутри транзакции запросить дескриптор файла у SQL Server.

  • Говоря иначе, вы не можете просто перейти к Filestream UNC из проводника Windows.

  • Если вы храните свой двоичный файл на сервере SQL, то обычно ~ 1,2 МБ - это точка останова, в которой вы должны отдавать предпочтение потоку файлов, а не VarBinary. Здесь MS предлагает 1 МБ, но есть еще одна статья в исследовательской работе, которую я не могу найти в данный момент, которая предлагает 1,2 - точка безубыточности.

  • Включение доступа UNC требует распределенной транзакции, поэтому для сервера SQL и потребителя пути UNC необходимо включить распределенные транзакции.

Ниже приведен фрагмент кода, который показывает, как получить дескриптор для потока файлов. Существует одно большое предупреждение : , транзакция не закрыта в этом фрагменте. Вам нужно будет прочитать двоичный файл, а затем закрыть транзакцию. Оставлять открытые транзакции явно нет-нет. 

    public FileStream GetStream(string FilePath){
        FileStream FStream = null;

        Conn = new SqlConnection( MyConnectionStringHere );
        Conn.Open();
        txn = Conn.BeginTransaction();

        using (SqlCommand cmd = new SqlCommand("SELECT GET_FILESTREAM_TRANSACTION_CONTEXT()", Conn, txn)){

            Object obj = cmd.ExecuteScalar();
            TransContext = (byte[])obj;
        }

        SafeFileHandle SHandle =  NativeSqlClient.GetSqlFilestreamHandle (FilePath, NativeSqlClient.DesiredAccess.Read, TransContext);
        FStream = new FileStream(SHandle, FileAccess.Read);

        return FStream;
    }
...