Появившиеся в PostgreSQL 9.5 политики защиты строк (Row Level Security) предоставляют архитекторам и разработчикам новые возможности для разграничения доступа к данным. В докладе рассмотрим создание и управление политиками защиты срок.

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

Для решения обеих задач мы создали Patroni - служебную программу для запуска PostgreSQL кластеров, состоящих из одного ведущего узла и множества ведомых, а также автоматического переключения ведущих узлов в случае аварии. Мы расскажем об архитектуре Patroni и о том, как он используется для решения разнообразных задач в Zalando, от экспериментов с поточной реализацией и придания "отказоустойчивости" существующим базам данных до запуска серверов в контейнерах Docker на базе платформы AWS.

Patroni является открытым программным продуктом и поддерживается компаний Zalando и сторонними разработчиками на http://github.com/zalando/patroni

Everyone's familiar with the basic data types - numeric, text, boolean, and so on. In this talk, we'll quickly review those types, and then go further into exploring the diverse and powerful data types that make Postgres easier to model, perform better, and enable whole new use-cases.

In addition to the new and exciting JSONB data type, we'll also look at types like ARRAYs, range types, and how to use domains to construct your own data types and aggregates. We'll even examine some of the 3rd party data types like emails and URIs and talk about why these are possible, and how they can be practically harnessed to improve your applications.

В докладе расскажу о том как, используя open-source решение liquibase и некоторый свод своих правил, мы в компании обеспечиваем миграции (версионность) баз данных, применяем в разработке практику непрерывной интеграции (Continuous Integration), обеспечиваем на проектах стабильность работы баз данных в условиях хронического преобладания количества разработчиков над dba.

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

В докладе поговорим о реализации такого подхода в PostgreSQL, воплощенной в виде типа данных jsonb. Будет описана функциональность, предоставляемая для работы с jsonb, для расширения кругозора будет рассказано об альтернативных реализациях в других традиционных базах данных с детальным сравнением (MySQL, Oracle, MS SQL). Помимо этого, приведем ряд бенчмарков и примеров с пояснениями, чего не следует бояться, а чего, по возможности, стоит избегать. В заключение будет сказано пару слов об общем направлении развития и чего можно ожидать в недалеком будущем.

Криптографические операции над данными необходимы для обеспечения безопасной работы и минимизации последствий утечки данных. В докладе приводится классификация криптографических алгоритмов и рассказывается про область применения алгоритмов каждого класса.

Доклад описывает возможные модели угроз и возникающие при этом варианты выбора алгоритмов и варианты их использования в случае работы с PostgreSQL.

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

В докладе я расскажу о специфичных возможностях PostgreSQL, которые сильно упрощают разработку в фреймворке Ruby on Rails.

- Поля типа hstore, поиск по ним и их индексация, примеры использования;
- json и jsonb типы полей, примеры использования и обновление до jsonb;
- текстовые функции и их применение: pg_trgm - поиск с ошибками, prefix - поиск с префиксами и т.п.

Я расскажу о нашем опыте перевоза 300+ ТБ метаданных и 250k RPS нагрузки с одной коммерческой СУБД на букву "O" в PostgreSQL.

Как Яндекс.Почта бекапит сотни терабайт данных в PostgreSQL при помощи форка Barman с поддержкой параллелизма, сжатия и честных инкрементов (page-level). Подробнее Как Яндекс.Почта бекапит сотни терабайт данных в PostgreSQL при помощи форка Barman с поддержкой параллелизма, сжатия и честных инкрементов (page-level).

В докладе я расскажу:
- что побудило нас делать свое решение для бекапов и восстановления, а не использовать существующие;
- как мы реализовали каждую из фич: параллелизм, сжатие, page-level increments;
- как это все настроить у себя;
- как мы проверяем, что наши бекапы консистентны;
- каким мы видим будущее решений для бекапов и восстановления в PostgreSQL;

Материал доклада предполагает, что слушатели хотя бы раз делали бекап/восстановление PostgreSQL (любым существующим решением).

