PostgreSQL *

Многие знают правила этой головоломки (Skyscrapers):

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

Задача: заполнить сетку числами так, чтобы в каждой строке и в каждом столбце каждое число использовалось лишь единожды."

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

Зачем же делать это на SQL? Потому что можем! А заодно потому что это позволит научиться конструировать "очень сложные запросы", что может пригодиться и в обычной работе.

• Может ли один запрос параллельно выполняться на разных серверах?
• Как найти запрос из pg_stat_activity в pg_stat_statements?
• Можно ли добавлять и удалять секции секционированной таблицы не останавливая приложение?
• Как пустить разработчиков на прод чтобы они могли всё видеть, но ничего не могли изменить?
• Почему VACUUM после COPY FREEZE заново переписывает всю таблицу и что с этим делать?
• Можно ли сжимать TOAST чем-то кроме медленного zlib?
• Как понять сколько времени длится блокировка найденная в pg_locks?
• Для чего нужны CYCLE и SEARCH рекурсивному запросу?
• Текст функций на каких языках (кроме C) не интерпретируется при вызове?

Что делать если перед вами стоит задача нагрузочного тестирования, в проекте используется postgres и хранятся персональные данные раскрытие которых недопустимо?

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

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

В этой статье мы рассмотрим, как развернуть полностью автоматизированную систему, которая детектируют отказ первичной базы данных, и инициирует failover, изменяя роль (promote) вторичной базы данных. Для реализации автоматического failover базы данных Moodle PostgreSQL мы будем использовать ClusterControl.

Базы данных — это Святой Грааль для хакеров, поэтому их необходимо защищать с особой тщательностью. Это первая из серии статей, в которых мы дадим обзор best practice в обеспечении безопасности баз данных. Мы начнем с одной из самых популярных СУБД с открытым исходным кодом, PostgreSQL, и рассмотрим несколько уровней безопасности, о которых стоит задуматься:

Хардверные ускорители: FPGA

Как нормальные DBA, мы подождали выпуск пары минорных версий к PostgreSQL 13, который должен порадовать нас многими полезными вещами, и теперь готовы перенести базу нашего сервиса мониторинга этой СУБД с 12-й версии на 13-ю.

Но как это сделать с минимальным простоем, а лучше вообще без него? На помощь придет функционал Foreign Data Wrappers, а точнее - postgres_fdw.

Нравится Kotlin? Считаешь SQL мощным инструментом? Подташнивает от слов ORM, JPA, Hibernate?

Есть выход! Автоматическая генерация SQL + JDBC без бойлер-плейта.

Привет!

Сегодня мы выпустили DataGrip 2021.1: наш самый мощный релиз за последние годы. И это не шутка!

Для приготовления асинхронных уведомлений listen/notify в реплике нам понадобится postgres. Как говорится в документации:

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

LISTEN, NOTIFY

Практически любая enterprise-система (под которой мы будем подразумевать некоторое ПО, где пользователи работают постоянно в течение всего рабочего дня) в современном мире стремится вырасти вместе с управляемым ей бизнесом в высоконагруженное web-решение вроде нашего СБИС.

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

Когда, где и как их может вызвать затаившийся до поры диверсант?

Привет, Хабр.

Несмотря на то, что на текущем месте работы взаимодействовать с PostgreSQL приходится значительно меньше, я продолжаю поддерживать свою библиотеку pg-index-health. Недавно я зарелизил версию 0.3.1, ключевой особенностью которой стала поддержка PostgreSQL 13.

Эта история началась достаточно давно, ещё в октябре 2020. В процессе мне пришлось отказаться от embedded версии СУБД в тестах, перейти на Testcontainers, столкнуться с ошибкой в PG13 и даже немного пообщаться в переписке с одним из разработчиков Постгреса... Но обо всем по порядку.

Гибридное Облако (Hybrid Cloud) - это общий архитектурный дизайн в любой компании. Эта концепция сочетает в себе публичное облако, частное облако и даже локальные решения, что позволяет компаниям иметь гибкость в отношении того, где хранить и как использовать свои данные. Она также помогает при реализации среды высокой доступности (High Availability environment). Проблема заключается в том, что развертывание такой среды может быть сложной и трудоемкой задачей. В этом блоге мы увидим, что такое гибридное облако, рассмотрим некоторые соображения, которые необходимо принять во внимание, прежде чем использовать его, а также то, как развернуть эту среду с помощью ClusterControl.

