Python-сообщество

django + db – srv1
redis – srv2
some app – srv3, srv4, srv5, …

Модель одна – на сайте. Больше ничего нет.

Сайте (srv1) просто интерфейс для пользователя, в базе же общая инфа. На srv3, srv4, srv5, некая софтина (далее soft) без каких либо баз (soft – библиотека, в которой через subprocess/some_libs происходит управление системой, что-то делает). И сам soft ничего в базу не пишет. Если б я мог, я б писал пару строк в базу, чтоб пользователь мог увидеть результат работы задачи – максимум false/true и на каком сервере было выполнение. Но я не очень понимаю как это сделать, ведь мне нужна структура базы (model). А городить костыли для того чтоб из soft используя чистый SQL и писать что-то в базу я не горю желанием. А там еще и отношения между моделями…

Как получать результат. Тут я думал о трех вариантах. 1 – очередь, в которую “воркеры” кидают результаты. 2 – читать результат из Redis (лучше). Для этого нужно хранить UID в базе и по нему запрашивать результат в Redis. 3 – API на сайте (жалкое подобие уже почти готово – todo: изучить django rest framework) Это лучше всего, как мне кажется.

Т.е. у меня нет каких-то огромных данных, которые я кидаю между серверами предварительно потроша базу. Отправляю dictionary, получаю dictionary, пишу в базу. В dictionary обычно от 3 до 10 параметров. И то они почти всегда зависят какую кнопку пользователь нажимает на сайте.

И я вижу что Ваш опыт разработки в этой среде выше моего. И Вы упомянули про Alchemy. Я же ничего кроме django ORM не использую, что видимо меня и ограничивает в некоторых телодвижения.

Фактически из всего что я сделал осталось реализовать только получение данных от ворверов (скорее всего для этого буду использовать 2 вариант, а когда “подрасту” 3).

4kpt_IV
Для обмена данными между “задающим задачу” и “выполняющим задачу” должна быть очередь.

Что из себя представляет очередь? Использовать RabbitMQ?

Можно и кролика. Есть и другие варианты. Мне больше по-душе beanstalkd.

k0st1an
Т.е. у меня нет каких-то огромных данных, которые я кидаю между серверами предварительно потроша базу. Отправляю dictionary, получаю dictionary, пишу в базу. В dictionary обычно от 3 до 10 параметров. И то они почти всегда зависят какую кнопку пользователь нажимает на сайте.

Это пока нет И я просто привел пример костыльности использования RQ в качестве очереди.

k0st1an
Как получать результат. Тут я думал о трех вариантах. 1 – очередь, в которую “воркеры” кидают результаты. 2 – читать результат из Redis (лучше). Для этого нужно хранить UID в базе и по нему запрашивать результат в Redis. 3 – API на сайте (жалкое подобие уже почти готово – todo: изучить django rest framework) Это лучше всего, как мне кажется.

1. Еще одна очередь? А на “упавшие” задачи еще одну можно примастырить
2. RQ результаты пишет в редис, это да. Но в этом случае нужно реализовывать “чтеца” со стороны сервера…
3. Если правильно организовать очередь, то можно обойтись только ей. Хотя вариант с json реализуется проще всего

k0st1an
И Вы упомянули про Alchemy. Я же ничего кроме django ORM не использую, что видимо меня и ограничивает в некоторых телодвижения.

Аналог Django ORM. Получше но и посложнее. С джангой не дружит, если что. Используется на всех других вебфреймверках: pylons, pyramid, flask, bottle и т.п.

4kpt_IV
Мне больше по-душе beanstalkd

Ок, гляну. Встречал недавно. RabbitMQ – круто, но гораздо больше кода писать, который я пока не готов отлаживать ввиду сроков.

4kpt_IV
Но в этом случае нужно реализовывать “чтеца” со стороны сервера…

Именно по этому этот вариант мне не очень нравится.

4kpt_IV
Аналог Django ORM.

Несколько раз пытался найти инфу как подружить, но всё костыли, причем очень жуткие. А потом еще и поддерживать это…

