Как обфусцировать базу в Postgres для задач нагрузочного тестирования веб-приложений

Postgres - отличная база данных для высоконагруженных веб-приложений. В свою очередь для таких веб-приложений периодически встает задача нагрузочного/стресс тестирования. Кроме очевидных сложностей: эмуляции рабочего окружения близкого к продуктовому и генерации трафика есть задача подготовки базы данных для тестового окружения. В эпоху борьбы за приватность персональных данных (152-ФЗ, GDPR, HIPAA) использование базы с прода выглядит плохой идеей. Выход один - обфусцировать данные.

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

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

Постгрессовый планнер с памятью

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

Шардман - естественный подход к шардингу в PostgreSQL

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

Сколько нужно инженеров, чтобы скобки заработали?

Недавно появившийся в PostgreSQL, jsonb subscripting не выглядит так же захватывающе, как другие улучшения в jsonb. Но те изменения, которые видны пользователю - всего лишь верхушка айсберга. Как много людей было вовлечено в разработку, и какие решения были сделаны в дизайне? Как много времени это заняло, и какие хорошие/плохие идеи существуют для продвижения патча? Эти и несколько других вопросов будут целью это презентации.