Есть мастер процесс и он получает некоторую задачу: список элементов, размер пачки, Кол-во обработчиков.
Мастер процесс вычитывает данные в память (все сразу или дочитывает их в процессе ), разбивает их на пачки, отдает по одной пачке каждому обработчику и ждёт окончания выполнения И ожидается результат обработки от воркера, т к могут быть обработаны не все элементы пачки, но требуется продолжать работу или попытаться отдать пачку на обработку другому воркеру снова, помечает обработанные пачки . Затем мастер-процесс снова отправляет пачки освободившимся обработчикам для загрузки. То есть обработчики(воркеры) получают новые задания по мере их освобождения. Алгоритм общий, поэтому нет специфики конкретной задачи. Для оптимизации можно попытаться группировать элементы для выравнивания тяжести пачек, но это скажется на порядке обработки, что не всегда нужно.
Если есть одна огромная таблица, которую надо обработать, то ее вычитывать сразу нет надобности и она партиционируется по PK. Далее наш мастер процесс распределяет пачки айдишников, а воркеры обрабатывают записи и получают новые данные по мере обработки.
То есть когда делается массовая обработка вся нагрузка распределяется не сразу по воркерам, а по мере их освобождения, с учётом возможной повторной обработки элементов из-за временных ошибок. На начальном этапе также может быть либо слишком трудоёмко рассчитывать перформанс по обработке каждого элемента, либо не возможно.
Это реализация пуш-модели(оркестрационной) с точкой отказа в виде мастера.
В яндекс-картах при поиске обращаю внимание на рейтинг заведения(например, кафе), который не персонализированный, а некий групповой. Разве не логично, если запросы и пользователи часто спрашивают по одной и той же тематике, то отнести их к этой группе и воспринимать рекомендации от таких пользователей как компетентный? Возможно, это поможет снизить затраты на асессоров по этой теме.
Какие конкретно искаженные или ложные сведения из учебной программы СССР имеются ввиду? Есть пруфы?
У нас было реализовано по-другому.
Есть мастер процесс и он получает некоторую задачу: список элементов, размер пачки, Кол-во обработчиков.
Мастер процесс вычитывает данные в память (все сразу или дочитывает их в процессе ), разбивает их на пачки, отдает по одной пачке каждому обработчику и ждёт окончания выполнения И ожидается результат обработки от воркера, т к могут быть обработаны не все элементы пачки, но требуется продолжать работу или попытаться отдать пачку на обработку другому воркеру снова, помечает обработанные пачки . Затем мастер-процесс снова отправляет пачки освободившимся обработчикам для загрузки. То есть обработчики(воркеры) получают новые задания по мере их освобождения. Алгоритм общий, поэтому нет специфики конкретной задачи. Для оптимизации можно попытаться группировать элементы для выравнивания тяжести пачек, но это скажется на порядке обработки, что не всегда нужно.
Если есть одна огромная таблица, которую надо обработать, то ее вычитывать сразу нет надобности и она партиционируется по PK. Далее наш мастер процесс распределяет пачки айдишников, а воркеры обрабатывают записи и получают новые данные по мере обработки.
То есть когда делается массовая обработка вся нагрузка распределяется не сразу по воркерам, а по мере их освобождения, с учётом возможной повторной обработки элементов из-за временных ошибок. На начальном этапе также может быть либо слишком трудоёмко рассчитывать перформанс по обработке каждого элемента, либо не возможно.
Это реализация пуш-модели(оркестрационной) с точкой отказа в виде мастера.
В яндекс-картах при поиске обращаю внимание на рейтинг заведения(например, кафе), который не персонализированный, а некий групповой. Разве не логично, если запросы и пользователи часто спрашивают по одной и той же тематике, то отнести их к этой группе и воспринимать рекомендации от таких пользователей как компетентный? Возможно, это поможет снизить затраты на асессоров по этой теме.