PGConf.Russia 2022

В июне 2020 года АльфаСтрахование, как и другие страховые компании, была обязана использовать АИС РСА 2.0 для обеспечения работы ОСАГО в соответствии с законодательством. Компания занимает ведущие позиции на рынке ОСАГО, поэтому системы АИС ОСАГО, которые хранят информацию по обращениям от бизнес-систем до РСА и обратно, начали испытывать неожиданную нагрузку, БД стала деградировать, потреблять огромные для ее размера ресурсы. Деградация внезапно наступала и внезапно заканчивалась, причины были неясны. Творческий коллектив инженеров и экспертиза Postgres Pro решили проблему. Виновником оказался MyBatis (ORM) в Java-сервисах. История о том, что надо внимательно изучать документацию и проектировать высоконагруженные системы.

Расширение plv8 очень недооценено, хотя оно позволяет значительно упростить разработку для ряда задач. Уже год как мы используем его в наших проектах. Но главная причина низкой популярности – сложность сборки расширения, к тому же требующей много трафика и места на диске для временных файлов. Поэтому мы решили собирать plv8 сами и поставлять готовые бинарники (не только поставлять нашим заказчикам, а вообще выложить в открытый доступ). Сначала просто выложили бинарные файлы на github. Потом сделали докер-образ Postgres с уже установленным plv8 на основе Debian. Образ получился тяжеловатым, поэтому стали смотреть в сторону alpine, но сборка под alpine оказалась сложнее, чем мы предполагали. Я расскажу, с какими трудностями мы столкнулись и как их преодолели. Так же кратко расскажу, для каких задач хорошо подходит plv8 и как сделать процесс разработки удобнее. И, конечно, поделюсь ссылками на наши докер-образы для последних версий Postgres 13 и 14, действительно компактные и открытые для любого использования.

Чем больше таблиц участвует в запросе, тем сложнее планировщику выбрать подходящий план выполнения (увеличивается время и используемая память). Как бы подсказать планировщику, что лучше эту пару таблиц соединить первой, а остальные - потом? Как поступить, если видно, что часть запроса можно улучшить, но оптимизатор этого не делает? В докладе я расскажу про управление порядком соединений - вы узнаете, как можно повлиять на формирование плана запроса стандартными способами "ванильного" PostgreSQL.

Традиционные дисковые базы данных имеют врожденное физическое ограничение по сравнению с In-Memory СУБД в виде подсистемы хранения, которая даже в случае All-Flash NVMe на порядки более медленная, чем оперативная память CPU. Это особенно критично для развития приложений бизнес-аналитики и OLAP-сценариев на дисковых СУБД. Есть достаточное количество примеров ускорения традиционных СУБД, в том числе и PostgreSQL, которые мы рассмотрим, и предложим новый, Storage-центричный подход к аппаратному ускорению дисковых баз данных.