SQL-Ex blog

Пересказ статьи Jonathan Duran. PostgreSQL WAL Internals for Data Engineers

Понимание PostgreSQL WAL

Недавно, работая над проектом CDC, я осознал, что никогда в действительности не находил времени, чтобы вникнуть во внутреннее устройство PostgreSQL, которое делает возможным потоковую обработку транзакций. Все мы знаем CDC (захват измененных данных) как магию, которая позволяет нам помещать изменения данных почти в реальном времени в системы типа Kafka, Snowflake или data lake - но на самом деле основную работу выполняет специальный компонент инженерных решений PostgreSQL: журнал предупреждающей записи (WAL).

Эта статья посвящена данному компоненту - что такое WAL, как он обеспечивает надежность PostgreSQL, и какую роль он играет в возможности CDC. Мы обсудим то, как PostgreSQL обрабатывает транзакции из памяти на диск, как он избегает дорогих операций ввода-вывода, и как он элегантно восстанавливает данные после сбоя. Продолжить чтение "Внутреннее устройство WAL в PostgreSQL для инженеров данных"

Авторы: Elizabeth Garrett Christensen и Erik Jones, Do You Need to Tune Postgres Vacuum?

Если вы работаете с Postgres какое-то время, вы, вероятно, слышали, как кто-то упоминал «очистку» (vacuuming) базы данных или использовал термин «раздувание» (bloat). Оба эти понятия звучат как рутинная и надоедливая работа, но они — просто часть жизни здоровой базы данных. В современных версиях Postgres autovacuum обычно обрабатывает эти проблемы за кулисами. Но по мере роста вашей базы данных вы можете начать задаваться вопросом: достаточно ли настроек по умолчанию? Нужно ли мне запускать очистку Postgres вручную? Или почему моя база данных внезапно занимает гораздо больше места на диске, чем должна?

Давайте углубимся в то, зачем нужна очистка, как работает autovacuum и когда вам действительно нужно вмешаться и настроить его.

Продолжить чтение "Нужно ли настраивать Vacuum в Postgres?"

§ Новая задача от Baser и pegoopik опубликована на рейтинговом этапе под номером 24 (оценка сложности 2 балла).
Выполнены следующие переносы:
Новая задача -> 24 -> 4 -> 166 (обуч.этап).
Второй этап теперь начинается с задачи 4.

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 193 (Learn)		7		9
 140 (SELECT)		5		6
 Guest's book		3		16

Продолжить чтение "Новости за 2026-03-28 - 2026-04-03"

Автор: Itzik Gan Baruch, How to learn CI/CD fast

Непрерывная интеграция и непрерывная доставка (CI/CD) критически важны для ускорения выпуска программного обеспечения, и начать работать с ними не так сложно, как кажется. CI/CD стали краеугольной технической архитектурой успешных внедрений DevSecOps. CI/CD имеет репутацию сложной и труднодостижимой, но это не обязательно так. Современные инструменты позволяют командам начать работу с минимальной настройкой и управлением инфраструктурой. Вот как вы можете «быстро стартовать» с CI/CD и получить быстрые, наглядные победы в производительности для вашей команды DevSecOps.

Продолжить чтение "Как быстро освоить CI/CD"

Автор: ByteGoblin/, Setting Up PostgreSQL High Availability with Patroni and Ansible

В современном мире, управляемом данными, обеспечение высокой доступности вашей базы данных имеет решающее значение для непрерывности бизнеса. PostgreSQL — мощная открытая реляционная база данных, которую можно настроить для обеспечения высокой доступности (High Availability, HA), чтобы минимизировать простои и сохранить доступ к данным. Одно из популярных решений для достижения высокой доступности PostgreSQL — использование Patroni (шаблона для управления кластерами PostgreSQL) в сочетании с Ansible (инструментом автоматизации, который упрощает развёртывание приложений, управление конфигурацией и оркестрацию).

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

Продолжить чтение "Обеспечение высокой доступности PostgreSQL с помощью Patroni и Ansible"

Автор: Joe Celko, Combinations, permutations, and derangements

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

Факториалы

Функция факториала обычно записывается как (n)!, и она определяется как произведение первых (n) натуральных чисел. Таким образом, 5! равно (5 · 4 · 3 · 2 · 1) = 120. Как обычно, ноль — это особый случай: 0! = 1, что можно доказать с помощью несколько иного определения факториала. Вместо определения через произведение определим его рекурсивно следующим образом: n! = CASE WHEN n = 0 THEN 1 ELSE n · (n-1)! END.

Показывая процесс шаг за шагом, рекурсия разворачивается так:

