Настройка Elasticsearch для пошуку в мобільному додатку
Нативний пошук по базі даних через LIKE '%query%' не працює для продукту з більш, ніж кількома тисячами записів: повільно, немає релевантності, немає підсвітки збігів, немає повнотекстового пошуку з морфологією. Elasticsearch вирішує всі ці проблеми, але вимагає правильної настройки на стороні сервера та грамотної інтеграції в мобільному клієнті.
Архітектура: мобільний додаток не звертається до ES напрямку
Головне правило: мобільний клієнт ніколи не робить запити напрямку до Elasticsearch. Завжди через backend API. Причини — безпека (не розкривати структуру індексу та облікові дані), можливість кешування на сервері, контроль навантаження.
Типова схема: мобільний додаток → GET /api/search?q=кроссовки&category=sport&page=1 → Laravel/Node backend → Elasticsearch → відповідь з пагінацією та метаданими.
Настройка індексу
Для російськомовного контенту обов'язковий аналізатор з морфологією. Використовуємо плагін analysis-morphology (від Артефакту) або analysis-russian (вбудований в ES). Без морфології пошук "кроссовки" не знайде "кроссовок" або "кроссовка".
Приклад маппінгу поля з російським аналізатором:
{
"mappings": {
"properties": {
"name": {
"type": "text",
"analyzer": "russian",
"fields": {
"keyword": { "type": "keyword" }
}
}
}
}
}
Поле keyword потрібно для сортування та агрегацій — text для цього не підходить.
Що важливо для мобільного UX
Підказки при вводі (autocomplete). Реалізуємо через completion suggester або search_as_you_type тип поля. Другий простіший у настройці та добре працює для коротких запитів:
"title": {
"type": "search_as_you_type"
}
Запити йдуть при кожній зміні поля з debounce 300ms. Показуємо не більше 5-7 підказок.
Фасетний пошук (фільтри). Агрегації ES дозволяють отримувати кількість товарів у кожній категорії/бренді одним запитом. В мобільному додатку це нижній шіт з фільтрами — значення чипів оновлюються при кожній зміні фільтра без повторного запиту (використовуємо cached aggregations).
Релевантність та ранжування. function_score запит дозволяє підвищити рейтинг нових товарів, товарів з високим рейтингом або персоналізованих результатів. Для e-commerce типова формула: базовий текстовий score × boost за популярність × decay-функція по даті.
Пагінація. Стандартний from/size працює тільки до 10 000 результатів (обмеження index.max_result_window). Для курсорної пагінації використовуємо search_after з sort по унікальному полю. В мобільному додатку це нескінченний скролл без кнопки "наступна сторінка".
Офлайн-пошук
ES вимагає мережевого підключення. Для базового офлайн-пошуку: кешуємо останні результати в SQLite, пошук по кешу через FTS5 (CREATE VIRTUAL TABLE ... USING fts5). Якість гірша, але працює без мережі.
Моніторинг та продуктивність
Повільні запити до ES (більше 500ms) потрібно логувати. На сервері включаємо slowlog — ES сам пише в лог запити довше порога. В мобільному додатку відображаємо skeleton-заглушки поки йде пошук, та показуємо "Пошук займає більше часу, ніж зазвичай" якщо запит не вернувся за 3 секунди.
Терміни: настройка індексу ES з російською морфологією, інтеграція search API та базовий UI пошуку — 1-2 тижні. Фасетний пошук, автодповнення та офлайн-кеш — 3-4 тижні.







