Блог

Я хочу создать систему, которая позволит тысячам пользователей загружать изображения с планшета в систему управления контентом. За одну загрузку каждый пользователь может загружать до 12 изображений одновременно, и в день может быть до 20 000 загрузок. Поскольку число составляет менее 240 000 изображений в день, мне было интересно, каков наилучший подход, чтобы избежать закупорки бутылок в часы пик.

Я подумываю об использовании фермы веб-серверов (IIS) для загрузки изображений через HTTP POST. Где каждое изображение меньше 200 КБ, и я мог бы хранить изображения в файловой системе. Это будет 48 ГБ в день и всего 16 ТБ в год.

Тогда я мог бы сохранить метаданные изображения в базе данных SQL Server вместе с другими текстовыми данными. Позже пользователи захотят отозвать изображения и другие (текстовые) данные из базы данных на планшет для дальнейшей обработки.

В небольших масштабах это не проблема, но меня интересует, что, по мнению всех, является наилучшим подходом для загрузки / извлечения такого большого количества изображений / записей в день?

Мне было интересно, как лучше всего избежать закупоривания бутылок в часы пик.

Достаточно оборудования. Точка.

Я подумываю об использовании фермы веб-серверов (IIS) для загрузки изображений через HTTP POST.

Нет альтернативы тому, что стоит упомянуть.

Это будет 48 ГБ в день и всего 16 ТБ в год.

Да. Современное хранилище просто фантастическое 😉

Тогда я мог бы сохранить метаданные изображения в базе данных SQL Server вместе с другими текстовыми данными.

Что делает этот ia довольно маленькой базой данных ldat — что хорошо. В конце это означает, что проблема сводится к хранилищу изображений, база данных на самом деле не такая большая.

В небольших масштабах это не проблема, но меня интересует, что, по мнению всех, является наилучшим подходом для загрузки / извлечения такого большого количества изображений / записей в день?

Я не уверен, что вы уже достигли больших масштабов. Проблемы будут повсюду:

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

• Резервное копирование / восстановление — это проблема, но намного меньше, когда вы используете (а) ленты и (б) корзины, как сказано выше — вероятность полной проблемы мала. Также «3-4 копии на отдельных машинах» могут работать достаточно хорошо.

За исключением проблемы с корзиной — т. Е. Вы не можете поместить все эти файлы в простую папку, что будет очень громоздко — у вас все в порядке. Это не совсем супер большой. Сохраняйте веб-уровень без состояния, чтобы его можно было масштабировать, то же самое на серверной части хранилища, затем используйте базу данных, чтобы связать все это вместе, и убедитесь, что вы ЧАСТО делаете резервные копии базы данных (например, все 15 минут).

Одним из возможных способов является загрузка с клиента непосредственно на Amazon S3. Он будет масштабироваться и принимать любое количество файлов, загружаемых на него. После завершения загрузки на S3 сохраните ссылку на объект S3 вместе с полезной метой в своей базе данных. При этой настройке вы избежите узкого места при загрузке файлов и сможете сохранять ~ 240 000 записей в день в своей базе данных, что не должно быть проблемой.

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