И сколько проектов без s3 нормально живет? навалом

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

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

Этот опыт - работать через абстракцию, которой пофиг на s3 =) Но тут соглашусь - пощупать будет не лишним, и знать что это такое

И сколько проектов без s3 нормально живет? навалом

В моем понимании "интернет-магазин" это очень много медиа файлов. Фото товаров в разных скейлах, аттачи в комментариях и саппорте, постеры/баннеры и прочая хрень. Да это можно все хранить локально, но зачем нагружать диск тачки которая и без кого занята приложением?

да очень малому числу интернет магазинов нужен s3 на самом деле, в большинстве своем за глаза хватит локального хранения

В моем понимании "интернет-магазин" это очень много медиа файлов. Фото товаров в разных скейлах, аттачи в комментариях и саппорте, постеры/баннеры и прочая хрень. Да это можно все хранить локально, но зачем нагружать диск тачки которая и без кого занята приложением?

Весь вопрос в трафике. Если не уперлись в диск тачки - пусть работает, че нет то. Чтобы его напрячь на ssd , это надо прям постараться (ну т.е. иметь уже довольно мощный трафик).

А если у нас локальный магазин памперсов - такого трафика там и не будет никогда

Удобно в чем? Администрировать свой minio? Платить дополнительно для облачный сервис? Не иметь нормальной работы с listingом и объемами? Это прежде всего object storage и удобен он масштабированием. Если масштабирования не требуется в чем удосбство?

Удобно потому что свое тоже нужно администрировать тот же minio нормально поддерживает кубер

Удобно потому что свое тоже нужно администрировать тот же minio нормально поддерживает кубер

Я противовес локалки ставлю. Какой кубер....

так мужики спасибо за советы) но если без дополнительных сервисов, вот есть у меня локально 30 гб и этого пока что хватит, вот как мне организовать хранение допустим возьмем конкретно - картинки товаров?)

Просто сохраняешь туда файлы

) в чем вопрос тогда

Маунтишь этот вольюм в симфу и в нгинкс

Настраиваешь домен отдельный в нгинксе

И в КФ его

так мужики спасибо за советы) но если без дополнительных сервисов, вот есть у меня локально 30 гб и этого пока что хватит, вот как мне организовать хранение допустим возьмем конкретно - картинки товаров?)

берете fly system или подобное. Чтобы иметь если что абстракциб перехода на тот же s3. А пути выстраиваете в зависимости от работы с вашим приложением. Как вариант: /images/products/{productId}/{uuid}.jpg например. Хранить в БД имхо лучше полный путь, т.е. /images/ тоже ( так и хранить /images/products/{productId}/{uuid}.jpg). Но это на вкус и цвет, свои плюсы и минусы.

Но например у вас может быть такое, что еще продукта нет, а уже загружаете какие то файлы. Тогда /images/products/{productId}/{uuid}.jpg не получится (точнее варианты есть, но уже более мудрено).

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

Так что имхо, начните с простого (/images/products/{productId}/{uuid}.jpg) + локальное хранение + либа для абстракции или как по доке примеры. Может на symfony cast есть что.

Понял, пойду пробовать мастерить что нибудь)

мы храним так берем хеш файла, создаем папку 2 символа хеша, 2 символа хеша и кладем сам файл, и отдаем файлы напрямую через nginx

c759c17df2bff098472c762cd1d133f7 files/images/с7/59/c759c17df2bff098472c762cd1d133f7

мы храним так берем хеш файла, создаем папку 2 символа хеша, 2 символа хеша и кладем сам файл, и отдаем файлы напрямую через nginx

А разные размеры картинок как делаете?

это отдельно храним в таблице

Понял, пойду пробовать мастерить что нибудь)

да не надо придумывать что-то. Ну вот придумаешь, а другим потом это поддерживать. Небольшое s3 хранилище орендавал и поехали. Или miniio и когда вырастишь переехай в облако. Вы же не пишете собственные яп и не конструируете свои субд. Вот и пользуйтесь готовым

