Сделай сам веб-сервис с асинхронными очередями и параллельным исполнением

[AndersonDunai]

А каково оно в сравнении, скажем, с Celery?

[sergeypid]

Celery больше функций, но она сложнее. Rq позволяет с минимальными затратами времени реализовать рабочее решение, Здесь очень хорошо описаны Про и Контра celery vs. rq, перевожу кратко:

• Документация RQ полная и простая. Документация Celery сложнее для восприятия, хотя тоже подробная.
• Средства мониторинга Celery и RQ легко устанавливаются и оба хороши.
• Поддержка брокеров очередей: у RQ только Redis, Celery выигрывает (Redis, RabbitMQ). Redis, а значит RQ не гарантирует доставку 100% сообщений.
• Приоритетные очереди. Подходы разные, но оба работают.
• Операционные системы. RQ только unix-подобные (fork), Celery побеждает.
• Языки программирования. RQ только Python, Celery позволяет слать сообщения из одного языка другому (сорри).
• API. Celery гибче, RQ проще.
• Celery поддерживает подзадания, RQ — неизвестно (мне тоже неизвестно).
• Сообщество. Celery активнее, но оба проекта вполне активны.

У всех нас ограничено место в голове, поэтому если организация асинхронных очередей заданий для вас не основная работа, то RQ позволяет легко и просто построить качественное решение, за которое не будет стыдно. Celery конечно круче.

[Toshiro]

Статья любопытная, не знал про RQ. За статью — 5!) Но надо было остановиться после краткого сравнения.

Вот не надо опять про какие то там мистические ограничения в голове и особенно про «у всех нас».

Ограничения в голове только у всех вас, а за всех нас говорить нехорошо. Была бы карма, влепил бы комменту минус((

[kolyaflash]

> sudo pip install flask

Дальше не читал.

[sergeypid]

А как же бывшая?

[sergeypid]

Це по мови як мене в дитячому садочку клыкалы

[bestfriend]

helloworld.py

[zoonim116]

Для большей гибкости деплоя проекта, лучше изпользовать virtual env, а не ставить пакеты глобально.

[Realmixer]

При чём здесь классификация картинок? Это отдельная тема. Дядя же ясно написал:

Естественно, его применение не ограничивается этими вашими нейронными сетями.

Смысл статьи в построении системы выполнения сравнительно длительных заданий. Вместо классификации картинок сервис может их ресайзить, например.

[r66qq3Ek]

Это тянет на enterprise или все такие вариант прототипирования?
Формально такой функционал можно стандартными http.server и threading уложить строк в 30.

[sergeypid]

Enterprise конечно звучит гордо применительно к open-source но это конечно более устойчивое решение чем http.server и threading.
Пространство HTTPD полностью отделено от потоков «тяжелых» задач, есть средства контроля приоритета и мониторинга для админов.

[mrgloom]

Скорее всего мне нужен так называемый data orchestration framework, но всё равно спрошу.

Есть ли возможность подключить несколько серверов разных конфигураций?
Есть возможность задавать разные типы тасков и разные типы воркеров?
Есть ли возможность запускать задачи которые описаны через directed acyclic graph? В этой связи больше интересует запуск с места в графе где задача зафейлилась.
Как это всё дебажить и мониторить(хотелось бы что то типа дашборда с метриками и т.д.)?

[sergeypid]

RQ работает на одном сервере (насколько мне известно). Вашему списку требований удовлетворяет, например, Akka.

[mrgloom]

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

А так мы пробовали https://github.com/apache/incubator-airflow на том же celery, но как то это всё сложно и непонятно как дебажить.