Доброго времени суток! Есть задача написать конвертер файлов из одного формата в другой. Это не распространенные форматы и типы их никому ничего не скажут. Алгоритм конвертирования отработан и вопросов не вызывает. Хотелось бы получить несколько советов по архитектуре решения. Как лучше реализовать. Я предполагаю использовать временные файлы, но как в этом случае результаты отдавать пользователю пока не знаю. В общем, поделитесь пожалуйста лучшими практиками. Какие способы использовать, где хранить файлы, как отслеживать удаление уже скачанных экземпляров и т.д. Можно без кода, просто поэтапно, но желательно поподробнее, это мне поможет впоследствии разобраться как писать код. Спасибо.
Спасибо, почитаю, но там вроде конкретный код обсуждается. Типа как отдать файл пользователю. Мне же интересна архитектура построения конвертеров файлов, которых так много в инете. Там я выбираю файл на диске, загружаю на сервер, отрабатывает скрипт и мне возвращается ссылка именно на мой файл ,который потом (наверное) автоматически удаляется с сервера. Файлы будут маленькие и входящие и исходящие максимум 5 Мб. Но реально меньше.
Ну сохраните во временную папку, а потом удалите. Запросто. После того, как вы отдали файл, как описано в топике, можно удалять его. Он больше не нужен. с 5 мегабайтами php справится должен.
Хорошо, попробую сам описать, а Вы расскажите (дополните), где я не прав и что упустил. 1. Создаю скрипт upload. 2. Загружаю файл, получаю дескриптор временного файла. 3. Обрабатываю этот файл (конвертирую). 4. Сохраняю результаты. Вопрос где? 5. Создаю временную ссылку на ... куда файл результатов сохранил. 6. Пишу её в БД вместе с абсолютным путем и сроком жизни. 7. Вот тут пока не очень понятно, наверное надо сгенерировать элемент с временной ссылкой на форме. Здесь не понятно, как отдавать пользователю ссылку. В его сессии это понятно, но предполагается, что сразу несколько пользователей будут делать одно и то же. Короче делаю линк с временной ссылкой из БД по ID сессии. 8. После скачивания надо очистить временные файлы, входящий и исходящий. А потом ещё базу почистить от мертвых ссылок. Можно конечно по крону, но можно чистить и при входе нового пользователя, точнее при каждой новой задаче конвертирования. Наверное мусора много не будет.
входящий файл удалять после конвертирования надо, разве нет? приняли, записали, в очередь поставили. обработали, уведомили юзера. раз в день запускаем крон который будет удалять файлы обработанные более х дней назад.
Спасибо, а вопрос с сохранением результатов конвертирования. Их надо складывать в одну папку, именуя например ID+время+filename.zip или как, чтобы они отличались? И по поводу крона. Мне не очень нравится эта идея, т.к. файлов будет много. Сколько скачиваний, соответственно столько и загрузок. Время жизни у файла буду делать не более 15 минут. Чем плох мой вариант удалять первым делом при вызове конвертации все устаревшие ссылки. Получится, что при каждом добавлении новой будут удалены все устаревшие. И ещё, а временный файл обязательно удалять, они сами не удаляются? Ну это я просто не очень пока разбираюсь .
снимайся с ручника да? это как тебе надо и как тебе удобно. ты же определяешь это надо. сделай для начала хоть как. а потом уже увидишь плюсы-минусы решения и придумаешь другое. уникальный рандом доступный только пользователю - не этого ли достаточно для имени файла? тебе не нравится потому что ты её не понимаешь или почему еще? плох? ну это тебе решать. я вот например не понимаю зачем процедуре которая должна всосать файл от юзера заниматься перерыванием хулиарда файлов в файловой системе. ведь если юзеров и файлов будет много то и этих вот процессов зачистки будет так же много. а крон запускается одним процессом. то есть ты хочешь сбежать от однопоточного крона и положить файловую систему сканированием на каждом запросе. ок. да-да, вижу. класс. может и сам удалится. смотря на каком этапе у тебя временный файл. тот который от клиента пришел исчезает в момент завершения запроса. ой. чтоб с ним дальше работать ты будешь его наверное куда-то копировать. и ведь до того как он будет окончательно обработан - он тоже будет считаться временным файлом. нет? ну а после обработки его же можно удалить. это ж всего одна команда, нет? в общем я думаю стоит начать с основ программирования, с формулирования задач, с оценкой алгоритмов. а то блин тебе подсказывают а ты оказывается уже знаешь что всё говно и надо по-другому. рано тебе еще крутые конвертирующие сервисы делать.
Ну разве я так говорил? Я начинаю с основ, как раз с алгоритма. Про то, что всё говно я ни слова ни сказал. Благодарю за подсказки. Кстати, а они есть? Ну эти как ты говоришь крутые сервисы. Я пока не встречал. То, что видел друг от друга ничем не отличаются, ну разве что скриптом, который конвертирует. Но вижу я их как пользователь, а серверную сторону не вижу. И вообще, я не понимаю чем (какими словами) я вызвал у тебя такую реакцию?
какую реакцию? я тебе рассказал на личном опыте а ты отверг мои предложения по принципу "а мне так не нравится" а не "проводил исследования" или хотя бы "исходя из моего опыта" ну ты ж не говоришь какого рода конвертация идет. давай очередной раз на личном опыте поделюсь. было лет много назад заведено в метрополитен ареа нэтворках держать сервисы а-ля хостинг изображений. и все как на подбор работали с жипег, пиэнджи и гиф. причем били последние два только в путь (прозрачности и анимацию, если не понял о чем речь). беглый взгляд на список функций пыховой библиотеки GD дает ответ отчего же все эти сервисы такие однотипные и кривые. и я чисто ради интереса сделал альтернативный сервис, который не ломал прозрачности и анимации, а уж по кол-ву поддерживаемых форматов входных и выходных файлов вообще убойный был - на лист а4 еле помещалось. не сложно догадаться какую библиотеку я взял за основу этого "крутого" сервиса. и там была и очередность обработки, и уборка мусора по крону. и панель для зарегистрированного пользователя с возможностью пролонгации. и удаление по жалобам на порнографию. в общем просто немного подумал над тем чего не хватает другим фотохостингам в отдельно взятой городской сети. в общем может быть крутой конвертор, работающий с файлами, которые ты хочешь конвертировать - уже тоже существует. просто кто-то взял и сделал его.
Я не отверг, просто мне нужно понимать почему так или так. Я же объяснял почему мне этот вариант не понравился. Точнее я хотел сказать, что мне понравился другой вариант. Да, опыта пока нет, но считать я уже умею . Прикинул максимальную нагрузку - примерно 1 загрузка в минуту. Как прикинул долго рассказывать, да и надо ли. Вот исходя из этого получается, что при максимальной нагрузке (среднечасовой конечно) и временем жизни 15 минут (тут писал) получится, что будет лежать не более 15 файлов. При конвертации 16-го скрипт будет анализировать предыдущие 15 ссылок и свою. Потом удалять 1-ю и ссылок опять будет не более 15. При снижении нагрузки все 15 умрут и при простое сервера около 15 минут останется 1 ссылка. Ну это очень примерно, но всё же не тысячи. К сожалению пока нет, наверное по этому и занялся. Секретов тут никаких. Стал счастливым обладателем видеорегистратора StreetStorm 7810-G. Он использует базу радаров и оповещает о них. Но эта компания зашифровала свою базу в виде бинарника. А люди хотят её редактировать, дополнять, благо сервисов публикующих данные о камерах много. Но ни один из них не поддерживает формат StreetStorm. Я на форуме пообщался и понял, что это очень востребовано. Написал программу для конвертирования и редактирования базы, ну естественно предварительно разобрав бинарник. Однако локальная программа это не то, ей пользуются единицы, а остальные ждут, когда эти "единицы" выложат в сеть результаты. Поэтому решил сделать WEB-версию. Здесь у меня уже можно посмотреть базу радаров на карте Яндекса, что очень удобно при добавлении точек. Крутого конечно ничего, но уникальность - да.
понял. в общем посмотри в сторону того же пхп. у них крон раз в сколько-то минут по крону пробуждается и удаляет устаревшие файлы сессий. это делает один процесс и он гарантирует удаление мусора даже при нулевой посещаемости сайтов. и как следует из того что это один процесс - не будет лишней нагрузки на случай если вдруг одновременно придет сотня ботов. да, им там может и пару десятков файлов предстоит выбрать но это будет пара десятков однотипных запросов к субд без которых можно было и прожить. или вот движок этого форума - пхпбб - раз в сколько-то времени подсовывает в исходник страницы просьбу загрузить адрес крон.гиф - конечному пользователю пофигу ибо это прозрачная точка а система сама контролирует что будет показано только одному пользователю одновременно. из минусов этой реализации - если у тебя слабый по посещению сайт то один юзер пришел зарегистрировался и письмо с активацией (при определенных настройках) встало в очередь пока не будет выполнен "крон"-сценарий. а он будет выполнен дня через три например (до след. входа кого-нибудь хоть тех же ботов) - юзер уже забудет где хотел зарегистрироваться. вот тебе раз минус функциональности ориентирующейся на запросы к сервису. еще один минус - этот же пхпбб и этот же пример с редкой посещаемостью - первый посетитель вошедший после долгого простоя сайта разогревает кэш, компилирует шаблоны, удаляет старые темы из мусорки. просто потому что этих задач накопилось а все они выполняются по факту посещения кем-нибудь доски. и тут же приятный плюс - с версии 3.1 пхпбб комплектуется консольным сценарием, который можно навесить на родной системный крон. сильно систему не грузит раз нет посещений, но при этом доска всегда в актуальном состоянии. вот. к чему я. делая реализацию удаления по загрузке нового тебе придется делать еще и систему блокировки на случай состояния гонки. или тупо обойтись запуском уборщика по крону. решать тебе.
Спасибо большое! Очень убедительно. Да и спорить я конечно даже и не собирался. Были бы аргументы - не писал бы в ветку для новичков . Просто понять хотелось. Ещё хотел спросить. Уже по поводу конвертера. Он будет разбирать бинарник, в нем около 10 тыс. строк по 104 байта. Каждую строку надо анализировать, например 14 байт представляют собой координаты точки, зашифрованные по системе IEEE - 754-2008, там довольно сложная математика перевод сначала в двоичную систему, а потом в число с плавающей точкой с точностью до 8-го разряда. Так вот, стоит ли эту задачу реализовывать на PHP или посмотреть в сторону CGI? Правда я под линукс никогда не писал программ...
обработку запроса от клиента можно делать и на пхп. конвертацию файлов быстрее делать на других языках. отдавать результат опять можно на пхп. такая цепочка будет всяк проще чем одно приложение через кги
Если их будет десятки тысяч, то конечно нет. Напишите обвязку которая будет раскладывать файлы по папкам. К примеру файл qwerty.jpg будет лежать в категории /files/q/w/e/qwerty.jpg.
Во-первых такое количество реальных директорий создавать не нужно. Объект класса который в проекте работает с файлами должен будет их заводить по мере надобности, под конкретный файл. Во-вторых что и зачем по ним нужно регулярно искать? Хранить связи можно и нужно в базе (вместе с ссылкой на физический файл), как и искать по ним же (если речь идёт о поиске пути к файлу, то искать тут вообще ничего не нужно: путь строится из имени файла). Соответственно, при удалении физического файла удалить нужно и запись о нем в бд, и проч., как понимаете. Есть ряд служебных операций которые нужно будет проводить пробегая рекурсивно по директориям, но, имхо, практика показывает, что такая тройная вложенность есть оптимальный выбор под мои задачи хранения большого числа файлов (в моем случае это текстовые файлы и изображения проекта). Хранение всех файлов под одной записью директории может обернуться гораздо большими сложностями если вы понимаете специфику работы файловой системы и считывания файла под директорией которого хранится очень много других файлов.