Современное хранилище данных на основе PostgreSQL

Построение хранилища данных на основе PostgreSQL имеет долгую историю. Netezza, Redshift и Greenplum превратили определенные релизы PostgreSQL в решения для хранения данных. В настоящее время, с учетом тенденции к повышению производительности PostgreSQL (улучшение секционирования, статистики, JIT-компиляция и т. д.) и наличия продвинутых расширений, таких, как Swarm64 Data Accelerator, вы можете создать современное, надёжное и многофункциональное хранилище данных. В этом докладе будут рассмотрены тенденции PostgreSQL и хранилищ данных и затронуты ключевые аргументы в пользу выбора PostgreSQL для построения хранилища данных.

Сетевой фильтр PostgreSQL для EnvoyProxy

Как вы осуществляете мониторинг Postgres? Какую информацию вы собираете и насколько она помогает решать возникающие проблемы? Что если вам хочется или нужно логировать все запросы? Высоконагруженные базы данных могут выйти из строя при таком подходе.

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

Полезные ссылки:

• https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/postgres#arch-overview-postgres
• https://www.cncf.io/blog/2020/08/13/envoy-1-15-introduces-a-new-postgres-extension-with-monitoring-support/

Формирование отчетов и аналитики в реальном времени с PostgreSQL.

В современном мире операционная отчетность и аналитика в реальном времени становятся базовой потребностью. Существует огромное количество инструментов, практик и подходов, которые в свою очередь требуют различной экспертизы и ресурсов. В рамках данного выступления расскажу, как может происходить развитие с помощью PostgreSQL. Подводные камни при использовании различных схем. Поговорим про вопросы качества данных и производительности. Доклад будет интересен как тем, кто находится на начальном этапе, так и для практиков с многолетним опытом (буду рад горячим обсуждениям и вопросам после доклада) План доклада: 1. Эволюция построения отчетности - миграция с OLTP на OLAP. 2. Вызовы организации доставки данных в DWH. 3. Масштабирование архитектуры с ростом данных. 4. Вопросы качества данных. 5. Сохранение стабильности при большом кол-ве изменений. 6. Различные подходы по организации работ команды DWH. 7. И конечно же успешно решенные нами вызовы (pgAgent, PGWatch, работа с фс, новое прочтение postgresql.conf).

Повреждение данных: как его избежать, обнаружить и обеспечить восстановление

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