PgConf.Russia 2016

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

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

Корейская группа пользователей PostgreSQL была относительно мала и неактивна многие годы. Однако недавно, в Корее стали происходить изменения. Компании начали искать альтернативы применяемым дорогостоящим проприетарным РСУБД в целях сокращения TCO. Эту тенденцию также поддержали правительственные организации. Мы, компания Bitnine, руководим этим процессом в Корее. В 2015 г. мы запустили первую версию нашего решения на базе PostgreSQL, Agens SQL. Мы переводим документацию PostgreSQL на корейский и ведём группу пользователей PostgreSQL, а также пытаемся участвовать в работе глобальной группы разработчиков PostgreSQL. Кроме того, в этом году планируется проведение первой корейской конференции PostgreSQL и руководить её организацией будем мы. На этом выступлении мы сообщим о текущем состоянии корейской группы пользователей PostgreSQL и рынка СУБД PostgreSQL в Корее. Мы также расскажем о нашей деятельности в Корее и об историях успешного перехода с проприетарных РСУБД на PostgreSQL.

За годы моей работы с PostgreSQL возникло ясное представление, о том, каковы его основные достоинства ("Киллер-фичи", "вкусняшки"), из-за которых мы выбираем и рекомендуем выбирать эту СУБД.
1. Начало
2. Документация
3. Комьюнити
4.1 Транзакционный DDL
4.2 WAL и настоящая физическая репликация
4.3 Транзакционный снепшот и настоящая логическая репликация и PGQ
4.4 Потрясающая расширяемость
5. Успех

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