ACID: различия между версиями
[непроверенная версия] | [отпатрулированная версия] |
Нет описания правки |
м откат правок 178.173.103.183 (обс.) к версии Bezik Метки: откат ссылка на неоднозначность |
||
(не показано 47 промежуточных версий 32 участников) | |||
Строка 1: | Строка 1: | ||
{{значения|Acid}} |
{{значения|Acid}} |
||
'''ACID''' (от {{lang-en|atomicity, consistency, isolation, durability}}) — набор требований к [[Транзакционная система|транзакционной системе]], обеспечивающий наиболее надёжную и предсказуемую её работу — атомарность{{переход|#Атомарность}}, согласованность{{переход|#Согласованность}}, изоляцию{{переход|#Изоляция}}, устойчивость{{переход|#Устойчивость}}; сформулированы в конце 1970-х годов [[Джим Грей|Джимом Греем]]<ref>{{статья |автор=Jim Gray |заглавие=The Transaction Concept: Virtues and Limitations |ссылка=http://jimgray.azurewebsites.net/papers/thetransactionconcept.pdf |серия=Proceedings of the 7th International Conference on Very Large Databases |издание= |год=1981 |месяц=06 |номер= |страницы= |issn= |archivedate=2020-07-04 |archiveurl=https://web.archive.org/web/20200704115542/http://jimgray.azurewebsites.net/papers/thetransactionconcept.pdf }}</ref>. |
|||
Набор требований считается фактическим стандартом для высоконадёжных систем, прежде всего, [[Реляционная СУБД|реляционных СУБД]], при этом с середины 2000-х годов для построения распределённых СУБД предполагается отказ от части требований ACID (для обоснования чего используются [[теорема CAP]], [[теорема PACELC]]) или снижение строгости требований ([[Теорема CAP#BASE-архитектура|BASE]]). |
|||
В [[Информатика|информатике]] [[Акроним|акроним]] '''ACID''' описывает требования к [[Транзакционная система|транзакционной системе]] (например, к [[СУБД]]), обеспечивающие наиболее надёжную и предсказуемую её работу. Требования ACID были в основном сформулированы в конце 70-х годов [[Джим Грей|Джимом Греем]]<ref>[http://research.microsoft.com/~gray/papers/theTransactionConcept.pdf Gray, Jim. The Transaction Concept: Virtues and Limitations. Proceedings of the 7th International Conference on Very Large Databases: pages 144—154, 1981]{{ref-en}}</ref>. |
|||
⚫ | |||
== Требования ACID == |
|||
⚫ | |||
{{main|Атомарность}} |
{{main|Атомарность}} |
||
⚫ | Атомарность гарантирует, что никакая [[Транзакция (информатика)|транзакция]] не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» ([[rollback]]): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся во «внешне исходное» состояние — со стороны будет казаться, что транзакции и не было (естественно, счётчики, [[индекс (базы данных)|индексы]] и другие внутренние структуры могут измениться, но, если СУБД запрограммирована без ошибок, это не повлияет на внешнее её поведение). |
||
⚫ | |||
⚫ | Атомарность гарантирует, что никакая [[Транзакция (информатика)|транзакция]] не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся |
||
⚫ | |||
{{main|Согласованность данных}} |
{{main|Согласованность данных}} |
||
Транзакция, достигающая своего нормального завершения ({{lang-en|end of transaction, EOT}}) и тем самым фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты. Это условие является необходимым для поддержки четвёртого свойства. |
|||
⚫ | Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это — бизнес-правило, и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисления, то система останется в некорректном состоянии и свойство согласованности будет нарушено. |
||
Одно из самых сложных и неоднозначных свойств из четвёрки ACID. В соответствии с этим требованием, система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции. |
|||
Не нужно путать требование согласованности с требованиями целостности (integrity). Последние правила являются более узкими и, во многом, специфичны для [[Реляционная СУБД|реляционных СУБД]]: есть требования целостности типов (domain integrity), целостности ссылок (referential integrity), целостности сущностей (entity integrity), которые не могут быть нарушены физически в силу особенностей реализации системы. |
|||
⚫ | При этом в ходе выполнения транзакции согласованности не требуется: между зачислением и списанием из примера, скорее всего, внутри транзакции будет промежуточное несогласованное состояние системы, но благодаря требованию изолированности никаким другим транзакциям эта несогласованность не будет видна. Атомарность же гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой. |
||
⚫ | Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт |
||
== Изоляция == |
|||
⚫ | |||
=== Isolation — Изолированность === |
|||
{{см. также|Уровни изолированности транзакций}} |
{{см. также|Уровни изолированности транзакций}} |
||
Во время выполнения транзакции параллельные транзакции не должны оказывать |
Во время выполнения транзакции параллельные транзакции не должны оказывать влияния на её результат. Изолированность — требование дорогое, поэтому в реальных базах данных существуют режимы, не полностью изолирующие транзакцию ([[Уровень изолированности транзакций|уровни изолированности]], допускающие фантомное чтение и ниже). |
||
=== Durability — Надежность === |
|||
== Устойчивость == |
|||
{{falseredirect|Устойчивость (базы данных)}} |
|||
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя. |
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя. |
||
⚫ | |||
⚫ | |||
== Литература == |
== Литература == |
||
* {{книга |
* {{книга |
||
|автор = P.A. Bernstein, N. Goodman, V. Hadzilacos. |
|автор = P. A. Bernstein, N. Goodman, V. Hadzilacos. |
||
|заглавие = Concurrency Control and Recovery in Database Systems |
|заглавие = Concurrency Control and Recovery in Database Systems |
||
|издательство = Addison-Wesley |
|издательство = Addison-Wesley |
||
|год = 1986 |
|год = 1986 |
||
}} |
}} |
||
⚫ | |||
⚫ | |||
⚫ | |||
{{databases}} |
{{databases}} |
||
⚫ | |||
[[Категория:Теоретические основы баз данных]] |
[[Категория:Теоретические основы баз данных]] |
||
[[Категория:Обработка транзакций]] |
|||
[[ar:خصائص ACID]] |
|||
[[ca:ACID]] |
|||
[[da:ACID Transaktion]] |
|||
[[de:ACID]] |
|||
[[el:ACID]] |
|||
[[en:ACID]] |
|||
[[es:ACID]] |
|||
[[fi:ACID]] |
|||
[[he:ACID]] |
|||
[[hu:ACID]] |
|||
[[it:ACID]] |
|||
[[ja:ACID (コンピュータ科学)]] |
|||
[[ko:ACID]] |
|||
[[nl:ACID]] |
|||
[[pl:ACID]] |
|||
[[pt:ACID]] |
|||
[[simple:ACID]] |
|||
[[ta:அணுமை, சீரொருமை, தனிமை, நிலைப்பு]] |
|||
[[uk:ACID]] |
|||
[[vi:ACID]] |
|||
[[zh:ACID]] |
Текущая версия от 18:02, 26 сентября 2024
ACID (от англ. atomicity, consistency, isolation, durability) — набор требований к транзакционной системе, обеспечивающий наиболее надёжную и предсказуемую её работу — атомарность , согласованность , изоляцию , устойчивость ; сформулированы в конце 1970-х годов Джимом Греем[1].
Набор требований считается фактическим стандартом для высоконадёжных систем, прежде всего, реляционных СУБД, при этом с середины 2000-х годов для построения распределённых СУБД предполагается отказ от части требований ACID (для обоснования чего используются теорема CAP, теорема PACELC) или снижение строгости требований (BASE).
Атомарность
[править | править код]Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся во «внешне исходное» состояние — со стороны будет казаться, что транзакции и не было (естественно, счётчики, индексы и другие внутренние структуры могут измениться, но, если СУБД запрограммирована без ошибок, это не повлияет на внешнее её поведение).
Согласованность
[править | править код]Транзакция, достигающая своего нормального завершения (англ. end of transaction, EOT) и тем самым фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты. Это условие является необходимым для поддержки четвёртого свойства.
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это — бизнес-правило, и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисления, то система останется в некорректном состоянии и свойство согласованности будет нарушено.
При этом в ходе выполнения транзакции согласованности не требуется: между зачислением и списанием из примера, скорее всего, внутри транзакции будет промежуточное несогласованное состояние системы, но благодаря требованию изолированности никаким другим транзакциям эта несогласованность не будет видна. Атомарность же гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой.
Изоляция
[править | править код]Во время выполнения транзакции параллельные транзакции не должны оказывать влияния на её результат. Изолированность — требование дорогое, поэтому в реальных базах данных существуют режимы, не полностью изолирующие транзакцию (уровни изолированности, допускающие фантомное чтение и ниже).
Устойчивость
[править | править код]Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
Примечания
[править | править код]- ↑ Jim Gray. The Transaction Concept: Virtues and Limitations. — 1981. — Июнь. Архивировано 4 июля 2020 года.
Литература
[править | править код]- P. A. Bernstein, N. Goodman, V. Hadzilacos. Concurrency Control and Recovery in Database Systems. — Addison-Wesley, 1986.
Для улучшения этой статьи желательно:
|