5! = 5 · 4!

4! = 4 · 3!

3! = 3 · 2!

2! = 2 · 1!

1! = 1 · 0!

Посмотрите на последний шаг рекурсии. Теперь разделите обе части на единицу, чтобы получить (1! / 1) = 0! или 1 = 0! Обратите внимание, что всё, что было сделано до сих пор, является процедурным, а не ориентированным на множества. Специалисты по реляционным СУБД предпочитают уходить от процедурного кода. Для остальной части этой статьи вы можете думать о n! как о количестве способов упорядочить (n) элементов множества в последовательность. Очевидно, если у вас есть один элемент, то у вас есть только один способ упорядочивания. Но точно так же, если у вас ноль элементов, вы также на этом закончили. Как существует только одно пустое множество, так существует и только одна пустая последовательность.

Да, можно определить факториалы для отрицательных чисел, мнимых чисел, гамма-функцию для действительных чисел и другие вещи. Если вы не студент-математик, вам совершенно не понадобятся эти изощрённые трюки. Поскольку SQL — это язык баз данных, а не вычислительный язык, возможно, вы захотите использовать поиск по таблице, а не это рекурсивное определение. Вы можете найти таблицу чисел от одного до ста для заполнения таблицы. Факториальная функция растёт очень быстро!

0! = 1

1! = 1

2! = 2

3! = 6

4! = 24

5! = 120

6! = 720

7! = 5 040

8! = 40 320

9! = 362 880

10! = 3 628 800

11! = 39 916 800

12! = 479 001 600

Продолжить чтение "Сочетания, перестановки и беспорядочность"

Автор: Radim Marek, Good CTE, bad CTE

Обобщённое табличное выражение (Common Table Expression, CTE) — это первая возможность, к которой часто обращаются разработчики, выходя за рамки базового SQL, а зачастую и единственная. Вы пишете подзапрос после WITH, даёте ему имя и используете в остальной части запроса. Он существует только на время выполнения этого запроса.

Но популярность CTE обычно связана не столько с модернизацией кода, сколько с обещанием императивной логики. Для многих CTE выступает в роли простого для понимания средства от «страшных запросов» и способа навязать базе данных порядок выполнения. Многие пишут запросы так, как будто они говорят оптимизатору: «сначала сделай это, затем сделай то».

Это создаёт проблему. CTE обеспечивают декомпозицию запросов, рекурсию и многосоставные DDL. Планировщик обрабатывает их по-разному в зависимости от того, как вы их пишете и используете. Долгое время (до PostgreSQL 12) CTE служили барьером для оптимизации. Планировщик не мог проталкивать условия предикатов внутрь них, не мог использовать индексы на нижележащих таблицах. Он не мог сделать ничего, кроме как материализовать их и просканировать полученный результат.

PostgreSQL 12 изменил это. Теперь CTE могут быть встроены, материализованы или находиться в промежуточном состоянии, в зависимости от того, как вы их пишете.

Продолжить чтение "CTE - Хороший, плохой, злой"

Пересказ статьи Jeyaram Ayyalusamy. 32 - PostgreSQL 17 Performance Tuning: Understanding Optimizer Cost Parameters

PostgreSQL известна как одна из наиболее продвинутых реляционных баз данных с открытыми кодами, и одна из основных причин ее силы - оптимизатор запросов на основе стоимости.

Когда вы запускаете запрос, оптимизатор не выполняет его непосредственно. Он генерирует множество возможных планов выполнения и оценивает их стоимость. Выбирается план с самой низкой оценкой стоимости. Стоимость не измеряется в миллисекундах или циклах ЦП - она представляет собой абстрактные единицы, которые PostgreSQL использует для сравнения.

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

В этой статье мы:

1. Создадим таблицу с 10 миллионами строк для имитации реальной рабочей нагрузки.


2. Создадим индексы, чтобы дать возможность PostgreSQL построить несколько планов выполнения.


3. Подробно разберем модель стоимости в PostgreSQL.


4. Покажем, как настройка параметров стоимости может изменить решение при выборе плана.

Продолжить чтение "Настройка производительности в PostgreSQL 17: Понимание параметров стоимости оптимизатора"

§ Новая задача от pegoopik опубликована на обучающем этапе под номером 193 (оценка сложности 2 балла).

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 27 (DML)		7		4
 89 (SELECT)		3		6
 24 (DML)		2		6
 138 (SELECT)		2		5

Продолжить чтение "Новости за 2026-03-21 - 2026-03-27"

Автор: Richard Yen, EXPLAIN's Other Superpowers