Являюсь разработчиком и администратором баз данных и связанных подсистем в Авито уже на протяжении многих лет. Хочу поделиться опытом, полученным в ходе масштабного проекта по миграции Авито между дата-центрами: как мы осуществляли планирование, подготовку и непосредственно переезд с переключением площадки. Опишу общие особенности и специфику нашей миграции, "подводные камни" и неочевидные ограничения, с которыми приходилось справляться, в том числе, и в экстремальных условиях. Доклад будет интересен как DBA так и DevOps специалистам.

С ростом объема данных, количества пользователей и, как следствие, ростом нагрузки, возникает вопрос о масштабируемой архитектуре и распределении нагрузки, сохраняя при этом консистентность данных и отказоустойчивость системы. В своем докладе я расскажу, как мы решаем эти вопросы в Avito. Речь пойдет о реализации отдельных компонентов мета-шаблона Lambda Architecture с помощью PGQ и Londiste:
1. Работа с разными моделями данных: для обновления и чтения информации.
2. Batch and stream processing, обрабатывающий 1000 событий в секунду.
3. Инициализация и поддержка remote aggregates data sources.
4. Сохранение консистентности данных.
5. Восстановление при авариях и др.

В докладе будет рассказано о том, как Linux работает с виртуальной памятью. Будут освещены следующие вопросы:
- устройство таблицы страниц в x86-64, переключение контекста, page fault;
- устройство системы управления виртуальной памятью (VMM) в Linux;
- методы вытеснения страниц в Linux, page cache и анонимные страницы;
- huge и gigantic pages, transparent huge pages;
- как работает mmap(2) и что дают madvise(2), msync(2) и пр.;
- почему большие СУБД не используют mmap(2), а реализуют свой пул страниц;
- и, конечно, как потюнить VMM в Linux с помощью sysctl.

Рассказ о том как вынести инфраструктуру в облако Microsoft и как там работает PostgreSQL.

This talk is designed for PostgreSQL administrators. It covers all aspects of PostgreSQL administration, including installation, security, file structure, configuration, reporting, backup, daily maintenance, monitoring activity, disk space computations, and disaster recovery. Подробнее This talk is designed for PostgreSQL administrators. It covers all aspects of PostgreSQL administration, including installation, security, file structure, configuration, reporting, backup, daily maintenance, monitoring activity, disk space computations, and disaster recovery. It shows how to control host connectivity, configure the server, find the query being run by each session, and find the disk space used by each database.

PostgreSQL обладает отличной расширяемостью, пользователи могут добавлять сами буквально всё: типы данных, функции, операторы, типы индексов, языки хранимых процедур и т.д. Для того, чтобы использовать многие из этих возможностей, нужно уметь программировать под PostgreSQL на C. Мы уже провели ряд мастер-классов, которые показали, что это не так уж и сложно.

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

В докладе мы расскажем, как pg_pathman'у удаётся в разы ускорить выполнение запросов к секционированным таблицам, как мы этого добились, а также покажем практические приёмы по работе с ним. Кроме этого, мы дадим обзор ситуации с секционированием в PostgreSQL core: патч декларативного секционирования, и то, как мы присоединились к работе над ним для 9.7. Подробнее Секционирование в PostgreSQL традиционно реализуется с помощью наследования таблиц. Однако, использование наследования таблиц не позволяет применять концепцию секционирования в полной мере. Среди ограничений можно выделить:
- медленное планирование запросов при большом числе секций (линейная зависимость от числа секций),
- отсутствие механизма выбора секций на этапе выполнения запроса,
- отсутствие упрощения условий фильтрации к секциям,
- отсутствие HASH-секционирования,
- необходимость ручного управления секциями.

Расширение pg_partman автоматизирует управление секциями, убирая второе ограничение. Однако, все остальные ограничения остаются в силе.

Для преодоления этих ограничений мы реализовали расширение pg_pathman, которое использует хуки планировщика, введённые в PostgreSQL 9.5 В докладе будет рассказано, как, внедрившись в код планировщика, удалось добиться следующих результатов:
- ускорено планирование запросов (логарифмическое время для RANGE-секционирования и близкое к константе для HASH-секционирования),
- реализовано HASH-секционирование,
- реализован механизм выбора секций на этапе выполнения запроса,
- реализован механизм упрощения условий фильтрации для сканирования секций,
- реализовано автоматическое управление секциями, включая добавление секции непосредственно при вставке.

