PostgreSQL *

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

Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic

kznalp/PG_EXPECTO

Формулировка задачи:

Разработка специализированных конфигурационных файлов метрик для оценки производительности систем управления базами данных (СУБД) с использованием инструментария pg_expecto. Результаты работы предназначены для интеграции в системы мониторинга и обеспечения основ для реализации механизмов проактивного анализа производительности СУБД.

Привет- Хабр!

Поиск работы – это... боль. Нет- не так. Это – ад.

Это бесконечный скроллинг- десятки открытых вкладок.

Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.

Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.

Мы разберём:

Можно ли смоделировать хаос пуассоновских потоков бронирований и конечный автомат состояний рейса (от «по расписанию» до «приземлился») целиком внутри PostgreSQL? Мы решили, что для создания идеальной учебной базы данных — можно. Вместо старых статичных таблиц мы построили генератор, имитирующий жизнь глобальной авиакомпании. Рассказываем, зачем это было нужно и почему старая база на 2,5 ГБ перестала справляться с задачами.

Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR, а второй — хитрую комбинацию AND. Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.

«Современная производительность — это сложный пазл, где метрики СУБД, дисковые операции, потребление CPU и сетевые задержки тесно переплетены. Традиционное нагрузочное тестирование часто дает лишь часть ответа, заставляя нас собирать данные из десятка разных источников. В этой статье мы рассмотрим, как расширение pg_expecto становится единым источником истины, объединяя метрики инфраструктуры и PostgreSQL в едином контексте. Узнайте, как превратить разрозненные данные в целостную картину и получить точный ответ на вопрос: где на самом деле кроется узкое место вашей системы?»

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

Думаю, у каждого, кто искал работу, есть этот "любимый" запрос на hh. Вбиваешь "Python Developer", ставишь фильтр "нет опыта", а тебе вываливается 500 вакансий "Senior Analyst", где в требованиях "базовое знание SQL, Python будет плюсом".

Ручной разбор этой каши убивает время и мотивацию. Мой друг Роман (он IT-рекрутер и карьерный консультант) постоянно рассказывает, как кандидаты выгорают еще до первого собеса именно на этом этапе.

Я решил, что хватит. Пора автоматизировать рутину. Казалось бы, 30-минутная задача: дернул API, отфильтровал, откликнулся. Как же я ошибался. Сегодня расскажу, на какие грабли наступил, пока пилил «Аврору» - свой инструмент для автоматизации этого ада.

Очередной чат, и к тому же на rust?! Да, yet another. И да, в этой статье не будет каких-то новых откровений системного программирования с написанием своего фреймворка для работы со сетью на уровне драйверов или других испытаний. Этот альманах про мой первый опыт в веб-разработке, который может быть полезен для других новичков, ведь тут мы затронем помимо злосчастного rust такие вещи, как devcontainer, REST API, идентификацию-аутентификацию-авторизацию, WebSockets, SSE, юнит и интеграционные тесты, некоторые паттерны, логирование и прочее.

В мире СУБД общепринятая догма гласит: «Индексы ускоряют запросы». Но что, если в погоне за производительностью мы создали себе проблему? В этой статье, на практике показан парадоксальный сценарий, при котором удаление первичного ключа у таблицы pgbench_branch и последующее увеличение стоимости запроса привели к впечатляющему росту общей производительности PostgreSQL под нагрузкой. Слепое следование правилам может быть опаснее их осознанного нарушения. СУБД не так просты, как может показаться.

Как вы думаете, сколько человек документирует продукты в Postgres Professional? 50? 100? А вот и нет — всего десять. Рассказываем, как команде техписателей удается управлять сотнями файлов, почему их работа — это квест, и как они успевают контрибьютить в ванильный PostgreSQL.

Миграция PostgreSQL — редкий проект, где «быстро и безболезненно» почти никогда не совпадают. Дамп/восстановление годится для сотен гигабайт, потоковая репликация по WAL — для тех, у кого есть к ней доступ. Но когда простоя не хочется, а WAL недоступен, остаётся третий путь — логическая репликация.