нет никаких проблем с тем чтобы работать с файлами локально

в 99% проектах так и будет

c759c17df2bff098472c762cd1d133f7 files/images/с7/59/c759c17df2bff098472c762cd1d133f7

ещё кстати хорошей практикой (в зависимости для чего вы это делаете конечно) будет зашивать куда-то размеры и усреднённый цвет картинки Или где-то в респонсе с апи, или в query или в самом пути. Допустим files/images/с7/59/128:64:0394fc:x37447tc.jpeg или files/images/с7/59/x37447tc.jpeg?x=128&y=64&c=x37447tc или {"i":"files/images/с7/59/x37447tc.jpeg","x":128,"y":64,"c":"x37447tc"} тогда фронтенд ещё до запроса на сервер сможет скорректировать контент, особенно если загрузка ленивая (допустим статьи на сайте)

Можно ещё посмотреть на это https://github.com/liip/LiipImagineBundle

Само хендлит все

В сочетании с https://github.com/dustin10/VichUploaderBundle покроет думаю все требования для автора вопроса

Vich разрулит сохранение куда нужно, а liip на ходу обработает картинку и вернёт нужный рамзер, сохранив результат в кеш

Думаю liip не будет работать с S3, но автору вроде и не нужно

c759c17df2bff098472c762cd1d133f7 files/images/с7/59/c759c17df2bff098472c762cd1d133f7

Тоже писал про шарды, как раз хороший пример как легко реализовать

Зашивать шард в урл или куда-либо ещё говно идея. Смена шарда или его удаления повлечет за собой ворох проблем.

Зашивать шард в урл или куда-либо ещё говно идея. Смена шарда или его удаления повлечет за собой ворох проблем.

Не имеется ввиду не шард сервиса или тд. Это псевдошард пути на локалке

Тоже самое например симфа делает в кэше

Чтобы не делать одну папку помойку, так как при каком то объеме начинается проблемы с чтением

Но это актуально для локалки, для s3 пофиг наверное

папка 😂

Чтобы не делать одну папку помойку, так как при каком то объеме начинается проблемы с чтением

Не начинаются ) У меня есть папки с овер 30к файлов. Проблема ток открыть их с программы с визуальным списком. А так на чтение файла системой не влияет

Не начинаются ) У меня есть папки с овер 30к файлов. Проблема ток открыть их с программы с визуальным списком. А так на чтение файла системой не влияет

30к вроде немного еще

Ну рекомендация держать не более 4к в одной директории

Ну рекомендация держать не более 4к в одной директории

Ну вот сам и ответил :)

Можно по дате директории создавать, но это несколько раскрывает информацию

папка 😂

?

Хеш от файла тож говно. Если надо будет скопировать куда-то весь объем, то ты в жопе )

Хеш от файла тож говно. Если надо будет скопировать куда-то весь объем, то ты в жопе )

Зачем? Это просто инициация названия файла и пофиг как

Например можно uuid

Главная проблема - это коллизии

Раз создал, а дальше тупо по имени которое сохранил ходишь

Хеш от файла тож говно. Если надо будет скопировать куда-то весь объем, то ты в жопе )

хеш от файла говно потому, что ты не контролируешь кол-во файлов в директории

Зачем? Это просто инициация названия файла и пофиг как

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

если уж на то пошло, то можно сделать таблицу в которой вести имена бакетов и кол-во файлов в ней Но на вашем месте я бы не парился

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

Не понимаю в какую сторону ты идешь. Это не физические шарды, а логические, не более.

Если прожект непбольно то просто фигачить в 1 фолдер и всё

Если прожект непбольно то просто фигачить в 1 фолдер и всё

Для одной иноды вроде ограничения есть, зависит от фс

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

Или ты имена вообще не хранишь в БД? Я чет короче проблемы не понимаю.

