PGConf.Russia 2025

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

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

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

Мы разработали расширение Proxima, которое снимает необходимость в настройке и администрировании дополнительного программного обеспечения. Proxima — масштабируемый, отказоустойчивый прокси-сервер и пулер соединений, способный перенаправлять трафик на пишущий узел, а при работе с BiHA переключение на новый пишущий узел в случае аварии происходит автоматически. 

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

В центре внимания — проблемы построения прикладного решения на PostgreSQL, а именно высоконагруженного аналитического хранилища данных. На примере кейса компании ЕВРАЗ покажем эффект применения методологии Data Vault на СУБД PostgreSQL и Greenplum для разработки единой системы производственных показателей.

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

Это будет интересно всем, кто планирует использовать или уже сталкивается со сложностями применения методологии Data Vault и проблемами производительности DWH на стеке open source. Сравним варианты технической реализации модельного слоя business vault с учётом специфики PostgreSQL и Greenplum. Рассмотрим 5 реальных проблем, возникающих при эксплуатации DWH и их решение:

1.     Перенос логики сборки объектов Business Vault с PostgreSQL на Greenplum.

2.     Замедление ETL при сборке текущего состояния Business Vault в PostgreSQL.

3.     Замедление построения Data Lineage в PostgreSQL и Greenplum.

4.     Медленная работа при запросе сателлита в Greenplum.

5.     Медленные запросы с «in» или «or» при обращении к слою Business Vault.

При нагрузочном тестировании PostgreSQL бенчмарки замеряют время исполнения запроса (latency). Для более объективного результата запрос выполняется большое количество раз — из этого получается некоторый набор latency. Для оценки производительности PostgreSQL на данном запросе можно использовать стандартные методы, такие как медиана или среднее, но мы предлагаем использовать более комплексный подход. Как показала практика, такие выборки часто бывают мультимодальными и состоят из различных распределений с некоторыми параметрами. 

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