Загрузить & amp; хранить изображения на сервере
Я ищу способ хранения изображений профиля (листовок) в файловой системе для событий (действий).
По следующим причинам я планирую использовать изображения в кодировке base64 для отправки в виде json на сервер:
- Это только для изображений профиля с ограниченным размером файла до 150 КБ (мое веб-приложение не имеет дело с изображениями дальше, чем это на данный момент);
- Самое простое решение для совместимости с веб-браузером;
Лучший ответ (наиболее одобренный), который я нашел до сих пор, таков:
https://serverfault.com/questions/95444/storing-a-million-images-in-the-filesystem
Поскольку может быть много событий, со временем может быть много изображений.
Первое предложение:
Не храните фактический путь к базе данных. Лучше хранить изображения
порядковый номер для базы данных и есть функция, которая может генерировать путь
из порядкового номера. например:Путь к файлу = generatePathFromSequenceNumber (sequenceNumber);
Из этого порядкового номера я смогу вывести путь & имя файла для хранения в моей базе данных.
Это может быть глупым вопросом, но как мне получить порядковый номер из строки, закодированной в base64?
Решение
По следующим причинам я планирую использовать изображения в кодировке base64 для отправки в виде json на сервер:
- Это только для изображений профиля с ограниченным размером файла до 150 КБ (мое веб-приложение не имеет дело с изображениями дальше, чем это на данный момент);
- Самое простое решение для совместимости с веб-браузером;
Помните, что для хранения данных, закодированных в base64, накладные расходы составляют 33%. Это не тривиально, если у вас есть большое количество предметов, даже если они всего 150КБ. Base64 также не является дистанционно самым простым решением для совместимости с веб-браузером … оригинальное двоичное изображение.
Я настоятельно рекомендую пересмотреть ваш план здесь. Если вы храните закодированные изображения, вы тратите впустую дисковое пространство и не позволяете себе что-либо делать с изображением, если вы сначала не декодируете его.
Это может быть глупым вопросом, но как мне получить порядковый номер из строки, закодированной в base64?
Вы бы не. Этот порядковый номер является идентификатором в вашей базе данных изображения. У вас есть база данных с дополнительными данными об этих графических ресурсах, верно?
Другие решения
Код последовательности, вероятно, будет ключом для записи в базе данных, которую вы создаете, если вы примете это предложение.
Использование трехуровневого дерева также является хорошим предложением.
Однако вместо того, чтобы непосредственно брать порядковый номер и превращать его в инкрементный путь, я бы кое-как сгенерировал хеш или что-то полуслучайное, представляющее изображение, и использовал бы его для пути (если не хеш, то, возможно, случайная шестнадцатеричная строка, или UUID).
Если вы преобразуете идентификатор последовательности непосредственно в нумерованное имя файла, как показано в этом ответе, вы в конечном итоге запишите 10000 файлов в первый каталог, прежде чем начнете заполнять второй каталог. Я думаю, что это хорошая идея, чтобы попытаться получить случайное распределение по каталогам верхнего уровня. Когда вы получаете 1 миллион файлов, зачем платить полную стоимость чтения 1000 файлов в каталоге через конечные каталоги (потому что это все, что будет использоваться), когда вы могли бы вместо этого равномерно распределить их по всем конечным каталогам. Если ничего другого, это позволяет вам легко распределить дерево по нескольким файловым системам (возможно, потому что они находятся на разных серверах) в будущем.
Итак, в моем собственном приложении (на работе) ключи — это UUID, поэтому, например, мой первый ключ может быть aa082512eeb64694a24c16601b4d9f05, Затем он будет помещен в aa0/825/aa082512eeb64694a24c16601b4d9f05.jpg, Я не уверен, сколько файлов у проекта до сих пор, но мы передали 2 ТБ сохраненных изображений (в основном 1920×1080, не ограничиваясь 150 КБ файлами).
Кстати, w.r.t. Ваша кодировка base64, мы вместо этого получаем данные об изображении от пользователя отдельно от загрузки изображения. Мы выполняем фактическую загрузку в iframe. Это не самое приятное, но это позволило нам загружать изображения напрямую, не разбирая кодировку, при этом обновляя форму и реагируя на действия пользователя в главном окне. Я полагаю, что существуют библиотеки, которые могут сделать такие вещи для вас, я не помню, какой из них мы использовали.
Наш план на будущее — добавить код обнаружения функций и использовать только iframe для IE9 и использовать что-то более современное в IE10, Chrome, Firefox и т. Д.