PgConf.Russia 2016

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

Использование слабоструктурированных данных определенно является трендом современности, и это верно не только для NoSQL, но и для традиционных RDBMS. Многие реляционные базы данные (например, PostgreSQL, Oracle, db2, Mysql) позволяют хранить данные в json формате, и, очевидно, реализуют это по-разному.

Доклад содержит две части:

• Сравнение поддержки json в PostgreSQL и других реляционных базах данных, а именно Mysql, Oracle, db2, MSSql в контексте реализованных возможностей, функций и т.д.
• Сравнение производительности для баз с наиболее полной поддержкой json (PostgreSQL и Mysql) а также MongoDB на различных видах нагрузок и конфигураций.

• Первое появление постгреса в команде
• Борьба с репликацией
• Партицирование и миграции
• Кросс-датацентровое использование
• v8, json, jsonb, jsquery
• Апгрейд версии postgresql

На данный момент на продакшене бекенда справочного API 2GIS мы имеем с десяток различных баз в postgresql, около 120 шардов, миллионы записей в таблицах. При этом практически все данные хранятся в структурах jsonb

Я расскажу об эволюции продукта с точки зрения взаимодействия с СУБД.

When new versions of Postgres are released most of the attention is focused on new features. Inevitably a release note claiming speed improvements seems relatively mundane and doesn't provide the compelling argument for upgrading. However the reality is that these speed improvements represent pain points that have been identified and solved.

Reviewing the changes to the sort code in Postgres over the last 10 years clearly shows the kinds of problems users have run into. As usage patterns changed over years, databases scaled up, and hardware changed new problems arose and drove further development to solve them.

Upcoming changes in 9.5 and 9.6 will dramatically change the experience further. Making sorting UTF8 and other encodings less of a problem and handling scaling to larger machines with many processors and memory cache more effectively.