exam14 3

Шаблоны поддержания целостности данных (ACID, BASE)

Реферат к лекции 14 Шаблоны проектирования программ и баз данных

Выполнил: Веселов Илья, ИДБ-19-06

Проверил: Коньков Антон, ИДБ-19-06

ACID

ACID (Atomicity, Consistency, Isolation, Durability) — описание требований к СУБД, системе управления базами данных: атомарность, согласованность, изолированность и прочность.

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

Транзакция это единая логическая операция, которая может состоять из одного или нескольких шагов. Например, транзакцией может быть перевод денежных средств между банковскими аккаунтами (снятие денег из одного и пополнение другого). Если в середине такой транзакции возникнет ошибка, может возникнуть большая неконсистентность в данных. Деньги будут вычтены с одного счёта, но не зачислены в другой.

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

В частности, ACID имеет отношение к тому, как БД может восстанавливаться после ошибок, возникающих в процессе выполнения транзакции.

Atomicity (атомарность)

Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся во «внешне исходное» состояние — со стороны будет казаться, что транзакции и не было. Другими словами под атомарностью можно понимать «всё или ничего».

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

Consistency (консистентность, согласованность)

После нормального завершения работы (EOT, End of transaction) транзакция фиксирует допустимые результаты. Это свойство даёт гарантию того, что все данные будут целостны. Данные будут корректны в соответствии со всеми предопределёнными правилами, ограничениями, каскадами и триггерами, применёнными к БД.

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

Isolation (изолированность)

Во время выполнения транзакции параллельные транзакции не должны оказывать влияния на её результат. Гарантирует, что все транзакции будут выполняться изолированно. Другими словами, одна транзакция не сможет прочитать данные второй транзакции, которая ещё не выполнилась. Изоляция – это, в основном то, что и подразумевают люди, когда говорят об ACID в целом.

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

Чтение неподтверждённых данных (read uncommitted).

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

Чтение подтверждённых данных (read committed)

Можно свободно читать все изменения своей транзакции и зафиксированные изменения чужих транзакций.

Повторяемое чтение (repeatable read)

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

Сериализуемый (serializable)

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

Durability (стойкость)

Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.

Когда пригодится ACID?

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

В каких случаях не нужны ACID?

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

Основные принципы BASE

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

Но с NoSQL базами данных ситуация обстоит немного по-другому. Эти базы данных часто предназначены для обеспечения высокой доступности в кластере, а обычно это означает, что в некоторой степени жертвуют консистентностью и/или стойкостью. Однако большинство NoSQL баз данных в некоторой степени могут обеспечить атомарность.

Базы данных NoSQL охватывают ситуации, когда модель ACID является избыточной или фактически препятствует работе базы данных. Вместо этого NoSQL полагается на более мягкую модель, известную, соответственно, как модель BASE. Эта модель учитывает гибкость, предлагаемую NoSQL, и аналогичные подходы к управлению и хранению неструктурированных данных.

Термин «BASE» был предложен Эриком Брюером, автором теоремы CAP, согласно которой, в распределённых вычислениях можно обеспечить только два из трёх свойств: согласованность данных, доступность или устойчивость к разделению

BASE состоит из трех принципов:

Базовая доступность (basic availability)
Гибкое состояние (soft state)
Cогласованность в конечном счёте (eventually consistent)

Базовая доступность

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

Гибкое состояние

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

Cогласованность в конечном счёте

Многие NoSQL БД отказываются от гарантии изоляции и предлагают «согласованность в конечном счёте» (eventual consistency), согласно которой вы в конце концов увидите действительные данные, но есть вероятность, что ваша транзакция прочитает недействительные значения – то есть, временные, или частично обновлённые, или устаревшие. Это полное отклонение от требования немедленной согласованности ACID, которое запрещает выполнение транзакции до тех пор, пока предыдущая транзакция не будет завершена и база данных не приблизится к согласованному состоянию.

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly