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

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

Речь пойдет о достоинствах и недостатках инструментария Sequel. Этот компонент является полноценным ORM и QueryBuilder, объединяющий множество СУБД с проектами в экосистеме Ruby. Будут рассмотрены практические аспекты применения в приложениях, использующих всю полноту возможностей СУБД PostgreSQL. В доклад войдут примеры выполнения запросов с рекурсивным CTE, подзапросами, сложными выражениями, запросы со standby-сервера и др. More Доклад посвящен опыту использования 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

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

В докладе пойдет речь об особенностях хранения данных в 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. More 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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

Sometimes there is a need for partial exchange of data between multiple databases with identical structure, when complete data synchronization is not required. A user selects some records to export from his database, and records related to the selected records by means of foreign keys are exported automatically. When making import of data into the target database a number of problems emerge, because users can put data into their databases independently of each other, without coordinating their actions. A technology for solving this export/import task is implemented for my bibliographic information system. More Everyone knows about replication, synchronization, and backup of databases. But sometimes there may emerge the need for partial exchange of data between several peer (not master/slave) databases all sharing the same structure. Users may put data into their databases independently of one another and without coordination of their database activities. As a result, identical data in different databases might have not identical IDs which are used as primary keys. For example, the person “Andrew Tanenbaum” in the first database might have ID x , and the same person in the second database might have ID y , and the third database might not contain this person at all.

Partial exchange of data means that only some tuples are extracted (exported) from different tables that are linked via foreign keys. When a tuple from a referenced table is exported, then some tuples from referencing tables might be exported too. One knows that references made by one table to another table may constitute rather long chains of references. We will use the term cluster for the total collection of exported tuples.

When importing the cluster into the target database we have to not only check data for duplicates but we have to solve the problem of adjusting primary keys of identical data elements that reside in the exported cluster and in the target database. Recall that users put data into their databases independently of each other. In addition, of course, it would be desirable to have a possibility to import into the target database just some portion of tuples from the cluster that was exported from some source database.

I can suggest a method for solving this problem of partial exchange of data. This method was applied when my bibliographic information system has been developed.

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

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

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

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.

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.

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

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

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

An overview of the new features coming in 9.6.

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. More 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.

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

"We need two (or n) PostgreSQL masters in different data centers..." - this is one of most the popular questions that consultants can hear from their customers. And the correct answer is: "OK, what kind of task are you trying to solve?" Active-Active cluster of any kind doesn't automatically provide more availability than Active-StandBy. Moreover, things can be screwed up much easier with wrong tools.

In this talk I will guide you through some theory on what is exactly high availability and with what kind of algorithms, protocols and approaches you may achieve it. Every approach has some strengths and weaknesses, which I will illustrate with examples. Finally, I will show examples of real life solutions with variations in balance
between performance and availability.

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

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

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

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

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

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

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

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

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.

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.

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!

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

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

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

In the last ten years, open source databases have made a tremendous leap from being mainly used for Web applications and non-business-critical systems, to heavy adoption by enterprise core business-critical applications around the world. This presentation looks at the history of enterprise open source adoption, why enterprises adopt open source software and answers some of their questions and concerns.

We will also examine how enterprises should choose open source software, and how they can successfully select applications that easily use open source databases.

Finally, we will talk about how the community can work together to help build up the reputation of open source databases, and continue to grow adoptions by enterprises and governments globally.

We'll discuss how does Linux work with virtual memory. The following topics will be covered:
- x86-64 page table, context switch and page fault;
- internals of virtual memory management (VMM) in Linux;
- page eviction methods in Linux, page cache and anonymous pages;
- huge and gigantic pages, transparent huge pages;
- how mmap(2) works and what madvise(2), msync(2) etc. provide;
- why large databases don't use mmap(2), but rather implement buffer pool on their own;
- and, surely, how to tune Linux VMM using sysctl.

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.

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

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

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

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

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

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

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