PGConf.Russia 2024

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

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

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

В своём докладе я собираюсь рассказать о сравнительно малоизвестном и малоиспользуемом функционале встроенном в популярный отладчик GDB. Я собираюсь дать небольшой обзор по данному API и на примере PostgreSQL и Oracle показать как можно использовать данное API чтобы более наглядно показать/исследовать то что происходит внутри базы данных. В качестве примера я предполагаю рассмотреть некоторые аспекты парсинга SQL внутри данных баз данных.

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

В обзорных докладах по Postgres можно встретить упоминание алгоритма k-NN для поиска в пространстве. В данном докладе тема будет рассмотрена более глубоко, описан механизм индексирования поиска в пространстве в картинках. Так же я покажу, как с помощью популярного бесплатного расширения PostGIS применить алгоритм k-NN к географическим координатам точек на земном шаре, которые не являются прямоугольными. Для всех примеров будет показана реализация в ORM.