PGConf.Russia 2024

У разработчиков постоянно возникают проблемы при работе с базами данных. Они вызваны тем, что разработчики считают СУБД чёрным ящиком, который "просто работает" и даже не подозревают, что важно и нужно понимать не только стандарт SQL, но и подробности устройства конкретной СУБД.

Проекты разные, разработчики разные, но вот проблемы как правило одни и те же. Мы хотим продемонстрировать как разработчики пользуются базой данных и рассказать хорошо бы знать об устройстве СУБД, для того, чтобы писать код, который не разваливается как только компания из бодрого стартапа превращается в зрелый бизнес с планомерно растущими продажами и, соответственно, нагрузками.

Практически в любом успешном проекте можно встретить практически одинаковые проблемы. Они появились потому что бизнес хотел побыстрее получить готовый продукт и это в своё время помогло компании встать на ноги. В небольших проектах эти проблемы совершенно незаметны.

Фаззинг-исследование, это когда мы подаем в программу (или ее часть) случайные входные данные (на самом деле случайность весьма условна) и смотрим что из этого получится. И так много раз на многих процессорах.

Фаззинг исследование большого монолитного программного комплекса всегда не простая задача требующая неординарных решений. В этом докладе я расскажу что и как мы искали при помощи фаззинга и к каким результатам оно привело.

Исследование функций парсинга типов данных (input-функции): для разогрева;
Исследование функций реализующих операции между типами (op-функции): тут лучше учитывать структуру;
Фаззинг сетевой подсистемы: давайте притворимся, что мы POSIX-вызовы, так дешевле;
Восстановление дискового контекста: нужен день сурка.

Обзор средств PostgreSQL для работы с точками на сфере (земной или небесной) и их сравнительный анализ. point, spoint, spoint3, earthdistance, pg_sphere, PostGIS - для чего использовать и какие у какого средства плюсы и минусы? Затронем также вопросы поиска данных на сфере, включая kNN. В соавторстве с Виталием Давыдовым, ключевым мейнтейнером pg_sphere.

Всем нам хочется быть немножко Шерлоками и расследовать интересные и запутанные дела. Жизнь, однако, вносит свои коррективы и большинство задач на выходе имеют банальные решения вроде - добавьте индекс по такому-то полю. Обилие баз и команд приводит к постоянному фону таких задач. Ситуацию усложняет повсеместное использование всякого рода ORM. И сами разработчики и ORM, зачастую не особенно беспокоятся вопросами эффективного доступа к данным (построение запросов, наличие и оптимальность состава индексов итд). В докладе рассматривается инструмент мониторинга и анализа состояния баз данных Postgres созданный на основе Grafana. Особенно подробно рассмотрены части, которые помогают разработчикам самостоятельно понять, где и каким образом образуются слабые места в его взаимодействии с базой.