Расписания индексирования по типам контента, которые экономят CPU

Почему одно расписание ломается

Одно расписание индексирования проваливается по простой причине: оно предполагает, что все записи меняются с одинаковой скоростью. В реальности контент так не живёт.

Вакансия, отредактированная три раза за день, и справочная статья 2021 года не должны идти по одному и тому же пути обновления. Но один глобальный таймер относится к ним так, как будто это одно и то же.

Если таймер срабатывает слишком редко, свежие записи устаревают. Цена меняется, описание товара исправляют, новая страница публикуется или товар удаляют — а поиск всё ещё показывает старую версию. Пользователи замечают быстро и обвиняют поиск.

Если таймер работает слишком часто, система тратит CPU на записи, которые едва меняются. Индексатор постоянно проверяет архивные страницы, закрытые позиции и старый контент, к которому никто не притрагивался месяцами. Эта лишняя работа не делает поиск ощутимо свежее.

Проблема усугубляется на сайтах с разным контентом. Живая инвентаризация или объявления могут меняться много раз в день. Документы, профили и посадочные страницы меняются время от времени. Архивные записи могут лежать нетронутыми месяцами.

Одно расписание не справится со всем этим хорошо. Если вы настроите его под медленный контент, свежие записи отстанут. Если под быстрый — старые данные будут жечь CPU без пользы.

Команды часто откатываются к полной переиндексации, потому что это кажется безопасным. Но это создаёт пиковую нагрузку, которой можно было бы избежать. База данных берётся в хвост, кэши крутятся, рабочие индексирования начинают конкурировать с обычным пользовательским трафиком.

Дело не в поиске как таковом. Дело в том, что используют один темп для контента, который живёт с очень разной скоростью.

Группируйте контент по частоте изменений

Лучшее расписание начинается с сортировки контента на несколько простых групп.

Первая группа — записи, которые часто меняются и важны немедленно. Это цены, остатки, слоты бронирования, живые объявления и всё, что пользователи редактируют напрямую. Когда такие записи меняются, поиск должен обновиться скоро после этого. Если поиск говорит, что товар в наличии, а на странице товара — «распродано», доверие падает быстро.

Вторая группа — контент, который меняется, но не постоянно. Статьи, справочные страницы, страницы профилей и категории часто подходят сюда. Эти записи всё ещё важны, но им не нужно то же обращение, что запасам или активным объявлениям.

Третья группа — архив. Закрытые заказы, снятые с продажи товары, старые логи и прошедшие события могут ждать дольше между обновлениями. Некоторые команды кладут их в отдельный индекс. Другие обновляют их в тихие часы. В любом случае, вывод архивной работы из горячего пути обычно сильно сокращает использование CPU.

Правила перемещения записей между группами должны оставаться простыми. Новые или недавно отредактированные элементы идут в горячую группу. Если запись долгое время не менялась — переместите её в более медленную. Завершённые, просроченные или скрытые записи — в архив. Если кто-то снова отредактировал архивную запись, верните её в горячую группу.

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

Маркетплейс наглядно показывает это. Активные объявления — в горячей группе, пока продавцы меняют цены или остатки. Страницы профилей продавцов могут сидеть в медленной группе. Проданные объявления и старые транзакционные логи — в архиве после закрытия продажи. Такое разделение сохраняет свежие результаты свежими, не заставляя индексатор проверять всё весь день.

Установите приемлемые цели свежести

Хорошая целевая задержка — это максимально долгое время, которое пользователи готовы потерпеть до того, как поиск начнёт казаться неправильным.

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

Ответ зависит от типа контента. Уровни запасов, цены и новые объявления обычно требуют узких целей, потому что ошибки стоят денег или создают обращение в поддержку. Устаревшая справочная статья раздражает, но редко причиняет такой же вред.

Больше полезной информации дают тикеты поддержки, звонки продаж и логи поиска, а не догадки. Если клиенты жалуются, что остатки отстают на 20 минут — группе нужно меньшее окно. Если никого не волнует, что старое кейс‑стади показывается с задержкой в полдня, дайте ему полдня.

Простейший набор целей может быть таким:

• Запасы, цены и критичные по времени объявления: 1–5 минут
• Новый пользовательский контент или посты маркетплейса: 5–15 минут
• Страницы товаров и категории: 30–60 минут
• Справочная документация и блоги: 4–12 часов
• Архивный контент: 1–7 дней

Эти числа работают только если соответствуют бизнес‑стоимости. Если неправильные цены или просроченные предложения приводят к потерянным продажам — обновляйте их быстрее. Если старая статья меняется раз в несколько месяцев — пусть подождёт.

Оставьте запас на плохие дни. Трафик всплески, очереди растут, задания падают. Если группа должна укладываться в 15 минут, не стройте пайплайн, который в среднем показывает 14 минут только при спокойном трафике. Цельтесь ниже, чтобы расписание переживало пиковые нагрузки.

