Когда начинал разработку системы многомерного анализа данных временных рядов Dimension-UI, для внедрения зависимостей в исходном коде решил использовать Dagger 2. Практический опыт показал, что для приложений с большим количеством динамически создаваемых объектов инверсия зависимостей, реализованная в Dagger 2, не подходит.

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

Но накладные расходы на сопровождение всего этого хозяйства – прямо скажем, это боль.

Чтобы реализовать scope-зависимости, приходится писать и поддерживать много инфраструктурного кода внутри объектов, куда мы внедряем зависимости. В Dagger 2 такая реализация, во-первых, «загрязняет» код, а во-вторых, серьезно осложняет тестирование. Изолировать методы удобным способом не получается: в тестах нужно писать очень много кода, чтобы прокинуть необходимый контекст и корректно мокировать внешние зависимости. Я туда просто не полез — покрывал unit- и UI-тестами только базовую функциональность, где были Singleton-зависимости.

Даже с одними Singleton’ами приходится поднимать отдельную тестовую инфраструктуру для запуска приложения в тестовом режиме. Это не просто неудобно — это очень затратно по времени. Если сравнить усилия, которые надо потратить на реализацию тестирования подобного функционала в Spring и Dagger… Сравнение будет не в пользу Dagger. В целом я начал думать о переходе на runtime-генерацию графа зависимостей.

Недавно рассказывал про мониторинг истории активных сессий в базах данных Oracle, PostgreSQL, ClickHouse и MS SQL Server с использованием desktop-приложения Dimension-UI (link). В комментариях @KPSB92 задал вопрос о преимуществах/отличиях связки exporter Prometheus/Grafana и Dimension-UI, решил оформить ответ в эту небольшую статью.

Итак, возьмем для примера просмотр данных активных сессий в базе данных PostgreSQL и сравним визуализацию в Grafana и Dimension-UI. Посмотрим работу с интерфейсами обоих систем в динамике с помощью скринкастов.

Сегодня проверим Dimension‑UI на задаче мониторинга истории активных сессий в базах данных Oracle, PostgreSQL, ClickHouse и MS SQL Server в режиме реального времени.

История активных сессий (Active Session History, ASH) — очень удобный способ получения информации о работе БД в кратком виде. Когда важно максимально быстро отследить, что происходит с системой в настоящее время, оценить развитие текущей ситуации — это рабочая активность или начало каких‑либо проблем — в том числе, через быстрый просмотр baselines в недавнем прошлом системы и сравнить их с текущими данными.

Изначально, данный подход был разработан и применен в СУБД Oracle начиная с 10g версии. Архитектурно в Oracle это выглядит как плоская таблица в памяти V$ACTIVE_SESSION_HISTORY, в которую с определенным интервалом (стандартно 1 секунда, но его значение можно изменять) записывается состояние каждой активной сессии: идентификатор сессии, SQL‑запроса, процесса операционной системы, текущий статус сессии — в работе или ожидании получения доступа к ресурсу, статистики потребления памяти и проч.. Периодически информация из таблицы в памяти сбрасывается на диск в таблицу DBA_HIST_ACTIVE_SESS_HISTORY репозитория рабочей нагрузки AWR.

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

Достаточно большой период времени занимался технической поддержкой СУБД Oracle. Накопилось некоторое количество историй и заметок на полях по этому поводу, не могу не поделиться ими с вами. В общем — садимся по удобнее, берем попкорн, чашку горячего чая или кофе.. Дело было так.

Предлагается к рассмотрению метод динамического определения форматов хранения и типов индексации в таблицах аналитической базы данных Dimension DB. На основе метаданных из источников данных (SQL-запросов, таблиц или представлений) определяется формат хранения или представления данных, а по текущему распределению данных, автоматически определяется тип индексирования.

Английский язык всегда был для меня неприступной крепостью. И в школе и в институте я исправно ходил на занятия, выполнял домашние задания. Даже во время студенчества, перед написанием диплома ходил на курсы английского. Потом была покупка учебников Н.А. Бонк, словарей N нужных слов иностранного языка, перевод технической документации. Все это почему-то не приближало меня к уровню свободного владения. Это была загадка, terra incognita. Но пришло время (2009 год), и я решил все-таки разобраться с этим вопросом. На форумах часто встречал упоминания про книгу Н.Ф. Замяткина, прочитав которую, я нашел все ответы на интересующие меня вопросы по этой теме.

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

Готовим гибридную систему мониторинга + щепотка observability дабы нанести непоправимую пользу всему прогрессивному человечеству. С ароматом кофе, перед использованием можно добавить свои данные по вкусу.

• Требовали некоторых телодвижений по их установке и настройке – это Oracle Enterprise Manager Console (DB Console) или Oracle Enterprise Manager Grid Control (сейчас Oracle Enterprise Manager Cloud Control). DB Console из моей (и не только) практики требовал для установки применения очень сильных админских заклятий. Также в целях экономии ресурсов не все хотят ставить на сервера БД дополнительные сервисы или разворачивать на своей площадке отдельную инфраструктуру для мониторинга;
• Обладали рядом архитектурных недостатков. К примеру, в случае зависания сервера БД доступ к информации из истории активных сессий посредством Oracle Enterprise Manager Console становился невозможным, и оперативно выяснить, что «что-то пошло не так» (с) было практически нереально;
• Отсутствовала функциональность в части сохранения данных мониторинга и последующего его анализа на своей площадке.