Comments 41
Библиотеки, даже самые маленькие, лучше распространять через github. А библиотеки на PHP — через github + composer
Может вместо написания костылей настроит файловую систему и дисковую подсистему ОС?
Это скорее не костыли, а внедорожник.
Вы же верстаете так, что бы поддерживать устаревшие браузеры.
Можно поставить себе современный браузер, можно настроить ФС.
Но скорее всего, рано рано или поздно, учитывая текущие реалии, проект может попасть к кому-то, у кого она не настроена и кому по тем или иным причинам от нее что-то будет нужно. И вот тут-то Вас и вспомнят «добрым» словом.
Вы же верстаете так, что бы поддерживать устаревшие браузеры.
Можно поставить себе современный браузер, можно настроить ФС.
Но скорее всего, рано рано или поздно, учитывая текущие реалии, проект может попасть к кому-то, у кого она не настроена и кому по тем или иным причинам от нее что-то будет нужно. И вот тут-то Вас и вспомнят «добрым» словом.
это хороший совет, но что делать с 27 миллионами файлов? к которым в любой момент может потребоваться быстрый доступ
Действительно, как не настраивай файловую систему, но если 6 Терабайт (цифра из реального проекта, средний размер файла пол мегабайта) картинок закинуть в одну папку результат будет плачевный…
Я правильно понял 6 Тер = 6 000 000 000 0000 и 6 000 000 000 0000 / 500 000 ~ 12 млн. файлов?
Вот уж не знаю какие вы операционные системы эксплуатируете, но у меня на обычно ноуте живет каталог примерно с 50 млн. файлов каждый по 680 байт.
Он конечно занимает 200 Гб дискового пространства, но каких либо тормозов я не заметил. Аппликейшин на java, запущенный на этой же машине (где не производилось ни каких оптимизаций) произвольно находит (читает в поток) любой файл в пределах 2-х секунд. Имя файла это sha2-224
Вот уж не знаю какие вы операционные системы эксплуатируете, но у меня на обычно ноуте живет каталог примерно с 50 млн. файлов каждый по 680 байт.
Он конечно занимает 200 Гб дискового пространства, но каких либо тормозов я не заметил. Аппликейшин на java, запущенный на этой же машине (где не производилось ни каких оптимизаций) произвольно находит (читает в поток) любой файл в пределах 2-х секунд. Имя файла это sha2-224
на Вашем ноутбуке тоже было порядка 650000 запросов в сутки?
7 запросов в секунду? Если бы вы были внимательны то я писал что ноут это система без оптимизации.
Но вот только что изменил настройки ФС и застил считывать весь блок с inode в память. Буферы выросли до просто неприемлемых 3 Гб. Скорость доступа выросла всего 20 раз теперь файл читается за 0,1 сек. Работать просто невозможно из 15 Гб памяти что было доступно до оптимизации теперь доступно всего лишь 6 Гб. Пришлось зарезать яву машину до 4 Гб.
Так что вы правы лучше использовать странный костыль чем пытаться настроить систем из-за жалкого прироста производительности в 20 раз.
Но вот только что изменил настройки ФС и застил считывать весь блок с inode в память. Буферы выросли до просто неприемлемых 3 Гб. Скорость доступа выросла всего 20 раз теперь файл читается за 0,1 сек. Работать просто невозможно из 15 Гб памяти что было доступно до оптимизации теперь доступно всего лишь 6 Гб. Пришлось зарезать яву машину до 4 Гб.
Так что вы правы лучше использовать странный костыль чем пытаться настроить систем из-за жалкого прироста производительности в 20 раз.
Далее, имхо, и вполне возможно я ошибаюсь.
1) Без PSR-0 класс будет использовать неудобно.
2) Откуда нам брать Functions::arr_union()? Полагаю, тут можно использовать array_merge()
3) В find_upload(), как я понял, передается путь к файлу или относительный URL, но почему там не учитывается что текущий каталог может быть другой?
4) Если мы конструируем объект с настройками загрузки, а потом отдельно грузим файл, то по идее это должен быть синглтон. Иначе, почему бы не передавать файл на загрузку сразу в конструктор с настройками загрузки?
5) Что будет если однажды передать другие настройки сохранения файлов, оставив ту же папку для аплоада?
6) А как удалять файл?
1) Без PSR-0 класс будет использовать неудобно.
2) Откуда нам брать Functions::arr_union()? Полагаю, тут можно использовать array_merge()
3) В find_upload(), как я понял, передается путь к файлу или относительный URL, но почему там не учитывается что текущий каталог может быть другой?
4) Если мы конструируем объект с настройками загрузки, а потом отдельно грузим файл, то по идее это должен быть синглтон. Иначе, почему бы не передавать файл на загрузку сразу в конструктор с настройками загрузки?
5) Что будет если однажды передать другие настройки сохранения файлов, оставив ту же папку для аплоада?
6) А как удалять файл?
7) Не совсем понимаю зачем нужны get_upload_dir() и set_upload_dir() публично. Хотя они даже в классе нигде не используются. Плюс, set_upload_dir() копирует функционал get_upload_dir(), отличаются только созданием директорий.
8) Аналогичная ситуация с get_upload() и set_upload().
9) Самое главное, нигде в коде не увидел move_uploaded_file(). Как класс не может сохранять загруженные файлы? Сначала надо куда-то сохранить и только потом ему «скармливать»?
8) Аналогичная ситуация с get_upload() и set_upload().
9) Самое главное, нигде в коде не увидел move_uploaded_file(). Как класс не может сохранять загруженные файлы? Сначала надо куда-то сохранить и только потом ему «скармливать»?
Как то сильно похоже на ухудшенную копию… Рад ошибиться.
Работаем с php классом файлового хранилища.
TangoPHP файловое хранилище.
Работаем с php классом файлового хранилища.
TangoPHP файловое хранилище.
Да, вариант прост, но что если нам требуется не только хорошо сохранять файлы, но и еще быстро их находить?
Например у нас социальная сеть и мы хотим для каждого пользователя создать отдельную папку с номером его id и хранить в ней файлы которые в свою очередь тоже имеют свой id.
И для нас важно не только сохранить файл но и быстро найти где он лежит по его id.
Для этого данные о загруженных файлах можно хранить в БД и не беспокоить админов постоянными тормошениями файловой системы.
Например у нас социальная сеть и мы хотим для каждого пользователя создать отдельную папку с номером его id и хранить в ней файлы которые в свою очередь тоже имеют свой id.
И для нас важно не только сохранить файл но и быстро найти где он лежит по его id.
Для этого данные о загруженных файлах можно хранить в БД и не беспокоить админов постоянными тормошениями файловой системы.
>Для этого данные о загруженных файлах можно хранить в БД
NoSQL(наприем редис) — доступ быстрее будет :)
и вообще я не вижу надобности в этом классе. Если уж мы проектируем социальную сеть, то файлы должны лежать в статическом хранилище в удобном для быстрого вытаскивания виде. А внешние красивые урлы всегда можно перенаправить на nginx или апачем так как нам нужно.
NoSQL(наприем редис) — доступ быстрее будет :)
и вообще я не вижу надобности в этом классе. Если уж мы проектируем социальную сеть, то файлы должны лежать в статическом хранилище в удобном для быстрого вытаскивания виде. А внешние красивые урлы всегда можно перенаправить на nginx или апачем так как нам нужно.
давно, давно — Статья на хабре — Кстати в комментариях есть почему ограничено количество файлов в каталоге.
Не так давно —
Обработка файлов на сервере
TangoPHP файловое хранилище.
Работаем с php классом файлового хранилища
Не так давно —
Обработка файлов на сервере
TangoPHP файловое хранилище.
Работаем с php классом файлового хранилища
Поздравляю, вы изобрели хеш-таблицу с хеш функцией MD5 и хранением бакетов в ФС!
Twig тоже что-то подобное делает:
AB/
--CD/
----EFABC… (длинный хеш)
Только не узнавал что значат первые два уровня, в хеше эти данные вроде-как не содержатся
AB/
--CD/
----EFABC… (длинный хеш)
Только не узнавал что значат первые два уровня, в хеше эти данные вроде-как не содержатся
habrahabr.ru/post/70147/#comment_7727955 я случайно не туда написал. Ответьте.
В посте говорится о простоте поиска которого хоть убейте не вижу!
Я храню md5 в таблице и для поиска знаю, что файл лежит по адресу a/b/c/abcdef......gif
В Вашем случае путь к файлу все равно нужно где то хранить?
Я храню md5 в таблице и для поиска знаю, что файл лежит по адресу a/b/c/abcdef......gif
В Вашем случае путь к файлу все равно нужно где то хранить?
От файловой системы многое зависит. На raiserfs в свое время пробовал — разницы между одной директорией и иерархией не заметил. На ext3 разница была существенная.
Сколько файлов было в одной директории? на примерно терабайте эксперементировал разница одна папка 5-10с иерархия 5-7 мс. средний размер файла 300-500 килобайт. доставал скриптом.
Несколько тысяч. Давно пробовал, точнее не скажу.
Файлы делал пустыми.
Файлы делал пустыми.
пустой в смысле нулевого размера? тогда их может и не быть на диске, а они могут быть только в списке файлов, тогда чтение будет занимать доли секунды на любом количестве файлов…
Так меня и интересовала скорость lookup, а не чтения. Именно она зависит от количества файлов в директории.
не совсем так… список файлов храниться в файле, который разбросан по секторам жесткого диска, под него при создании директории выделяется определенное количество кластеров, которые идут подряд. После заполнения их записями выделяются новые кластеры, но если файлы пустые, и реальной записи на диск не идет, эти кластеры идут подряд. если файлы на диск пишутся то кластеры идут не подряд и головка винта начинает делать лишние проходы для чтения… как то так если на пальцах. SSD по другому.
Управление памятью даже в ext2 более хитрое и чаще всего директории, даже большие, оказываются не фрагментированными.
Разница в скорости происходит за счет представления — имены файлов организованы в линейный массив или в какое-нибудь дерево.
Разница в скорости происходит за счет представления — имены файлов организованы в линейный массив или в какое-нибудь дерево.
И за счет представления тоже, и за счет того, что каждый раз все равно читать с диска (кроме поиска файлов на реальном серваке куча задач которым нужна память после того, как сервер найдет файл он начинает его читать, что занимает проходы головки, значит следующий файл в другом каталоге, будет искаться медленнее…
а гонять сферитического коня в вакууме с файлами нулевого размера… в чем тогда смысл теста?
а гонять сферитического коня в вакууме с файлами нулевого размера… в чем тогда смысл теста?
случайно отправил.
после того как сервер найдет файл он начинает его читать, что занимает проходы головки, значит следующий файл в другом каталоге, будет искаться медленнее…
а гонять сферитического коня в вакууме с файлами нулевого размера… в чем тогда смысл теста?
после того как сервер найдет файл он начинает его читать, что занимает проходы головки, значит следующий файл в другом каталоге, будет искаться медленнее…
а гонять сферитического коня в вакууме с файлами нулевого размера… в чем тогда смысл теста?
Эм, и как скачать файл без php, например nginx'ом?
Хрена вы минусуте-то все? Дайте шанс чуваку. Ну сам переизобрёл велосипед, ну опубликовал. Это же не унылые псевдофилософские размышления на тему «почему HR такие глупые а я такой прекрасный», а вполне себе технический пост (хоть и не супер качественный). Вот такой вот приём разработки. Это же не оффтоп для хабра.
Я в любом случае учту все комментарии и переделаю класс.
Для меня важны любые отзывы.
Главное не вылететь с хабра.
Ну и нужно еще думать не обо мне, а о тех кто будет через поисковик искать ответ на вопрос как хранить файлы.
Сам пост (даже и не качественный) и комментарии дадут возможность тому кто ищет быстрее разобраться в вопросе.
Для меня важны любые отзывы.
Главное не вылететь с хабра.
Ну и нужно еще думать не обо мне, а о тех кто будет через поисковик искать ответ на вопрос как хранить файлы.
Сам пост (даже и не качественный) и комментарии дадут возможность тому кто ищет быстрее разобраться в вопросе.
Не переживайте, есть совсем хреновые статьи и авторы не вылетели. А строительством велосипедов страдали все, с опытом это проходит, но не у всех :)
А вы сделали решение, опубликовали его, стараетесь защитить, только так и можно идти к совершенству. А мелкие огрехи молодости я думаю Хабросообщество простит, всем было 20 лет.
А вы сделали решение, опубликовали его, стараетесь защитить, только так и можно идти к совершенству. А мелкие огрехи молодости я думаю Хабросообщество простит, всем было 20 лет.
> А вы сделали решение, опубликовали его, стараетесь защитить, только так и можно идти к совершенству. А мелкие огрехи молодости я думаю Хабросообщество простит, всем было 20 лет.
Только «стараетесь защитить» из этого списка надо убрать. Последнее что стоит делать новичку это защищать свой «велосипед». Правильный подход — это внять советам, пройти по предложенным ссылкам и вдохновиться решениями придуманными до нас и обкатанными в продакшене не одной сотней разработчиков. Ну и главный минус тех кто «сам не знаю но учу» это серьезные проблемы у других новичков кои еще не обладают критическим мышлением и по своей неопытности не могут отличить зерна от плевел.
П.С. этот код повторяется 5 раз, (и это далеко не единственная проблема исходников представленных в статье)
так делать нельзя. такие статьи лишь увеличивают энтропию, и новичку проще затеряться и вместо тру вей он может свернуть в такое болото что потом переучить будет крайне сложно
Только «стараетесь защитить» из этого списка надо убрать. Последнее что стоит делать новичку это защищать свой «велосипед». Правильный подход — это внять советам, пройти по предложенным ссылкам и вдохновиться решениями придуманными до нас и обкатанными в продакшене не одной сотней разработчиков. Ну и главный минус тех кто «сам не знаю но учу» это серьезные проблемы у других новичков кои еще не обладают критическим мышлением и по своей неопытности не могут отличить зерна от плевел.
П.С. этот код повторяется 5 раз, (и это далеко не единственная проблема исходников представленных в статье)
for($i=$this->branches;$i>=1;$i--) {
$dir=ceil($this->id/pow($this->max_file_count,$i))%$this->max_file_count;
$dir_file_arr[]=$dir>0?$dir:$this->max_file_count;
так делать нельзя. такие статьи лишь увеличивают энтропию, и новичку проще затеряться и вместо тру вей он может свернуть в такое болото что потом переучить будет крайне сложно
На изображении мы видим 2 ветви и по 3 файла в каждой папке.
Извините, пожалуйста, но я у впор не вижу 2 ветви на изображении.
Есть три уровня в дереве (слоя), (ну, или два уровня, если считать корень обособленной единицей), у каждого узла — по три ветви.
Я, возможно, заблуждаюсь, но а что мешает хранить файлы по папкам в виде год/месяц/день/час/хеш_имя? Да хоть до секунды папки создавать)
Как их потом искать?
сколько папок будет лет через пять — десять? И какова равномерность распределения фапйлов по каталогам в Вашем примере?
Ну если по месяцам — то не так много. Во всяком случае не так много, чтобы плодить какие-либо проблемы.
А плотность — ну если, например, вы примерно уверены, сколько юзеры грузят Вам на сайт (все еще подразумеваю высоконагруженный веб-ресурс), то и примерно распределение будете знать. Ну во всяком случае, плюс-минус 100 файлов погоды не сделают, ни так ли?)
А плотность — ну если, например, вы примерно уверены, сколько юзеры грузят Вам на сайт (все еще подразумеваю высоконагруженный веб-ресурс), то и примерно распределение будете знать. Ну во всяком случае, плюс-минус 100 файлов погоды не сделают, ни так ли?)
я как то переписывал такой проект, первоночально планировалось около тысячи пользователей в день, так и было первые четыре года жизни сайта, а потом что то произошло (я не вникал в маркетинг). И на сайт ломанулось до полумиллиона уников в день. Сообветственно выросли и нагрузки на сервер, и прочее… например оказалось что 32637 комментариев к одной статье это мало))) бывает и больше, а когда проектировали базу данных об этом не подумали, файлы хранились там в папках по дням, во первых накопилось число папок которые уже начали тормозить, во вторых, равномерность была мягко говоря никакая, в одной папке один файл в другой несколько тысяч…
Sign up to leave a comment.
Оптимальный способ хранения большого количества файлов на сервере