Практическое правило — иметь одну пользовательскую цель и одну внутреннюю. Если поиск должен быть свежим в 30 минут, проектируйте пайплайн так, чтобы он завершался за 10–15. Этот буфер даёт место для ретраев, пиков и рутинного обслуживания.

Постройте пути обновления

Начните с одного чистого полного индекса. Каждая группа контента нуждается в надёжной базе перед тем, как вы начнёте настраивать частоту обновлений. Если индекс уже содержит устаревшие поля, отсутствующие записи или старые URL, более частые обновления только быстрее распространят плохие данные.

После полного прохода сохраните контрольную точку для каждой группы. Это даёт ясный старт и упрощает поиск проблем позже.

Затем разделите обновления по типам контента и скорости изменений.

Горячие записи должны идти событийно. Когда цена товара меняется или объявление редактируют, отправляйте эту отдельную запись в индекс сразу.

Обычный контент можно обновлять пакетами по расписанию. Фиксированный интервал раз в 30 или 60 минут часто достаточен для страниц, которые меняются несколько раз в день.

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

Для упавших записей сделайте отдельный путь ретраев. Переиндексируйте только то, что сломалось, с лимитами и экспоненциальным откатом. Не перезапускайте весь набор данных из‑за одной ошибки.

Отслеживайте каждый путь отдельно. Если событийные обновления застопорились, а архивные задания продолжают завершаться — вы должны видеть это сразу.

Пара простых правил делает всю систему стабильнее. Держите размеры батчей умеренными, чтобы одна медленная задача не блокировала очередь. Храните временные метки изменений, чтобы планировщик мог пропускать записи, которые не менялись. Удаляйте дубликаты обновлений, когда одна и та же страница меняется несколько раз в коротком окне.

Такой пайплайн прозрачен — и именно поэтому он работает. Он использует меньше CPU, сохраняет движение свежих результатов и легче восстанавливается, когда одна очередь отстаёт.

Простой пример из одного магазина

Возьмём интернет‑магазин с тремя типами страниц: страницы продуктов, страницы обзора (browse) и старый контент.

Страницы продуктов — в быстрой полосе. Если меняется цена или популярный товар распродают, покупатели это заметят. Магазин должен отправлять такие обновления в поиск в течение нескольких минут. Неправильная цена или устаревший запас приводят к брошенным корзинам, обращениям в поддержку и недовольным покупателям.

Страницы категорий могут идти медленнее. Страница «кроссовки для бега» или «настольные лампы» не нужна перестраиваться при каждом изменении одного товара. Обновление раз в час обычно достаточно и намного щадящее для CPU.

Старый материал может ждать. Блоги прошлого года, редкая справочная статья и снятые с продажи страницы — всё это можно обрабатывать ночным батчем. Люди всё ещё найдут их в поиске, но система перестанет тратить ресурсы на то, что почти не меняется.

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

Когда распродажа закончится — верните их на медленную дорожку. Эта маленькая переключка важнее, чем многие думают. Много расписаний терпят неудачу, потому что сезонный контент считают фиксированным, даже если бизнес ведёт себя активно.

Наблюдайте за нагрузкой до того, как она превратится в бэклог

Расписание может выглядеть нормально, пока задания индексирования не начнут накапливаться. Тогда поиск устаревает, CPU остаётся высоким, и один загруженный час перерастает в следующий.

Вам не нужен огромный стек мониторинга. Небольшая панель с несколькими показателями обычно достаточна. Следите за CPU во время индексирования, длиной очереди, временем выполнения заданий и упавшими заданиями. Эти четыре числа покажут, успеваете ли вы обрабатывать работу быстрее, чем она приходит.

Если прыгает только одно число, исправление часто простое. Если растут все четыре — вероятно, одна группа контента создаёт основную боль.

Ищите группу, создающую самые большие всплески. Обновления продуктов могут завершаться за три минуты, а перестроения архива — 25 минут и повышать CPU с 40% до 90%. Это подскажет, где настраивать в первую очередь.

Когда поиск начинает замедляться, заранее ограничьте размер батчей. Меньшие партии кажутся менее эффективными на бумаге, но обычно держат задержку запросов стабильной и снижают шторм ретраев. Батч, который заканчивается чисто, лучше гигантского батча, который тайм‑ауит и запускается заново.

Архивные запуски перенесите в тихие периоды. Люди редко заметят, если десятилетний контент дождётся позднего вечера. Зато заметят, если текущие записи перестанут появляться в выдаче.

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

Здоровое расписание не держит CPU загруженным весь день. Оно поддерживает движение свежих результатов и не даёт вчерашней работе перелиться в завтра.

Ошибки, которые тратят CPU и замедляют поиск

Самая частая ошибка — относиться к любому изменению как к чрезвычайной ситуации.