В докладе мы расскажем, как pg_pathman'у удаётся в разы ускорить выполнение запросов к секционированным таблицам, а также покажем практические приёмы по работе с ним. Кроме этого, мы дадим обзор ситуации с секционированием в PostgreSQL core: патч декларативного секционирования, и то, как мы присоединились к работе над ним для 9.7.

Java is “the” Enterprise language, and probably the most used language to interact with a Postgres database. However, is Java with Postgres up to the task?

This talk will explore current limitations/issues in using PostgreSQL from Java, but will also try to provide solutions and/or paths to fix and improve the current situation. Special focus will be provided on achieving high performance and current best practices. Подробнее Java is “the” Enterprise language, and probably the most used language to interact with a Postgres database. However, is Java with Postgres up to the task?

This talk is a technical report on the state of the art of PostgreSQL and Java that will answer two basic questions:

* Is Java able to exploit 100% of the performance that PostgreSQL delivers? If not, where is the overhead? What can be done about it? Are there any technical or architectural patterns in PostgreSQL that may limit Java's performance?

* Can we access from Java all the available functionality exposed by PostgreSQL? If not, what is missing and how it can be fixed?

This talk will explore current limitations/issues in using PostgreSQL from Java, but will also try to provide solutions and/or paths to fix and improve the current situation. Special focus will be provided on achieving high performance and current best practices.

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

C2H5OH - это лёгкое и быстрое расширение для высокопроизводительного сервера nginx, позволяющее упростить и упорядочить серверную веб-разработку.

Не нужны скриптовые языки и тяжёлые фреймворки, достаточно PostgreSQL, nginx и c2h5oh. Я расскажу о личном опыте использования данного подхода, приведу примеры и результаты тестов.

An overview of the new features coming in 9.6.

Расскажу про способы достижения транзакционности в запросах между инсталляциями Postgres, о том почему эта транзакционность нужна и как масштабировать такие системы на чтение и запись.

PostgreSQL 9.5 has finally been released!

This talk will take a look at some of the new things coming in the new version, including things like UPSERT, GROUPING SETs, new WAL management and performance tools.

Размеры баз постоянно растут и не всегда есть возможность оперативно обновлять дисковую систему под растущие требования. Особенно неприятно, когда место на дисках заканчивается внезапно (в пятницу вечером) и нужно срочно что-то сделать, пока все не превратилось в тыкву.

В докладе пойдет речь об особенностях хранения данных в PostgreSQL, различных способах уменьшить занимаемое базой место, правильном проведении миграций на больших таблицах, мониторинге и выявлении проблем.

This talk takes a simple problem statement and shows five ways to write a query for it, the last one being the simplest of all using LATERAL.

Речь пойдет о достоинствах и недостатках инструментария Sequel. Этот компонент является полноценным ORM и QueryBuilder, объединяющий множество СУБД с проектами в экосистеме Ruby. Будут рассмотрены практические аспекты применения в приложениях, использующих всю полноту возможностей СУБД PostgreSQL. В доклад войдут примеры выполнения запросов с рекурсивным CTE, подзапросами, сложными выражениями, запросы со standby-сервера и др. Подробнее Доклад посвящен опыту использования ORM/DSL Sequel в Rails приложениях, обрабатывающих большие объемы аналитических данных. Не секрет, что подготовка отчетов требует использования практически всех возможностей языка SQL. В случае использования традиционных ORM, таких как ActiveRecord, вам может не хватить ёмкости DSL. Sequel решает эту проблему, поддерживая особенности синтаксиса 16 различных СУБД, против 6 у ActiveRecord.

Мы планируем рассмотреть примеры применения Sequel, в которых используются Recursive CTE, Grouping sets, slave-конфигурации. Расскажем о возможных проблемах.

