Может ли база данных поддерживать "атомарность", но не "согласованность" или наоборот?
Я читаю о свойствах ACID базы данных. Атомность и последовательность кажутся тесно связанными. Мне интересно, есть ли какие-то сценарии, в которых нам нужно просто поддерживать атомарность, а не согласованность или наоборот. Пример действительно поможет!
5 ответов
Они несколько связаны, но есть небольшая разница.
Атомарность означает, что ваша транзакция либо происходит, либо не происходит.
Согласованность означает, что применяются такие вещи, как ссылочная целостность.
Допустим, вы начинаете транзакцию, чтобы добавить две строки (кредит и дебет, который формирует одну банковскую транзакцию). Атомность этого не имеет ничего общего с согласованностью базы данных. Все это означает, что будут добавлены либо обе строки, либо ни одна строка.
Что касается согласованности, допустим, что у вас есть ограничение внешнего ключа от orders в products, Если вы попытаетесь добавить заказ, относящийся к несуществующему продукту, тогда наступит согласованность, чтобы вы не смогли это сделать.
Оба о поддержании базы данных в работоспособном состоянии, следовательно, их сходство. Первый пример будет гарантировать, что банк не потеряет деньги (или украдет их у вас), а второй будет гарантировать, что ваше приложение не будет удивлено заказами на продукты, о которых вы ничего не знаете.
Атомарность:
В атомарной транзакции выполняется либо ряд операций с базой данных, либо ничего не происходит. Гарантия атомарности предотвращает обновление базы данных только частично, что может вызвать большие проблемы, чем полное отклонение всей серии.
Последовательность:
В системах баз данных согласованная транзакция не нарушает никаких ограничений целостности во время ее выполнения. Если транзакция покидает базу данных в недопустимом состоянии, она прерывается и выдается сообщение об ошибке.
База данных, которая поддерживает атомарность, но не согласованность, позволит транзакциям, которые оставляют базу данных в несогласованном состоянии (то есть нарушать ссылочную или другие проверки целостности), при условии, что транзакция завершается успешно. Например, вы можете добавить строку в столбец int при условии, что транзакция, выполняющая это, успешно завершена.
И наоборот, база данных, которая поддерживает согласованность, но не атомарность, позволит завершать частичные транзакции, если эффекты этой транзакции не нарушают каких-либо проверок целостности (например, внешние ключи должны соответствовать существующей идентичности). Например, вы можете попробовать добавить новую строку, содержащую значения string и int, и даже если вставка не удалась на полпути из-за потери половины данных, строка будет разрешена при условии, что ни одна из потерянных данных не относится к обязательным столбцам и не содержит данных был вставлен в неправильно введенный столбец.
Сказав это, последовательность полагается на атомарность для обращения противоречивых транзакций.
Между атомарностью и последовательностью действительно существует тесная связь, но они не одинаковы:
СУБД может (теоретически) поддерживать согласованность, а не атомарность: например, рассмотрим транзакцию, состоящую из операций SQL O1,O2 и O3. Теперь предположим, что после O1 и O2 БД уже находится в согласованном состоянии. Затем СУБД может остановить транзакцию после O1 и O2 без O3 и при этом сохранить согласованность. Очевидно, что такая СУБД не поддерживает атомарность (поскольку O3 не был выполнен O1, а O2 был).
СУБД может (теоретически) поддерживать атомарность, а не согласованность: это может происходить в многопользовательском сценарии, где атомарность гарантирует только выполнение всех действий транзакции (или ни одной из них), но не гарантирует, что действия одного транзакция, выполненная одновременно с другой транзакцией, может не оказаться в несогласованном состоянии.
Однако я верю (но не доказал формально), что если ваша DMBS гарантирует как атомарность, так и изоляцию, то она также должна гарантировать согласованность.
Я также запутался, когда читал об атомарности и последовательности. Допустим, есть сценарий для пакетной вставки 1000 записей в таблицу учетных записей.
Атомарность пакета - это если все 1000 записей вставлены или ни одна из записей не вставлена в случае ошибки.
Согласованность пакета будет нарушена, если на уровне записи учетной записи мы установим логику, чтобы сделать вставку успешной, даже если тип данных не совпадает, связанная запись была вставлена в таблицу внешнего ключа, а затем удалена после успешной записи учетной записи. Обновить.
Надеюсь, этот пример устраняет путаницу.
У меня другое понимание согласованности в контексте ACID:
В рамках транзакции, если данный элемент данных извлекается и извлекается позже в той же транзакции, никаких изменений не видно. То есть транзакция получает согласованное состояние базы данных на протяжении всей транзакции. Единственными обновлениями, которые могут изменить данные, видимые для транзакции, являются обновления, сделанные самой транзакцией.
На мой взгляд, это равносильно сериализуемости.