Comments 49
Если топик понравится, перенесу в коллективный блог.
спасибо за статью, сейчас тем же самым занимаемся на работе, единый сервер хранения статических файлов, статья оказалась полезной.
Именно для этого я ее и писал). Скажу только то что прямо сейчас у нас встала задача вынесения статики на отдельные сервера и пока я не знаю насколько этот подход масштабируем.
у нас план следующий, есть порядка 15 серверов, и 2 сервера для хранения статики реплицированных, будет единое api для загрузки файлов под множество проектов, файлы складываются на файлове хранилище по принципу имя проекта и год месяц день… так же заносятся данные в бд для отслеживания где что…
То что вы описали по моему мнению правильный подход, и очень расширяемый, вплане добавить дополнительный возможности по ресайзу объектов, распаковок, ретуши и прочих манипуляций безгранично…
То что вы описали по моему мнению правильный подход, и очень расширяемый, вплане добавить дополнительный возможности по ресайзу объектов, распаковок, ретуши и прочих манипуляций безгранично…
Я храню картинки на отдельном сервере и домене.
Получаю хеш картинки и создаю папку с первыми двумя символами
Пример:
450x337
8f
8f30de72de3a710dc11c1b22caa5ede4.jpeg
/450x337/8f/8f30de72de3a710dc11c1b22caa5ede4.jpeg
Получаю хеш картинки и создаю папку с первыми двумя символами
Пример:
450x337
8f
8f30de72de3a710dc11c1b22caa5ede4.jpeg
/450x337/8f/8f30de72de3a710dc11c1b22caa5ede4.jpeg
Хэш картинки это же куча времени на подсчет, при этом пользы от него никакой, не?
Куча времени тратится только при загрузке файлов, потом хэш уже не генерируется, а берется из базы.
Это понятно, но смысла тратить процессорное время на такую операцию особого не вижу. Дублированные картинки — наверное, актуальны только для очень популярных хостингов, а для них время ещё дороже.
Хотя при масштабах в десятки серверов, наверное, уже и не особо важно, всё равно окупается.
Хотя при масштабах в десятки серверов, наверное, уже и не особо важно, всё равно окупается.
md5($now_time. $rnd. $file_size)
А зачем создавать папку? Почему нельзя складывать всё в одну? Это ограничение ФС?
вместо хеша использую id
а для разных размеров расширенное имя:
012345.jpg — оригинал — возможно хранится в другой папке
012345_320x240.jpg
012345_640x480.jpg
а для разных размеров расширенное имя:
012345.jpg — оригинал — возможно хранится в другой папке
012345_320x240.jpg
012345_640x480.jpg
Я тоже использую хеши, но не от файла, а как указанно выше md5($now_time. $rnd)
Из-за этого нельзя пройтись по файлам методом перебора ссылок т.к. имена файлов не идут одно за одним, а имеют довольно большой разброс.
Это спасает от автоматического выкачивания статики сторонними приложениями.
Из-за этого нельзя пройтись по файлам методом перебора ссылок т.к. имена файлов не идут одно за одним, а имеют довольно большой разброс.
Это спасает от автоматического выкачивания статики сторонними приложениями.
Как раз недавно стояла задача со статикой. Все картинки хранятся в директориях со структурой:
images/Y/m/d/картинка — в оригинальном размере. При запросе прямо в запросе указываю какой метод резайза применить и несколько субдоменов (по первым символам хеша картинки), например p1.example.com/resize/250x250/картинка. Ресайзер хранит кеш в отдельно смонированном разделе на tmpfs в оперативной памяти (у нас кеш порядка 150Мб) также в структуре по первым символам кеша e/8/кеш имени картинки.
С JS и CSS там отдельная история.
Чисто клиентской оптимизацией удалось достигнуть ускорение при холодной загрузке в 2 раза, при горячей почти в 5.
images/Y/m/d/картинка — в оригинальном размере. При запросе прямо в запросе указываю какой метод резайза применить и несколько субдоменов (по первым символам хеша картинки), например p1.example.com/resize/250x250/картинка. Ресайзер хранит кеш в отдельно смонированном разделе на tmpfs в оперативной памяти (у нас кеш порядка 150Мб) также в структуре по первым символам кеша e/8/кеш имени картинки.
С JS и CSS там отдельная история.
Чисто клиентской оптимизацией удалось достигнуть ускорение при холодной загрузке в 2 раза, при горячей почти в 5.
Мы хотим попробовать похожую схему.
Стораджи на которых хранится статика. Перед ними фронтенд с ресайзером, который еще и кеширует превью.
Код по webdav будет закачивать файлы на стораджи, и генерировать урлы которые указывают на фронтенд. При запросе картинки с фронтендов nginx в зависимости от того нашел ли файл по указанному пути будет его либо отдавать сразу либо передавать скрипту ресайзеру (ресайзер nginx не может делать то что нам нужно: прозрачность и углы, поэтому его использовать не будем).
Стораджи на которых хранится статика. Перед ними фронтенд с ресайзером, который еще и кеширует превью.
Код по webdav будет закачивать файлы на стораджи, и генерировать урлы которые указывают на фронтенд. При запросе картинки с фронтендов nginx в зависимости от того нашел ли файл по указанному пути будет его либо отдавать сразу либо передавать скрипту ресайзеру (ресайзер nginx не может делать то что нам нужно: прозрачность и углы, поэтому его использовать не будем).
А ещё для хранения/ресайза/расшаривания картинок есть вот такая библиотечка:
Primage — PHP library that works like a proxy for realtime images resizing and watermarking (+ cache support)
Primage — PHP library that works like a proxy for realtime images resizing and watermarking (+ cache support)
Всё уже написано до нас ) А вообще интересно. что правильнее — сохранять сначала в БД, а потом в писать файл или наоборот? В случае, когда запись файла в конце, можно получить лишнюю запись в бд, если запись файла выдаст ошибку. Потом ещё надо будет регулярно чистить базу на тему мертвых записей в БД.
Правильно сначала писать в базу, потому что если потом обломается загрузка картинки то выполнится rolback транзакции и в базе мусора не окажется. Базу можно и не чистить, вряд ли когда-нибудь это станет узким местом. Если уж так хочется почистить то нужно пользоваться полем is_deleted, так как написано в статье.
ролбэк — это время. При больших потоках, может быть и большое время. Надо считать.
правильнее, если это хайлоад:
картинку класть сразу на тот сервер (или два) откуда будет произведена отдача, далее в очередь поместить информацию о новом контенте.
постоянно мониторить очередь, например раз в сек и при наличие в ней элементов — запустить скрипт обработки ( ресайз + запись в БД) и делать это на отдельном сервере (как правило на том — который отдает статику)
В качестве сервера очередей у нас используется memcacheq
сылка по теме www.grid.net.ru/nginx/upload.ru.html
php-webdav.pureftpd.org/project/php-webdav
картинку класть сразу на тот сервер (или два) откуда будет произведена отдача, далее в очередь поместить информацию о новом контенте.
постоянно мониторить очередь, например раз в сек и при наличие в ней элементов — запустить скрипт обработки ( ресайз + запись в БД) и делать это на отдельном сервере (как правило на том — который отдает статику)
В качестве сервера очередей у нас используется memcacheq
сылка по теме www.grid.net.ru/nginx/upload.ru.html
php-webdav.pureftpd.org/project/php-webdav
Решил задачу почти аналогичным методом, только для храненния имя файла генерил хеш на основе его названия и времени загрузки.
Вы хотя бы ставьте тег PHP
О плюсах и минусах данного подхода лишь упоминается, что они есть. А где описание?
Минусы:
— любая ошибка ведет к появлению мусора как на файловой системе так и в базе данных.
— файл на файловой системе не защищен от удаления «руками» или другим приложением
— сложная функциональность для осуществления rollback-a
— нужна переделка при переносе решения с win на lin и обратно (работа с файлами отличается, темповый каталог тоже, права доступа тоже)
Плюсы:
— можно указать прямую ссылку на файл с файловой системы
Минусы:
— любая ошибка ведет к появлению мусора как на файловой системе так и в базе данных.
— файл на файловой системе не защищен от удаления «руками» или другим приложением
— сложная функциональность для осуществления rollback-a
— нужна переделка при переносе решения с win на lin и обратно (работа с файлами отличается, темповый каталог тоже, права доступа тоже)
Плюсы:
— можно указать прямую ссылку на файл с файловой системы
Не совсем понял с флагом «is_delete». Если мы хотим удалить картинку, мы ставим его в true. Сборщик посмотрит базу, удалить нашу картинку — а далее что? Снова поставив флаг в фальш, чтобы потом еще раз не пытаться удалять несуществующую уже картинку?
Сборщик удаляет картинку из файловой системы и из таблицы. Больше этой записи существовать не будет.
Насколько я знаю, в крупных проектах картинки никогда не удаляются. Есть мнение что это вызывает ненужную фрагментацию, да и просто не имеет смысла. Экономия копеечная, потому что количество удаляемых фотографий пренебрежимо мало по сравнению с добавляемыми фотографиями.
с выходом амазон S3 я перестал парится со статикой. все картинки и видео скидываются туда. под рельсы есть пара очень удобных плагинов которые решают вопрос с ресайзом под нужный размер е т.д. дополнительный плюс: можно очень просто и быстро порейти на cloudfront cdn.
Sign up to leave a comment.
Хранение, обработка и отдача статики