Производительность FILESTREAM SQL Server 2008 года
У меня были некоторые вопросы вокруг возможности FILESTREAM SQL Server 2008.
Что разница в производительности имела бы возврат файла, переданного потоком от SQL Server использование 2008 года возможности FILESTREAM по сравнению с прямым доступом к файлу от общего каталога?
Если бы 100 пользователей запросили 100 файлов 100 МБ (сохраненный через FILESTREAM) в 10 вторых окнах, то производительность SQL Server 2008 года замедлилась бы к проверке?
2 ответа
Если 100 пользователей запросят 100 100Mb файлов (хранящихся через FILESTREAM) в 10-секундном окне, замедлится ли производительность SQL Server 2008 до сканирования?
На каком сервере? Какое оборудование будет обслуживать эти файлы? Какие диски, сеть и т.д.? Так много вопросов.......
Есть действительно хороший пост в блоге Пола Рендала (Paul Randal) на SQL Server 2008: FILESTREAM Performance - посмотрите. Также есть 25-страничный блог о FILESTREAM - в нем есть некоторые советы по настройке производительности.
Но также посмотрите технический отчет Microsoft Research TechReport To BLOB or Not To BLOB.
Это очень глубокая и очень хорошо основанная статья, в которой все эти вопросы проходят сквозь призму их ответов.
Их вывод:
Исследование показывает, что если объекты больше одного мегабайта на средний, NTFS имеет явное преимущество. через SQL Server. Если объекты меньше 256 килобайт, база данных имеет явное преимущество. Внутри этого диапазона, это зависит от того, насколько интенсивно пишут рабочая нагрузка и срок хранения типичная реплика в системе.
Так что, судя по этому - если ваши капли обычно меньше 1 МБ, просто храните их как VARBINARY(MAX) в базе данных. Если они обычно больше, то просто функция FILESTREAM.
Я бы не беспокоился о производительности, а о других преимуществах FILESTREAM над "неуправляемым" хранением в файловой папке NTFS: сохраняя файлы вне базы данных без FILESTREAM, вы не имеете над ними никакого контроля:
- нет контроля доступа, предоставляемого базой данных
- файлы не являются частью вашей резервной копии SQL сервера
- файлы не обрабатываются транзакционно, e. g. вы можете оказаться с "зомби" файлами, на которые больше нет ссылок из базы данных, или "скелетными" записями в базе данных без соответствующего файла на диске
Эти особенности сами по себе делают использование FILESTREAM абсолютно целесообразным.
.Чтение FILESTREAM поверх Win32 происходит довольно быстро. См. Управление данными FILESTREAM с помощью Win32. Однако следует следовать рекомендациям FILESTREAM . В конце концов, это то, что Power Sharepoint и MS не поставит что-то столь важное, как Office (==Sharepoint) на нерабочее хранилище. Вокруг FILESTREAM есть некоторые примеры и технические статьи, я мог только откопать Laren Electronics Fuels Analysis of Formula One Racing Data with SQL Server, но я знаю, что есть и более детальные числовые данные. Если я правильно помню, то это говорит о том, что FILESTREAM в общем затеняет производительность SMB примерно на 90-95%, выше определенного размера файла. Для маленьких файлов начинают проявляться накладные расходы, связанные с получением API ручки FILESTREAM.
Я бы также поддержал Марка в рекомендации по чтению статьи Research на эту тему (есть также интервью 9-го канала с Катарин Ван Инген, доступное на подкастах iTunes, где она рассказывает об этой работе), но имейте в виду, что статья опубликована в 2006 году до FILESTREAM была официально выпущена, так что она не учитывает специфику FILESTREAM.
Что касается вашего второго вопроса, то задавать вопрос о производительности только путем указания нагрузки, а не емкости системы - это бессмысленно. Купол на 128 CPU Superdome с горой SAN-хранилищ даже не заметит вашу нагрузку. SQL, работающий на 256 Мб ноутбуке с горой шпионских программ, даже не заметит Вашу нагрузку...
.