Программа PgConf.Russia 2017

Машины баз данных — представители «высшего света» в мире корпоративных ИТ; Teradata, Exadata, Netezza — не смотря на то, что в их основе вполне доступные серверные узлы архитектуры x86 — о них говорят и пишут как о hi-end-системах, на что есть определённые основания. Объективно машины баз данных востребованы многими корпоративными заказчиками, как за уникальные возможности, так и за те удобства, которые дают готовые предконфигурированные комплексы.

Консорциум в составе системного интегратора IBS, выполнившего немало проектов по внедрению различных машин баз данных, российского вендора PostgreSQL Postgres Professional и израильской компании-разработчика суперкомпьютерных сетевых решений Mellanox представил машины баз данных в различных конфигурациях для PostgreSQL под управлением СУБД Postgres Pro Enterprise.

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

Многие знают, что соединения в PostgreSQL дорогие, а потому их надо экономить. Для решения этой задачи давно есть PgPool-II и PgBouncer. В Яндексе никого не удивить десятками тысяч соединений к одной базе и с незапамятных времён мы используем pgbouncer. В этом докладе я расскажу о проблемах, с которыми мы сталкивались, и способах их решения.

MongoDB – популярная NoSQL CУБД, используемая в основном для работы с OLTP системами. Но из-за отсутствия требований ACID (в частности, транзакций как таковых), а также серьезных проблем с производительностью при работе с OLAP/DW нагрузками, все больше пользователей MongoDB рассматривают возможность перехода на реляционные СУБД, выбирая зачастую именно PostgreSQL. Это открывает перед сообществом PostgreSQL большие возможности по “обращению” пользователей из NoSQL в SQL. В этом докладе мы расскажем о сложностях, с которыми сталкиваются пользователи MongoDB, и представим соверменные инструменты и open-source решения, с помощью которых можно осуществить миграцию на PostgreSQL в режиме реального времени или через процесс ETL. В частности, мы обсудим ToroDB Stampede – open-source решение, которое создает реплику MongoDB в режиме реального времени, конвертирует документы JSON в реляционные таблицы и сохраняет данные в PostgreSQL.

Я представлю новый метод доступа, который расширяет имеющиеся возможности GIN-индексов, используя дополнительную информацию, хранящуюся в списке/дереве идентификаторов. Например, дополнительная информация о позициях позволяет новому методу доступа возвращать результаты по релевантности, что может значительно сократить время исполнения полнотекстовых запросов. Это также может ускорить фразовый поиск, так что данный метод будет весьма эффективным при полнотекстовом поиске. Сохранение временных меток открывает перед нами несколько интересных возможностей – мы можем отсортировать результаты по времени (например, свежие статьи, удовлетворяющие полнотекстовому запросу) на основе временных меток как таковых или сохраненных указателей, упорядоченных по временным меткам. Оба способа обеспечивают на порядок большее ускорение для таких типов запросов.

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

Этот доклад будет интересен как Oracle DBA, рассматривающим PostgreSQL как альтернативную реляционную СУБД в своем портфолио, так и PostgreSQL DBA, которые хотят сравнить Oracle и PostgreSQL. Этот доклад не является руководством по миграции или призывом использовать ту или иную платформу. Мы сравним общую структуру обеих платформ с точки зрения конфигурирования памяти, логические структуры данных и их физическое представление, затронем некоторые вопросы безопасности, а также рассмотрим имеющиеся инструменты резервного копирования и восстановления данных.

Шардингом базы данных называют распределение данных по большому количеству серверов для повышения производительности при работе с большими объемами данных. С появлением технологии Foreign Data Wrappers (FDW), стало возможным рассматривать шардинг в постгресе при разумном объеме изменений программного кода. Я занимаюсь улучшением инфраструктуры FDW, в т.ч. наследованием внешних таблиц и push-down запросов, что позволяет постгресу эффективно исполнять распределенные запросы через FDW. В этом докладе мы рассмотрим шардинг на FDW и его сценарии использования, затем я продемонстрирую, как организовать шардинг, и покажу, что для этого было сделано в постгресе. В заключение мы рассмотрим основные планы на будущее - в первую очередь, это асинхронное исполнение запросов и поддержка распределенных транзакций.

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

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

