Comments 16
Ну это что-то ваше внутренне-эликсирное (что-то на этот раз слишком много сленга).
Вообще, конечно, удивительно, что Erlang не взлетел на машинах типа Sun Niagara. Вы не знаете почему?
И, кстати, сейчас с распространением всяких M4 и прочих Огрызков, у нас есть реально многопоточные монстры, потенциал которых могут раскрыть лишь языки с удобной параллелизуемостью. На десктопе (или даже хуже — на ноуте). Есть у вас, Эликсирщиков, какие-то подвижки в эту сторону?
Какого еще сленга? Вы что, никогда не сталкивались с Job и Job Runners? Даже обычная λ в AWS — это по сути своей Job.
На десктопе (или даже хуже — на ноуте)
Ну, кто-нибудь рано, или поздно, напишет что-нибудь. Вот сегодня буквально в новостях мелькал https://makepad.nl — библиотека UI-примитивов на расте; учитывая, что втащить раст совсем несложно, может быть, кто-то и займется. Есть Scenic, я туда даже коммитил что-то, но вроде проект почти не развивается. Есть Elixir Desktop.
Но я вижу будущее именно в кооперативном UI+Processing, где UI — написан на чем-то более заточенном под кнопки и синхронность, а processing — отдан Beam. У меня статический рендеринг блога, например, на эликсире: там довольно много текстов, каждый нужно в HTML отрендерить, а потом — индексатор для локального поиска запустить. Было очень забавно при апгрейде ноута: количество ядер увеличилось в восемь раз, рендеринг ускорился в семь. А индексация (я чужую библиотеку взял, на ноде) — не ускорилась вообще :)
В любой мало-мальской экосистеме обязательно будет такая штука, как «job runner»
Нет, мы не сделаем правильно, не поправим наши схемы, не озаботимся триггерами и persistent views
Загрузить обновления данных в CSV для 60000 товаров. С валидацией данных конечно же, с выдачей ошибок валидации пользователю в том же CSV.
Отправить 40000 товаров на обработку в другую систему, с соответствующими изменениями в своей базе для каждого товара в результате успешной и неуспешной отправки.
Загружать файл, загруженный пользователем, в 2 разных файловых хранилища. В одно во время запроса пользователя, в другое позже, чтобы он не ждал. Нужно учесть, что любое хранилище может быть недоступно в данный момент, и загружать когда станет доступно.
Ну давайте, расскажите, как вы это сделаете с триггерами и persistent views, без фонового процесса обработки.
Ну давайте, прочитайте следующий абзац и ознакомьтесь с моим тезисом: «не используйте сторонние библиотеки для выполнения долгоиграющих задач».
Для CSV, кстати, собственный фоновый процесс не нужен: λ в S3 справится без вашего участия. На 40K товаров я просто запущу 40К разных [эрланговских] процессов, тут жобы тоже никому не впёрлись.
Нужно учесть, что любое хранилище может быть недоступно в данный момент, и загружать когда станет доступно.
А вот это без меня. Мои хранилища всегда доступны.
Вспомнил тут, как у нас жоба на загрузку «товаров» как раз добавила всем седых волос, потому что там что-то с таймаутами было. Я переписал на параллельное выполнение и на max инстансе амазона оно 2ГБ CSV обрабатывало 3 секунды. С валидацией, конечно.
и ознакомьтесь с моим тезисом: «не используйте сторонние библиотеки для выполнения долгоиграющих задач»
Непонятно, что это означает. Долгоиграющую логику для задачи, включая обработку ошибок, обычно пишут программисты, это часть кода проекта. Как напишут, так она и будет работать. А в системе выполнения фоновых задач (джобов) нет долгоиграющей логики, и ей без разницы, долгую задачу запускать или короткую, потенциальные проблемы будут одинаковые. Она проверяет разве что код завершения процесса, и то если только ее специально об этом попросить. При этом писать собственную систему запуска фоновых задач вы тоже не предлагаете. То есть ни своей ни сторонней системы запуска фоновых задач в проекте не будет.
Поэтому с учетом процитированного мной текста я понял это так, что вы советуете вообще не запускать фоновые процессы, а использовать триггеры, persistent views, и аналогичные средства.
В любой мало-мальской экосистеме
- Это что-то ваше внутренне-эликсирное - Вы что, никогда не сталкивались с Job и Job Runners?
На 40K товаров я просто запущу 40К разных [эрланговских] процессов, тут жобы тоже никому не впёрлись.
Вы сами себе противоречите. То про любые проекты говорите, то про специфику Эрланга. Как реализовать эту задачу в проектах на других языках, где нет эрланговских процессов?
Не говоря уже о том, что 40К разных фоновых процессов это и есть джобы, а код который их запускает это job runner. Ну да, если у вас уже есть job runner, то использовать другой job runner без особой необходимости нет смысла. С этим вроде никто не спорит.
А если 40К надо отправить в стороннюю систему, и она не рассчитана на такое количество одновременных веб-запросов, то и код на вашей стороне будет выполняться долго.
А вот это без меня. Мои хранилища всегда доступны.
А, ну понятно. Если задача неудобная, мы просто откажемся ее делать. Конечно так любые инструменты можно не использовать. Может быть у вашей компании есть средства держать собственное файловое хранилище, а другие компании часто используют Amazon S3 или аналогичные, которые они не контролируют. И при работе с ними надо учитывать, что они могут быть недоступны из-за технической неисправности на их стороне или на любой промежуточной точке пути IP-пакета, или по причине неоплаты/непродления договора вовремя. Поэтому должен быть фоновый процесс, который запускается несколько раз с достаточным интервалом, а если все-таки не получилось, пишет ошибку в систему логов, которая отправляет alert программистам.
Для CSV, кстати, собственный фоновый процесс не нужен: λ в S3 справится без вашего участия
Ага, код лямбды наверно сам магически напишется и запустится для нужной строки CSV-файла, а потом соберет их обратно в нужном порядке. Вы предлагаете заменить "localJobRunner.run(csvRow)" на "lambdaJobRunner.run(csvRow)" и называете это "не используйте джобы, никакой бизнес-логики в джобах". Может в Эрланге и есть какая-то разница, в остальных языках для программиста это один фиг код, который он должен написать на некотором языке и который будет работать где-то на сервере параллельно основному процессу. Там любые фоновые процессы обычно называют джобами. Если бы вы говорили про внутреннюю специфику проектов на Эрланг, то и вопросов бы не было, но выше вы возразили против этого утверждения.
там что-то с таймаутами было
переписал на параллельное выполнение
Конечно, если вы не понимаете что происходит в инструменте, то с его использованием могут быть проблемы. Это относится не только к джобам. В тех job runners, которые я использовал, описанных вами проблем не было.
Ну ок, вы сделали внутреннюю часть джобы параллельной, а где тут неиспользование джобы и джобера, или хотя бы неиспользование бизнес-логики в джобе? Должен быть код, который принимает CSV файл, запускает параллельные фоновые процессы с бизнес-логикой сохранения товара в базу для каждой строки (job), ждет их завершения, собирает результаты (например ошибки валидации), чтобы вернуть их пользователю. Это и есть то, что называют job runner. А если вы это делаете с помощью системы лямбд, которую написали в AWS, то он сторонний.
В тех job runners, которые я использовал, описанных вами проблем не было.
Ну и славно. Мой текст вы прочитать (или понять) не удосужились, зато у вас все и так работает — так что он вам и не нужен.
И при работе с ними надо учитывать, что они могут быть недоступны из-за технической неисправности на их стороне или на любой промежуточной точке пути IP-пакета, или по причине неоплаты/непродления договора вовремя. Поэтому должен быть фоновый процесс, который запускается несколько раз с достаточным интервалом, а если все-таки не получилось, пишет ошибку в систему логов, которая отправляет alert программистам.
На это вот отвечу, пожалуй, потому что это — просто вопиющая безграмотность.
Ни один сторонний сервис нельзя вызывать из своего кода напрямую, по одной простой причине: ваш код не может знать, что делать с ошибкой, которой вчера не было. Поэтому любой сторонний сервис (S3, Redis, DB, API, Whatever) — нуждается в обёртке, которая знает, что сделать, если сервис сбойнул. Такая обёртка для S3, скорее всего, будет делать что-то наподобие «попробовать еще раз наудачу, потом сгрузить в доступное back-up хранилище и запустить процесс типа watchdog, который будет мониторить S3, и когда оно придет в себя — перенесет файл туда». Плюс метрики, алерты и прочее.
Тогда основной код без потери общности может считать, что удаленное хранилище всегда доступно. Иначе — придется городить костыли наподобие «запускается несколько раз с достаточным интервалом», которые в общем случае не способны отработать правильно по причинам, которые я изложил в тексте.
Мой текст вы прочитать (или понять) не удосужились
Естественно, я вам прямым текстом написал "непонятно". И не я один. Вы пишете о каких-то одному вам понятных проблемах с одному вам известными инструментами. При этом почему-то предполагаете, что эти проблемы есть с любыми джобами в любых проектах, и читатели вас должны понять без пояснений.
нуждается в обёртке, которая знает, что сделать, если сервис сбойнул. Такая обёртка для S3, скорее всего, будет делать что-то наподобие
Я именно про такую обертку и говорю.
потом сгрузить в доступное back-up хранилище
"В доступное хранилище" оно и так уже загружено во время запроса пользователя. Если оба недоступны, ему будет показана ошибка "Не удалось загрузить файл". Задача в том, чтобы загрузить во второе позже. Это и есть система backup-хранилищ. Если одно недоступно когда надо скачать файл, система получит его из другого.
и запустить процесс типа watchdog, который будет мониторить S3
А что значит "мониторить"-то?) Наверно периодически проверять доступность с достаточным интервалом? А если так, зачем между попытками держать запущенным отдельный процесс для каждого файла, если они ничего не делают?
Мне насрать с высокой колокольни на читателей.
Захотят — поймут, не захотят — пройдут мимо.
И да, эти проблемы есть с любыми жобами в любых мало-мальски сложных проектах.
Ну в ваших проектах может и есть. Но насколько я могу судить, кроме вас на Хабре больше никто про это не писал, хотя джобы используются примерно везде. Так что можно предположить, что у большинства специалистов с ними проблем нет.
Захотят — поймут
Это зависит не только от их желания, а еще и от достаточности информации в статье для понимания.
у большинства специалистов с ними проблем нет
Это да. У специалистов в современном мире вообще мало проблем. У пользователей — много.
от достаточности информации в статье для понимания
На невнятность изложения мне жалуется настолько исчезающе малое количество людей, что у меня есть сложившееся мнение в этой дихотомии недопонимания.
У пользователей может и есть какие-то проблемы с использованием проектов компаний, но в моей практике это никогда не было связано с использованием джобов, сторонних библиотек для джобов, или бизнес-логики в джобах, и я никогда это не слышал от других специалистов.
В большинстве языков нет поддержки многопоточности на уровне языка, поэтому любая работа с потоками и процессами делается с использованием какой-то сторонней библиотеки. Джоба это просто еще один обработчик запроса в дополнение к десяткам остальных выполняющихся прямо сейчас, и аналогично им он может содержать любую логику, просто запускается не пользователем и не формирует HTTP-ответ кому-то.
Тут вы писали, что не сохраняете поле state заказа в базу данных, а держите его только в памяти приложения в гринтредах. Возможно, проблемы с джобами в ваших проектах связаны с этим подходом. В других языках результаты обработки сохраняются в базу данных, поэтому любой процесс может загрузить состояние сущности, сохраненное ранее в другом процессе, и продолжить обработку в соответствии с бизнес-логикой.
исчезающе малое количество людей, что у меня есть сложившееся мнение
Возможно, большинство тех, кто не понимает ваше изложение, просто не считают нужным сообщать это вам?
Не складывайте медленный код в жобу