А если надо тупо всё- то тупо всё и копируешь

Или ты имена вообще не хранишь в БД? Я чет короче проблемы не понимаю.

Не, я про то, что файлы мелкие. Картинки. И их дофига. Но проблема с хешем в том, что директорий, в которых лежат файлы очень много. Рсинк тотже копирует такое ппц долго. Почти как фтп. Сначала проверяет наличие директории, потом создаёт по одной, потом ток сам файл копирует.

Т.е. переезд с сервера на сервер это становится проблемой

Т.е. переезд с сервера на сервер это становится проблемой

Тип между хранением по хэшу и хранением 1 помойки ты выбрал бы помойку?

Или в стретегии хэша слишком много сегментов?

Грубо говоря, 1 первой буквы достаточно

Тип между хранением по хэшу и хранением 1 помойки ты выбрал бы помойку?

Что-типа того. На данный момент я для поста генерирую рандом буквы 7штук, и путь 2/2/3. Туда все барахло. Постов немного, а вот картинок дофига. И ещё я пришел к тому, что картинки неплохо было бы в один файл скидывать. И писать оффсет и размер рядышком.

Но один файл это для крупных ребят

Что-типа того. На данный момент я для поста генерирую рандом буквы 7штук, и путь 2/2/3. Туда все барахло. Постов немного, а вот картинок дофига. И ещё я пришел к тому, что картинки неплохо было бы в один файл скидывать. И писать оффсет и размер рядышком.

Так сам же делаешь то же самое по сути

Что-типа того. На данный момент я для поста генерирую рандом буквы 7штук, и путь 2/2/3. Туда все барахло. Постов немного, а вот картинок дофига. И ещё я пришел к тому, что картинки неплохо было бы в один файл скидывать. И писать оффсет и размер рядышком.

Вообще не понял...

Так сам же делаешь то же самое по сути

Это всё ещё говно, да. Но лучше чем хеш от картинки в путь превращать ) Никогда так не делайте

Это всё ещё говно, да. Но лучше чем хеш от картинки в путь превращать ) Никогда так не делайте

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

Между твоим 7 символами и хэшем, особо разницы не вижу, кроме затраченных ресурсов и фичи перезаписи

Вообще не понял...

Файловые системы очень плохо работают с мелкими файлами. Максимально хуево я бы сказал ) Поэтому писать картинку в один гигафайл, на максимальный размер. И рядышком метаданные сохранять хз. Тип какая-то картинка с 1 по 11432байт

Файловые системы очень плохо работают с мелкими файлами. Максимально хуево я бы сказал ) Поэтому писать картинку в один гигафайл, на максимальный размер. И рядышком метаданные сохранять хз. Тип какая-то картинка с 1 по 11432байт

Что значит плохо? В чем это отражается?

Между твоим 7 символами и хэшем, особо разницы не вижу, кроме затраченных ресурсов и фичи перезаписи

Количество директорий, говорю же, оно в сотни раз меньше

Не, я про то, что файлы мелкие. Картинки. И их дофига. Но проблема с хешем в том, что директорий, в которых лежат файлы очень много. Рсинк тотже копирует такое ппц долго. Почти как фтп. Сначала проверяет наличие директории, потом создаёт по одной, потом ток сам файл копирует.

Вот в чем

Копирование всего этого очень болезненное

Количество директорий, говорю же, оно в сотни раз меньше

У тебя 2 директории по 2 символа, у него 2 директории по 2 символа - одинакого все.

Копирование всего этого очень болезненное

А как с этим потом работать в приложении? Как такие картинки читать из веба? Писать поверх этого утилиту?

У тебя 2 директории по 2 символа, у него 2 директории по 2 символа - одинакого все.

Ток у него 2 директории на каждую картинку, а у меня на пост )

Копирование всего этого очень болезненное

Короче какая то муть, имхо. Тем более если говорить, что если прилага большая - то там уже вообще s3, и нет никаких директорий