Крупномасштабное хранилище изображений

Question

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

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

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

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

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

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

Спасибо за все замечания и предложения. Дополнительная информация о бонусе о проекте:

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

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

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

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

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

Так что мои вопросы:

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

Answer 1

Вот некоторые случайные мысли о реализации и возможных проблемах, основанные на предположениях: средний размер изображения 100 кбайт и установившееся состояние 50 МБ (5 ГБ) изображений. Это также предполагает, пользователи не будут получать доступ к файловому хранилищу напрямую, и будет делать это с помощью программного обеспечения или веб-сайта:

1. Носитель: Размер изображения вы даете равнозначно довольно мизерные скорости чтения и записи, Я думаю, что наиболее распространенные жесткие диски не будут иметь проблемы с этой пропускной способностью. Однако я бы поставил их в конфигурацию RAID1 для обеспечения безопасности данных. Резервные копии, похоже, не слишком большие, так как это всего лишь 5 гб данных.

2. Хранилище файлов: Чтобы предотвратить проблемы с максимальными файлами в каталоге, я бы взял хэш (минимум MD5, это было бы самым быстрым, но наиболее вероятным столкновением). И прежде чем люди щебетают, чтобы сказать, что MD5 сломан, это для идентификации, а не для безопасности. Злоумышленник может накладывать изображения на вторую атаку на прообраз и заменять все изображения на goatse, но мы рассмотрим это маловероятно), а конвертировать - в шестнадцатеричную строку. Затем, когда пришло время спрятать файл в файловой системе, возьмите шестнадцатеричную строку в блоках из 2-х символов и создайте на ней структуру каталогов для этого файла. Например. если хэш файлов равен abcdef, корневой каталог будет ab, а затем под этим каталогом cd, под которым вы должны сохранить изображение с именем abcdef. Настоящее имя будет храниться где-то в другом месте (обсуждается ниже).

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

   Другое преимущество здесь: Если вы столкнулись с проблемами скорости передачи или проблемами с файловой системой в целом, вы можете легко отделить отложенные файлы на других дисках. Просто измените программное обеспечение, чтобы поддерживать каталоги верхнего уровня на разных дисках. Поэтому, если вы хотите разделить хранилище пополам, 00-7F на одном диске, 80-FF на другой.

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

3. Хранение метаданных: в то время как строки 50M кажутся много, большинство СУБД построены, чтобы издеваться над таким количеством записей, с достаточной ОЗУ, конечно. На основе SQL Server написано следующее, но я уверен, что большинство из них применимы к другим.Создайте таблицу с хешем файла в качестве первичного ключа, а также такие вещи, как размер, формат и уровень вложенности. Затем создайте другую таблицу с помощью искусственного ключа (для этого будет полезна колонка Identity Identity), а также исходное имя файла (varchar (255) или что-то еще) и хеш в качестве внешнего ключа обратно в первую таблицу, и дату, когда он был добавлен, с индексом в столбце имени файла. Также добавьте любые другие столбцы, которые вам нужно выяснить, если файл истек или нет. Это позволит вам сохранить исходное имя, если у вас есть люди, пытающиеся помещать один и тот же файл под разными именами (но в остальном идентичны, так как они имеют то же самое).

4. Техническое обслуживание: Это должно быть запланированное задание. Пусть Windows беспокоится о том, когда ваша задача выполняется, меньше для вас, чтобы отлаживать и ошибаться (что делать, если вы выполняете техническое обслуживание каждую ночь в 2:30 утра, а вы где-то, что наблюдает летнее/летнее время. 2:30 утра не происходит во время замены пружины). Затем эта служба будет запускать запрос к базе данных, чтобы установить, какие файлы истек (на основе данных, хранящихся в имени каждого файла, поэтому он знает, когда истекли все ссылки, указывающие на сохраненный файл. Любой хешированный файл, на который не ссылаются по крайней мере одна строка в таблице имен файлов больше не требуется). Затем служба удалит эти файлы.

Я думаю, что это касается основных частей.

EDIT: Мой комментарий становится слишком долго, перемещая его в редактирование:

Упс, моя ошибка, это то, что я получаю за делать математику, когда я устал. В этом случае, если вы хотите избежать избыточной избыточности добавления уровней RAID (например, 51 или 61, например, для зеркального отображения в полосатом наборе), хеширование предоставит вам преимущество в том, что вы можете сложить 5 1TB дисков на сервер, а затем программное обеспечение для хранения файлов охватывает диски с помощью хэша, как упомянуто в конце 2. Вы можете даже RAID1 использовать диски для дополнительной безопасности.

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

Я вижу двукратную обратную сторону по дате/времени для каталогов. Во-первых, вряд ли распределение будет однородным, это приведет к тому, что некоторые каталоги станут более полными, чем другие. Хеширование будет равномерно распределяться. Что касается spanning, вы можете контролировать пространство на диске при добавлении файлов и начинать перетекать на следующий диск, когда пробег заканчивается. Я предполагаю, что часть срока действия связана с датой, поэтому у вас будут старые диски, которые начнут пустым, поскольку новые будут заполняться, и вам нужно будет выяснить, как сбалансировать это.

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

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

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

Answer 2

Храните изображения в базе данных SQLite. Сначала звук сумасшедший, но он серьезно работает быстрее, чем их хранение в файловой системе, и занимает меньше места.

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

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

Попробуйте, вы будете приятно удивлены.

Answer 3

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

• использование sha1 файла в качестве имени файла (при необходимости, хранить поставляемый пользователь имя файла в БД)

  дело в том, что если вы заботитесь о данных, вы должны хранить контрольную сумму в любом случае.
  Если вы используете sha1 (sha256, md5, другой хэш), тогда будет легко проверить данные файла - прочитайте файл , cacl hash, если он соответствует имени, тогда данные действительны. Предполагая, что это веб-приложение какого-либо типа, имя файла на основе хэша может использоваться как etag при обслуживании данных. (проверьте пример .git для примера). Это предполагает, что вы не можете использовать предоставленного пользователь имени файла в любом случае, так как пользователь может отправить что-то вроде «<>? :(). .txt»

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

  Основным тестом здесь является то, что должно быть возможно идентифицировать файл, просто просмотрев только в PATH \ FILE, без выполнения поиска метаданных в БД. Если вы храните/контролируете шаблоны строго по времени, то STORE \ DATE \ HH \ FILE имеет смысл, если у вас есть файлы, принадлежащие пользователям, то, возможно, STORE \ < 1-й N-разрядный номер UID> \ UID \ FILE смысл.

• использовать транзакции для операций с файлами/метаданных

  т.е. начать запись в файл метаданных TRX, попытайтесь писать файл в ФС, в случае успеха совершить TRX, откат на ошибки. Необходимо проявлять максимальную осторожность, чтобы избежать ситуации, когда у вас есть метаданные файлов в БД и нет файлов в FS и наоборот.

• использовать несколько корневых места

  хранения т.е. STORE01 \ STORE02 \ STORE \ - это могут помочь в развитии (и позже с масштабированием). Возможно, что несколько разработчиков будут использовать один центральный БД и хранилище файлов, которые являются локальными для их машины. Использование STORE с самого начала поможет избежать ситуации, когда раскладка метаданных/файлов. будет действовать в одном экземпляре приложения, и не действует в других ..

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