Обслуживание изображений с сервера SQL против файловой системы против S3 и т. Д.

Мое приложение (классический asp yay!) Имеет около 2,1 миллиона изображений при 25 ГБ, и это всего лишь данные за 90 дней, и я хотел бы сделать как минимум 365. Мне нужно взять их под контроль, и я рассматриваю все варианты. Что вы думаете о плюсах и минусах следующих практик:

• Преимущества SQL Server: простое резервное копирование Минусы: производительность?
• Преимущества файловой системы: Скоростные минусы: избыточность, резервное копирование выполняется медленно (в настоящее время изучается создание синтетических полных резервных копий вместо этого, которые могли бы сделать это лучше)
• S3 и другие плюсы: пропускная способность смещена с моего центра обработки данных на Amazon, практически неограниченное хранилище. Минусы: затраты, анализ затрат сложен (оценка 80% моей пропускной способности - это изображения для целей окупаемости инвестиций), трудно / дорого обходиться поставщикам услуг в случае необходимости

Кто-нибудь еще имеет дело с проблемой многомиллионного изображения и как вы ее решили?

У нас нет миллионов изображений, но есть сотни тысяч, и мы используем гибридный подход - mysql для метаданных, изображения, сохраненные на локальном диске для резервного копирования, и отправленные на Amazon s3, где они предоставляются пользователям. У нас не было проблем с Amazon и доступностью. Переход на облачный фронт - в наших планах, просто нужно найти время.

Это обсуждение может быть полезным для вас при принятии решения:
http://ask.metafilter.com/59635/Millions-of-images

Я бы пошел с метаданными на сервере SQL и файлы в файловой системе (или s3 или облачного фронта). Но лучший ответ зависит от некоторых других моделей использования:

• часто меняются изображения
• можете ли вы обслуживать изображения непосредственно из файловой системы (то есть img src="...") или вам нужно, чтобы они контролировались доступом. Если последнее, то решение для базы данных лучше
• Вы предоставляете небольшое количество изображений большую часть времени (последние 10%) или это распространение относительно широко распространено.

Резервное копирование миллионов изображений будет сложным независимо от того, как вы их упорядочите - это просто много данных. Я хотел бы найти хорошее практическое исследование по резервному копированию больших двоичных объектов на SQL-сервере, прежде чем принять решение об этом. (Вот статья, которая может быть полезна: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

Если вы решите сохранить их в файловой системе, вы можете прочитать этот вопрос о ServerFault, чтобы узнать, что делать, а что нет: хранить миллион изображений в файловой системе .

Игнорируйте людей, которые говорят: « Не храните изображения / двоичные данные в базе данных », поскольку они основывают свои ответы на старой информации (при условии, что вы будете хранить данные в столбце типа VarBinary). Проблемы производительности, связанные с использованием SQL Server для хранения изображений, теперь можно уменьшить с помощью типа данных FILESTREAM в SQL Server 2008. По сути, тип данных FILESTREAM позволяет сочетать простоту хранения данных в базе данных с производительностью, получаемой от обслуживания. файлы из файлового хранилища NTFS.

Процитирую SQL Mag :

«Новая поддержка FILESTREAM в SQL Server 2008 сочетает в себе преимущество доступа к объектам LOB напрямую из файловой системы NTFS с ссылочной целостностью и простотой доступа, предлагаемыми механизмом реляционных баз данных SQL Server».

Для получения дополнительной информации читайте этот блог Ravi S.Maniam на MSDN .

Хотя я не имею дело с проблемой миллионов изображений, я бы использовал Amazon CloudFront. Все файлы хранятся в корзине S3, но являются серверами через систему доставки контента Amazon. Я бы не использовал S3 в одиночку.

Мой второй выбор - файловая система. Простая и легкая, единственная проблема в том, что если все эти файлы окажутся в одном каталоге, то все будет очень сложно.

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

Базы данных предназначены для транзакционных данных / согласованности и безопасности.

Медиа-файлы (изображения, аудио, видео), как правило, создаются и, возможно, удаляются, но очень редко обновляются. Поэтому, как правило, нет необходимости поддерживать их в транзакционном соответствии с другими данными, и база данных не даст вам никакой реальной выгоды. Текстовое содержание, возможно, другое дело.

Если у вас нет проблем с тем, что кто-то тянет ваш файл напрямую, если у него есть URL-адрес файла, то с файловой системой все в порядке. Если вы работали с чем-то вроде библиотеки фотографий, где вы ожидаете зарядку, прежде чем люди загрузят файл, то это, вероятно, другое дело. То есть, как только пользователь заплатил, он может получить URL, специфичный для этого пользователя или действительный только в течение короткого времени, и приложение обрабатывает несколько или временные URL, указывающие на одно и то же изображение. Это все еще может быть обработано приложением и файловой системой, но в итоге вы предоставляете носитель через приложение, а не как прямую загрузку файла (что в большинстве случаев исключает любые преимущества S3), и между БД и файловой системой меньше различий ,