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