Реиндексация без простоев: как AACSearch сохраняет поиск живым при изменениях схемы

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

Хорошего выхода нет — если только вы не построили реиндексацию без простоев на основе алиасов. AACSearch именно это и сделал. Вот как это работает изнутри.

Проблема традиционной реиндексации

У поискового индекса есть схема: имена полей, типы, стратегии индексирования и конфигурации сортировки. Когда схему нужно изменить — добавить поле, сменить тип, обновить настройки фасетов — AACSearch (как и большинство поисковых движков) требует удалить коллекцию и создать её заново.

Наивный подход:

1. Удалить существующую коллекцию
2. Создать новую с обновлённой схемой
3. Переимпортировать все документы
4. Обновить приложение, чтобы оно указывало на новую коллекцию

Шаг 3 — это проблема. Для каталога из миллиона документов это занимает 5–15 минут. Всё это время поиск либо не возвращает никаких результатов (коллекция удалена), либо отдаёт устаревшие данные из старой схемы.

Решение: версионированные коллекции + атомарная смена алиаса

AACSearch использует паттерн, позаимствованный из blue-green деплойментов баз данных: версионированные коллекции с уровнем алиасов.

Каждый поисковый индекс в AACSearch соответствует коллекции AACSearch с именем:

{orgShortId}_{indexSlug}_v{version}

Например, abc123_products_v1.

Когда в организации создаётся индекс с именем products, AACSearch создаёт:

• Коллекцию: abc123_products_v1
• Алиас: abc123_products → abc123_products_v1

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

Процесс реиндексации

Когда запускается реиндексация (через дашборд или API), происходит следующее:

Шаг 1: Создание новой коллекции

AACSearch создаёт abc123_products_v2 с обновлённой схемой. Существующая abc123_products_v1 остаётся нетронутой. Поиск продолжает обслуживаться из v1 через алиас.

Шаг 2: Наполнение новой коллекции

Все документы из буфера инджеста потоком передаются в v2. Для каталога из 500 000 документов это занимает 2–4 минуты. Всё это время приложение по-прежнему запрашивает v1 — поиск работает и возвращает актуальные результаты.

Шаг 3: Верификация

Перед сменой алиаса AACSearch выполняет шаг проверки: убеждается, что v2 получила не меньше ожидаемого количества документов (с допуском 5% для учёта удалений, произошедших с момента начала реиндексации). Если верификация не проходит — из-за ошибки инджеста или сетевой проблемы — реиндексация прерывается, и v1 остаётся активной. Никакого простоя, никаких частичных данных.

Шаг 4: Атомарная смена алиаса

После успешной верификации AACSearch атомарно переключает алиас:

abc123_products → abc123_products_v2

С этого момента все новые поисковые запросы идут в v2. Переключение занимает микросекунды — не существует момента, когда алиас ни на что не указывает.

Шаг 5: Очистка

v1 сохраняется в течение настраиваемого периода хранения (по умолчанию: до следующей успешной реиндексации). Это мгновенная точка отката: если с v2 что-то пошло не так, можно вручную переключить алиас обратно на v1 без необходимости в новой полной реиндексации.

Что запускает реиндексацию

В AACSearch реиндексацию запускают три события:

Изменения схемы: Когда вы обновляете схему индекса (добавляете поле, меняете конфигурацию фасетов, обновляете веса поиска), для применения изменений к существующим документам требуется реиндексация. AACSearch ставит её в очередь автоматически.

Ручная реиндексация: Реиндексацию можно запустить вручную из дашборда (Индекс → Реиндексировать) или через API. Полезно, когда вы внесли массовые изменения в каталог товаров и хотите пересчитать ранжирование с обновлёнными весами.

Реиндексация, инициированная коннектором: Когда CMS-коннектор выполняет полную синхронизацию и количество документов существенно меняется (>20% от текущей коллекции), AACSearch может автоматически запустить реиндексацию для обеспечения согласованности.

Инджест во время реиндексации

Важная деталь для высоконагруженных магазинов: что происходит с новыми обновлениями товаров, пока идёт реиндексация?

AACSearch использует буфер инджеста с подходом DB-first. Когда вы отправляете документ в AACSearch (через коннектор или API), он сначала записывается в очередь PostgreSQL. Фоновый воркер затем обрабатывает очередь и отправляет документы в AACSearch.

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

Сценарий отката

Что если после смены алиаса что-то пошло не так? Возможно, в v2 есть баг схемы, который проявляется только на определённых запросах.

Поскольку v1 сохраняется, откат выполняется быстро:

1. Обнаружить проблему (через аналитику, частоту ошибок или ручную проверку)
2. Переключить алиас обратно: abc123_products → abc123_products_v1
3. Исправить проблему схемы в v2
4. Запустить реиндексацию заново, чтобы создать v3 и перейти вперёд

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

Как запустить реиндексацию через API

Если вы автоматизируете деплойменты и хотите запускать реиндексацию программно:

curl -X POST https://app.AACSearch.com/api/rpc/search.reindex \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "indexId": "YOUR_INDEX_ID" }'

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

Итог

Реиндексация без простоев — не магия. Это закономерный результат разделения логического имени (алиаса) и физической коллекции. AACSearch берёт всё это на себя автоматически, чтобы вам не приходилось об этом думать:

• Изменения схемы → реиндексация запускается автоматически
• Реиндексация выполняется в новой версионированной коллекции
• Алиас атомарно переключается по готовности
• Старая версия сохраняется для отката
• Инджест продолжается во время реиндексации без потери данных

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