Жизнь после импортозамещения: некоторые особености настройки БД и хранимых процедур
Многие литературные произведения заканчиваются свадьбой, а про дальнейшую жизнь героев читателю скупо сообщают, что они жили долго и счастливо. В 2019 распределенное серверное приложение, работающего 24/7 на полигоне 16 железных дорог от Калининграда до Хабаровска плюс несколько БД центрального уровня, было перенесено с Oracle 11g SE на ванильный PostgreSQL 11.9. Но наша история не закончилась на успешном импортозамещении - жизнь продолжалась и порой преподносила сюрпризы. Мы столкнулись с некоторым количеством эксплуатационных проблем, часть из которых удалось решить за счет реорганизации данных, часть - за счет изменения хранимых процедур, а еще часть - за счет изменения парамеров PostgreSQL. Решение наших проблем было бы невозможным без встроенной в приложение системы логирования и профилирования. Доклад посвящен примерам успешного диагностирования и решения проблем с производительностью приложения для БД PostgreSQL, все взаимодействие с которым осуществляется только через слой хранимых процедур.
Слайды
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
45 минММихаил Московский Postgres Professional Инженер
Скорость физической репликации в PostgreSQL.
Репликация - один из важных механизмов, призванный обеспечить отказоустойчивость и масштабируемость базы данных. В нашей практике мы регулярно сталкиваемся с проблемой низкой производительности репликации. Это побудило нас исследовать факторы, влияющие на скорость физической репликации. В этом докладе я расскажу о полученных результатах исследования. Также покажу, как менялась производительность репликации на разных версиях PostgreSQL.
-
45 мин
.JPG.180x180.jpg "Павел Толмачев")
Павел Толмачев Postgres Professional Специалист образовательного отделаКоллапс в планах запросов. Достигаем и управляем
Чем больше таблиц участвует в запросе, тем сложнее планировщику выбрать подходящий план выполнения (увеличивается время и используемая память). Как бы подсказать планировщику, что лучше эту пару таблиц соединить первой, а остальные - потом? Как поступить, если видно, что часть запроса можно улучшить, но оптимизатор этого не делает? В докладе я расскажу про управление порядком соединений - вы узнаете, как можно повлиять на формирование плана запроса стандартными способами "ванильного" PostgreSQL.
-
22 мин
Игорь Косенков Postgres Professional ИнженерКУК без потерь
Катастрофоустойчивый кластер (КУК) подразумевает небольшую потерю данных при катастрофе основного Дата-центра (ДЦ) и переключении на резервный. Это обусловлено асинхронной репликацией между основным и резервным ДЦ. Но есть решение, которое позволит исправить эту ситуацию - обеспечить нулевую потерю данных при катастрофе основного ДЦ. Об этом решении и пойдет речь в моем докладе.
-
22 мин
Иван Фролков Postgres Professional инженер-консультантТемпоральные типы и их использование
Я пересмотрел за жизнь много всякого кода, и очень часто встречал некоторый разнобой в обработке дат и времени: то у сторон не сходились отчеты за месяц, то суточные отчеты получались разные в Москве и Сан-Франциско, то еще чего-нибудь в таком же роде. Это не сказать чтобы сильно страшно, но довольно утомительно. Причина такого рода проблем всегда была связана с неаккуратной обработкой дат и времени. Тому, как этого можно постараться избежать, и посвящен мой доклад.