Недавно столкнулась с такой проблемой в работе: в разрабатываемом веб-приложении отслеживается история запусков неких алгоритмов. При изначальной проработке решения, моя коллега предложила делать этот журнал результатов запуска алгоритмов в виде таблицы.

В чём тут проблема?

1) Проблема заключается в том, что каждый из алгоритмов даже за один час может запуститься по расписанию N раз. Под каждый запуск будет создана строка. Если же учесть, что алгоритм запускается не в единственном экземпляре, а под каждый из экземпляров обрабатываемых сущностей предметной области, которых может быть M = 1..1000+, а самих алгоритмов более 50, то становится очевидным - таблица будет пухнуть очень быстро. 2) Вторая проблема - в хранении. Все эти миллионы строк хранятся в БД PostgreSQL. О том, чтобы быстро по требованию пользователя извлечь из такого, всё прибавляющегося количества строк, нужную информацию - и говорить не приходится. 3) Третья проблема - изначально было запланировано, что содержимое таблицы будет... выгружаться в Excel! То есть мы тут же, ещё не написав и строчки кода, пробили ограничение на количество строк в файле Excel. А главное - никакой живой аналитики сама по себе выгрузка пользователю не даст.

Какие предложены решения?

1) Во-первых, я предложила отказаться полностью от использования PostgreSQL. Вместо этого я предложила использовать ClickHouse, куда будем для каждого из алгоритмов записывать в виде временного ряда результаты его запуска. 2) Во-вторых, я предложила полностью отказаться от табличного представления данных. Вместо этого я предложила реализовать представление во временной шкале (типа как временные диаграммы PlantUML), где каждый блок - это результат запуска, а каждая строка - один алгоритм. 3) Отдельно скажу о блоках на временной шкале. Цвет блока имеет семантическое значение: - зелёный - алгоритм успешно отработал; - жёлтый - алгоритму не удалось обработать хотя бы 1 сущность предметной области; - красный - алгоритм завершился с ошибкой. Длина и расположение блоков на временной шкале также напрямую зависят от времени запуска алгоритма и времени его завершения.

Сразу скажу, что здесь каждый блок - это агрегированный результат запуска алгоритма. То есть, в момент наступления момента очередного запуска алгоритма, запускается M экземпляров этого алгоритма. Когда все они завершают свою работу, то специальный сервис консолидирует результаты их работы и, таким образом, мы в ClickHouse записываем именно консолидированные результаты (которые нас и интересуют), и на временной шкале мы также видим их.

Как этот подход представлен команде?

1) Во-первых, конечно, C4 диаграмма, чтобы показать моё предложение о хранении данных и взаимодействии сервисов. 2) Во-вторых, вместо тысячи слов и картинок - кликабельный интерактивный прототип (типа как на картинках в настоящей статье), чтобы вся команда могла потыкать кнопки и понять, что удобнее.

Какие фичи ещё есть у временной шкалы?

1) фильтрация блоков запусков алгоритмов в зависимости от их статуса 2) всплывайки на блоках с краткой информацией 3) по клику на блок показывается панель со всеми интересующими пользователя подробностями. 4) экспорт проблемных запусков в Excel (прямая борьба с миллионами строк, о которых говорили в начале!) 5) фильтрация временной шкалы с помощью слайдера с возможностью подгружать дополнительные данные на 1 сутки в прошлое за раз.

В результате получилось решение, которое не только удовлетворяет потребностям службы технической поддержки приложения, но даже понравилось бизнес-эксперту и, возможно, будет внедрено как часть будущего дашборда для конечных пользователей, чтобы избавиться от свойства "чёрного ящика", когда пользователи не понимают, что там под капотом.

Пишите в комментариях о своём опыте подобной оптимизации интерфейса и подхода к хранению данных!