📂 Шпаргалка по Eventual Consistency в распределённых системах!

Например, Event-Driven обеспечивает асинхронное распространение изменений между сервисами, а CQRS позволяет разделять операции чтения и записи с независимым обновлением моделей данных.

На картинке — 4 архитектурных подхода, которые помогают управлять согласованностью данных, снижать связанность компонентов и масштабировать распределённые системы.

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

Переносите строки без промежуточной выборки!

Обычно архивирование делают в два этапа: сначала копируют записи, затем удаляют исходные. В PostgreSQL можно связать эти действия через DELETE ... RETURNING.

-- Удаляем строки и сразу получаем их содержимое
DELETE FROM events
WHERE created_at < DATE '2025-01-01'
RETURNING id, user_id, payload, created_at;

А теперь используем возвращённые строки как источник для вставки:

WITH moved AS (
    DELETE FROM events
    WHERE created_at < DATE '2025-01-01'
    RETURNING id, user_id, payload, created_at
)
INSERT INTO events_archive (
    id, user_id, payload, created_at
)
SELECT id, user_id, payload, created_at
FROM moved;

Всё выполняется одним оператором SQL. Если вставка в архив завершится ошибкой, удаление тоже откатится.
При этом можно преобразовать данные перед архивированием:

WITH moved AS (
    DELETE FROM events
    WHERE created_at < DATE '2025-01-01'
    RETURNING id, payload, created_at
)
INSERT INTO events_archive (id, payload, archived_at)
SELECT id, payload, now()
FROM moved;

🔥 DELETE ... RETURNING внутри WITH позволяет переносить строки между таблицами одним атомарным запросом, без отдельного чтения и передачи данных через приложение.

➡️ SQL Ready | #совет

👍 Интересная статья лежит на Хабре: «За пределами EXPLAIN: как увидеть выполнение запроса вживую в распределённой СУБД»!

В этой статье:
• Узнаете, почему EXPLAIN не всегда помогает понять причины медленного выполнения SQL-запросов;
• Разберёте, как pg_query_state позволяет отслеживать выполнение запросов в Apache Cloudberry в реальном времени;
• Посмотрите, как архитектура с Go-агентами и сервисом YAGPCC помогает собирать метрики с множества узлов без перегрузки координатора.

🔊 Продолжай читать на Habr!

➡️ SQL Ready | #статья

Почему перенос условия из ON в WHERE меняет семантику LEFT JOIN

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

Рассмотрим запрос, который должен возвращать всех пользователей и количество их завершённых заказов:

SELECT
    u.id,
    COUNT(o.id) AS completed_orders
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
WHERE o.status = 'completed'
GROUP BY u.id;

Этот запрос исключает пользователей без завершённых заказов. Предикат o.status = 'completed' является null-rejecting: он не может вернуть TRUE, когда o.status содержит NULL. Поэтому строки, дополненные NULL при внешнем соединении, отбрасываются.

Для сохранения всех пользователей ограничение на статус необходимо включить в условие соединения:

SELECT
    u.id,
    COUNT(o.id) AS completed_orders
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
   AND o.status = 'completed'
GROUP BY u.id;

Теперь пользователь без завершённых заказов остаётся в результате с количеством 0. Здесь принципиально использование COUNT(o.id): агрегат игнорирует NULL, тогда как COUNT(*) учитывает и строку, созданную внешним соединением при отсутствии совпадений.

В PostgreSQL аналогичную задачу можно решить через агрегатный FILTER, сохранив соединение со всеми заказами:

SELECT
    u.id,
    COUNT(o.id) FILTER (
        WHERE o.status = 'completed'
    ) AS completed_orders
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
GROUP BY u.id;

Различие между этими вариантами становится существенным при вычислении нескольких агрегатов. FILTER позволяет применять независимые условия к разным агрегатам без повторного соединения таблиц:

SELECT
    u.id,
    COUNT(o.id) FILTER (
        WHERE o.status = 'completed'
    ) AS completed_orders,
    COUNT(o.id) FILTER (
        WHERE o.status = 'pending'
    ) AS pending_orders
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
GROUP BY u.id;

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

Проверить фактический план выполнения можно через EXPLAIN:

EXPLAIN (ANALYZE, BUFFERS)
SELECT
    u.id,
    COUNT(o.id)
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
WHERE o.status = 'completed'
GROUP BY u.id;

