Хранение изображений большого размера

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: мой комментарий становился слишком длинным, перемещая его в редактирование:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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