В этом материале — практический сценарий: как заранее перенести схему, обеспечить уникальную идентификацию строк (PK/уникальный индекс/REPLICA IDENTITY FULL), настроить публикации и подписки, следить за первичной загрузкой через pg_stat_subscription, корректно остановить запись на источнике и синхронизировать последовательности.

Лайфхаки для миграций, оптимизации и избегания граблей

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

• Не сломать прод при миграции.
• Избежать N+1 и других проблем SQL-запросов.
• Планировать откаты и работать безопасно на высоконагруженных БД.

Давайте честно – пока что Postgres редко используется для действительно больших и нагруженных баз. Этому множество причин, но главная формулируется просто: «не тянет».

У каждого есть своя граница, где Postgres ещё применим, а дальше —уже нет. Обычно это где-то между одним и пятью терабайтами, дальше жить с этим «больно».

База просто не может обработать большой объем данных с той скоростью, которую способны выдать диски.

И вот — Postgres 18, впервые за долгое время, предлагает не косметическую, а фундаментальную новинку. То, что в Oracle есть уже 20+ лет — асинхронный ввод-вывод (аsync IO).

Попробуем посмотреть async IO и ответить на вопрос - стал ли Postgres ближе к «взрослым» нагрузкам?

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

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

В статье рассматривается создание кластера Patroni последней версии 4.0.7 и etcd 3.6.5 в контейнерах docker. Приводится пример, когда Patroni не может автоматически восстановить и запустить кластер PostgreSQL. 

Patroni в докере

Задача запуска Patroni в докере обсуждалась на реддит и гитхаб. Приводился пример наиболее простой сборки batonogov/patroni-docker, которая состоит из 7 контейнеров: трёх с кластером etcd и трёх с PostgreSQL 17 под управлением Patroni (мастер и две реплики), один контейнер с HAProxy.

Каково это — стоять у истоков того, что сегодня стало технологическим фундаментом всего Рунета? В новом большом интервью «В Офисе» — Олег Бартунов, один из главных мейнтейнеров PostgreSQL и основатель компании Postgres Pro. Он вспоминает, как в 90‑х собирал дистрибутивы ОС через знакомых в КГБ, разбирал «кишки» компьютеров ради науки и писал письма Сергею Брину — задолго до появления Google и GitHub.

В подкасте  «В Офисе» я, Ваня Ботанов, автор телеграм-канала «Деплой» вместе с Олегом Бартуновым. Поговорили о том, с чего начинался Postgres, каково быть ядром мирового опенсорса, что изменилось в сообществе после 2022 года. Это первая часть двухчасового разговора на сложные темы – умер ли Open Source и как из учёного и первооткрывателя звёзд стать бизнесменом.

Одна из открытых пока задач в области баз данных - поддержание базы данных в консистентном состоянии одновременно на нескольких экземплярах СУБД (узлах), принимающих клиентские соединения независимо друг от друга. Суть проблемы заключается не в том, чтобы синхронизировать состояние удалённо по сети, а в том, что в случае отказа одного из узлов такой системы остальные должны продолжить свою работу без перерыва: принимать соединения, коммитить транзакции не потеряв при этом консистентность. Аналогией для случая одного экземпляра СУБД здесь может быть, к примеру, обеспечение работы при отказе планки оперативной памяти или прерывающемся доступе к нескольким ядрам процессора.

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

В статье я расскажу о практических кейсах и сложностях, возникающих (и возникавших) в процессе миграции данных между СУБД (Oracle -> Postgres), а также о собственном инструменте миграции данных, который вы также можете попробовать.

В этом руководстве мы разберем непонятности вокруг Unicode и узнаем, как строить надёжные, интернациональные Java-приложения. Разберём теорию, укажем на подводные камни, а затем соберём «Глобальный сервис приветствий» на Quarkus, который переживёт весь хаос реального текста.

К концу статьи вы разберётесь с тем,

– как устроен Unicode и как Java на самом деле хранит текст;
– почему длина строки и перебор символов сложнее, чем кажется;
– как нормализация предотвращает неприятные несоответствия;
– как настроить REST-сервис и базу данных для безопасной работы с Unicode.