Комментарии 6
1. Это называется трассировка
2. Не знаю как для БД, но для приложений есть стандарт OpenTracing и его реализация, например Jaeger
2. Не знаю как для БД, но для приложений есть стандарт OpenTracing и его реализация, например Jaeger
1. Да, согласен. Не задумывался раньше над точным определением этого слова, посмотрел внимательнее, спасибо.
2. Про Jaeger почитаю, спасибо. Судя по ключевой терминологии (span, trace) — это действительно промышленная реализация той же идеи.
2. Про Jaeger почитаю, спасибо. Судя по ключевой терминологии (span, trace) — это действительно промышленная реализация той же идеи.
По пункту 2: Если надо быстро сделать, то небольшой свой пакет всё же удобнее. А если централизованно, да ещё и во многих местах, то конечно надо за готовыми реализациями идти.
Индексы и констрейнты на таблице логов?! Если эта штука для постоянного логгирования, то её нужно сделать максимально быстрой и легковесной. А для трассировки pl/sql все-таки в оракле есть иерархический профайлер…
Что вы вкладываете в понятие «максимально легковесной»?
Аргументация по индексам.
В таблице log_instances:
1. индекс по log_instance_name позволяет эффективно найти корневой id лога по названию логируемого приложения, которое известно клиенту.
В таблице log_table:
1. Первичный ключ на log_id думаю очевиден: по нему, например, происходит UPDATE при обновлении end_ts, когда активность завершает работу.
2. Индекс на parent_log_id позволяет ускорить иерархический запрос получения лога.
3. Пожалуй, несильно обязателен индекс по action_name, но может возникнуть ситуация сравнить времена активностей двух запусков приложений.
Лог пишется в OLTP режиме, накладные расходы с поддержкой индексов минимальны. Во всяком случае, логируя по такой схеме, pl/sql пакеты на проде, мы не замечали каких-либо проблем.
На счёт pl/sql профайлера, он не позволяет выполнять root cause analysis в ретроспективном режиме. То есть для того, чтобы понять, в чём была проблема, вам нужно заново запускать приложение с включённым профайлером. Во многих ситуациях это может быть неприемлемо. И информация профайлера на мой взгляд не столь user-friendly по сравнению с настраиваемым логом. Я согласен, что профилированием тоже не стоит пренебрегать, но мне кажется логирование решает немного другую задачу.
Аргументация по индексам.
В таблице log_instances:
1. индекс по log_instance_name позволяет эффективно найти корневой id лога по названию логируемого приложения, которое известно клиенту.
В таблице log_table:
1. Первичный ключ на log_id думаю очевиден: по нему, например, происходит UPDATE при обновлении end_ts, когда активность завершает работу.
2. Индекс на parent_log_id позволяет ускорить иерархический запрос получения лога.
3. Пожалуй, несильно обязателен индекс по action_name, но может возникнуть ситуация сравнить времена активностей двух запусков приложений.
Лог пишется в OLTP режиме, накладные расходы с поддержкой индексов минимальны. Во всяком случае, логируя по такой схеме, pl/sql пакеты на проде, мы не замечали каких-либо проблем.
На счёт pl/sql профайлера, он не позволяет выполнять root cause analysis в ретроспективном режиме. То есть для того, чтобы понять, в чём была проблема, вам нужно заново запускать приложение с включённым профайлером. Во многих ситуациях это может быть неприемлемо. И информация профайлера на мой взгляд не столь user-friendly по сравнению с настраиваемым логом. Я согласен, что профилированием тоже не стоит пренебрегать, но мне кажется логирование решает немного другую задачу.
На первичный ключ log_id можно ещё добавить reverse опцию Oracle при создании индекса, чтобы уменьшить contention на самый крайний блок B*Tree индекса. Потеряется возможность использовать через индекс range запросы, но они не нужны — весь доступ по log_id идёт через операцию равенства. На практике у нас не было в этом необходимости.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Иерархическое логирование приложения в Базу Данных