1. Введение в проблему, примеры сложных запросов для расчета статистики.
2. Описание Sequel, преимущества, недостатки.
3. Опыт использования, проблемы и решения. Slave конфигурации.
4. Примеры с Recursive CTE, подзапросами и прочим.
5. Q&A

Иногда возникает необходимость частичного обмена данными между несколькими базами данных с одинаковой структурой, когда полная синхронизация данных не требуется. Пользователь выбирает некоторые записи для экспортирования из своей базы данных, а вместе с ними автоматически экспортируются и записи, связанные по внешним ключам с выбранными записями. При импортировании данных в целевую базу данных возникает целый ряд проблем, поскольку пользователи могут заполнять свои базы данных независимо друг от друга, не согласовывая свои действия. Технология решения описанной задачи реализована мною на примере библиографической информационной системы. Подробнее Всем известно о репликации, синхронизации и резервном копировании базы данных. Но иногда возникает необходимость частичного обмена данными между несколькими равноправными (не master / slave) базами данных, имеющими одинаковую структуру. При этом пользователи могут заполнять свои базы данных независимо друг от друга, не согласовывая свои действия. В результате тождественные данные в базах данных могут иметь не совпадающие уникальные идентификаторы, служащие первичными ключами. Например, в первой базе данных персоналия «Эндрю Таненбаум» в таблице «Персоналии» может иметь ID, равный x, эта же персоналия во второй базе данных может иметь ID, равный y, а в третьей базе данных такой персоналии может вообще не быть.

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

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

Мною предлагается технология решения описанной задачи. Она реализована на примере библиографической информационной системы.

"Нам нужны один (или несколько) мастер-узлов PostgreSQL в разных дата-центрах..." - один из наиболее популярных вопросов, которые консультант может услышать от своего заказчика. И правильный ответ на него: "ОК, какую задачу вы пытаетесь решить?" Кластер Master-Master любого типа не дает автоматических гарантий более высокой доступности по сравнению с Master-Standby. Более того, с кластером типа Master-Master куда легче облажаться, выбрав неправильные инструменты.

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

Примерное содержание:
- Проблематика хранения и обеспечения SLA для транзакционных данных PostgreSQL
- Аппаратные решения по обеспечению хранения бизнес-критичных данных PostgreSQL
- Комплексный подход к обеспечению доступности и непрерывности бизнес приложений на PostgreSQL
- Решения для резервного копирования и быстрого восстановления данных PostgreSQL
- Примеры реализации у заказчиков

