bigbes: но речь же шла о тарантуле, а там нету многого из того, о чем Вы говорите. Я могу ошибаться, но тарантул - это всего лишь распределенное key-value хранилище.
Спасибо, думал над этим. Такой подход действительно очень сильно стимулировал бы самостоятельную работу и креативность, а также, действительно добавил бы знаний всем в той области, в которой лежит их интерес.
Но, есть несколько проблем, и если бы нам удалось их решить - то это было бы вообще круто:
Первая — неуверенность в себе, сложность выбора проекта. Не все команды смогут выбрать достойный проект, некоторым нужно будет и подсказать, а значит нужен список вариантов. А некоторые, наоборот, захотят сложные проекты, просто потому, что не могут оценить сложность.
Вторая — сложности проектных решений. Грамотно построить архитектуру нескольких проектов с самого начала будет сложно для преподавателей, но гораздо сложнее будет донести ее до студентов. Получиться, что на лекциях мы должны будем уделить внимание всем проектам и новому материалу.
Про гит — именно так и задумано, и да, питон идет первым) А вообще, на этапе питона мы придумали много интересных подходов и ставим себе целью научить думать алгоритмами и переносить решения с реальности на алгоритмы. Например сортировку собираемся показывать наглядно на мешочках с песком)
Спасибо, интересная точка зрения. О нескольких мини-проектах почему-то даже и не думали, но вот в чем проблема: есть желание оставить после курса чувство целостности, чтобы кроме знаний осталось понимание завершенности задачи. Проект должен стать для студентов чем-то вроде примера, в который можно прийти, подсмотреть реализацию, и вернуться назад к своей задаче, таким себе вводом в проф. практику.
Подход с несколькими мини-проектами очень похож на ВУЗовские ЛР, и откровенно говоря, они не очень аффективны.
@adugin, мне кажется, Вы применяете по отношению к школьнику немного строгое мерило) Простите, если такая моя мысль Вам неприятна. Я не ставлю себе целью переубедить Вас, или отписать Вам только для того, чтобы мой комментарий был последним. Если Вам кажется, что стоит начать с гугла - почему бы Вам не написать это в прямой и необидной форме, а если сможете еще и подкрепить свои рекомендации - будет даже лушче, Вам не кажется?
@rdvlip, если есть время и желание сделать хорошо — можно посмотреть в сторону wait-conditions (docs.python.org/2/library/threading.html#condition...). Это специальный механизм управления синхронизацией между несколькими потоками. Чтобы не дергать флаг об изменении конфигурации из redis'а раз в секунду, можно поставить worker'у wait-condition завязанный на объект-дескриптор из django, а сам worker усыплять на дельту времени от now() и до timestamp'а задачи. Это (потенциально) позволит уведомить worker о новой конфигурации прямо в момент ее появления и избавит Вас от цикла внутри worker'а. Естественно,
такая конфигурация предусматривает, что информация о задаче скопирована в worker из redis, тогда нет нужды вообще дергать redis до завершения задачи.
Почему я говорю "потенциально"? Я не уверен, что wait-condition из менеджера разбудит поток, ушедший по sleep'у. Есть вероятность, что worker узнает о сигнале из менеджера уже после пробуждения, а это может быть критично, если есть вероятность того, что пользователь поставит новую задачу на время раньше той, которую ожидает worker.
Для швейцарской точности можно ставить sleep на пару секунд меньше наступления события и запускать цикл с проверкой раз в несколько миллисекунд, так можно чуть-чуть нивелировать издержки планировщика задач ОС, но стоит ждать чуть большей активности CPU. Кроме этого, есть же еще и приоритеты процессов.
В любом случае, даже если делать цикл с подергиванием флага из redis со sleep'ом даже в 100мсек нагрузка на CPU будет в пределах нормы.
Описанная Вами схема подходит для этой задачи и сделана достаточно грамотно. Но все-же несколько советов есть.
Во-первых, рассмотрите вариант держать в памяти задачи на некоторый временной интервал, предположим час, или день. Все зависит от того сколько задач для демона в среднем появляется за этот период. Соотнесите это число умноженное на размер дескриптора задачи в памяти с доступной памятью и увидите сколько задач можно держать всего. Для этого я рекомендую redis. Он очень компактно расставляет данные в памяти. Так у Вас появится возможность во-первых, держать больше задач в памяти, а во-вторых, легко проверять их статус. Не нужно будет дергать БД каждый раз, дернуть redis будет быстрее и легче, даже с django. Да и посчитать расход памяти проще, там обычный ascii + небольшой overhead.
Теперь, когда есть несколько задач на интервале система упрощается. Задача worker'a сводиться к тому, чтобы взять первую задачу из очереди, определить время, когда нужно проснуться и уснуть. На сколько уснуть зависит от того, насколько вовремя нужно дернуть порт, если погрешность в минуту допустима - установите sleep на 20 секунд. И так в цикле. Если время подошло - дергаем порт, если нет - засыпаем обратно на 20 сек.
В этом же цикле можно вставить проверку на флаг того, что расписание изменилось и стоит перечитать конфигурацию. Это может быть какой-нибудь спец. ключ в редисе, который поставить из django проще простого. Redis тут хорош еще и тем, что гарантирует атомарность операций. В качестве очереди можете использовать список: redis.io/commands#list но храните в нем только id задачи, а сами задачи храните обычными ключами так вы сможете очень быстро и просто добраться к ним из джанго в любой момент без перебора списка.
По пункту 5 вроде-бы отписал)
Стоит также сказать, что то же worker может сам себе подгружать задачи из БД в redis пачкой после выполнения последней запланированной тоесть менеджеру django можно призабить на это.
Попробуйте для первого проекта взять такую задачу, предметную область которой Вы хорошо понимаете, чтобы небыло необходимости параллельно изучать еще и ее. Так Вы сможете сконцентрировать внимание на продумывании того "как сделать", а не того "что сделать". Примеры я привел для того чтобы показать на какую сложность стоит ориентироваться.
На сколько быстро Вы справитесь зависит от задачи и от Вас. С учебой, если она профильная, совмещать такие задачи возможно. С другими делами тоже) Начинайте)
@opium, у нас в универе есть преподаватель, который говорит, что может любой ЯП выучить за 2 недели. Так вот, когда он это говорит — студенты смеются, наверное, они понимают что это — невозможно. Суть ведь не в ЯП, суть в инструменте, который стоит з ЯП, но даже синтаксис за 2 недели выучить на уровне "я знаю этот ЯП" крайне проблематично.
@Sild, были б на тостере минусы - я б поставил Вам с удовольствием. Видимо Вы не в 9-м классе, а до сих пор не поняли, что перед тем как "писать" нужно иметь представление того, что делаешь. Не вижу проблем в том, что человек развернуто задал вопрос. Это свидетельствует хотя бы о том, что он подходит к этому вопросу основательно, а Вы могли бы и мимо пройти, если формат А4 Вам не под силу.
Из своего опыта скажу, что задача должна быть больше чем на 2 недели, то есть не просто 1-2 алгоритма сложных примененных в одной работе. Это должна быть целостная система, в которой можно побыть и архитектором и программистом и тестером. К примеру, какой-нибудь менеджер задач, или маленькая СУБД на 3-4 типа данных, или какой-нибудь парсер многопоточный. Не думайте, что это вам не под силу только потому, что я употребляю незнакомые слова. Главное верить). Задача должна быть в первую очередь интересной, тогда и сложности преодолеть будет проще. Удачи)
@alexyat, мне кажется, стоит быть осторожным с таким стеком технологий. Я не знаю насколько хорошо обстоят дела с objective-c на платформах отличных от mac, но точно не лучше того же С/С++ предложенного автором в самом вопросе. Я также не знаком с синтаксисом и возможностями objective-c, но думаю что производительность труда в сравнении опять же с С/С++ если и выше, то не намного и точно не покрывает возможные трудо-затраты на дальнейшее масштабирование или развертывание на хосте. Стоит также сказать, что vps на mac os это чуть-чуть экзотика. По крайней мере, у самых известных сервисов, таких как Amazon, Rackspace или даже Digital Ocean mac'ов нету.
@SabMakc, поля участвуют в запросах. Условия выборки заведомо известны на уровне логики. Сейчас трудно сказать сколько полей будет запрашиваться, но точно не все. Предполагаю, что основная часть выборки будет по 20-30 полей/запрос. Данные будут запрашиваться постоянно на протяжении приблизительно 16 часов/сутку. Мы ожидаем ~5к-6к запросов/сек.
Стоит также сказать, что записей в таблицах будет не так много - около 60к-100к на пиковых нагрузках. Именно поэтому хочется максимально задействовать кэш. Памяти у нас не очень много, да и посчитать сколько ее потребуется на данном этапе сложно (много text-полей).
Спасибо. Я знаю о декомпозиции и даже использовал это слово в заголовке, но НЛО переименовало вопрос ;) А если серьёзно, то да, мы, конечно же думаем над этим, но проблема то как раз в том, что данные эти уж слишком связаны друг с другом и в неплохом таком проценте случаев нужно будет запрашивать данные из 2з-3х таблиц. Просто хочется оптимально.
