Comments 49
Если топик понравится, перенесу в коллективный блог.
спасибо за статью, сейчас тем же самым занимаемся на работе, единый сервер хранения статических файлов, статья оказалась полезной.
Именно для этого я ее и писал). Скажу только то что прямо сейчас у нас встала задача вынесения статики на отдельные сервера и пока я не знаю насколько этот подход масштабируем.
у нас план следующий, есть порядка 15 серверов, и 2 сервера для хранения статики реплицированных, будет единое api для загрузки файлов под множество проектов, файлы складываются на файлове хранилище по принципу имя проекта и год месяц день… так же заносятся данные в бд для отслеживания где что…
То что вы описали по моему мнению правильный подход, и очень расширяемый, вплане добавить дополнительный возможности по ресайзу объектов, распаковок, ретуши и прочих манипуляций безгранично…
То что вы описали по моему мнению правильный подход, и очень расширяемый, вплане добавить дополнительный возможности по ресайзу объектов, распаковок, ретуши и прочих манипуляций безгранично…
Я храню картинки на отдельном сервере и домене.
Получаю хеш картинки и создаю папку с первыми двумя символами
Пример:
450x337
8f
8f30de72de3a710dc11c1b22caa5ede4.jpeg
/450x337/8f/8f30de72de3a710dc11c1b22caa5ede4.jpeg
Получаю хеш картинки и создаю папку с первыми двумя символами
Пример:
450x337
8f
8f30de72de3a710dc11c1b22caa5ede4.jpeg
/450x337/8f/8f30de72de3a710dc11c1b22caa5ede4.jpeg
Хэш картинки это же куча времени на подсчет, при этом пользы от него никакой, не?
UFO just landed and posted this here
Куча времени тратится только при загрузке файлов, потом хэш уже не генерируется, а берется из базы.
Это понятно, но смысла тратить процессорное время на такую операцию особого не вижу. Дублированные картинки — наверное, актуальны только для очень популярных хостингов, а для них время ещё дороже.
Хотя при масштабах в десятки серверов, наверное, уже и не особо важно, всё равно окупается.
Хотя при масштабах в десятки серверов, наверное, уже и не особо важно, всё равно окупается.
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
UFO just landed and posted this here
Решил задачу почти аналогичным методом, только для храненния имя файла генерил хеш на основе его названия и времени загрузки.
Вы хотя бы ставьте тег PHP
О плюсах и минусах данного подхода лишь упоминается, что они есть. А где описание?
Минусы:
— любая ошибка ведет к появлению мусора как на файловой системе так и в базе данных.
— файл на файловой системе не защищен от удаления «руками» или другим приложением
— сложная функциональность для осуществления rollback-a
— нужна переделка при переносе решения с win на lin и обратно (работа с файлами отличается, темповый каталог тоже, права доступа тоже)
Плюсы:
— можно указать прямую ссылку на файл с файловой системы
Минусы:
— любая ошибка ведет к появлению мусора как на файловой системе так и в базе данных.
— файл на файловой системе не защищен от удаления «руками» или другим приложением
— сложная функциональность для осуществления rollback-a
— нужна переделка при переносе решения с win на lin и обратно (работа с файлами отличается, темповый каталог тоже, права доступа тоже)
Плюсы:
— можно указать прямую ссылку на файл с файловой системы
Не совсем понял с флагом «is_delete». Если мы хотим удалить картинку, мы ставим его в true. Сборщик посмотрит базу, удалить нашу картинку — а далее что? Снова поставив флаг в фальш, чтобы потом еще раз не пытаться удалять несуществующую уже картинку?
Сборщик удаляет картинку из файловой системы и из таблицы. Больше этой записи существовать не будет.
Насколько я знаю, в крупных проектах картинки никогда не удаляются. Есть мнение что это вызывает ненужную фрагментацию, да и просто не имеет смысла. Экономия копеечная, потому что количество удаляемых фотографий пренебрежимо мало по сравнению с добавляемыми фотографиями.
с выходом амазон S3 я перестал парится со статикой. все картинки и видео скидываются туда. под рельсы есть пара очень удобных плагинов которые решают вопрос с ресайзом под нужный размер е т.д. дополнительный плюс: можно очень просто и быстро порейти на cloudfront cdn.
Sign up to leave a comment.
Хранение, обработка и отдача статики