Использование SQL Server в качестве хранилища изображений

Question

Является ли SQL Server 2008 хорошим вариантом для использования в качестве хранилища изображений для веб-сайта электронной коммерции? Он будет использоваться для хранения изображений продуктов различных размеров и углов. Веб-сервер выводит эти изображения, считывая таблицу с помощью кластерного идентификатора. Общий размер изображения составит около 10 ГБ, но его нужно будет масштабировать. Я вижу много преимуществ по сравнению с использованием файловой системы, но я обеспокоен тем, что SQL-сервер, не имеющий O (1), не является лучшим решением, учитывая, что на сайте много трафика. Это будет даже бутылочка? Каковы некоторые мысли или, возможно, другие варианты?

Answer 1

10 Gb - это не очень большой объем данных, поэтому вы, вероятно, можете использовать базу данных для ее хранения и не иметь больших проблем, но, конечно, лучше всего использовать файловую систему, а управление безопасностью - лучше использовать БД (резервные копии и согласованность).

К счастью, SQL Server 2008 позволяет иметь свой кусок пирога и съесть его, с:

The FILESTREAM Attribute

В SQL Server 2008 можно применить атрибут FILESTREAM к колонку VARBINARY и SQL Server затем сохраняет данные для этого столбца в локальной файловой системе NTFS. Сохранение данных в файловой системе приводит к двум основным преимуществам:

• Производительность соответствует потоковой производительности файловой системы.
• Размер BLOB ограничен только размером тома файловой системы.

Однако столбец можно управлять так же, как любым другим столбец BLOB в SQL Server, поэтому администраторы могут использовать управление и безопасность возможности SQL Server для интеграции управления данными BLOB с остальными данными в реляционной базе данных - без необходимости отдельно управлять данными файловой системы.

Определение данных как столбца FILESTREAM в SQL Server также обеспечивает согласованность на уровне данных между реляционными данными в базе данных и неструктурированными данными, которые физически хранятся в файловой системе. Столбец FILESTREAM ведет себя точно так же, как и столбец BLOB, что означает полную интеграцию операций обслуживания, таких как резервное копирование и восстановление, полная интеграция с моделью безопасности SQL Server и полная поддержка транзакций.

Разработчики приложений могут работать с данными FILESTREAM через одну из двух моделей программирования; они могут использовать Transact-SQL для доступа и управления данными, как и стандартные столбцы BLOB, или они могут использовать потоковые API Win32 с транзакционной семантикой Transact-SQL для обеспечения согласованности, что означает, что они могут использовать стандартные вызовы чтения/записи Win32 для FILESTREAM BLOB, как если бы они взаимодействовали с файлами в файловой системе.

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

Answer 2

Для чего-то вроде веб-сайта электронной коммерции, я бы, скорее всего, поместил изображение в хранилище blob в базе данных. Хотя вы не хотите заниматься преждевременной оптимизацией, простое преимущество того, чтобы мои изображения были легко организованы вместе с моими данными, а также очень портативными, - это одно автоматическое преимущество для чего-то вроде электронной торговли.

Answer 3

Если изображения индексируются, поиск не будет большой проблемой. Я не уверен, но я не думаю, что поиск файловой системы - O (1), больше похож на O (n) (я не думаю, что файлы индексируются файловой системой).

Что меня беспокоит в этой настройке - это размер базы данных, но если правильно управлять, это не будет большой проблемой, и большое преимущество в том, что у вас есть только одна вещь для резервного копирования (базы данных) и не беспокоиться о файлах на диске.

Answer 4

Как правило, хорошим решением является хранение изображений в файловой системе и метаданные (имя файла, размеры, последнее обновленное время и все, что вам нужно) в базе данных.

Сказав это, «правильного» решения нет.

Answer 5

Заканчивать эту белую бумагу от MS Research (http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45)

Они подробно именно то, что вы ищете. Краткая версия заключается в том, что любой размер файла более 1 МБ начинает ухудшать производительность по сравнению с сохранением данных в файловой системе.

Answer 6

Я сомневаюсь, что O(log n) для поиска будет проблемой. Вы говорите, что у вас 10 ГБ изображений. Предполагая, что средний размер изображения составляет 50 КБ, это 200 000 изображений. Выполнение индексированного поиска в таблице для строк 200K не является проблемой. Он был бы небольшим по сравнению с временем, необходимым для фактического чтения изображения с диска и передачи его через ваше приложение и клиенту.

По-прежнему стоит учитывать обычные плюсы и минусы хранения изображений в базе данных по сравнению с сохранением путей в базе данных к файлам в файловой системе. Например:

• Изображения в изоляции транзакций ПОВИНУЕТСЯ базы данных, автоматически удалять, если строка будет удалена и т.д.
• базы данных с 10GB изображений, конечно, больше, чем в базе данных, хранящей только путей доступа к файлам изображений. Резервная скорость и другие факторы актуальны.
• Необходимо настроить заголовки MIME на ответ, когда вы подаете изображение из базы данных через приложение.
• Изображения в файловой системе легче кэшируются веб-сервером (например, Apache mod_mmap) или могут обслуживаться более компактным веб-сервером, таким как lighttpd. Это на самом деле довольно большая выгода.