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

Question

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

Answer 1

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

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

Атрибут FILESTREAM

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

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

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

Определение данных как столбца 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

Ознакомьтесь с этой статьей от MS Research (http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45)

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

Answer 3

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

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

• Изображения в базе данных подчиняются изоляции транзакции, автоматически удаляются при удалении строки и т. Д.
• База данных с 10 ГБ изображений, конечно, больше, чем база данных, хранящая только пути к файлам изображений. Скорость резервного копирования и другие факторы имеют значение.
• Вам необходимо установить заголовки MIME в ответе, когда вы подаете изображение из базы данных через приложение.
• Изображения в файловой системе легче кэшируются веб-сервером (например, Apache mod_mmap) или могут обслуживаться более тонким веб-сервером, таким как lighttpd. На самом деле это довольно большое преимущество.

Answer 4

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

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

Answer 5

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

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

Answer 6

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