Исправление опечатки в одной записи не должно запускать полную переиндексацию всей таблицы. Это превращает мелкое обновление в тысячи или миллионы записей, лишние операции с кэшем и слияния без реальной пользы.

Ещё одна ошибка — придавать косметическим правкам тот же приоритет, что и изменениям, влияющим на деньги или доступность. Если товар распродан — поиск должен обновиться быстро. Если кто‑то поправил пунктуацию в подзаголовке — пользователи могут подождать.

Удаления создают отдельный класс проблем. Некоторые команды хорошо справляются с вставками и правками, но откладывают удаления до ночной зачистки. Мёртвые записи остаются в выдаче, пользователи кликают их, а индекс тратит место и вычислительные ресурсы на данные, которых уже не должно быть.

Большинство систем не нуждаются в тяжёлом потоке удаления. Удаляйте документ быстро или помечайте его, чтобы следующее обновление убрало его без затрагивания несвязанных записей.

Один застрявший джоб тоже может повредить всему пайплайну. Некорректная запись, тайм‑аут или упавшая зависимость не должны замораживать все последующие обновления. Тем не менее многие очереди всё ещё работают как однополосная дорога.

Пара ранних признаков опасности:

• Лаг очереди постоянно растёт при нормальном трафике
• Небольшие правки запускают те же задания, что и полные импорты
• Удалённые элементы всё ещё появляются часами
• Одна упавшая запись останавливает появление свежего контента

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

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

Проверки перед релизом

Расписание может выглядеть чисто на бумаге и всё равно провалиться под реальным трафиком. Перед запуском протестируйте те части, которые обычно ломаются в первую очередь.

Начните с обещания, которое заметят пользователи. Если товар, тикет или объявление меняются, оно должно появиться в поиске в целевом окне для горячего контента. Проведите небольшой живой тест: отредактируйте пять свежих записей, засеките время и проверьте, когда индекс отразит каждое изменение. Если одно занимает 30 секунд, а другое — 12 минут, путь ещё не стабилен.

Затем протестируйте тормоза безопасности. Архивные задания должны замедляться или приостанавливаться, когда CPU превышает лимит, иначе они вытеснят свежие обновления. Простое правило работает хорошо: если CPU держится выше вашего лимита несколько минут — приостанавливайте архивные батчи и давайте закончить горячим обновлениям.

Сократите чеклист перед релизом до ключевого:

• Измените горячую запись и подтвердите, что поиск обновился в целевом окне
• Поднимите нагрузку и подтвердите, что архивные задания приостанавливаются первыми
• Нарочно сломайте одно обновление и убедитесь, что путь ретрая работает
• Удалите запись и подтвердите, что она исчезает из индекса
• Попросите коллегу одним предложением объяснить каждое правило расписания

Последняя проверка звучит просто, но быстро ловит запутанные планы. Если команда не может сказать: «новости обновляются за 2 минуты, страницы продуктов за 15, архивы ночью», значит система, вероятно, слишком сложна в обслуживании.

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

Логика ретраев тоже важна. Одна упавшая партия не должна оставлять дыру в индексе до утра. Задание должно ретраиться, логировать причину и останавливаться после разумного лимита.

Если эти проверки проходят, у вас ещё не идеальная система. Зато у вас есть та, которой команда доверяет в обычный вторник — а это именно то, что важно.

Поддерживайте расписание в актуальном состоянии

Большинству команд подходит расписание, которое можно объяснить за минуту. Если правила помещаются на одной странице, люди их поддерживают. Если правила превращаются в кучу исключений, они деградируют, и использование CPU начинает расти.

Три группы — достаточно для первой версии: горячий контент, который часто меняется; обычный контент, который меняется время от времени; и архивный контент, который редко меняется. Это покрывает большинство сайтов.

Запустите первую версию на две недели и наблюдайте за CPU, глубиной очереди, задержкой обновлений и небольшим набором поисковых результатов, которые команда проверяет часто. Реальный трафик быстро выявит странные случаи.

После обзора удаляйте правила, которые больше не соответствуют паттернам изменения контента. Раздел, который обновлялся каждый час, может теперь меняться раз в месяц. Архивная зона может снова стать активной после перезапуска. Убирайте такие правила, прежде чем они превратятся в постоянную трату.

Также полезно назначить одного владельца расписания. Ему не нужно запускать каждую задачу вручную. Он просто должен замечать, когда нагрузка, паттерны контента или бизнес‑приоритеты меняются и инициировать обновление правил.

Если команда хочет внешний ревью, Oleg Sotnikov at oleg.is работает со стартапами и небольшими компаниями по инфраструктуре, поиску и AI-first инженерным операциям. Короткий обзор часто достаточно, чтобы найти задания, которые запускаются слишком часто, очереди, которые нужно перенести на тихие часы, или правила, которые больше никому не нужны.

Назначьте дату следующего обзора до релиза. Если у даты нет владельца, расписание устареет задолго до индекса.