Ускорение исполнения запросов в PostgreSQL с использованием JIT-компилятора LLVM
В настоящее время в PostgreSQL для исполнения SQL-запросов используется интерпретатор. Это приводит к накладным расходам, связанным с неявными вызовами функций-обработчиков и проверок, которых можно было бы избежать при создании исполняемого кода "на лету" (JIT-компиляции) под конкретный SQL-запрос: в этом случае во время выполнения уже известна структура используемых таблиц и типы данных. Особенно это актуально для сложных запросов, где производительность процессора является основным ограничением. В настоящий момент существует два известных проекта, реализующих JIT-компиляцию в PostgreSQL: коммерческое решение Vitesse DB и open-source проект PGStorm. В первом проекте за счет использования LLVM JIT авторам удается получить ускорение до 8 раз на тестах из набора TPC-H. Второй проект реализует JIT-компиляцию запроса с использованием CUDA для исполнения его на GPU, что позволяет ускорить выполнение некоторых типов запросов на порядок.
Наша работа посвящена добавлению поддержки JIT-компиляции SQL-запросов в PostgreSQL с использованием компиляторной инфраструктуры LLVM. В докладе будет подробно рассмотрено, как JIT-компиляция может быть использована для ускорения различных этапов исполнения SQL-запросов, а также особенности трансляции SQL-запросов в LLVM-биткод для получения эффективного исполняемого кода. Также будут представлены предварительные результаты тестирования JIT-компилятора на наборе тестов TPC-H.
Слайды
Видео
Другие доклады
-
22 минДДенис Иванов 2ГИС Ведущий разработчик
Эволюция использования PostgreSQL в справочном API 2GIS
- Первое появление постгреса в команде
- Борьба с репликацией
- Партицирование и миграции
- Кросс-датацентровое использование
- v8, json, jsonb, jsquery
- Апгрейд версии postgresql
На данный момент на продакшене бекенда справочного API 2GIS мы имеем с десяток различных баз в postgresql, около 120 шардов, миллионы записей в таблицах. При этом практически все данные хранятся в структурах jsonb
Я расскажу об эволюции продукта с точки зрения взаимодействия с СУБД.
-
45 мин
Никита Волков Sannsyn AS Senior Developer and Data ScientistДекларативное программирование клиентов Postgres в Haskell с помощью Hasql
Речь пойдёт о "hasql", высокоэффективной библиотеке для интеграции Haskell с PostgreSQL. Вы познакомитесь с удивительным языком программирования Haskell, преимуществами декларативного программирования и техническими решениями библиотеки, среди которых имплементация бинарного протокола для общения с Postgres. Эта библиотека используется проектом PostgREST, популярным универсальным REST API для баз данных Postgres.
-
45 мин
Александр Коротков Postgres Professional Руководитель разработкиРасширяемость PostgreSQL: Истоки и новые горизонты
Postgres изначально был спроектирован таким образом, чтобы индексные методы доступа были расширяемыми. Известная цитата гласит: "Совершенно необходимо, чтобы пользователь мог создавать новые методы доступа, обеспечивающие эффективный доступ к значениям нетрадиционных типов данных" Michael Stonebraker, Jeff Anton, Michael Hirohama. Extendability in POSTGRES, IEEE Data Eng. Bull. 10 (2) pp.16-23, 1987
Изначально, heap был просто одним из методов доступа. Таким образом, подключаемые методы доступа означали также и подключаемые хранилища, если говорить современным языком. Сейчас в таблице pg_am системного каталога хранятся индексные методы доступа, интерфейс которых хорошо задокументирован. Таким образом, для того, чтобы современный PostgreSQL отвечал первоначальному замыслу необходимо реализовать две фичи:
- Подключаемые индексные методы доступа, т.е. возможность реализовывать новые типы индексов путём добавления строк в таблицу pg_am;
- Подключаемые хранилища, т.е. возможность реализовывать совершенно другие движки для хранения данных, не использующие традиционный heap.
Помимо чисто механической работы, такой как реализация команды "CREATE ACCESS METHOD", подключаемые индексные методы доступа должны был защищены WAL'ом. Сейчас, сообщество не хочет, чтобы расширения могли определять свой собственный формат WAL-записей, потому что возникает риск поломать одновременно recovery и репликацию, что неприемлемо. Другим подходом к этой проблеме является обобщённый формат WAL-записей, который задаёт разницу между версиями страницы в общем виде.
Очень немногие СУБД поддерживают сейчас подключаемые хранилища. Самая распространённая из них – MySQL. Но обращение к различным хранилищам в MySQL подобно обращению к различным СУБД. Поэтому, с нашей точки зрения, PostgreSQL не должен идти таким путём.
Однако, сейчас пользователи PostgreSQL всё больше понимают преимущества, которые они бы получили от использования альтернативных хранилищ. Идея колоночного и in-memeory хранилищ для PostgreSQL очень популярна. Одновременно с этим, возрастают наши технические возможности их реализовать. PostgreSQL приобрёл механизмы FDW и custom nodes. Обобщённый WAL и расширяемые индексные методы доступа ожидают включения в 9.6. Очень много работы на пути к подключаемым хранилищам уже сделано, даже если эта работа преследовала совсем другие цели.
Наступило время, когда разработчикам ядра PostgreSQL нужно всерьёз задуматься о нативной поддержке подключаемых хранилищ без костылей. В конце концов, мы должны получить команду "CREATE STORAGE ENGINE name ...", как один из механизмов расширяемости.
В докладе будут продемонстрированы текущие результаты в области подключаемых индексных методов доступа, а также концепция подключаемых хранилищ.
-
22 мин
Петр Грибанов 1С Технологический евангелист"1С:Предприятие": самая популярная в России/СНГ платформа разработки с поддержкой PostgreSQL
Более 300.000 разработчиков используют в качестве основного средства разработки технологическую платформу "1С:Предприятие". Я расскажу об особенностях идеологии и архитектуры платформы "1С:Предприятия", которые позволили ей стать одним из самых массовых средств разработки в России и СНГ, и о том, почему СУБД PostrgreSQL становится все популярнее среди пользователей технологий 1С.