В плане может появиться Hash Join вместо Hash Left Join или другой тип внутреннего соединения. Конкретный алгоритм зависит от статистики, индексов и оценок стоимости, поэтому наличие LEFT JOIN в sql не гарантирует сохранение внешнего соединения в физическом плане.

🔥 Перенос предиката между ON и WHERE при внешнем соединении — семантическое преобразование, а не просто изменение записи sql. Null-rejecting предикаты могут устранять строки без совпадений и создавать условия для упрощения LEFT JOIN до INNER JOIN оптимизатором.

➡️ SQL Ready | #практика

📂 16 паттернов программирования, которые должен знать каждый разработчик!

Например, Two Pointers помогает эффективно работать с массивами, Sliding Window — находить подмассивы по заданным условиям, а Dynamic Programming — решать сложные задачи через повторное использование результатов подзадач.

На картинке — 16 популярных алгоритмических паттернов и структур данных, которые пригодятся на технических собеседованиях.

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

Ускоряйте массовую загрузку через FREEZE!

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

BEGIN;

CREATE TABLE events_import (
    id bigint,
    payload jsonb
);

COPY events_import
FROM '/data/events.csv'
WITH (FORMAT csv, FREEZE true);

COMMIT;

FREEZE позволяет избежать последующей работы по заморозке загруженных строк. Но есть условие: таблица должна быть создана или очищена через TRUNCATE в текущей подоперации транзакции.

Опция пригодится и при повторной полной загрузке таблицы:

BEGIN;

TRUNCATE events_import;

COPY events_import
FROM '/data/events.csv'
WITH (FORMAT csv, FREEZE true);

COMMIT;

FREEZE не отключает обычные проверки ограничений и не гарантирует ускорения самого импорта. Его преимущество — уменьшение будущей работы VACUUM по заморозке строк.

🔥 Используйте COPY FREEZE при полной загрузке новых или очищенных таблиц, чтобы сократить последующую работу по обслуживанию данных.

➡️ SQL Ready | #совет

😎 Индексы в PostgreSQL — подробное руководство по оптимизации SQL-запросов!

Статья о том, как работают индексы в PostgreSQL, зачем они нужны и в каких случаях помогают ускорить выполнение запросов. Материал объясняет принципы индексирования и влияние индексов на поиск, фильтрацию и обработку данных. Отдельное внимание уделяется ситуациям, когда индексы не используются или могут снижать производительность.

📌 Оставляю ссылочку: sqllab.ru

➡️ SQL Ready | #сайт

Удаляйте данные небольшими порциями!

В PostgreSQL у DELETE нет LIMIT. Но ограничить количество удаляемых строк можно через подзапрос.

DELETE FROM events
WHERE id IN (
    SELECT id
    FROM events
    WHERE created_at < now() - interval '90 days'
    LIMIT 1000
);

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

Если очистку запускают несколько процессов, можно добавить блокировку с пропуском уже занятых строк:

DELETE FROM events
WHERE id IN (
    SELECT id
    FROM events
    WHERE created_at < now() - interval '90 days'
    FOR UPDATE SKIP LOCKED
    LIMIT 1000
);

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

🔥 DELETE через ограниченный подзапрос позволяет удалять данные порциями, сокращая длительность транзакций и нагрузку от массовой очистки.

➡️ SQL Ready | #совет

📂 Как работает Git: наглядная шпаргалка!

Основные команды Git и схема взаимодействия между рабочей директорией, индексом (staging area), локальным и удалённым репозиториями.

На схеме также показано, как работают git fetch, git pull и другие команды для управления изменениями и синхронизации репозиториев.

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

Почему ON CONFLICT DO NOTHING может скрывать ошибки в данных

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

Допустим, есть таблица пользователей:

CREATE TABLE users (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    email TEXT NOT NULL UNIQUE,
    username TEXT NOT NULL UNIQUE
);

Добавим существующего пользователя:

INSERT INTO users (email, username)
VALUES ('alex@example.com', 'alex');

Теперь приложение пытается зарегистрировать другого пользователя:

INSERT INTO users (email, username)
VALUES ('maria@example.com', 'alex')
ON CONFLICT DO NOTHING;

Запрос завершится без ошибки, но новая запись не появится. Причина в том, что ON CONFLICT DO NOTHING без указания цели конфликта обрабатывает нарушения уникальности по всем подходящим уникальным ограничениям и индексам.

