Как ускорили поиск жильцов в админ-панели PDP Mobile через Elasticsearch
В PDP Mobile вынесли полнотекстовый поиск пользователей в Elasticsearch: SQL начал тормозить на десятках тысяч жильцов в нескольких ЖК. Параллельно разложили DevFeedbacks по категориям.
«Почему я ввожу жильца, а админка думает дольше, чем я ищу его в списке глазами?»
Такой вопрос неприятно слышать, когда речь не про редкий отчёт, а про базовую операцию в админ-панели УК. В PDP Mobile администраторы ищут пользователей постоянно: по жильцам, помещениям, привязкам, обращениям. Пока данных немного, SQL-запросы живут спокойно. Когда в системе уже десятки тысяч жильцов в нескольких ЖК, поиск начинает упираться в то, что база хорошо хранит транзакционные данные, но не любит изображать быстрый полнотекстовый движок.
Мы вынесли пользовательский поиск в Elasticsearch. Не для красоты архитектуры, а потому что админский сценарий стал слишком чувствительным к задержке: оператор вводит строку, ждёт результат и теряет темп работы.
Где SQL перестал быть удобным
Поиск пользователей в УК редко выглядит как аккуратный фильтр по одному полю. В реальной админке вводят фрагмент имени, телефона, адреса, помещения или ещё что-то из того, что есть у диспетчера перед глазами. Данные при этом размазаны по домам, корпусам, помещениям и связям с жильцами.
SQL можно заставить искать по нескольким полям. Можно добавить индексы. Можно переписать запросы. Но в нашем случае объём уже был на уровне десятков тысяч жильцов, причём не в одном доме, а в нескольких ЖК. Для админ-панели это стало заметно: поиск перестал быть мгновенной вспомогательной функцией и превратился в отдельное ожидание.
Решение было прагматичным: оставить данные там, где они живут, а быстрый полнотекстовый поиск пользователей отдать Elasticsearch. Для оператора меняется только ощущение от формы поиска. Для разработки — появляется отдельный контур, за которым надо следить: индекс, обновления, соответствие результатов данным в основной системе.
Что отдали Elasticsearch
В Elasticsearch ушла задача быстрого поиска пользователей в админ-панели УК. Это важное ограничение. Мы не переносили туда бизнес-логику и не пытались сделать из поискового индекса новую основную базу.
Индекс нужен для ответа на вопрос: «какие пользователи подходят под введённую строку?» Дальше админка уже может открыть карточку и работать с данными в привычном сценарии.
Самый полезный спор был не про сам Elasticsearch. С ним как раз всё понятно: если нужен быстрый полнотекстовый поиск по большому набору сущностей, инструмент подходит. Спорили о границе ответственности. Где поиск, а где точные фильтры? Что показывать, если пользователь найден по связанному помещению? Как не превратить индекс в склад всего подряд?
На таких местах легко разогнаться и начать индексировать все сущности «на будущее». Мы старались держаться исходной боли: администратору нужен быстрый поиск жильцов. Чем уже назначение индекса, тем проще потом объяснять странные результаты и чинить рассинхрон.
DevFeedbacks как отдельный сигнал
Рядом с поиском всплыл второй слой задачи — обратная связь от пользователей. В PDP Mobile она собирается как DevFeedbacks, и мы начали раскладывать её по категориям:
- начисления;
- ИПУ;
- платежи;
- помещения;
- жильцы.
Это не про скорость запроса, а про приоритизацию доработок. Когда обратная связь лежит одной кучей, сложно понять, где чаще болит: в оплатах, в показаниях счётчиков или в карточках помещений. Категории дают хотя бы рабочую опору для разбора.
Связь с поиском тут прямая, хотя не техническая. Админ-панель — место, где проблемы данных становятся видимыми. Если пользователь не находится, найден не тот жилец или непонятно, к какому помещению он относится, это быстро превращается в обращение. Поэтому ускорение поиска и классификация DevFeedbacks оказались частями одной истории: меньше гадания при работе с жильцами и понятнее очередь исправлений.
Вопрос к тем, кто делал админский поиск
У нас решение получилось таким: для десятков тысяч жильцов в нескольких ЖК полнотекстовый поиск пользователей вынесли в Elasticsearch, а обратную связь начали раскладывать по категориям, чтобы видеть, какие зоны продукта требуют внимания.
Остался вопрос, где проходит правильная граница. Elasticsearch хорошо ускоряет поиск, но добавляет индекс как отдельную сущность: его нужно обновлять, проверять и не перегружать лишними данными.
Как вы решаете похожий сценарий в админках: до какого объёма и сложности держите поиск на SQL, а в какой момент выносите его в Elasticsearch или другой поисковый движок?