Как работают атомарные транзакции в базе данных?
Атомарность делает возможным, чтобы транзакция имела только 2 результата:
- она успешно выполняет все операции и фиксируется
- прерывается из-за сбоя и отменяет все изменения
В единой базе данных атомарность возможна благодаря сохранению всех изменений в данных в журнале опережающей записи (WAL).
Каждый раз при внесении изменений WAL сохраняет их на диске, чтобы они сохранились надолго.
Каждая запись в WAL содержит всю информацию для отмены всех изменений.
Однако подход WAL недостаточен, если транзакция затрагивает более одной базы данных.
В таких ситуациях часто используется протокол двухфазной фиксации (2PC).
Согласно этому протоколу, один процесс должен быть координатором, а остальные - участниками.
Задача координатора - следить за тем, чтобы участники выполняли свою часть работы.
Чаще всего координатором является клиентский процесс, которому требуется транзакция.
Протокол состоит из 2 этапов:
1. Подготовка.
Координатор просит всех приготовиться к завершению транзакции. Каждый участник отвечает, может ли он совершить транзакцию или нет.
После ответа участники ждут дальнейших инструкций.
2. Коммит.
Если все участники готовы, координатор посылает им запрос на фиксацию. В противном случае он попросит прервать транзакцию.
Этот шаг является точкой невозврата: транзакция должна быть зафиксирована или прервана.
Протокол 2PC работает, но имеет ряд недостатков:
- он медленный, так как требует многократных обходов между процессами
- блокируется при сбое координатора или отказе участника на этапе фиксации.
Репликация задействованных процессов делает 2PC более надежным, но добавляет сложности.
#db
👉 @database_info
Атомарность делает возможным, чтобы транзакция имела только 2 результата:
- она успешно выполняет все операции и фиксируется
- прерывается из-за сбоя и отменяет все изменения
В единой базе данных атомарность возможна благодаря сохранению всех изменений в данных в журнале опережающей записи (WAL).
Каждый раз при внесении изменений WAL сохраняет их на диске, чтобы они сохранились надолго.
Каждая запись в WAL содержит всю информацию для отмены всех изменений.
Однако подход WAL недостаточен, если транзакция затрагивает более одной базы данных.
В таких ситуациях часто используется протокол двухфазной фиксации (2PC).
Согласно этому протоколу, один процесс должен быть координатором, а остальные - участниками.
Задача координатора - следить за тем, чтобы участники выполняли свою часть работы.
Чаще всего координатором является клиентский процесс, которому требуется транзакция.
Протокол состоит из 2 этапов:
1. Подготовка.
Координатор просит всех приготовиться к завершению транзакции. Каждый участник отвечает, может ли он совершить транзакцию или нет.
После ответа участники ждут дальнейших инструкций.
2. Коммит.
Если все участники готовы, координатор посылает им запрос на фиксацию. В противном случае он попросит прервать транзакцию.
Этот шаг является точкой невозврата: транзакция должна быть зафиксирована или прервана.
Протокол 2PC работает, но имеет ряд недостатков:
- он медленный, так как требует многократных обходов между процессами
- блокируется при сбое координатора или отказе участника на этапе фиксации.
Репликация задействованных процессов делает 2PC более надежным, но добавляет сложности.
#db
👉 @database_info
👍5
Media is too big
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Симулятор SQL
Вступление
Знакомство с продуктом
Первые запросы
Redash
Как решать задачи
Redash display
Фильтрация данных
Агрегация данных
Группировка данных
Подзапросы
источник
#db
👉 @database_info
Вступление
Знакомство с продуктом
Первые запросы
Redash
Как решать задачи
Redash display
Фильтрация данных
Агрегация данных
Группировка данных
Подзапросы
источник
#db
👉 @database_info
👍7🔥2
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Симулятор SQL. Часть 2
JOIN
Выбираем нужный JOIN
JOIN практика
Оконные функции основы
Оконные функции RANK и LAG
Продуктовые метрики
Построение дашбордов
Анализ Retention
Заключение
Часть 1 https://news.1rj.ru/str/database_info/924
источник
#db
👉 @database_info
JOIN
Выбираем нужный JOIN
JOIN практика
Оконные функции основы
Оконные функции RANK и LAG
Продуктовые метрики
Построение дашбордов
Анализ Retention
Заключение
Часть 1 https://news.1rj.ru/str/database_info/924
источник
#db
👉 @database_info
👍4🔥1
PostgreSQL: обеспечение уникальности записи с проверкой даты валидности
Как бы вы решали такую задачу? Предположим, есть таблица с купонами, и у купонов есть некая дата устаревания valid_until. Вам надо обеспечить такое ограничение (constraint) на уровне БД, чтобы у одного человека мог быть только один действующий купон.
Т.е., таблица изначально выглядит так:
https://habr.com/ru/companies/karuna/articles/794468/
#db
👉 @database_info
Как бы вы решали такую задачу? Предположим, есть таблица с купонами, и у купонов есть некая дата устаревания valid_until. Вам надо обеспечить такое ограничение (constraint) на уровне БД, чтобы у одного человека мог быть только один действующий купон.
Т.е., таблица изначально выглядит так:
CREATE TABLE coupons (
id bigint primary key generated by default as identity,
user_id bigint not null,
created_at timestamp not null,
valid_until timestamp not null
)
https://habr.com/ru/companies/karuna/articles/794468/
#db
👉 @database_info
Хабр
PostgreSQL: обеспечение уникальности записи с проверкой даты валидности
Как бы вы решали такую задачу? Предположим, есть таблица с купонами, и у купонов есть некая дата устаревания valid_until. Вам надо обеспечить такое ограничение (constraint) на уровне БД, чтобы у...
👍5