Секционирование в PostgreSQL - давно ожидаемый функционал. И хотя в Postgres возможно реализовать секционирование через наследование, такой подход имеет ряд недостатков, таких как необходимость вручную создавать секции и поддерживать триггеры, значительные накладные расходы на планирование и отсутствие оптимизаций времени выполнения. В докладе мы расскажем про расширение pg_pathman, над которым мы работаем. pg_pathman поддерживает HASH и RANGE секционирование и выполняет оптимизации на этапах планирования и исполнения, поддерживает быструю вставку за счет отказа от триггеров в пользу Custom Node, содержит функции для управления секциями (add, split, merge и др.), поддерживает FDW, неблокирующую миграцию данных и другие возможности. Мы также расскажем об интеграции pg_pathman в PostgresPro Enterprise Edition и поддержку Oracle-подобного синтаксиса для секционирования. В завершение мы расскажем о новых возможностях секционирования в PostgreSQL 10, что реализовано и пути дальнейшего развития.

Большие потоки данных нередко могут создавать проблемы даже с самой их загрузкой в БД - кроме загрузки собственно данных необходимо создавать для них индексы, проводить после загрузки VACUUM как для корректной работы Index-only scans и т.п. О том, как можно если не избежать этих проблем, то, по крайней мере, в значительной степени избежать их и посвящен этот доклад.

В докладе будет освещена автоматизация перехода в PostgreSQL c других баз данных с помощью Ispirer Migration and Modernization Toolkit. Будут затронуты вопросы миграции данных и SQL кода, конвертации клиентских приложений, встроенного SQL и API баз данных, рассмотрены примеры осуществлённых проектов по миграции из Oracle в PostgreSQL и из Microsoft SQL Server в PostgreSQL.

Современным высокопроизводительным и горизонтально-масштабируемым СУБД в ходе своей работы требуется перемещать огромные объемы данных между компонентами системы. Справляться с этой задачей они должны быстро и без задержек для пользователей. Именно на высочайшей пропускной способности, ультранизких задержках, а также разгрузке CPU от сетевых задач фокусируется компания Mellanox при разработке своих технологий интерконнекта. В своем докладе Михаил расскажет какую роль быстрая сетевая инфраструктура играет в системах СУБД и Big Data, а также поделится опытом компании Mellanox по построению таких систем совместного с ведущими мировыми производителями.

В машинах баз данных от Oracle и Teradata в качестве внутренней сети применяется Infiniband, и для его использования вендорами созданы проприетарные протоколы (iDB, BYNET). Для комплексов Скала-СР / Postgres Pro применен интерконнект на базе Ethernet со всеми свойствами, присущими Infiniband — субмикросекундными задержками, стагигабитной пропускной способностью, и, главное, поддержкой RDMA — протокола прямого доступа к оперативной памяти удалённых узлов с разгрузкой центральных процессоров от транспортных операций. Специально для поддержки этих возможностей в машинах баз данных в Postgres Professional разработали программные дополнения, обеспечивающие доставку журналов упреждающей записи и координацию транзакций по RDMA, им и будет посвящена основная часть доклада. Кроме того, в докладе будут представлены конфигурации, основные технические характеристики и результаты испытаний комплексов линейки Скала-СР / Postgres Pro.

1. Особенности взаимодействия 1С:Предприятие 8 и PostgreSQL 9 1.1 Изменения в редакциях платформы 1С 1.2 Схемы v81c_data и v81c_index 1.3 Трансляция запросов 1С в SQL 1.4 События технологического журнала 1С для диагностики PostgreSQL
2. Анализ запросов, вызывающих проблемы производительности в PostgreSQL 2.1 Бесплатный инструмент для автоматизации разбора логов 2.2 Правило Парето на практике 2.3 Установка и настройка инструмента 2.4 Практический пример оптимизации запроса 2.4.1 Проблема в запросе PostgreSQL 2.4.2 Выяснение нерациональных операций в запросе 2.4.3 Способы устранения неоптимальностей
3. Статистка PostgreSQL для диагностики производительности 3.1 Сравнение с возможностями MS SQL Server, различия 3.2 Диагностика блокировок 3.3 Диагностика рабочей нагрузки 4 Примеры из практики команды gilev.ru

В докладе я расскажу почему Postgres отлично подходит как BI платформа для решения классических OLAP-задач.

Будет дан краткий обзор доступных open source BI решений. Расскажу об архитектуре нашего решения (snowflake scheme), как мы делаем Extract Load Transform, настройках Postgres для специфических профилей нагрузки. Также упомяну о том, как мы пытались использовать Postgres в виде колоночной базы данных (cstore_fdw от Citus) и что из этого вышло. В конце доклада кратко расскажу про минусы и проблемы нашего подхода.

В докладе будет рассказано о том, как мы реализовали хранение таблиц с большим количеством строк (1 млрд + строк в сутки). Проект существует в production 2 год. Это крупный транспортный проект всероссийского масштаба.