Большинство людей, работающих с PostgreSQL, в конечном итоге узнают две команды для настройки запросов: EXPLAIN и EXPLAIN ANALYZE.

EXPLAIN показывает выбранный планировщиком план выполнения, а EXPLAIN ANALYZE выполняет запрос и добавляет статистику времени выполнения. Для большинства задач настройки этого уже достаточно для получения большого объёма информации.

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

В этой статье мы рассмотрим некоторые из этих менее популярных опций.

Продолжить чтение "Cуперспособности EXPLAIN в PostgreSQL"

Автор: Shaun Thomas, Using Patroni to Build a Highly Available Postgres Cluster—Part 3: HAProxy

Статьи серии:

• Как Patroni обеспечивает высокую доступность PostgreSQL


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Добро пожаловать в третью часть нашей серии по созданию высокодоступного кластера Postgres с помощью Patroni! Часть первая была полностью посвящена созданию DCS с использованием etcd для обеспечения критически важного уровня DCS для кластера, а часть вторая добавила Patroni и Postgres в программный стек. Хотя на этом этапе можно остановиться и использовать кластер как есть, есть ещё один компонент, который сделает его гораздо более функциональным в целом.

Новым соединениям нужен способ легко и надёжно достигать основного узла. Patroni предоставляет REST-интерфейс для опроса каждого узла о его состоянии, что делает его идеальным решением для любого программного обеспечения или уровня балансировки нагрузки, совместимого с HTTP-проверками. Часть третья посвящена добавлению HAProxy для выполнения этой роли, завершая кластер уровнем маршрутизации.

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

В противном случае, давайте завершим кластер!

Продолжить чтение "Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx"

Автор: Ilya Kosmodemiansky, An Ultimate Guide to Upgrading Your PostgreSQL Installation: From 17 to 18

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

Эта статья основана на моём докладе на PGConf.EU 2024, дополненном с учётом пути обновления 17→18 и значительных улучшений, появившихся в версии 18. В это время года мы обычно рекомендуем нашим клиентам обновляться: текущий релиз 18.3 достаточно стабилен.

Продолжить чтение "Полное руководство по обновлению PostgreSQL с 17 на 18"

Пересказ статьи Jared Westover. Calculate a Moving Average with T-SQL Windowing Functions

Хотя мне нравится использовать SQL Server, есть несколько вещей, для которых лучше подходят другие инструменты. Например, вычисление скользящего среднего или накопительных итогов зачастую проще выполнить с помощью таких инструментов, как Power BI или Excel. Это связано с тем, что Microsoft разрабатывала эти программы, имея в виду подобную функциональность. Недавно мы оптимизировали сложный запрос скользящего среднего, написанный для SQL Server 2008R2. Сюрприз! В SQL Server нет встроенной функции для вычисления скользящего среднего. Но не беспокойтесь, я покажу вам, как это сделать.

В этой статье я рассмотрю два метода для создания скользящего среднего в SQL Server. Мы начнем со старого и менее производительного способа, который присутствовал в нашей производственной системе. Кто знает, может быть вы все еще используете устаревшую версию SQL Server. Затем я покажу современный способ с использованием оконных функций и то, как добавление индекса, все меняет. К концу статьи вы будете готовы, чтобы справиться с этим скользящим средним в следующий раз, когда это кому-то понадобится, а не просто скажете: "Используй Excel".

Продолжить чтение "Вычисление скользящего среднего с помощью оконных функций в T-SQL"

Автор: Shaun Thomas, Using Patroni to Build a Highly Available Postgres Cluster—Part 2: Postgres and Patroni

Статьи серии:

• Как Patroni обеспечивает высокую доступность PostgreSQL


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni


• Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Продолжить чтение "Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni"

Автор: Umair Shahid, Thinking of PostgreSQL High Availability as Layers

Высокая доступность для PostgreSQL часто рассматривается как единое, большое, драматичное решение: «Делаем мы HA или нет?»

Такой подход толкает команды к двум крайностям:

• «геройская архитектура», которая стоит дорого и всё равно вызывает напряжение при эксплуатации, или


• минималистичная архитектура, которую все надеются, что будет просто продолжать работать.

Более спокойный способ проектирования — рассматривать HA и аварийное восстановление (DR) как слои. Вы начинаете с базового уровня, а затем добавляете конкретные возможности только тогда, когда ваши RPO/RTO и бюджет их оправдывают.

Давайте пройдём по слоям от «одного основного узла» до «многосайтовой готовности к аварийному восстановлению».

Продолжить чтение "Представление о высокой доступности PostgreSQL как о слоях"