В Low-code приложениях время отклика интерфейса при выборке данных свыше 50 000 записей часто вырастает с 200 мс до 10-15 секунд из-за неэффективных фильтров. Основная проблема не в объеме БД, а в том, как платформа генерирует SQL-запрос, превращая простые визуальные фильтры в тяжелые Full Table Scan.
Ловушка визуальных фильтров и Client-side фильтрации
Многие Low-code платформы по умолчанию используют клиентскую фильтрацию: приложение выгружает весь массив данных (например, 20 МБ JSON) в браузер, а затем скрывает лишние строки. При объеме данных более 5 000 строк задержка отрисовки (Rendering Lag) достигает 3-5 секунд, что делает интерфейс нерабочим.
Кейс: в CRM-системе на Low-code при попытке отфильтровать 10 000 сделок по статусу «В работе» через клиентский фильтр, потребление RAM вкладкой браузера прыгало до 1.2 ГБ, вызывая зависание страницы. Переход на Server-side фильтрацию (фильтрация на уровне БД) сократил время отклика до 400 мс.
Экспертный вывод: Любая выборка, где потенциальный результат превышает 500 записей, должна быть строго серверной. Использование клиентских фильтров на больших объемах — критическая архитектурная ошибка.
Влияние сложности фильтров на Execution Plan
Сложность фильтрации в Low-code часто растет экспоненциально: добавление одного условия «ИЛИ» или поиск по части строки (%текст%) может увеличить время выполнения запроса с 100 мс до 4 секунд. Это происходит из-за того, что визуальные конструкторы часто генерируют неоптимальные вложенные подзапросы (Subqueries) вместо простых JOIN.
На практике использование фильтра по текстовому полю без индекса на таблице из 100 000 строк замедляет ответ сервера в 15-20 раз. Если в системе реализована разработка приложений на Low-code: системный подход к управлению данными и проектированию БД, то индексы должны быть расставлены по всем полям, участвующим в частотных фильтрах.
Экспертный вывод: Избегайте фильтров типа «содержит» (LIKE '%...%') в начале строки, так как они игнорируют индексы. Используйте полнотекстовый поиск или жесткие фильтры по категориям.
Сортировки и проблема «тяжелых» полей
Сортировка по вычисляемым полям (Virtual Columns) — главный «убийца» производительности. Когда Low-code платформа считает значение «на лету» для каждой строки перед сортировкой, нагрузка на CPU сервера возрастает на 300-500%. Сортировка 10 000 строк по обычному ID занимает 50 мс, а по вычисляемой сумме заказов — до 3 секунд.
Пример: в финансовом модуле сортировка по полю «Текущий баланс» (сумма всех транзакций клиента) приводила к таймауту запроса (Gateway Timeout 504) при росте базы до 200 000 записей. Решение — денормализация данных: создание физического поля «Баланс», которое обновляется триггером при каждой транзакции.
Экспертный вывод: Никогда не сортируйте данные по виртуальным полям. Переносите расчеты в физическую таблицу или используйте материализованные представления.
Методы оптимизации: пагинация и ленивая загрузка
Передача всех данных в один запрос — путь к краху системы. Внедрение Offset-пагинации (по 50 записей на страницу) снижает нагрузку на сеть на 90-95%. Однако при очень больших смещениях (например, переход на 1000-ю страницу) скорость падает, так как БД все равно сканирует предыдущие записи.
Эффективнее использовать Cursor-based пагинацию (фильтрация по последнему ID полученной записи). Это сокращает время отклика с 2 секунд до 150 мс независимо от глубины пролистывания. В связке с этим важна синхронизация данных при разработке приложений на Low-code: стратегии работы с дублями и конфликтами версий, чтобы пользователь не видел одну и ту же запись дважды при перелистывании из-за новых вставок в БД.
Экспертный вывод: Для интерфейсов с бесконечным скроллом или глубокой пагинацией используйте только Cursor-based подход. Классический Offset допустим только для маленьких таблиц (до 10 000 строк).
Вывод
Для обеспечения высокой скорости интерфейса в Low-code необходимо полностью отказаться от клиентской фильтрации и сортировки по вычисляемым полям. Начинать оптимизацию следует с анализа Execution Plan запросов и внедрения физических индексов по ключевым фильтрам. Мой выбор: строгая Server-side пагинация на курсорах и денормализация данных для всех полей, по которым требуется сортировка. Избегайте «удобных» визуальных фильтров, которые создают сложные вложенные запросы — лучше переписать их на чистый SQL-вид (View) на стороне БД.