Обзор миграции

Большинство миграций в AACsearch имеют одинаковую форму: выгрузить данные, отмаппить схему под коллекцию в стиле Typesense, переиграть документы в AACsearch, переключить read-путь приложения и вывести старый стек. Специфика по источнику — в отдельных гайдах; они фокусируются на риске cutover.

Эта страница — точка старта. Выберите гайд по своему источнику, в день переключения прогоните чек-лист, а guide по источнику закрывает остальное.

Выберите стартовую точку

Если источника нет в списке, Database search — самый общий шаблон: извлечь, описать схему, ingest, валидировать.

Что одинаково для всех миграций

Независимо от источника, вы будете:

1. Маппить схему. Имена полей, типы, что ищем (query_by), что фильтруем, что сортируем.
2. Выгружать документы. NDJSON или CSV. Большинство источников отдают напрямую; для SQL — запрос.
3. Выбирать модель арендатора. Один индекс на org или per-tenant — определяется объёмом и требованиями изоляции. См. Изоляция арендаторов.
4. Переигрывать в AACsearch. Через ingest-buffer. Буфер впитывает объём и аккуратно делает back-pressure — пейсить не нужно.
5. Валидировать. Сэмплинг запросов. Сравнение top-N до и после. См. Валидация.
6. Переключаться. Клиент идёт в AACsearch. Старый держим тёплым минимум 7 дней — на откат.

Что меняется

Почти всегда нужно перенастроить:

Ранжирование

У каждого движка свои дефолты. Самые частые сюрпризы:

• Веса полей. Algolia/Elasticsearch разрешают давать title больше веса, чем description; AACsearch — через query_by_weights. Перетюньте; не ждите, что старые веса перенесутся.
• Boost-правила. Time decay, popularity — перекодируйте в sort_by.
• Stop words и стемминг. У каждого свои. Сделайте корпус «такой запрос возвращал X» и правьте курациями.

Поведение токенизатора

Дефолтный токенизатор Typesense годен для общего текста, но отличается от Elasticsearch-анализаторов, которые сильно конфигурируемы. Заложите спринт валидации против реального query-лога, не синтетики.

Валидация

Соберите 100 представительных запросов из аналитики. По каждому сравните top-5 до и после. Классификация:

• Identical — top-5 совпадает, может в другом порядке.
• Mostly same — 3+ из top-5 совпадают.
• Drift — меньше 3 совпадений.

Drift-кейсы — это места, куда уходят усилия на тюнинг. Часть — баги миграции (поле не отмапилось), часть — улучшения (новый движок ранжирует лучше), часть — требуют курации.

Не пропускайте этот шаг. Миграция без query-level валидации — это путь к фидбеку «поиск стал хуже после миграции», который вы не сможете опровергнуть.

Модели cutover

Два паттерна. Выбирайте по толерантности к риску.

Dark-launch и потом flip

1. Индексируете в AACsearch параллельно с существующим.
2. Зеркалите запросы в оба, логируете результаты.
3. Сравниваете в течение какого-то времени (день, неделя).
4. Flip read-трафика в AACsearch.
5. Старый держим читающим 7 дней.

Ниже риск, больше инженерных усилий.

Cutover с окном отката

1. Индексируете в AACsearch.
2. Валидация по 100-query сэмплу.
3. Flip в тихое окно.
4. Старый — горячий fallback 7 дней.
5. После окна выключаете путь отката.

Меньше инженерии, больше дисциплины на деплое. Подходит, когда поиск не на критическом revenue-пути.

Чего мы не делаем

• Автоматизированную end-to-end миграцию. Нет тулзы «дай мне креды Algolia и получи работающий индекс AACsearch». Схема, ранжирование, курации — слишком проектно-специфичны.
• Не обещаем «drop-in replacement». Движки разные. Закладывайте 1–2 недели пост-миграционного тюнинга на нетривиальный корпус.
• Не мигрируем код приложения за вас. SDK есть — см. SDKs; основные клиентские паттерны — в гайдах по источникам, но рефакторинг клиента — на вас.

См. также

• Чек-лист миграции — dry run, валидация, cutover, откат
• Реиндексирование — для пост-миграционных изменений схемы
• Изоляция арендаторов — решите модель до миграции, не после