никогда не храните абсолютные пути в БД

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

Ожидается, что количество входящих файлов составит около 500 000 в неделю (в среднем около 100 Кбайт каждый), достигнув пика около 100 000 файлов в день и 5 в секунду. Ожидается, что общее количество файлов достигнет десятков миллионов, прежде чем достигнет равновесия, когда срок действия файлов по разным причинам истекает при скорости ввода.

Поэтому мне нужна система, которая может хранить около 5 файлов в секунду в часы пик, при этом читая около 4 и удаляя 4 в любое время.

Моя первоначальная идея заключается в том, что на самом деле должно быть достаточно простой файловой системы NTFS с простым сервисом для хранения, устаревания и чтения. Я мог бы вообразить, что служба создает подпапки для каждого года, месяца, дня и часа, чтобы поддерживать минимальное количество файлов в папке и разрешать ручное истечение срока действия в случае необходимости.

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

редактировать

Спасибо за все комментарии и предложения. Еще немного бонусной информации о проекте:

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

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

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

Там будет время простоя каждый день, когда техническое обслуживание может быть выполнено.

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

Итак, мои вопросы:

Какие технологии сделают надежную работу?Какие технологии будут иметь самые низкие затраты на внедрение?Какие технологии будет проще поддерживать ИТ-отдел клиента?Какие риски существуют для данной технологии в таком масштабе (данные 5-20 ТБ, 10-100 миллионов файлов)?

Ответы на вопрос(0)

Ваш ответ на вопрос