Когда мы обсуждали различные подходы - также обсуждали и этот вариант.
Но он не подошёл. К примеру, бывает и такое, когда за один МР ты насоздаёшь объектов, а потом часть удалишь. Потом смотри весь этот лог и перетирай его.
А вот, к примеру, фишка, которая у нас сейчас вводится в поддержку ( вот прям сейчас допиливаем и будем тестить ): можно комментарием к объекту управлять его контектом. Вот пример: допустим, такая-то таблица должна быть только на тестовом и ревью сервере, а на проде - нет. Всё что мы делаем - просто в комментарии к таблице пишем флаг, а парсер уже всё сам настраивает.
Ну и ещё раз попробую напомнить про тот подход, который я описывал: если мы в функции с 1к строк ( к примеру ) модифицируем 1-у строку, то ревьюеру будет удобно такое проверять, поскольку в репозитории будет показана модификация одной строки, а не сплошь тысяча новых строк.
Надеюсь, я донёс мысль :)
У нас на одном из проектов ( не самом большом ) 700+ функций. Бывает и такое, что одновременно открыто 3 МР на изменение одной и той-же функции.
Запросы работали более-менее норм, пока база чутка не расжирела. После этого оказалось так, что разработчики не до конца нормализовали БД.
Планировщик сбился, статистика неверная, обращение к тостам. Ну и база встала на лопатки.
Так что, не обязательно вы увидите эффект сразу после изменения БД, он может проявиться через неделю-месяц-год.
У каждого свои метрики. У нас пока система не полностью настроена на такое. Но вот часть:
кол-во активных / кол-во подключение
быстрый мониторинг, я же знаю, что у меня в БД не может быть больше 2-4 одновременных запросов. Если кол-во автивных запросов пошло вверх - что-то не так.
кол-во таплов в секунду
просто можно увидеть нагрузку на чтение ( ну типа как люди смотрят нагрузку на диск у себя в десктопе). Не совсем информативно, но видно то-же что-то
pg_stat_statements
долгосрочная перспективна, раз в день/неделю читаете и сбрасываете статистику. В будущем можно искать узкие места
логи внешних сервисов
у нас внешние сервисы ( в частности крон ) свои логи кидает в ( да да, не кибана :) ), я раз в день-два проверяю логи и смотрю, были ли ошибки ( в т.ч. ошибки, что долго выполнялся запрос или не было доступа к подключению ( пул перегружен) )
1) Вообще современные (широко используемые фронтенд-фремворки) прекрасно умеют кушать дататайм с таймзоной и сразу кастить в свою локальную таймзону Конечно, я не фронтендер, но уточнял у "своих" - мне сказали, что всё само делается. Так что в принципе, без разницы абсолютно
2) С другой стороны, мы однажды столкнулись с проблемой агрегации ( сумма за сутки ). Агрегация происходила в БД, а там своя таймзона. Решение было простое - фронт прокидывает в хэдерах запроса свою таймзону, а бэкенд сначала переопределяет полученную таймзону как сессионную таймзону, а потом уже выполняет запрос :)
прошу прощения, видимо, я не так понял Да, в случае с time - чаще всего приходится работать именно с timetz
Кстати, изначально пункт назывался `Используйте timestamptz для дататайма, а time - для времени дня`. Но статья и так получалась очень раздутой и во время рефакторинга решил эту часть обрезать
Создание временной таблицы ( create temp table ) в любом случае идёт на диск.
Как видно на практике, молодые разработчики боятся использовать `многоэтажные` CTE ( with (),() select ) и пытаются пробиться через использование временных таблиц.
В большинстве случаев этого делать не стоит.
И в который раз повторюсь, что есть разные случаи и в некоторых стоит работать именно через временные таблицы ( или только через них )
вообще, в случае микросервисов, и взаимодействия бд только с одним приложением, проблема с таймзоной внутри бд перестает быть актуальной. конкретное приложение становится ответственным за правильную работу с таймзоной. и соответственно можно хранить время в бд без таймзоны.
Вот у меня в данный момент боевой проект. Всё работало круто, всё было нормально, потому что было в одной таймзоне.
И как только началось расширение в другие регионы - случилось то что случилось. Вот правим ошибки
Нормализация. Делать нормализацию только потому, что "так учили" - сомнительно. Бывает приходится сознательно денормализовывать данные.
А кто сказал, что надо всегда делать 6 уровней нормализации Это всегда рекомендательные советы и не более, понятное дело, что ради оптимизации иногда надо идти на денормализацию.
Отдельные схемы для разных модулей. Крайне сомнительно. Особенно, если данные используются далеко не одним модулем.
Я абсолютно согласен, что имеет смысл использовать временные таблицы, когда это делать надо
Согласен, что код чище, Но скорость меньше..
На счёт статистики, если планировщик ошибается на 20-30% - проблем вообще не должно быть. Если очень большая ошибка - стоит посмотреть, почему он так считает и разобраться
Ну если ваш бизнес позволяет Вам сделать отдельный кластер с 2Тб ссд и железом как на проде для отладки одного аналитического запроса - пожалуйста, так и делайте
Когда мы обсуждали различные подходы - также обсуждали и этот вариант.
Но он не подошёл.
К примеру, бывает и такое, когда за один МР ты насоздаёшь объектов, а потом часть удалишь. Потом смотри весь этот лог и перетирай его.
А вот, к примеру, фишка, которая у нас сейчас вводится в поддержку ( вот прям сейчас допиливаем и будем тестить ): можно комментарием к объекту управлять его контектом.
Вот пример: допустим, такая-то таблица должна быть только на тестовом и ревью сервере, а на проде - нет. Всё что мы делаем - просто в комментарии к таблице пишем флаг, а парсер уже всё сам настраивает.
Ну и ещё раз попробую напомнить про тот подход, который я описывал: если мы в функции с 1к строк ( к примеру ) модифицируем 1-у строку, то ревьюеру будет удобно такое проверять, поскольку в репозитории будет показана модификация одной строки, а не сплошь тысяча новых строк.
Надеюсь, я донёс мысль :)
У нас на одном из проектов ( не самом большом ) 700+ функций. Бывает и такое, что одновременно открыто 3 МР на изменение одной и той-же функции.
@suburg, @mayorovp
Написал статью, где показал этот способ ( тот что тут в комментах описывал )
Случай у меня был +- год назад.
Запросы работали более-менее норм, пока база чутка не расжирела. После этого оказалось так, что разработчики не до конца нормализовали БД.
Планировщик сбился, статистика неверная, обращение к тостам. Ну и база встала на лопатки.
Так что, не обязательно вы увидите эффект сразу после изменения БД, он может проявиться через неделю-месяц-год.
У каждого свои метрики.
У нас пока система не полностью настроена на такое. Но вот часть:
кол-во активных / кол-во подключение
быстрый мониторинг, я же знаю, что у меня в БД не может быть больше 2-4 одновременных запросов. Если кол-во автивных запросов пошло вверх - что-то не так.
кол-во таплов в секунду
просто можно увидеть нагрузку на чтение ( ну типа как люди смотрят нагрузку на диск у себя в десктопе). Не совсем информативно, но видно то-же что-то
pg_stat_statements
долгосрочная перспективна, раз в день/неделю читаете и сбрасываете статистику. В будущем можно искать узкие места
логи внешних сервисов
у нас внешние сервисы ( в частности крон ) свои логи кидает в ( да да, не кибана :) ), я раз в день-два проверяю логи и смотрю, были ли ошибки ( в т.ч. ошибки, что долго выполнялся запрос или не было доступа к подключению ( пул перегружен) )
Да тут в целом, наверное, все советы будут универсальные ( ну или большинство )
ну я тут отпишу в двух абзацах:
1) Вообще современные (широко используемые фронтенд-фремворки) прекрасно умеют кушать дататайм с таймзоной и сразу кастить в свою локальную таймзону
Конечно, я не фронтендер, но уточнял у "своих" - мне сказали, что всё само делается. Так что в принципе, без разницы абсолютно
2) С другой стороны, мы однажды столкнулись с проблемой агрегации ( сумма за сутки ). Агрегация происходила в БД, а там своя таймзона.
Решение было простое - фронт прокидывает в хэдерах запроса свою таймзону, а бэкенд сначала переопределяет полученную таймзону как сессионную таймзону, а потом уже выполняет запрос :)
promt-engineer :)
могу точно сказать, что разработчик пойдёт за мылом и верёвкой в таком случае :)
прошу прощения, видимо, я не так понял
Да, в случае с time - чаще всего приходится работать именно с time
tzКстати, изначально пункт назывался `Используйте timestamptz для дататайма, а time - для времени дня`. Но статья и так получалась очень раздутой и во время рефакторинга решил эту часть обрезать
Создание временной таблицы ( create temp table ) в любом случае идёт на диск.
Как видно на практике, молодые разработчики боятся использовать `многоэтажные` CTE (
with (),() select) и пытаются пробиться через использование временных таблиц.В большинстве случаев этого делать не стоит.
И в который раз повторюсь, что есть разные случаи и в некоторых стоит работать именно через временные таблицы ( или только через них )
Мб Вы не до конца прочитали...
PostgreSQL-ю всё равно, в какой таймзоне вы пихаете данные - всё кастанётся в UTC.
А когда будете делать select - получите дататайм в таймзоне, которая у Вас настроена в сессии
Вот у меня в данный момент боевой проект.
Всё работало круто, всё было нормально, потому что было в одной таймзоне.
И как только началось расширение в другие регионы - случилось то что случилось. Вот правим ошибки
Я могу ошибаться, но материализованные представления умеют в статистику сразу
1) Последовательность из pg_dump
2) check_function_bodies = false
3) ФК и прочие подобные зависимости в отдельном файле
Вот эти 3 пункта держат всё так, чтобы не было ошибок
А кто сказал, что надо всегда делать 6 уровней нормализации
Это всегда рекомендательные советы и не более, понятное дело, что ради оптимизации иногда надо идти на денормализацию.
А кто сказал, что модули строго изолированы ?
Я абсолютно согласен, что имеет смысл использовать временные таблицы, когда это делать надо
Согласен, что код чище, Но скорость меньше..
На счёт статистики, если планировщик ошибается на 20-30% - проблем вообще не должно быть. Если очень большая ошибка - стоит посмотреть, почему он так считает и разобраться
Ну если ваш бизнес позволяет Вам сделать отдельный кластер с 2Тб ссд и железом как на проде для отладки одного аналитического запроса - пожалуйста, так и делайте
Потому что по ней видно, кто , когда и в какой задаче ( с каким коммитом ) изменял тот или иной объект.
Все скрипты написаны так, чтобы их двойной запуск ничего не ломал + система перепроверки миграций.
Да, все скрипты по объектам распиханы ( типа ./schema_name/type/name/object_name.sql )
о_О, спасибо, будет что на досуге прочитать )
Вот именно для каких-то тестов именно на проде ( и только на проде ) - отдельная схема.
Мы заливаем миграции через liquibase, но и даже у пользователя, под которым выполняются миграции - не админка.
А как-же агрегаты по времени ?