Доклад представляет переосмысленную и расширенную версию моего выступления на meetup в Mail.ru в ноябре 2015 года ( http://www.slideshare.net/darthkremer/postgresql-54726684 ):
- изменена схема транспорта wal на standby;
- в полнотекстовом поиске стали использовать GIN вместо GiST индексов;
- анализ нагрузки по вновь смигрированным системам.

There have been many different ways to take backups of PostgreSQL systems over the years, and the tools to do so have evolved both inside PostgreSQL and as addons.

Are you using pg_dump for backups? Calling pg_start_backup()? Writing an archive_command? Then you're probably missing out on new features, and possibly even risking your backups.

In this talk we'll go through the "right" way to do backups on modern versions of PostgreSQL, both using builtin tools and proven external utilities.

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

В мире веб-технологий наблюдается значительный интерес к сравнительному анализу MySQL и PostgreSQL. Сообщество PostgreSQL проявляет достойную уважения активность в освещении сильных сторон PostgreSQL и слабых сторон MySQL. При этом сведения о MySQL часто содержат неточности и заблуждения, многие из которых я рассмотрел в серии статей "Памятка евангелиста PostgreSQL" на Хабрахабре.

В этом докладе я попытаюсь посмотреть на эту дискуссию с другого угла: порассуждаем о том, какие сильные стороны есть у MySQL, какие возможности позволяют этой СУБД обслуживать самые масштабные и высоконагруженные веб-проекты, а также попробуем ответить на вопрос "Когда PostgreSQL завоюет мир?"

A hands-on walkthrough of creating a custom aggregate in C, and packaging it as an extension.

В моем докладе я расскажу об open-source прототипе, разработанном в Zalando для сбора информации из изолированных PostgreSQL баз данных, применяющем возможности потоковой логической репликации в PostgreSQL с преобразованием данных для использования в разных системах их обработки (Data Lake, Operational Data Store, системы вычисления КПЭ или автоматического мониторинга за процессами). Слушатели узнают, как именно можно использовать логическую потоковую репликацию в мире микросервисов. Подробнее Стремительно стартовав в 2008 году, Zalando продолжает развиваться, не снижая скорости. На пути от скромного стартапа к многонациональной корпорации возникает множество сложнейших задач, особенно для Zalando Technology. Команда из 900 человек, распределенных в Берлине, Дортмунде, Дублине и Хельсинки, продолжает расти, планируя еще до конца 2016 года увеличиться в два раза.

Столь динамичный рост научил нас оперативно менять процессы и перестраивать организационную структуру в зависимости от актуальных задач. С марта 2015 года мы применяем Radical Agility — новейшую стратегию, провозглашающую Автономность, Целеустремленность и Мастерство (Autonomy, Purpose and Mastery) ключевыми принципами — для сплоченной работы команд программистов и менеджеров продукта.

Реализуя автономность, команды теперь могут самостоятельно выбирать стеки технологий для разработки своих продуктов. Микросервисы, использующие для коммуникации RESTful API, предполагают снижение стоимости интегрирования между такими командами. Изолированные AWS аккаунты, при поддержке разработанной в Zalando open-source PaaS платформы (STUPS.io), дают возможность каждой автономной команде использовать нужное ей количество вычислительных ресурсов для проведения экспериментов и выкатывания новых функций.

Возникает другая проблема с микросервисами, изолированными в собственных AWS аккаунтах: команды хранят данные локально, недоступно для централизованных процессов сбора данных. В такой среде довольно сложно автоматизировать ETL процессы для дальнейшего анализа данных или интегрировать данные, принадлежащие различным сервисам.

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

В моем докладе я расскажу об open-source прототипе, разработанном в Zalando для сбора информации из изолированных PostgreSQL баз данных, применяющем возможности потоковой логической репликации в PostgreSQL с преобразованием данных для использования в разных системах их обработки (Data Lake, Operational Data Store, системы вычисления КПЭ или автоматического мониторинга за процессами). Слушатели узнают, как именно можно использовать логическую потоковую репликацию в мире микросервисов.

PostgreSQL 9.6 is not done yet, and we are still in active development. However, a lot of things are already known - this talk will take a look at some of the things that are available in what will eventually become PostgreSQL 9.6.

Что мониторить и как: обзор решений для мониторинга PostgreSQL, построение self-hosted решения на Zabbix.

Мы обсудим результаты performance-тестирования PostgreSQL во FreeBSD и Linux (в том числе, Gentoo Linux). Я обещал организаторам не смеяться, поэтому доклад пройдет в атмосфере пленумов ЦК КПСС. Есть видеоанонс доклада, в котором я даже не улыбаюсь: http://pgday.ru/video/PostgreSQL_Announce.mov

- преимущества и недостатки MPP-архитектуры
- выбор среди доступных MPP-систем, почему выбрали Greenplum
- архитектура Greenplum
- интеграция Greenplum c системами хранилища (SAS, Informatica, Hadoop)
- мониторинг
- несколько best practices + возникшие проблемы

Greenplum DB - массивно-параллельная СУБД без разделяемых ресурсов, построена на базе PostgreSQL, в конце прошлого года продукт выведен в OpenSource.

1. Обзор истории возникновения и развития Greenplum.
2. Обзор архитектуры и ключевых компонентов системы.
3. Основные возможности платформы.
4. Загрузка данных.
5. Выполнение запросов.
6. Интеграция с Hadoop.
7. Дальнейшее направление развития.

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

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

Наконец, мы поговорим о том, как разные представители сообщества могут общими силами повлиять на изменение репутации открытых СУБД, чтобы увеличить количество переходов на них среди крупных компаний и государственных организаций во всём мире.

Некоторое время назад в JetBrains решили, что те возможности, которые предоставляют IDE на плафторме IntelliJ для работы с базами данных, могут быть интересны не только разработчикам на java или php, но и тем, для кого работа с данными — основная деятельность. Так появился DataGrip — продукт для SQL разработчиков, который может подключиться к любой СУБД и обладает всеми преимуществами других IDE от JetBrains.

В докладе будут рассмотрены базовые примеры использования DataGrip, сделан акцент на некоторых уникальных возможностях и показано, как избежать рутины в работе с SQL.

One of the hardest parts of upgrading PostgreSQL between major versions is the downtime required. However, since 9.4 was released it has been possible to migrate from 9.4+ to 9.5+ with zero downtime. This talk includes a live demo!

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

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

В данный момент, для переадресации запросов к новому ведущему серверу используется следующие подходы:
- передача запросов на актуальный ведущий сервер через proxy-сервер (pgbouncer, pgpool, haproxy и пр.);
- перенаправление запросов путем перенастройки работы сети (NAT, перенос IP-адресов);
- переадресация запросов средствами DNS.

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

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

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

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

Доклад посвящен новым возможностям B-tree, которые позволяют уменьшить размер индексов и значительно ускорить их работу. Покрывающие индексы, сжатие дубликатов, а также roadmap будущих улучшений. Теория от разработчиков и множество примеров реального использования.

Все мы пишем тесты (O RLY?), хотя и не любим это делать. Не написал тест - получишь "факап" и, вместе с написанием теста, будешь чинить данные.

В этом докладе я хочу рассказать:
- как полюбить писать тесты для PL/pgSQL c применением BDD (python, behave, py.test);
- как мерить code coverage для хранимых процедур;
- как автоматизация нам поможет страдать поменьше.

JavaScript покинул браузер и захватывает мир, исполняясь на всех доступных машинах Тюринга.
Оказывается, JS может вполне комфортно существовать и внутри PostgreSQL благодаря расширению plv8, поддержке бинарного типа данных JSONB и гибкой системе индексирования.

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

In this talk I would like to draw the listeners' attention to some of the unexpected aspects of PostgreSQL statistics analyzer behavior, shed some light on the current state of affairs, propose a possible solution to some of the highlighted problems and hopefully ignite a general discussion on this subject.

In respect to storage, retrieval, aggregation and reporting of industrial manufacturing data, special considerations are needed. Data are immutual and written only once. Customers are normally interested in streams and aggregations, not in a single data record. Really "Big Data" may apply.

In one of our projects, we have to store more than 3 million measurements every second into PostgreSQL, resulting in a Terabyte database. Technicians expect to evaluate both live data and historical data within an acceptable period of time. Not only within the company's network, but also outside using tablet or smartphone.

By example of real live industrial projects, the requirements and technical aspects of our solutions will be explained. This includes how the required performance is achieved by using PostgreSQL array features and XML capabilities.

Рассказ пойдет о состоянии сообществ разработчиков, использующих PostgreSQL в мире, на основе данных Stack Overflow.

Полнотекстовый поиск присутствует в PostgreSQL больше 10 лет. За это время он прочно обосновался в ядре и получил широкую известность. Но это не повод его не улучшать. В докладе будут представлены новые возможности, внесенные в будущую версию PostgreSQL 9.6, такие как: значительное уменьшение времени поиска, новые функции работы с данными, улучшение словарей и давно ожидавшийся поиск фраз.

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

В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.

У PostgreSQL нет встроенных средств для учета производимых изменений и командной работы над БД. И разным командам приходится решать этот вопрос индивидуально.

Как гарантировать, что БД полностью занесена в репозиторий? Как гарантировать обратное - что БД полностью восстановлена из репозитория? Как вести разработку средствами БД, но при этом быть уверенным, что все изменения буду закоммичены? Как провести слияние веток своим любым средством? Как накатить патч? А что делать со справочниками?

Наш подход позволяет команде из 6 базистов согласовано работать без страха отстрелить соседу ногу. А если инцидент и происходит, то без головной боли найти виновного и исправить последствия. Подход оттачивался в течение 3 лет и включает в себя манифест и пару утилит. И тем, и другим мы готовы поделиться.

Построение GIN может занять много времени и требует 100% процессорного времени. Но мы легко можем использовать более чем 100%, особенно теперь, когда в постгресе есть parallel workers. Это позволяет ускорить построение GIN в разы. В докладе раскрыт подход, реализация и результаты.

Основная идея доклада - опыт использования PostgreSQL в системах анализа и моделирования обстановки, оперативного управления и поддержки принятия решений. Ключевая особенность - необходимость обработки терабайт как структурированных, так и слабо структурированных данных: телеметрии, геометрии и др.

В настоящее время осуществляется переход на унифицированное хранение данных на базе PostgreSQL с использованием следующих способов взаимодействия:
1. Классический реляционный для нормативно-справочной информации, исходных данных, символик отображения.
2. Объектно-ориентированный для слабо структурированных данных (динамические данные по объектам управления). Переход с MongoDB на JSONB и использование VODKA (в перспективе).
3. Семантический поиск для анализа накопленных данных. Использование ontop над PostgreSQL.

Партицирование:
1) обоснование и примеры использования,
2) настройка - шаг за шагом,
3) особенности использования в проектах Ruby on Rails - возможные проблемы, решения, краткий обзор гемов для работы с партицированными таблицами.

