PgConf.Russia 2016

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

Изначально компания «БАРС Груп» была ориентирована на задействование в своих проектах СУБД Oracle, но появление PostgreSQL игнорировать не могла. На конференции мы расскажем, как пришли к использованию PostgreSQL и поделимся опытом перевода на эту СУБД большой медицинской информационной системы.

1. Опыт использования СУБД PostgreSQL и Oracle в проектах компании. Предпосылки и мотивация использования СУБД PostgreSQL.

2. Ход и результаты эксперимента миграции медицинской информационной системы:

   • разработка утилиты конвертации кода PL/SQL в PgSQL;
   • проблемы переноса сложных пакетов;
   • патчи к PostgreSQL как варианты решения этих проблем.

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

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