Суммарный объем данных 300 Tb на 25 серверах PostgreSQL * 2 Data Center. Будет рассказано об ошибках организации хранения больших таблиц на начальном этапе проекта, и о том как эти ошибки были устранены. Так же расскажу о том, как организована ротация данных и архивирование. Затрону вопросы о том, чего нам не хватало в PostgreSQL 9.4 из того, что появилось в 9.5 и в 9.6. А так же, какие новые возможности, нам хотелось бы увидеть в новых релизах PostgreSQL.

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

Разработку таких приложений можно значительно упростить, если использовать NoSQL-функциональность PostgreSQL, особенно json и jsonb.

1. Почему сейчас самое время задуматься о переходе на PostgreSQL.
2. Готовность 1С и PostgreSQL работать друг с другом.
3. Почему нужно начать с Windows
4. Первый опыт перевода достаточно больших баз 1С на Postgre.
5. Масштабные проекты на высоконагруженных системах, примеры в цифрах
6. На что обратить внимание в коде 1С? Результаты оптимизации кода в обработке «Печать ценников и этикеток».

Большинство из основных сервисов компании Skype использует платформу баз данных, построенную на основе PostgreSQL и других open-source технологиях, таких как Skytools, plProxy, pgBouncer и других. Эта платформа состоит из нескольких сотен серверов с тысячами баз данных, которые обрабатывают сотни тысяч транзакций в секунду. При этом архитектура платформы позволяет ее пользователям (приложениям и их разработчикам) работать с "логическими" базами данных, не беспокоясь об их реальной "физической" структуре.

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

Для хранения и обработки пространственных данных в Postgres существует расширение PostGIS. В нём обычно рассматривается обычная Евклидова плоскость без времени и неопределённости, но реальный мир зачастую сложнее. Посмотрим, как можно сделать так, чтобы тысячи машинок плавно ездили по карте OpenStreetMap в реальном времени с помощью Postgres.

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

В докладе будет рассказано о практике применение отечественного оборудования и свободного ПО, включая PostgreSQL, для миграции центра обработки данных государственной информационной системы, использовавшей оборудования и ПО IBM. Будет рассказано о применённом подходе и технологиях миграции БД “наживую” без останова работы Системы с IBM DB2 на PostgreSQL, о оптимизациях PostgreSQL для использования на процессорах Эльбрус, о практическом опыте эксплуатации cистемы.

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

В компании Skype мы сталкиваемся c разнообразными проблемами, связанными с тестированием баз данных: - Обобщение и отражение в тестовой среде всего многообразия вариантов продуктовой среды для тысяч реализаций PostgreSQL, связанных с удаленным вызовом процедур (RPC) и репликациями, серверной инфраструктурой, а также внешними скриптами БД. - Постоянно растущие требования к поддержке новых аппаратных средств, недостаточная очистка тестовых данных. - Различия между тестовой и продуктовой средой со временем накапливались.

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

Доклад посвящён миграции Системы документационного управления «Приоритет» в рамках идеологии импортозамещения с MS SQL на Postres 9.5 и выше. Будут затронуты особенности архитектуры решения и сложности с которыми столкнулись при миграции T-SQL кода на pgsql и как они были решены.

Подробнее: https://pgconf.ru/news/94168

В прошлом году был принят стандарт ISO/IEC 9075-2:2016, в котором наконец-то был стандартизирован синтаксис и семантика JSON и операций над ним в языке SQL. В докладе будет рассказано о требованиях этого стандарта и чем они отличаются от реализации JSON/JSONB в PostgreSQL, в частности, о JSON Path (аналог XPath для XML), о SQL/JSON функциях и о том, что мы планируем сделать в PostgreSQL для соответствия стандарту.

Обзор архитектуры СУБД Greenplum Database (GPDB) с массивно-параллельной архитектурой (MPP). Из этого доклада вы узнаете о внутреннем устройстве GPDB, научитесь конфигурировать и настраивать GPDB, а также распределять данные для эффективной работы с MPP.

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

Краткий рассказ о том, чего за 2 года работы добилась компания Postgres Professional.

• наши достижения в разработке PostgreSQL.
• что такое российская СУБД Postgres Pro и как она соотносится с PostgreSQL
• что такое Postgres Pro Enterprise и почему Enterprise.
• что с учебными курсами и сертификацией?

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