A lot has changed since SQL '92 but it seems that many developers didn't get the memo. This talk describes modern techniques implemented in PostgreSQL that help you get the job done faster and cleaner.

A look at the different indexing strategies available in PostgreSQL and how they do their thing.

В докладе предлагается вариант оптимизации обработки большого объёма статистических данных.

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

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

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

PL/pgSQL is a very robust development language that allows you to write complex business logic. The downside is: as the complexity of your functions grows, how do you debug them? We have all used RAISE statements to print out the progress of our functions, but they can quickly overwhelm your logs and become useless.

In this talk, we will:
- Walk through the setup of 2 key PostgreSQL extensions, the PL/pgSQL Debugger and the PL Profiler
- Demonstrate how the PL Profiler can identify problem areas in your functions
- Setting breakpoints in functions and triggers
- Stepping through PL/pgSQL functions
- Discuss the performance impact of running the extensions on production environments

Apache HAWQ - решение класса SQL on Hadoop, построенное на базе PostgreSQL и представляющее собой порт Greenplum DB. Позволяет выполнять SQL запросы на данных HDFS путем форка postgres-процесса на DataNode.

1. Обзор истории возникновения и развития HAWQ.
2. Обзор архитектуры и ключевых компонентов системы.
3. Основные возможности платформы.
4. Загрузка данных.
5. Выполнение запросов.
6. Сравнение с конкурентами (Hive, Impala).
7. Дальнейшее направление развития.