k0st1an
Несколько раз пытался найти инфу как подружить, но всё костыли, причем очень жуткие. А потом еще и поддерживать это…

Так и не надо поддерживать. Эта штука для тех, кто не пользуется django Или Вы думаете, что на джанго весь мир клином сошелся?

Я Вам советовал реализацию не потому, что использую джанго (кстати, к очереди, вроде, есть плагин для джанги) а потому, что интенсивно использую RQ. Крайне удачная вещь, хоть и не для Вашей задачи…

4kpt_IV
Так и не надо поддерживать. Эта штука для тех, кто не пользуется django

Да это давно было…

Посмотрел beanstalkd, что опечалило:

• задания висят до тех пор пока сам их не удалишь.
  

Опасно тем, что кто-то другой может подобрать задание. А в целом шустрый и очень простой. Подумаю еще, мне нужно чтоб можно было держать несколько очередей. Надо опять глянуть RabbitMQ, он блокирует задание и ожидает его выполнения… не отдаст задание пока не выйдут сроки, вроде так.

Отредактировано k0st1an (Фев. 10, 2016 22:15:04)

k0st1an
Опасно тем, что кто-то другой может подобрать задание.

Кто? Если у Вас один проверяющий? Ставьте его на блок сами. С кроля тоже может привалить несколько заданий, так что не питайте иллюзий.

k0st1an
Да это давно было…

Не понял, если честно

4kpt_IV
Не понял, если честно

Ну, как алхимию прикрутить к django.

4kpt_IV
Кто? Если у Вас один проверяющий? Ставьте его на блок сами. С кроля тоже может привалить несколько заданий, так что не питайте иллюзий.

Это уже отредактированное сообщение. Я когда смотрел описание либы для работы с beanstalkd не увидел сходу как создать несколько очередей и не было ничего сказано про блокировку задания. Потом увидел ссылку на оригинальную библиотеку и там уже все было описано как надо. Там и peek() и stats() и stats_tube(). Осталось это все обмозговать.

k0st1an
Ну, как алхимию прикрутить к django.

Еще раз. Алхимия не для джанги. Не надо ее прикручивать. Никто же не додумывается к ПХП прикручивать питон Алхимия это антиджанга, как-бы. Именно с использование алхимии и начался мой переход с джанги. Если Вам нравится алхимия, то нужно задуматься нужна ли джанга. Но это лирика.

По Вашему вопросу. Выбирайте любою очередь и вперед. Написать механизм блокировки на уровне изменения названия задания, я думаю, даже для начинающего питониста не будет проблемой. И вообще нужно привыкать ручками, ручками И архитектуру выучите и дополнительные возможности, которые Вам требуются в проекте, сможете реализовать. А то, что первое время будет получаться что-то страшное - не важно. Все равно, через 3 года Вы на свой старый код смотреть не сможете…

P.S. И я не думаю, что архитектурно получится хуже, чем использование таск-менеджера для передачи данных между сервисами

4kpt_IV
Еще раз. Алхимия не для джанги.

Я как роз про это и понял тогда

А в целом да, практика решает всё.

Еще один вопрос. Из нашей дискуссии я не понял одного, не уловил разницу между Celery/RedisQ и вместо RabbitMQ/Beanstalkd будем думать о всяких либах, которые дают работать с RabbitMQ/Beanstalkd. Потому как либы и Celery/RedisQ единственное что можно сравнивать. Абстрагируемся от функционала, возьмём просто принцип. Celery/RedisQ и либы дают один функционал, один результат. И разницу уловить не могу . Celery/RedisQ даже своих воркеров дают, только строчи код для своих задач.

k0st1an
Celery/RedisQ и либы дают один функционал, один результат. И разницу уловить не могу . Celery/RedisQ даже своих воркеров дают, только строчи код для своих задач.

Если из всех моих объяснений Вы не поняли, в чем между ними разница и почему использование RQ/Celery в качестве очереди - это как микроскопом забивать гвозди, то используйте их. Мне уже надоело, если честно. Удачи.