Соберём решения в проверяемый проект каталога: от требований до восстановления после сбоя.
Примеры course-products используют учебную схему и товар из главы 5 «Mapping и типы полей». Разборы упражнений ниже используют отдельный публичный набор тренажёра.
- От сценария к документу
- Контракт и качество
- Итоговое задание
Соберём решения в проверяемый проект каталога: от требований до восстановления после сбоя.
Курс ориентирован на Elasticsearch 9.4.3. Разборы упражнений используют публичный набор products; остальные запросы показывают отдельные учебные индексы и могут требовать подготовки или прав, недоступных в тренажёре. Ответы сокращены, score может меняться. Для расширенных функций проверяйте лицензию и вариант развёртывания.
От сценария к документу
Запишите основные сценарии: поиск по артикулу, подбор по описанию, фильтры и сравнение предложений. Для каждого задайте ожидаемые результаты и обязательные ограничения. Затем выберите границу документа, поля для точного и полнотекстового поиска, nested-области и правила обновления. Схема должна обслуживать реальные запросы; копия реляционных таблиц не является автоматически хорошим поисковым документом.
СамопроверкаКонтракт и качество
Опишите API выдачи: допустимый ввод, обязательные фильтры, сортировки, курсор, счётчики и ошибки. Отдельно определите стратегии ранжирования и ослабления запроса. Подготовьте размеченный набор и регрессионные случаи: артикулы, отсутствующие поля, несколько offers и нулевая выдача. Введите ограничения p95, размера ответа и допустимой задержки синхронизации.
СамопроверкаИтоговое задание
Подготовьте проект каталога на миллион товаров с двумя языками и несколькими продавцами. Включите mapping с анализаторами, пять сценариев запросов, фасеты, метрики качества и план доставки обновлений. Опишите reindex при изменении анализатора, переключение aliases и восстановление из snapshot. Самопроверка: ни один fallback не ослабляет доступ; повторы не создают дубли; offers не смешиваются; качество измеряется; восстановление проверяемо. Обоснуйте каждый компромисс вместо выбора настроек «на всякий случай».
Итоговый запрос связывает кандидатов, ограничения и аналитику; его качество проверяется сценариями.
{
"size": 10,
"query": {
"bool": {
"must": [
{
"match": {
"name": "wireless headphones"
}
}
],
"filter": [
{
"term": {
"in_stock": true
}
},
{
"range": {
"price": {
"lt": 200
}
}
}
]
}
},
"aggs": {
"brands": {
"terms": {
"field": "brand",
"size": 10
}
}
},
"_source": [
"name",
"brand",
"price"
]
}Как читать результат
Итоговый запрос связывает кандидатов, ограничения и аналитику; его качество проверяется сценариями.
Разбор на примере каталога
Результат проектирования должен позволять другому разработчику воспроизвести решения: какие поля и анализаторы используются, какие ограничения обязательны, как выглядит курсор и что означает каждый счётчик. Для каждой спорной настройки запишите причину и способ проверки. Не требуйте заранее максимальной сложности: если лексический baseline проходит критерии, векторная ветвь должна доказать дополнительную пользу. Отдельно перечислите предположения о нагрузке и свежести, чтобы их изменение приводило к пересмотру соответствующих решений.
СамопроверкаСамопроверка
Сначала ответьте самостоятельно, затем раскройте объяснение.
1. С чего начать проектирование?
С пользовательских сценариев, критериев качества и ограничений.
2. Как выбрать границу документа?
По требованиям поиска и характеру обновлений, учитывая денормализацию и nested.
3. Что доказывает корректность миграции?
Догонка изменений, проверки данных и регрессии поиска до переключения.
4. Какие метрики нужны кроме NDCG?
Latency, ошибки, свежесть индекса и стоимость обработки.
5. Когда проект готов к реализации?
Когда определены контракты, компромиссы, проверки качества и процедуры отказа и восстановления.
Ситуационный разбор модуля: Современный поиск и проектирование
Заказчик хочет семантический поиск для двух языков и точный поиск по артикулам. Составьте две retrieval-ветви и план сравнения с лексическим baseline. Объясните бюджет inference, ограничения доступа и действия при недоступности модели.
Критерии самопроверки
Точный путь сохранён, гибрид проверяется по размеченным запросам, доступ одинаков во всех ветвях, определены timeout и лексический fallback, проверены deployment и лицензия.
Краткая памятка
- С пользовательских сценариев, критериев качества и ограничений.
- По требованиям поиска и характеру обновлений, учитывая денормализацию и nested.
- Догонка изменений, проверки данных и регрессии поиска до переключения.
- Latency, ошибки, свежесть индекса и стоимость обработки.
- Когда определены контракты, компромиссы, проверки качества и процедуры отказа и восстановления.
Официальная документация
Готовы применить знания?
Подтвердите прочтение, чтобы сохранить своё место. Чтение и решение заданий учитываются отдельно в этом браузере с помощью гостевой cookie.