Если под «сложностью» понимать именно сложность присущую самой задаче (inherent complexity), то, безусловно, такую сложность надо распределять между абстракциями, где абстракции более высокого уровня полагаются на корректную реализацию соответствующего низкоуровнего API.
Когда речь идёт об упрощении, часто имеют в виду так называемую accidental complexity — то есть искусственно привнесённая сложность в силу разного рода причини: недостаток знаний технологии, сжатые сроки и.т.д. Эти «сложности» могут накапливаться, не принося никакого нового функционала продукту. Их пытаются описать в терминах технического долга и убедить владельцев продукта на выделение времени на их устранение (рефакторинг).
Спасибо за статью.
Из пожеланий хотелось бы увидеть, как описанные аномалии решаются в PostgreSQL, если вы приурочили статью к запуску этого курса. В частности, как PostgreSQL поддерживает Serializable Snapshot Isolation (SSI) и Snapshot Isolation через уровни изоляции SERIALIZABLE и REPEATABLE READ.
Тема транзакций хорошо разобрана в книге Martin Kleppmann «Designing Data-Intensive Applications». Судя по всему часть примеров взята из неё.
Спасибо за статью.
Хотел уточнить, о каком уровне поддержки идёт речь, когда вы перечислили Postgres, Redshift, BigQuery и.т.д.? К каждой из этих БД у Data Build Tool есть свой особый коннектор? Поддерживает ли Data Build Tool JDBC соединение к произвольной БД и возможность исполнять через JDBC код моделей?
На первичный ключ log_id можно ещё добавить reverse опцию Oracle при создании индекса, чтобы уменьшить contention на самый крайний блок B*Tree индекса. Потеряется возможность использовать через индекс range запросы, но они не нужны — весь доступ по log_id идёт через операцию равенства. На практике у нас не было в этом необходимости.
Что вы вкладываете в понятие «максимально легковесной»?
Аргументация по индексам.
В таблице 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 по сравнению с настраиваемым логом. Я согласен, что профилированием тоже не стоит пренебрегать, но мне кажется логирование решает немного другую задачу.
1. Да, согласен. Не задумывался раньше над точным определением этого слова, посмотрел внимательнее, спасибо.
2. Про Jaeger почитаю, спасибо. Судя по ключевой терминологии (span, trace) — это действительно промышленная реализация той же идеи.
Когда речь идёт об упрощении, часто имеют в виду так называемую accidental complexity — то есть искусственно привнесённая сложность в силу разного рода причини: недостаток знаний технологии, сжатые сроки и.т.д. Эти «сложности» могут накапливаться, не принося никакого нового функционала продукту. Их пытаются описать в терминах технического долга и убедить владельцев продукта на выделение времени на их устранение (рефакторинг).
Из пожеланий хотелось бы увидеть, как описанные аномалии решаются в PostgreSQL, если вы приурочили статью к запуску этого курса. В частности, как PostgreSQL поддерживает Serializable Snapshot Isolation (SSI) и Snapshot Isolation через уровни изоляции SERIALIZABLE и REPEATABLE READ.
Тема транзакций хорошо разобрана в книге Martin Kleppmann «Designing Data-Intensive Applications». Судя по всему часть примеров взята из неё.
Хотел уточнить, о каком уровне поддержки идёт речь, когда вы перечислили Postgres, Redshift, BigQuery и.т.д.? К каждой из этих БД у Data Build Tool есть свой особый коннектор? Поддерживает ли Data Build Tool JDBC соединение к произвольной БД и возможность исполнять через JDBC код моделей?
Аргументация по индексам.
В таблице 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 по сравнению с настраиваемым логом. Я согласен, что профилированием тоже не стоит пренебрегать, но мне кажется логирование решает немного другую задачу.
2. Про Jaeger почитаю, спасибо. Судя по ключевой терминологии (span, trace) — это действительно промышленная реализация той же идеи.