GG
Вопрос именно в эффективности решения задачи
Size: a a a
2020 June 22
GG
Потому что если вы реально хотите отслеживать "зелёные квадратики" двухсот тысяч тасок в день, то это... Вообще не отслеживание
+
ML
База постгрес пухнет, шедюлер не успевает и воркеры за ним
По нагрузке да, согласен. В принципе можно запустить разные типы источников на разных инстансах airflow.
GG
Не, конечно речь не о том, чтоб смотреть на все это, когда все ок.
Наоборот, заметили проблему, идем смотрим на DAG, где иммено падает и на сколько это массово (т.е. если проблема с конкретным сервисом, это сразу будет видно по DAGу), и логи тут же
В этом плане подходит то что уже есть у airflow.
Наоборот, заметили проблему, идем смотрим на DAG, где иммено падает и на сколько это массово (т.е. если проблема с конкретным сервисом, это сразу будет видно по DAGу), и логи тут же
В этом плане подходит то что уже есть у airflow.
Мне кажется, но не факт, что эйрфлоу хорош, когда скоуп задач очерчен (1) и когда изредка, но нужно старые таски перезапускать (2)
GG
Если их не нужно перезапускать - смысл вообще тащить этот тяжёлый метастор с инфой о всех запусках? Стреляй в очередь (=celery) и вычитывай джобу и на выполнение ее
SG
Если их не нужно перезапускать - смысл вообще тащить этот тяжёлый метастор с инфой о всех запусках? Стреляй в очередь (=celery) и вычитывай джобу и на выполнение ее
В общем, вот да. Аерфлоу == постоянство
ML
Да, согласен. Airflow скорей не подходит. Собственно это и хотел узнать. Благодарю, сэкономили время
GG
Да, согласен. Airflow скорей не подходит. Собственно это и хотел узнать. Благодарю, сэкономили время
знаешь, что в этой всей истории обидно?
GG
PR. Тот самый пиар, который нам говорит - вот, смотри, очешуенная штука, она решит все твои проблемы
GG
а потом выясняются ограничения. На практике. Очень болезненные
GG
контроль ожиданий - это очень большая и больная тема
GG
вот тебе обещают нечто, и не выполняют - результат - клиент потерян навсегда (по крайней мере, если рынок достаточно большой)
SG
А что вообще может потянуть 200 тыс в сутки?
Да что угодно. Постгрес, например
GG
200 тыс в сутки - это 2 в секунду на постоянку
M
Да что угодно. Постгрес, например
я думаю имеется в виду система оркестрации и исполнения задач а не бд
ML
База постгрес пухнет, шедюлер не успевает и воркеры за ним
Кстати, про "пухнет"
Очередь задач у нас на postgresql реализована. И уже видимо приближаемся к началу возникновения проблем, но пока еще норм. Задумались так же посмотреть на что-то готовое.
Celery (rabbitmq) покрывает не все потребности в очереди. Т.е. как доставка задач до воркеров - ок.
А вот планирование (как описал выше), каждая задача после выполнения, откладывается на некоторое время для повторного выполнения (определяется бизнес-логикой).
В очереди порядка 5-7 млн. задач. В день выполняется 200-300 т. задач.
Может кто-то посоветует что можно попробовать.
Основные требования: распределенная очередь (можно запускать много инстансов воркеров на разных серверах на один тип задач), приоритеты (у каждой задачи 2-3 уровня приоритета). Собственно наверно все, из важных требований.
Пока идея такая, что сделать свою очередь на postgres, с партицированием по типам задач и шардингом при необходимости. (текущая реализация не распределенная, можем запускать на один тип задач, только воркеры с одного инстанса).
Очередь задач у нас на postgresql реализована. И уже видимо приближаемся к началу возникновения проблем, но пока еще норм. Задумались так же посмотреть на что-то готовое.
Celery (rabbitmq) покрывает не все потребности в очереди. Т.е. как доставка задач до воркеров - ок.
А вот планирование (как описал выше), каждая задача после выполнения, откладывается на некоторое время для повторного выполнения (определяется бизнес-логикой).
В очереди порядка 5-7 млн. задач. В день выполняется 200-300 т. задач.
Может кто-то посоветует что можно попробовать.
Основные требования: распределенная очередь (можно запускать много инстансов воркеров на разных серверах на один тип задач), приоритеты (у каждой задачи 2-3 уровня приоритета). Собственно наверно все, из важных требований.
Пока идея такая, что сделать свою очередь на postgres, с партицированием по типам задач и шардингом при необходимости. (текущая реализация не распределенная, можем запускать на один тип задач, только воркеры с одного инстанса).