PgConf.Russia 2016

Общая информация об 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 на совершенно новый уровень. Сочетая в себе легкость настройки, высокую производительность и почти неограниченную масштабируемость потоковая репликация является эффективным инструментом, а ее наличие становится неотъемлемым компонентом любого постгресового "сетапа". Более того, в процессе дальнейшего развития PostgreSQL, потоковая репликация продолжает развиваться и обзаводиться новыми функциями (каскадные конфигурации, слоты репликации) вплоть до того, что на данном этапе своего развития, потоковая репликация позволяет выстраивать bi-directional replication конфигурации.

Из доклада вы узнаете о том, как устроена потоковая репликация снаружи и внутри, и о практических аспектах эксплуатации потоковой репликации включая такие вещи как настройка, сопровождение, мониторинг, поиск и устранение проблем.

Участникам мастер-класса следует скачать себе образ виртуальной машины для KVM, Virtual box или VMWare, распаковать его (gzip2) и запустить виртуальную машину.

Если у Вас нет ни одной из перечисленных программ для виртуализации, то нужно запустить виртуальную машину с CentOS 7 и установленным postgresql из оф.репозитория yum.postgresql.org.

Ссылка на образы для скачивания: https://goo.gl/Yy4UzH

Все говорят, что для максимальной производительности работы из Java с базой данных нужно использовать PreparedStatements и Batch DML. Практика показывает, что нельзя слепо идти на поводу у прописных истин. Нужно понимать особенности конкретной базы и характера передаваемых данных. В докладе мы рассмотрим то, как эффективное использование протокола PostgreSQL позволяет добиться высокой производительности при выборке и сохранении данных. На примерах увидим как простые изменения в коде приложения и JDBC драйвера на порядок ускоряют запросы. Мы увидим как задействовать механизм server prepared statements из клиенсткого кода и узнаем его узкие места. Обсудим средства эффективной передачи данных в базу. Многие обсуждаемые доработки недавно вошли в состав официального JDBC драйвера. Доклад будет полезен не только Java программистам, т.к. многие подводные грабли вытекают из самого протокола общения PostgreSQL с внешним миром.

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