A0, A1, ZZ… ну это предположительно

нет

вообще что захочешь

для 100 сс можно исользовать любые однобайтовые символы от 0-9a-zA-Z и знаки @#$%*&-+()!":';/?

Что значит "можно"? Стандарта нет никакого?

вообще это ж просто словарь

не обязательно ограничиваться только видимыми символами у нас 256 вариантов

не нужен стандарт, нужна схема или готовая библиотечка для перевода из одной сс в другую

не нужен стандарт, нужна схема или готовая библиотечка для перевода из одной сс в другую

Самому написать - задачка уровня универа. 😊

понятное дело, но работать оно будет аццки медленно

просто с матчастью плохо, не знаю как оптимизировать многочисленные pow

возведения в степень для больших чисел

понятное дело, но работать оно будет аццки медленно

Вы черезчур помешаны на скорости. Сначала реализуйте - скорость будет вполне приемлемой.

Вариант хранения в папке понравился. Чем не подходит?

а вы предлагаете создавать папки названием с sha1 кодом нужной картинки?

просто я бы хотел еще сохранять картинки в каталоге с датой загрузки

но можно наоборот имя картинки - дата, а путь sha хэш

а вы предлагаете создавать папки названием с sha1 кодом нужной картинки?

Вижу так - в таблице все атрибуты картинки, на диске по sha в имени файла можно найти саму картинку

Имя картинки - дата -- плохая идея из-за возможных повторов.

так даже в бд отпадает нужда, зачем хранить атрибуты их можно так получить

Имя картинки - дата -- плохая идея из-за возможных повторов.

она же в отдельном каталоге по хэш коду храниться будет

так даже в бд отпадает нужда, зачем хранить атрибуты их можно так получить

Чтобы иметь возможность искать по дате, лучше засунуть её в БД, чем перебирать файлы.

однозначно, так можно еще теги прикрутить

кстати да, какую лучше бд юзать для поиска по тегам, датам, размеру

думал сначала elastic search

но еще были планы связать с реферам(страниц где эти картинки используются)

referal

кстати да, какую лучше бд юзать для поиска по тегам, датам, размеру

Ну эт не ко мне. Я фанатик ql (если нужно чисто на go решение), либо postgresql в остальных случаях.

но пути к постам планируется менять а pgsql слишком огромный и я слышал что nosql бд справляются с этим быстрее

ну вот и все вроде, выговорился )

а кстати, нет ли у вас чатов на холивары?

pgsql vs mysql

а кстати, нет ли у вас чатов на холивары?

Господин Дуров может забанить, т.к. нагрузку будем создавать большую. 😄

спасибо за идею с путями в sha1

но у меня еще чувство что это будет аццки тормозить прибольшом количестве картинок

как большие репозитории в git'e

даже если разбивать пути на на большее количество составляющих, например sha[0:2]/sha[2:4]/sha[4:6]/....

даже если разбивать пути на на большее количество составляющих, например sha[0:2]/sha[2:4]/sha[4:6]/....

Здравая мысль. В крупных проектах типа ipfs так и делают.

всеравно в одном подкаталоге получится очень много вариантов

Здравая мысль. В крупных проектах типа ipfs так и делают.

в git'e так делают ), у меня репы так на гитлабе тормозят аццки что я один проект несколько раз в новые репозитории переносил

Ну не знаю... В одной папке всё хранить - наверно ещё хуже. А раз умные люди юзают такой способ с разбивкой на папки - возможно это оптимальный вариант.

на счет этого однозначно согласен, все что собираюсь делать уже было реализовано, и ни в коем случае не считаю что линус глупее меня просто думаю как лучше разбить в моем случае, и так что бы файловая система не пострадала и скорость была норм ведь можно sha1 по 2 символа разбить - это будет макс. по 1024 подкаталога а можно по 1 символу - это 32 подкаталога, - явно мало(наверно) и нужно ли делать 100500 подкаталогов на весь sha, ведь это хеш и есть вероятность что первые символы будут часто повторяться и тогда будут проблемы и возможно это уже рассуждения о сферическом коне в вакууме..

всеравно в одном подкаталоге получится очень много вариантов

очень много - понятие относительное. по мне так очень мало

может кто то что то подобное делал? как вы это реализовывали?

или может есть схожие проекты, где можно что то подобное подглядеть

стандартный подход - бить по трем первым символам хэша, т.е. будет три уровня вложенности.

тоесть sha[0:3]/sha[3:6]/sha[6:9]/sha[9:] получается в одном подкаталоге может быть макс 32к подкаталога

не много ли?

sha[0]/sha[1]/sha[2]/sha

все

спс, попробую пока так

или нет, попробую по 2символа, а потом хз что делать

делай по одному

тоесть sha[0:3]/sha[3:6]/sha[6:9]/sha[9:] получается в одном подкаталоге может быть макс 32к подкаталога

Если sha в хексе, то 4096

но это всеравно много для одного подкаталога, не? какое оптимальное количество подкаталогов для одной папки?(в среднем для ехт3-4)

но это всеравно много для одного подкаталога, не? какое оптимальное количество подкаталогов для одной папки?(в среднем для ехт3-4)

Зачем использовать ext3 в 2017 году?

потому что есть еще старые vds

тоесть sha[0:3]/sha[3:6]/sha[6:9]/sha[9:] получается в одном подкаталоге может быть макс 32к подкаталога

Но зачем? Чего вы хотите этим добиться?

потому что есть еще старые vds

Centos 4?

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

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

Что именно тормозит когда много файлов? Какая именно операция?

операция поиска каталога по имени в каталоге где много других каталогов

я так думаю, может я совсем не прав

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

а не хранят все в одном каталоге

возможно они тоже не правы, но не могут миллионы людей ошибаться (с) мавроди )

возможно они тоже не правы, но не могут миллионы людей ошибаться (с) мавроди )

Слышал что-то подобное в другой форме - "Миллионы мух не могут ошибаться".

)))

операция поиска каталога по имени в каталоге где много других каталогов

readdir(2) занимает один seek

тогда зачем это все городят?

https://m.habrahabr.ru/post/152193/

тогда зачем это все городят?

Именно потому что я написал выше

https://m.habrahabr.ru/post/152193/

спасибо, я уже читал её, но полезно было вспомнить именно сейчас )

Правда тут вопрос идёт только про удаление. Возможно, остальной функционал (создание/доступ и т.п.) работает нормально... Но кто знает!

Именно потому что я написал выше

потому что seek? я думаю потому что readdir :))) прямой доступ по имени скорее всего вообще не тормозит

Или виндузятники?

Или виндузятники?

Сорри, успел удалить

Кстати, для пользователя виндоуз в принципе не плох. А вижуал студия - вменяемая иде.

Тут гоферы, для них вЫзуал студио кодЭ

потому что seek? я думаю потому что readdir :))) прямой доступ по имени скорее всего вообще не тормозит

да, прямой тормозит только если будет miss в dentry cache