В данном случае email уникален, но username = 'alex' уже существует. Если приложение проверяет только успешность выполнения SQL-запроса, оно может ошибочно считать регистрацию завершённой.

Чтобы обрабатывать только ожидаемый конфликт, следует явно указать его цель:

INSERT INTO users (email, username)
VALUES ('maria@example.com', 'alex')
ON CONFLICT (email) DO NOTHING;

Теперь PostgreSQL пропустит вставку только при конфликте по email. Нарушение уникальности username приведёт к ошибке 23505 (unique_violation).

Дополнительно можно использовать RETURNING:

INSERT INTO users (email, username)
VALUES ('alex@example.com', 'alex2')
ON CONFLICT (email) DO NOTHING
RETURNING id;

Если запись вставлена, запрос вернёт её id. Если вставка пропущена из-за конфликта по email, результат будет пустым. Это позволяет приложению отличать успешную вставку от пропущенной операции без дополнительного SELECT. Важно учитывать, что RETURNING при DO NOTHING не возвращает существующую строку и не сообщает причину конфликта.

🔥 При использовании ON CONFLICT DO NOTHING важно явно указывать цель конфликта, если бизнес-логика допускает дубликаты только по определённому ключу. В сочетании с RETURNING это позволяет контролировать результат вставки, не скрывая нарушения уникальности по другим ключам.

➡️ SQL Ready | #практика

Обновляйте агрегаты одним запросом!

Когда нужно пересчитать статистику по пользователям, не обязательно сначала получать агрегаты, а затем обновлять каждую запись отдельно.

PostgreSQL позволяет объединить INSERT ... SELECT с ON CONFLICT:

INSERT INTO user_stats (user_id, total)
SELECT user_id, sum(amount)
FROM payments
GROUP BY user_id
ON CONFLICT (user_id)
DO UPDATE
SET total = EXCLUDED.total;

Здесь GROUP BY вычисляет суммы, а ON CONFLICT обновляет существующие записи или добавляет новые.

Для этого на user_stats(user_id) должно быть ограничение уникальности. Можно сразу пересчитывать несколько показателей:

INSERT INTO user_stats (user_id, total, orders_count)
SELECT user_id, sum(amount), count(*)
FROM payments
GROUP BY user_id
ON CONFLICT (user_id)
DO UPDATE SET
total = EXCLUDED.total,
orders_count = EXCLUDED.orders_count;

🔥 INSERT ... SELECT ... ON CONFLICT позволяет пересчитывать и сохранять агрегаты одним запросом, без циклов и промежуточной обработки в приложении.

➡️ SQL Ready | #совет

😍 Продвинутая оптимизация PostgreSQL — WAL, VACUUM и проектирование БД!

Статья о том, как повысить производительность PostgreSQL за счёт правильной настройки внутренних механизмов СУБД и проектирования структуры базы данных. Материал посвящён не только оптимизации SQL-запросов, но и причинам возникновения проблем с производительностью. Рассматриваются WAL (журнал предзаписи), VACUUM и AUTOVACUUM, очистка устаревших версий строк, управление транзакциями и проектирование таблиц.

📌 Оставляю ссылочку: dbserv.ru

➡️ SQL Ready | #сайт

🧐 Годная статья лежит на Хабре: «Как мы разрешили чтение с реплик PostgreSQL — и почему шесть лет говорили „нет“»!

В этой статье:
• Узнаете, почему чтение с реплик PostgreSQL может угрожать отказоустойчивости и приводить к проблемам с актуальностью данных;
• Разберёте, как организовать маршрутизацию запросов через Patroni, Consul и PgBouncer с учётом отставания репликации;
• Посмотрите, как перенос части запросов на реплики помог снизить пиковую нагрузку на primary и какие риски при этом остались.

🔊 Продолжай читать на Habr!

➡️ SQL Ready | #статья

Почему NOT EXISTS не всегда эквивалентен EXCEPT!

При сравнении двух наборов данных в sql часто используют NOT EXISTS или EXCEPT. Оба подхода позволяют найти строки, присутствующие в одном наборе и отсутствующие в другом. Однако их семантика различается при наличии дубликатов и NULL.

Рассмотрим задачу: найти товары поставщика, отсутствующие в основном каталоге. Создадим таблицы в PostgreSQL:

CREATE TABLE supplier_products (
    product_id INT
);

CREATE TABLE catalog_products (
    product_id INT
);

INSERT INTO supplier_products (product_id)
VALUES (10), (10), (20), (NULL);

INSERT INTO catalog_products (product_id)
VALUES (20), (NULL);

Один из вариантов решения — коррелированный NOT EXISTS:

SELECT s.product_id
FROM supplier_products s
WHERE NOT EXISTS (
    SELECT 1
    FROM catalog_products c
    WHERE c.product_id = s.product_id
);

Результат (порядок строк не гарантируется):

product_id
----------
10
10
NULL

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

Строка с NULL также попадает в результат: сравнение NULL = NULL не возвращает TRUE, поэтому соответствие не обнаруживается. Теперь выполним EXCEPT:

SELECT product_id
FROM supplier_products

EXCEPT

SELECT product_id
FROM catalog_products;

Результат:

product_id
----------
10

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

Это отличается от обычного сравнения через =. Если необходимо сохранить кратность строк, стандарт sql предусматривает EXCEPT ALL:

SELECT product_id
FROM supplier_products

EXCEPT ALL

SELECT product_id
FROM catalog_products;

Результат:

product_id
----------
10
10

EXCEPT ALL работает с мультимножествами. Количество экземпляров каждой строки определяется формулой:

max(количество_слева - количество_справа, 0)

Например, если товар встречается слева пять раз, а справа три раза, результат содержит две строки. NOT EXISTS действует иначе: если найдено хотя бы одно соответствие, все строки внешнего набора с таким значением исключаются.

Ещё одно различие возникает при сравнении составных ключей.
Предположим, сравниваются пары (product_id, warehouse_id), причём warehouse_id может содержать NULL. Создадим таблицы:

CREATE TABLE supplier_stock (
    product_id INT,
    warehouse_id INT
);

CREATE TABLE catalog_stock (
    product_id INT,
    warehouse_id INT
);

INSERT INTO supplier_stock VALUES
(10, NULL), (10, NULL), (20, 1);

INSERT INTO catalog_stock VALUES
(10, NULL);

Обычное равенство не позволит сопоставить строки (10, NULL):

SELECT s.product_id, s.warehouse_id
FROM supplier_stock s
WHERE NOT EXISTS (
    SELECT 1
    FROM catalog_stock c
    WHERE c.product_id = s.product_id
      AND c.warehouse_id = s.warehouse_id
);

Для NULL-безопасного сравнения стандарт SQL предусматривает IS NOT DISTINCT FROM.

Чтобы одновременно устранить дубликаты и воспроизвести семантику EXCEPT без ALL, добавим DISTINCT:

SELECT DISTINCT
    s.product_id,
    s.warehouse_id
FROM supplier_stock s
WHERE NOT EXISTS (
    SELECT 1
    FROM catalog_stock c
    WHERE c.product_id IS NOT DISTINCT FROM s.product_id
      AND c.warehouse_id IS NOT DISTINCT FROM s.warehouse_id
);

Результат:

product_id | warehouse_id
-----------+-------------
20         | 1

Для этих столбцов запрос эквивалентен EXCEPT без ALL. Все примеры рассчитаны на PostgreSQL. Поддержка отдельных конструкций зависит от СУБД и версии. По производительности универсального победителя нет: результат зависит от данных, индексов и плана выполнения.

🔥 NOT EXISTS проверяет отсутствие соответствия, EXCEPT вычисляет разность множеств без дубликатов, а EXCEPT ALL учитывает кратность строк. При выборе конструкции важно учитывать NULL и повторяющиеся значения.

➡️ SQL Ready | #практика

🐱 PostgreSQL Cookbook — практический справочник по работе с PostgreSQL на русском языке!

Материалы представлены в формате практических примеров: конкретная задача, способ её решения и пример SQL-кода. Такой формат позволяет не только изучать возможности PostgreSQL, но и использовать справочник непосредственно во время разработки. Особенно полезен, когда нужно разобраться с определённой конструкцией SQL, подобрать подходящий запрос или найти решение типовой задачи.

📌 Оставляю ссылочку: dsbasko.github.io

➡️ SQL Ready | #сайт

Почему оконная функция LAST_VALUE часто возвращает не последнюю строку!

