LINUX.ORG.RU

А почему в очередях не делают динамические маперы чанков? Или делают?

 


1

1

Тут возникла задача ребилдить посты форума в количестве нескольких хреналионов. Причем для максимальной скорости надо ребилдить равномерными блоками.

А равномерные блоки получить не просто. Skip/limit на таких количествах откровенно лажают. Бить по датам - в начале и в конце плотность разная. Добавить к посту рандом и побить на диапазоны - можно, но будет рандомная чтение с диска, грустно.

Теоретически можно конечно в один проход сделать сразу все чанки и заправить в очередь. Но это овер дофига метаданных разом. Плюс мапер будет долго работать - неудобно.

Я вот что подумал - а почему в очередях нет такий фичи, как «map on demand»? То есть очередь время от времени дергает мапер, он смотрит количество ожидающих чанков и если остается мало, то докидывает еще. То есть в каждый конкретный момент мы не гоняем дикие объемы данных и мапер не тупит. Хитрость в том, что мапер должен запоминать последние границы, чтобы вместо skip / limit использовать gt XXX / limit.

Перед тем как лисапедить, облазил всякие celery и ничего подобного не нашел. Даже странно. Может плохо искал?

★★★★★

Речь о древовидных структурах постов, которые могут прирастать в любой ветке? Не думаю, что в этом случае вообще возможны равномерные блоки с жесткими лимитами по количеству.
Имхо, лучше шинковать по объему.

blexey ★★★★ ()
Ответ на: комментарий от blexey

Структура плоская, но очень длинная (все посты форума подряд). Ребилдить лучше примерно последовательно. Это фактически стандартная задача «разбивки на страницы», которая на больших объемах в чистом виде не разрешима и не параллелится.

Единственный способ разбить равномерно и «дешево», который я придумал - генерить чанки итератором. Нам ведь не надо сразу все чанки знать, достаточно иметь столько чтобы занять все ядра.

Фишка в том, чтобы итератор после отработки запоминал не порядковый номер, а ID поста. Тогда вместо дорогого skip будет дешевый range запрос.

У меня сейчас сделано с разбивкой по датам. Так себе - плотность постов в начале и в конце в 10 раз отличается.

Vit ★★★★★ ()
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от Vit

Можно при добавлении нового поста в любое место ветки темы сразу инкрементить количество постов для этой темы. Тогда, быстро пробежавшись по темам, достаточно дёшево будет видно границы разбивки по количеству тем/постов.

blexey ★★★★ ()
Ответ на: комментарий от blexey

Количество постов в топиках есть, но это мало что даст - во-первых собьется глобальный порядок по дате создания. Во-вторых, гиморно агрегировать данные из нескольких тем, когда не хватает. Бывает ведь много тем из одного поста

Ты зря к темам привязываешься, они на задачу не влияют. И не решают проблему как фазу мапинга сделать «быстрой».

Если мапинг долгий - при сбое понадобится рестарт с нуля. Плюс по нажатию кнопки «запустить», будет большая неприятная пауза когда не понятно программа просто тупит или рухнула.

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

Vit ★★★★★ ()

Сразу маппить в секреттер, чтобы закюринговать, и влимитить в чанк нужное количество маппетов, а уже затем посеквестить по ним, сверяясь с метаданными, и пушить. При необходимости скипить и лимитировать, но смотреть при этом на маппинг и кюрринг, то есть, осторожно.

anonymous ()

Статические обычно делают, динамические как-то не принято, не прижилось

anonymous ()

Vit возможно я скажу глупость применительно к твоему случаю, но!

Мне кажется - будь проще и всё наладится. У строителей DNS серверов был\есть похожий затык связанный с очисткой кэша. bind делал это болезненно долго. И вот однажды мужиков (помоему в pdns) так достало что они всё упростили _радикально_ ... и взлетело. Их метода отмапленная на твой случай пожалуй будет звучать так: 1) Сортируешь посты по дате 2) Нарезаешь на чанки тупо количеству постов. Ну по 10000 за проход к примеру

Имеешь: - простой колд, который работает. - предсказуемое время работы. Я бы даже сказал вычислимое ... - PROFIT

:)

anonymous ()
Ответ на: комментарий от Vit

Всю специфику твоей задачи знаешь только ты. Тебе и решать. А исходя из того, что ты о ней поведал, я подозреваю, что этого никто не делал просто потому, что в этом не возникло необходимости.

blexey ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.