1) О Чемпионате мира по футболу 2018 и поставленных задачах; 2) Инструментарий отдела моделирования и аналитики; 3) Аналитика пассажиропотоков аэропорта Кольцово и железнодорожного транспорта дальнего и ближнего сообщения (Яндекс.Расписания); 4) Анализ населенности и занятости населения (2ГИС); 5) Прокладка маршрутов клиентских групп с автоматическим выводом метаинформации и сборка отчетных материалов (PostgreSQL + QGIS + Python + LaTeX); 6) Развертывание карт-сервера для предоставления доступа к маршрутам заказчику (Ubuntu + PostGIS + QGIS-Web-Client)

Практический опыт миграции с Oracle и MS SQL Server на PostgreSQL с помощью технологии Database Adapter.

Технология миграции: - Эмуляция протоколов взаимодействия клиент-сервер. - Миграция из одной СУБД в другую, критичные отличия и способы решения. - Обзор успешных проектов. - Референс: Рассказ об опыте миграции от Босс Кадровик при участии заместителя генерального директора АО "БОСС. Кадровые системы" Гусева Михаила Анатольевича.

Приводятся некоторые примеры и приёмы в проектировании архитектуры Web-приложений с совместным использованием технологий ORM с применением хранимых процедур Postgres на примере Python Django. Рассматриваются варианты реализации бизнес-логики в рамках СУБД с сохранением преимуществ Django и применения встроенной админ-панели.

Часто бывает так, что у вас уже есть postgresql в production, но нет выделенного DBA. Для того, чтобы база данных не была для вас черным ящиком, я расскажу как диагностировать различные проблемы в ходе эксплуатации постгреса. Мы попробуем разобраться, как ответчать на "бытовые"" вопросы обычного системного администратора: - все ли хорошо с базой сейчас - на что тратятся ресурсы сервера БД - что в первую очередь оптимизировать, чтобы уменьшить потребление ресурсов

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

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

Я очень люблю сложные предметные области, строгую типизацию в приложении и 3НФ, но очень не люблю ORM. Поэтому мне приходится активно использовать хранение сериализованных структур в json-полях (даже до появления типа json). В докладе расскажу о некоторых особенностях работы с хранением сложных объектов внутри полей СУБД, расскажу где и как подстелить себе соломку и какие проблемы могут возникнуть.

В этом докладе будут рассмотрены идеи и их реализации по ускорению различных частей обобщённых поисковых деревьев (GiST) :

1. Внутристраничное индексирование
2. Технология фрактальных деревьев
3. Применение современных алгоритмов индексирования многомерных данных (RR*-дерево)
4. Возможные расширения интерфейса GiST

В данный момент в PostgreSQL для исполнения SQL-запросов применяется интерпретатор, реализующий модель итераторов (Volcano-модель). В то же время можно добиться существенного ускорения, выполняя динамическую компиляцию запроса «на лету». В этом случае можно генерировать код, специализированный для конкретного SQL-запроса, а также применять компиляторные оптимизации, учитывая, что во время выполнения уже известна структура используемых таблиц и типы данных. Такой подход особенно актуален для сложных запросов, скорость выполнения которых ограничена производительностью процессора.

Мы используем PostgreSQL с 2003 года и прошли путь от базы в пару гигабайт до кластера с текущим размером более 5Тб. Текущие кол-во таблиц > 700, число хранимых процедур ~1500. Чем готовы поделиться: - рассказать о проблемах, с которыми пришлось сталкиваться на разных этапах развития и найденными решениями - наработанными практиками администрирования - мы работаем с несколькими базами, которые тесно связаны друг с другом, используем для этого свое расширение - у нас работает несколько команд, и есть выработанная методика и инструменты, которые позволяют им не мешать друг другу - мы используем много различных стендов для тестирования, готовы рассказать по какому принципу и как мы их поднимаем - ну, и конечно, про оптимизацию, поиск узких мест и ситуаций, с которыми нам приходится сталкиваться при нагрузках

Небольшой доклад о том как Avito собирает и мониторит нагрузку на базы данных. Отправка метрик из хранимых процедур в Graphite. Сбор метрик pg_stat* и отображение их в Grafana. Примеры из жизни.

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

Год назад мы ступили на долгий путь реализации в Citus возможности горизонтального масштабирования в новом измерении - для повышения скорости записи. Так как все запросы на запись обрабатывались через один узел PostgreSQL, скорость записи в Citus ограничивалась CPU-ресурсами одного узла. Citus MX - это новая версия Citus, которая предоставляет доступ к распределенным таблицам с любого узла, обеспечивая повышение скорости записи до уровня NoSQL решений.