Оконные функции позволяют выполнять вычисления по набору связанных строк без сворачивания результата через GROUP BY. Однако для некоторых функций результат зависит не только от PARTITION BY и ORDER BY, но и от границ оконного фрейма.

Особенно часто это проявляется при использовании LAST_VALUE. Рассмотрим задачу: для каждой операции необходимо вывести её сумму и сумму последней операции соответствующего счёта.

Предположим, данные представлены таблицей:

transactions(
    id,
    account_id,
    amount,
    created_at
)

Попробуем решить задачу через LAST_VALUE (PostgreSQL):

SELECT
    id,
    account_id,
    amount,
    LAST_VALUE(amount) OVER (
        PARTITION BY account_id
        ORDER BY created_at
    ) AS last_amount
FROM transactions;

На первый взгляд LAST_VALUE должна возвращать сумму последней операции в пределах account_id. Но результат может совпадать с amount текущей строки.

Причина заключается в оконном фрейме. При наличии ORDER BY стандартный фрейм в PostgreSQL определяется как:

RANGE BETWEEN UNBOUNDED PRECEDING
          AND CURRENT ROW

При этом CURRENT ROW в режиме RANGE включает группу строк с одинаковыми значениями сортировки — peer group. Рассмотрим операции одного счёта:

id  account_id  amount  created_at
--  ----------  ------  ----------
1   42          100     2026-01-10
2   42          200     2026-01-11
3   42          300     2026-01-12

Для запроса с LAST_VALUE результат будет:

id  amount  last_amount
--  ------  -----------
1   100     100
2   200     200
3   300     300

Фрейм заканчивается на текущей строке или её peer group, поэтому последующие операции с большими значениями сортировки не входят в расчёт.

Чтобы получить действительно последнюю операцию раздела, необходимо явно расширить фрейм:

SELECT
    id,
    account_id,
    amount,
    LAST_VALUE(amount) OVER (
        PARTITION BY account_id
        ORDER BY created_at, id
        ROWS BETWEEN UNBOUNDED PRECEDING
                 AND UNBOUNDED FOLLOWING
    ) AS last_amount
FROM transactions;

Теперь фрейм охватывает все строки счёта, а LAST_VALUE возвращает сумму последней операции. Для приведённых данных last_amount будет равен 300 во всех строках.

Дополнительная сортировка по id обеспечивает однозначный порядок при совпадении created_at, если id уникален. Но есть ещё один нюанс — различие между ROWS и RANGE. Рассмотрим накопительную сумму:

SELECT
    id,
    account_id,
    amount,
    SUM(amount) OVER (
        PARTITION BY account_id
        ORDER BY created_at
    ) AS running_total
FROM transactions;

Предположим, две операции одного счёта имеют одинаковое время:

id  amount  created_at
--  ------  ----------
1   100     10:00:00
2   200     10:00:00
3   300     11:00:00

При стандартном RANGE обе операции с временем 10:00:00 принадлежат одной peer group. Результат накопительной суммы:

id  amount  running_total
--  ------  -------------
1   100     300
2   200     300
3   300     600

Это корректное поведение: фрейм первой строки включает все операции с тем же значением created_at.

Если необходимо накапливать сумму строго по одной операции, следует использовать ROWS и уникальный порядок сортировки:

SELECT
    id,
    account_id,
    amount,
    SUM(amount) OVER (
        PARTITION BY account_id
        ORDER BY created_at, id
        ROWS BETWEEN UNBOUNDED PRECEDING
                 AND CURRENT ROW
    ) AS running_total
FROM transactions;

Теперь результат будет:

id  amount  running_total
--  ------  -------------
1   100     100
2   200     300
3   300     600

Различие принципиальное: ROWS задаёт границы относительно позиций строк, а RANGE — относительно значений сортировки. При этом без уникального ORDER BY последовательность строк с одинаковыми ключами остаётся неопределённой.

Также LAST_VALUE возвращает значение последней строки фрейма, а не максимальное значение столбца. Поэтому замена на MAX(amount) может изменить смысл расчёта. Поддержка оконных фреймов различается между СУБД, а порядок вывода строк без внешнего ORDER BY не гарантируется.

🔥 ORDER BY внутри OVER определяет порядок вычисления, но не обязательно включает весь раздел во фрейм. Для LAST_VALUE и накопительных агрегатов важно явно задавать границы фрейма и детерминированный порядок сортировки.

➡️ SQL Ready | #практика