🥞Транзакции

Зачем нужны транзакции, расшифровать ACID

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

  • Атомарность (Atomicity): Транзакция считается атомарной, если все ее операции выполняются как единое целое. Это означает, что либо все операции транзакции успешно завершаются, либо ни одна из них не выполняется. Таким образом, транзакция либо полностью выполняется, либо откатывается к исходному состоянию.

  • Согласованность (Consistency): Гарантирует, что данные остаются в согласованном состоянии до и после выполнения транзакции. Транзакция должна приводить базу данных из одного согласованного состояния в другое согласованное состояние.

  • Изолированность (Isolation): Обеспечивает, что выполнение одной транзакции не влияет на выполнение других транзакций. Каждая транзакция должна работать независимо от других и не должна видеть промежуточные результаты других транзакций.

  • Долговечность (Durability): Гарантирует, что изменения, внесенные транзакцией, остаются постоянными даже в случае сбоя системы. После успешного завершения транзакции изменения должны сохраняться даже при перезапуске системы.

Таким образом, транзакции и ACID-свойства обеспечивают надежность и целостность данных в базах данных, что является критически важным для обеспечения корректности операций и предотвращения потери данных.

Что такое уровни изоляций транзакций и зачем они нужны

Уровни изоляции транзакций - это механизмы, которые определяют степень изоляции параллельно выполняющихся транзакций в базе данных[1][2]. Они позволяют устранять аномалии, которые могут возникать при конкурентном доступе к данным[1][2].

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

- **Потерянное обновление** - две транзакции изменяют одни и те же данные, результат непредсказуем[1]

- **"Грязное" чтение** - транзакция читает данные, которые еще не зафиксированы другой транзакцией[1][2]

- **Неповторяющееся чтение** - один и тот же запрос в рамках транзакции возвращает разные результаты[1]

- **Фантомное чтение** - в результатах повторяющегося запроса появляются или исчезают строки, измененные другой транзакцией[1]

Уровни изоляции определяют, какие блокировки будут устанавливаться на данные и как долго они будут удерживаться[2]. Чем выше уровень изоляции, тем меньше аномалий возникает, но тем ниже параллелизм и производительность[1][2].

Таким образом, уровни изоляции транзакций позволяют балансировать между изоляцией и производительностью, выбирая оптимальный уровень для конкретного приложения[1][2]. Они являются важным механизмом обеспечения целостности данных в реляционных базах данных при конкурентном доступе[1][2].

Citations:

[1] https://struchkov.dev/blog/ru/transactional-isolation-levels/

[2] https://learn.microsoft.com/ru-ru/sql/odbc/reference/develop-app/transaction-isolation-levels?view=sql-server-ver16

[3] https://practicum.yandex.ru/blog/chto-takoe-normalizaciya-dannyh/

[4] https://appmaster.io/ru/blog/chto-takoe-normalizatsiia-dannykh

[5] https://info-comp.ru/database-normalization

Расскажите CAP теорему

CAP теорема - это утверждение о том, что распределенная система баз данных может одновременно гарантировать только два из трех свойств[1][2][3][4]:

  1. Согласованность (Consistency)

  • Все клиенты видят одни и те же данные в один и тот же момент времени[2][3]

  • Отсутствие конфликтов при записи данных[4]

  1. Доступность (Availability)

  • Каждый запрос получает непустой ответ[2][3]

  • Система продолжает работать даже при отказе отдельных узлов[4]

  1. Устойчивость к разделению сети (Partition tolerance)

  • Система продолжает работать при сбоях сети[2][3]

  • Данные доступны, даже если часть узлов недоступна[4]

Согласно теореме, в случае сбоя сети в распределенной системе можно гарантировать только два из этих свойств[1][3]:

  • CP (Consistency + Partition tolerance): система сохраняет согласованность, но может стать недоступной при сбоях сети[3][4]

  • AP (Availability + Partition tolerance): система сохраняет доступность, но данные могут быть не согласованы при сбоях сети[3][4]

  • CA (Consistency + Availability): система сохраняет согласованность и доступность, но не устойчива к разделению сети[3][4]

Таким образом, CAP теорема демонстрирует неизбежные компромиссы при проектировании распределенных систем[1][2][3][4]. Разработчики должны выбирать, какие свойства являются наиболее важными для их приложения.

Citations: [1] https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP [2] https://hazelcast.com/glossary/cap-theorem/ [3] https://www.geeksforgeeks.org/the-cap-theorem-in-dbms/ [4] https://www.influxdata.com/glossary/cap-theorem/ [5] https://www.bmc.com/blogs/cap-theorem/

PreviousИндексыNextМасштабирование

Last updated