В рамках мастер-класса мы рассмотрим и решим с помощью продвинутых средств PG следующую задачу.

Есть множество людей, у которых известны координаты и относительно большой массив социальных данных. По запросу от каждого человека требуется выдавать список других "подходящих" близких, отсортированных по рангу, зависящему функционально от этих данных. Задача возникает в случае классического геодейтинга, но с "хитрой" выдачей.

В общем случае, для сколько-нибудь значимого объема данных такое не решается в рантайме с помощью ORDER BY. Будут подробно рассмотрены следующие инструменты: intarray для хранения массивов данных, PostGIS для работы с геоданными, FDW для общения служебных баз с мастер-базой.

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

Есть множество людей, у которых известны координаты и относительно большой массив социальных данных. По запросу от каждого человека требуется выдавать список других "подходящих" близких, отсортированных по рангу, зависящему функционально от этих данных. Задача возникает в случае классического геодейтинга, но с "хитрой" выдачей.

В общем случае, для сколько-нибудь значимого объема данных такое не решается в рантайме с помощью ORDER BY. Будут подробно рассмотрены следующие инструменты: intarray для хранения массивов данных, PostGIS для работы с геоданными, FDW для общения служебных баз с мастер-базой.

В каждом случае мы рассмотрим предоставляемую функциональность, попробуем докопаться до сути происходяшего под капотом, научимся просто генерировать большой объем адекватных тестовых данных, посмотрим и обсудим запросы к базе и результаты EXPLAIN.