Команда Dalibo уже много лет выпускает open-source инструменты для работы с PostgreSQL наряду с другими программными решениями (см. http://dalibo.github.io/).

В этот раз я расскажу о temBoard, новом инструменте удаленного управления БД PostgreSQL. Данный проект доступен по ссылке https://github.com/dalibo/temboard.

temBoard позволяет осуществлять мониторинг состояния БД, контроль за выполнением процессов, удаленную настройку параметров и задач... А в будущем мы планируем еще больше новых полезных фич! Основное назначение temBoard – это создание полноценной консоли управления для PostgreSQL, которая так необходима DBA для выполнения ежедневных задач.

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

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

В этом докладе будет объяснено, как работает подсистема ввода-вывода в Linux, как страницы данных PostgreSQL попадают с диска в разделяемый буфер и обратно, и с помощью каких механизмов можно управлять этими процессами.

Опыт разработки с нуля, внедрения и развития BI системы http://colibri365.ru для анализа данных в государственных органах. Современные реалии в муниципалитетах РФ, как мы с этим живём. Выжимание производительности из постгреса, использование новейших функций, переписывание запросов, чтобы оптимизатору было проще и другие особенности нашей системы. Приведшие к написанию 4 научных статей и 4 патчей к PG, подробнее о которых в докладах Андрея Бородина.

1. Определение автономной транзакции.
2. Обзор возможностей автономных транзакций в "больших" СУБД: Oracle.
3. Логика работы автономных транзакций PostgresPro.
4. Обзор средств эмуляции автономных транзакций в PostgreSQL.
5. Сравнение скорости работы встроенного механизма автономных транзакций PostgresPro и средств эмуляции PostgreSQL.

Очевидно, что множества удобно использовать в различных типах приложений. Хотя в PostgreSQL и нет встроенного типа для множеств, до некоторой степени их можно смоделировать с помощью встроенных типов “массив” и “JSONB”. Кроме того, возможность ускорения запросов с операциями вхождения уже встроена в реализацию индексов GIN.

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

< Query failed: ERROR: deadlock detected
< DETAIL: Process 17371 waits for ShareLock on transaction 102733872; blocked by process 10414.
< Process 10414 waits for ShareLock on transaction 102733874; blocked by process 17371.

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

В кратком докладе-сообщении будет объяснена механика взаимодействия блокировок, приводящая к ситуации дедлока; приведены ссылки на документацию; разобрана техника "обхода" данной проблемы конкурентной работы с данными; показаны обобщенные приемы из практики.

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

"1С:Предприятие" - самая популярная в России/СНГ платформа разработки бизнес-приложений, которая уже более 10 лет поддерживает PostgreSQL. Фирма 1С использует PostgreSQL в своём облачном сервисе 1С:Fresh. В этом докладе мы поделимся опытом и наблюдениями, возникшими в ходе эксплуатации этого сервиса, и обсудим интересные случаи и особенности тандема 1С+Postgres.

В слое хранения, используя PostgreSQL с самого старта разработки, мы прошли путь от небольшого кластера на виртуалке до многохостовой системы, которая обеспечивает near real-time обработку смешанной OLTP-OLAP нагрузки. В этом докладе собираюсь рассказать про основные этапы развития нашего аналитического решения на уровне приложения и инфраструктуры, особенности эксплуатации PG, которые возникали в процессе.

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

В процессе построения и эксплуатации сервиса МойСклад был разработан и поддерживается механизм для полуавтоматической корректировки схемы базы данных. В докладе - история появления и развития, варианты поддерживаемых конверсий.

ZSON - это расширение PostgreSQL для прозрачног сжатия JSONB-документов. Сжатие основывается на использовании разделяемого словаря строк, наиболее часто используемых в заданных JSONB документах (не только ключей, но также и значений, элементов массивов, и т.д.) В некоторых случаях ZSON может сэкономить до половины дискового пространства и увеличить количество TPS на 10% за счет меньшего I/O.

Алексей расскажет о технических деталях и опыте применения подхода экстремальной нормализации данных для создания инфраструктур данных с уникальными потребительскими характеристиками. В сравнении с решениями лидеров рынка такие инфраструктуры обладают, например, такими преимуществами, как: - оперативная обработка 10 ПБ данных и больше, - в 2-6 раз более высокая производительность, - сквозная 100% консистентность данных, - практически линейная горизонтальная масштабируемость, - в 4-10 более низкая стоимость владения, - и т. д. Изложенный подход уже нашел применение за пределами России в решениях для операторов связи, ритейла, финтеха, современном производстве (Industry 4.0, индустриальный IoT), в государственном секторе.