Привет, Хабр! Наш проект "Пятерочки #налету", описанный в статье "Как тебе такое, Джефф Безос?"продолжает развиваться - надеемся, что вскоре дадим по нему апдейт. Ну а пока расскажем о еще более масштабном проекте, в ходе которого удалось обновить систему мониторинга автотранспорта на 15 000 машин.

Зачем она нужна? Представьте, что у вас есть магазин с постоянными клиентами, которые каждый день приходят за нужными им товарами. И есть грузовик, который каждое утро привозит эти товары. И вдруг в одно прекрасное утро грузовик не приезжает, или приезжает, но гораздо позже обычного, либо приезжает, но привозит испорченные товары. Хаос и разочарование на лицах покупателей неминуемы. А ведь это только один магазин и один грузовик. А что, если магазинов и грузовиков - много тысяч? В этом случае нужна сверх -надежная система мониторинга транспорта, которая поможет навести порядок с доставкой товаров. Под катом - описание системы, рассказ о том, как однажды все (ну, почти) поломалось и о том, как мы все поправили, переделав систему.

"Шеф, всё пропало, у нас serial на мегатаблице кончился!" - а это значит, что либо вы его неаккуратно накрутили сами, либо у вас действительно данных столько, что разрядности integer-столбца уже не хватает для вашей большой и активной таблицы в PostgreSQL-базе.

Да и столбец этот не простой, а целый PRIMARY KEY, на который еще и ряд других немаленьких таблиц по FOREIGN KEY завязан. А еще и приложение останавливать совсем не хочется, ибо клиентам 24x7 обещано...

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

Всем привет. Сегодня я бы хотел поделиться рецептом установки утилиты PGHero с подключением нескольких баз данных. PGHero — это простенькая утилита, написанная на Ruby, с минималистичным дашбордом для мониторинга производительности БД PostgreSQL.

Что может показать нам PGHero:

• статистику по запросам: количество вызовов, среднее и суммарное время выполнения (с возможностью хранения истории);

• активные в данный момент запросы;

• информацию о таблицах: занимаемое на диске место, даты последних запусков VACUUM и ANALYSE;

• информацию об индексах: занимаемое на диске место, наличие дублируемых/неиспользуемых индексов. Также может порекомендовать добавить индекс при наличии сложных запросов с Seq Scan;

• статистику по открытым подключениям к БД;

• вывод основных настроек БД, влияющих на производительность (shared_buffers, work_mem, maintenance_work_mem и т.д.)

Прим. перев.: в конце января Percona опубликовала результаты своего небольшого сравнения производительности для СУБД PostgreSQL, запущенной на x86- и ARM-инстансах AWS. Результаты получились интересными даже с учетом всех допущений, сделанных самими авторами и отмеченных комментаторами оригинальной статьи. А чтобы вы могли сделать собственные выводы, предлагаем вниманию перевод этого материала.

Ожидаемый рост количества ARM-процессоров в дата-центрах уже довольно давно является горячей темой для обсуждения, и нам было любопытно узнать, как они справятся с PostgreSQL. Основным препятствием на этом пути была недоступность в целом серверов на базе ARM-чипов для тестирования и оценки. Все изменилось после того, как в 2018 году AWS представила линейку инстансов на основе ARM-процессоров. Впрочем, особого ажиотажа не последовало: многие посчитали их "экспериментальным" предложением. Мы тоже опасались рекомендовать эти инстансы для критически значимого применения и не прилагали особых усилий для их оценки. Но когда в мае 2020 было анонсировано второе поколение инстансов на основе Graviton2, решили пересмотреть свое отношение. Нужно было объективно взглянуть на показатель цена/производительность новых машин при работе с PostgreSQL.

Здравствуйте! В эфире снова Радио SQL.

Давненько не выходили в эфир, но тут братья-гуманоиды из соседнего Малого МакГеланового облака подкинули задачку. Сходу в один присест задачка не решилась, пришлось подумать. Значит и в Западном рукаве Галактики тоже могут найтись желающие поломать мозг об задачку. Сейчас изложу условие, а ответ следующим посланием уйдёт.