PgConf.Russia 2016

Когда множество пользователей, процессов или потоков выполнения одновременно модифицируют их общие данные, это может вызывать проблемы, если каким-то образом не урегулировать условия гонки. Эти проблемы особенно остро проявляются в базах данных, реализующих семантику ACID. Набор изменений, объединённых в транзакцию базы данных, должен проявляться атомарно, и для параллельных транзакций, и для процесса восстановления после сбоя. Каждая транзакция должна переводить базу данных из одного согласованного состояния (с точки зрения бизнес-правил) в другое. Для эффективной разработки необходимо иметь возможность запрограммировать каждую транзакцию независимо от других транзакций, которые по стечению обстоятельств могут выполняться в то же самое время. В случае сбоя все изменения, внесённые транзакциями, об успешном завершении которых были уведомлены приложения, а также все изменения, ставшие видимыми для других транзакций, должны оставаться в базе после восстановления. За многие годы были выработаны различные стратегии обеспечения этих гарантий, а иногда гарантии корректировались тем или иным способом. В данном докладе будет рассказано, каким образом обеспечиваются эти гарантии или их компромиссные варианты, с упором на методику сериализуемой изоляции снимков (SSI, Serializable Snapshot Isolation), применяемую в PostgreSQL (и ни в какой другой производственной СУБД на данный момент). Хотя SSI уже работает быстрее и с большей степенью параллельности, чем любая другая методика управления условиями гонки с наиболее типичной нагрузкой, есть много путей для дальнейшего увеличения производительности, некоторые из которых требуют помощи эксперта по различным методам доступа индексов; эти вопросы и будут обсуждены в данном докладе. Кроме того, на докладе будут представлены некоторые общие идеи о том, как можно использовать методики SSI с XTM в распределённой системе. В конце мы оставили время для группового обсуждения оптимизации и возможных применений в распределённой среде.

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

Greenplum — это форк PostgreSQL, оптимизированный для использования в аналитике и хранилищах данных. Компания Pivotal в начале 2015 г. анонсировала, что часть её продуктов станут продуктами Open Source, в том числе и Greenplum Database. На этом выступлении будет представлен обзор истории Greenplum, всего процесса перевода продукта в мир Open Source и препятствий, с которыми мы столкнулись. Мы также расскажем, как можно принять участие в нашем проекте.

Самый часто используемый тип индексов в PostgresSQL - B-tree. Эта структура данных и связанные с ней алгоритмы развиваются уже больше 40 лет. Но, как мы знаем, нет предела совершенству. В этом докладе пойдет речь об особенностях структуры B-tree и его реализации в PostgreSQL, важных для оптимального использования индексов. Кроме того, мы представим улучшения функциональности B-tree в PostgreSQL, которые войдут в релиз 9.6. Это компрессия дубликатов и новые возможности использования покрывающих (covering) индексов.