PgConf.Russia 2016

В настоящее время в 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.

Общая информация об adsterra.com

• adsterra.com - биржа интернет рекламы
• В данный момент имеет порядка 150 млн показов баннеров в сутки.120 положение в alexa.com на 30.11.2015. Записывает в postgresql до 10000(и больше) событий в секунду. Читает до 5000
• 20 отдельных серверов под БД с различными ролями
• Активно использует логику внутри БД. Много PL/pgsql и SQL функций.

Причины выбора Postgresql

• История создания adsterra.com.
• Сжатые сроки отведенные на разработку определили выбор в пользу готовых систем хранения данных.
• Postgresql привлек своей бесплатностью и рядом фишек, которых не было у конкурентов. Некоторые в итоге оказались полезными, некоторые не очень.

Описание архитектуры проекта

• Общая схема взаимодействия
• Роли групп серверов
• Использование различных методов для взаимодействия серверов: Потоковая репликация, Londiste, postgres_fdw. Плюсы и минусы каждого.
• Шардинг
• Использование SQL под OLTP

Проблемы возникшие в ходе разработки/использования и варианты решения:

• Материализованные представления. Проблемы с обновлением и поддержкой. Что сделали в итоге.
• Londiste. Какие проблемы были решены в ходе разработки, а какие так и не были.
• Проблемы потоковой репликации.
• Автовакум и вакум.
• Странности планировщика.
• Конкурентный доступ.

Крутые штуки Postgresql, которые сильно помогли

• Массивы, intarray и GIN индексы. Но не все гладко.
• Партиционирование. Но не все есть, что хочется.
• PL/pgsql. Но не всегда следует его использовать.
• unlogged таблицы. Но с умом.

Текущие разработки и нерешенные проблемы

• Реализация колоночной аналитики штатными средствами.
• Проблемы странных планов запросов.
• Логическая репликация мечты
• Мультимастер...

Речь пойдет о кластерных решениях для PostgreSQL на основе потоковой репликации и pgpool-II, которые очень популярны в Японии. Также рассматриваются новые возможности следующей версии pgpool-II, которая будет выпущена этой зимой.

За годы моей работы с PostgreSQL возникло ясное представление, о том, каковы его основные достоинства ("Киллер-фичи", "вкусняшки"), из-за которых мы выбираем и рекомендуем выбирать эту СУБД.
1. Начало
2. Документация
3. Комьюнити
4.1 Транзакционный DDL
4.2 WAL и настоящая физическая репликация
4.3 Транзакционный снепшот и настоящая логическая репликация и PGQ
4.4 Потрясающая расширяемость
5. Успех