Ускорение запроса

Требовалось сократить время выполнения тяжёлого статистического отчёта без рискованных изменений в критичной внешней системе.

Задача

Ускорить построение статистического отчёта: максимальное количество одновременных конференций с разбивкой по дням.

Контекст

Сервер конференций сохраняет полную информацию о:

• старте конференций;
• входе и выходе участников;
• повторных входах;
• перезапусках и переподключениях.

Эти данные хранятся в БД Openfire и используются как источник для построения статистических отчётов.

Проблема заключается в том, что отчёт выполняется слишком долго, особенно на рабочих объёмах данных.

Рассмотренные варианты

1. Добавить индекс в таблицы Openfire

Плюсы:

• запросы выполняются значительно быстрее;
• решение внедряется быстро и технически просто.

Минусы:

• увеличивается нагрузка на запись в БД Openfire;
• появляются кастомные изменения в стороннем продукте;
• есть риск дополнительных задержек, таймаутов и побочных эффектов в работе сервера.

2. Сделать репликацию нужных таблиц Openfire

Предполагалась синхронизация данных раз в сутки с построением отчётов по данным за предыдущий день.

Плюсы:

• отчёты отвязываются от основной рабочей базы;
• можно спроектировать отдельную структуру таблиц;
• можно создать нужные индексы под аналитические запросы;
• отчёты выполняются быстро.

Минусы:

• появляется новая инфраструктурная сущность;
• внедрение и поддержка требуют дополнительных усилий со стороны разработки и администрирования.

3. Собирать данные отдельно в Videomost через WebSocket

Плюсы:

• отчёты отвязываются от Openfire;
• можно изначально спроектировать структуру хранения под нужную аналитику.

Минусы:

• требуется разработка нового функционала и новых таблиц;
• появляется зависимость от jconf и текущего формата XMPP;
• при изменениях в jconf потребуется доработка решения;
• надёжность записи ниже, чем у данных, уже зафиксированных в Openfire;
• старые отчёты не будут доступны, статистику нужно накапливать заново после внедрения.

4. Перестроить структуру текущих запросов

Идея состоит в том, чтобы изменить схему выборки данных и вынести тяжёлый подзапрос в отдельную таблицу для повторного использования.

Плюсы:

• не требуется менять Openfire;
• не нужно добавлять новые сервисы и отдельный функционал;
• базовые отчёты начинают работать быстро;
• более сложные отчёты с фильтрами по тарифу и медиасерверу выполняются за приемлемое время.

Минусы:

• без индексов на таблицах Openfire скорость всё равно не максимальная;
• часть отчётов остаётся не мгновенной, а просто приемлемой по времени.

Выбранное решение

На текущем этапе выбирается четвёртый вариант: переработка структуры запросов без изменений в Openfire.

Ключевая идея состоит в выделении тяжёлого подзапроса в отдельную таблицу с возможностью повторного использования. Это позволяет снизить стоимость основных вычислений и не создавать риски для боевой БД Openfire.

Почему был выбран именно этот вариант

Решение дает практический баланс между скоростью, стоимостью внедрения и операционными рисками:

• без кастомизации стороннего продукта;
• без дополнительной инфраструктуры;
• без потери исторических данных;
• с заметным ускорением основных отчётов.

См. также

• PostgreSQL / MySQL
• Workaround для MariaDB