Consistency — Согласованность
Одно из самых сложных и неоднозначных свойств из четвёрки ACID. В соответствии с этим требованием, система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции. Не нужно путать требование согласованности с требованиями целостности (integrity). Последние правила являются более узкими и, во многом, специфичны для реляционных СУБД: есть требования целостности типов (domain integrity), целостности ссылок (referential integrity), целостности сущностей (entity integrity), которые не могут быть нарушены физически в силу особенностей реализации системы.
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой. Это бизнес-правило и оно не может быть гарантировано только проверками целостности, его должны соблюсти программисты при написании кода транзакций. Если какая-либо транзакция произведёт списание, но не произведёт зачисление, то система останется в некорректном состоянии и свойство согласованности будет нарушено.
Наконец, ещё одно замечание касается того, что в ходе выполнения транзакции согласованность не требуется. В нашем примере, списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции, никаким другим транзакциям эта несогласованность не будет видна. А атомарность гарантирует, что транзакция либо будет полностью завершена, либо ни одна из операций транзакции не будет выполнена. Тем самым эта промежуточная несогласованность является скрытой.
Isolation — Изолированность
Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат. Это свойство не соблюдается на уровне изолированности Repeatable Read и ниже.
Durability — Надежность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
Назовите три проблемы параллелизма.
В информатике параллели́зм — это свойство систем, при которой несколько вычислений выполняются одновременно, и при этом, возможно, взаимодействуют друг с другом. Вычисления могут выполняться на нескольких ядрах одного чипа с вытеснящим разделением времени потоков вычислений на одном процессоре, либо выполняться на физически отдельных процессорах. Для выполнения параллельных вычислений разработаны ряд математических моделей, в том числе сети Петри, исчисление процессов, модели параллельных случайных доступов к вычислениям и модели акторов.
Проблематика
Поскольку вычисления в параллельных системах взаимодействуют друг с другом, число возможных путей выполнения может быть чрезвычайно велико, и результирующий итог может стать недетерминированным. Параллельное использование общих ресурсов может стать одним из источников недетерминированности, приводящей к таким проблемам, как взаимная блокировка или фатальный недостаток ресурсов.[1]
Построение параллельных систем требует поиска надёжных методов координации выполняемых процессов, обмена данными, распределения памяти и планирования для минимизации времени отклика и увеличения пропускной способности.
Имеется, по существу, три случая ошибочного исполнения (И соответственно три связанные с ними проблемы (см. ниже).—^ Примеч. пер.), т. е. три ситуации, когда транзакция, корректная сама по себе, может продуцировать тем не менее ошибочный результат из-за вмешательства со стороны некоторой другой транзакции, конечно, при отсутствии подходящего механизма управления. Заметим, между прочим, что транзакция, осуществляющая вмешательство, также может быть сама по себе корректна. Речь идет, таким образом, о чередовании операций из двух корректных транзакций, которое продуцирует в целом некорректный результат.
К указанным выше проблемам относятся:
1. Проблема утраченного обновления.
2. Проблема зависимости от незафиксированных обновлений.
3. Проблема анализа на противоречивость.
Рассмотрим поочередно каждую из них.
Проблема утраченного обновления
Рассмотрим ситуацию, показанную на рис. 11.1. Предполагается, что этот рисунок читается следующим образом: транзакция А осуществляет выборку некоторой записи R в момент времени t1.
| Транзакция А | Время | Транзакция В | ||
| — | — | |||
| — | — | |||
| FETCH R | t1 | — | ||
| — | — | |||
| — | t2 | FETCH R | ||
| — | — | |||
| UPDATE R | t3 | — | ||
| — | — | |||
| — | t4 | UPDATE R | ||
| — | — | |||
Рис. 11.1. Транзакция А утрачивает обновление в момент t4
Транзакция В осуществляет выборку той же самой записи R в момент времени t2. Транзакция А обновляет эту запись в момент t3 исходя из значений, «увиденных» в момент времени t1, а транзакция В обновляет ту же запись в момент времени t4, исходя из значений, «увиденных» в момент t2, являющихся теми же самыми, что и значения, «увиденные» в момент t1. Обновление, осуществляемое транзакцией А, утрачивается в момент t4, поскольку транзакция В перекрывает его своим обновлением, даже на него «не глядя».
^ Проблема зависимости от незафиксированных обновлений
Проблема зависимости от незафиксированных обновлений возникает в случае, если одной транзакции разрешается осуществлять выборку или, хуже того, обновление записи, которая уже была обновлена другой транзакцией, но это обновление еще не было зафиксировано этой другой транзакцией. Поскольку оно еще не было зафиксировано, всегда существует возможность, что оно никогда не будет зафиксировано, и вместо этого произойдет откат. В результате первая транзакция «увидит» некоторые данные, которые теперь больше не существуют, и в некотором смысле «никогда» не существовали. Рассмотрим рис. 11.2 и 11.3.
| Транзакция А | Время | Транзакция В | ||
| — | — | |||
| — | — | |||
| — | t1 | UPDATE R | ||
| — | — | |||
| FETCH R | t2 | — | ||
| — | — | |||
| — | t3 | ROLLBACK | ||
| — | ||||
Рис. 11.2. Транзакция А становится зависимой от незафиксированных изменений в момент t2
| Транзакция А | Время | Транзакция В | ||
| — | — | |||
| — | — | |||
| — | t1 | UPDATE R | ||
| — | — | |||
| UPDATE R | t2 | — | ||
| — | — | |||
| — | t3 | ROLLBACK | ||
| — | ||||
Рис. 11.3. Транзакция А обновляет незафиксированное изменение в момент t2 и утрачивает это обновление в момент t3
В первом из этих примеров (рис. 11.2) транзакция А «видит» незафиксированное обновление (или незафиксированное изменение) в момент t2. Затем это обновление в момент t3 аннулируется. Следовательно, транзакция А выполняется при ошибочном предположении, а именно при предположении, что запись R имеет значение, «увиденное» в момент t2, тогда как на самом деле она вообще имеет значение, которое имела до момента t1. В результате вполне возможно, что транзакция А будет продуцировать некорректный результат. Отметим, между прочим, что откат транзакции В (по команде ROLLBACK) может и не являться следствием каких-либо ошибок в В. Он может быть, например, результатом отказа системы. (И транзакция А уже может завершиться к этому времени. В результате отказ системы не вызовет необходимости издать команду ROLLBACK также и для А.)
Второй пример (рис. 11.3) еще хуже. Транзакция А не только становится зависимой от незафиксированного изменения данных в момент t2, но и фактически утрачивает обновление в момент t3, поскольку операция ROLLBACK в момент t3 заставляет восстановить для записи R ее значение, которое она имела в момент t1. Это другой вариант проблемы утраченного обновления.
^ Проблема анализа на противоречивость
Рассмотрим рис. 11.4, на котором показаны две транзакции А и В, оперирующие записями счетов. Транзакция А суммирует остатки на счетах, транзакция В переносит сумму 10 со счета 3 на счет 1. Продуцируемый А результат 110, очевидно, некорректен, и если бы А должна была записать этот результат в базу данных, она оставила бы фактически базу данных в противоречивом состоянии. Будем говорить, что А «видела» противоречивое состояние базы данных и поэтому провела анализ на противоречивость. Отметим различие между данным и предыдущим примером. Здесь нет проблемы зависимости А от незафиксированных изменений, поскольку В фиксирует все произведенные ею обновления прежде, чем А «увидит» запись СЧЕТА 3.
| СЧЕТ 1 | СЧЕТ 2 | СЧЕТ 3 | ||||
| 40 | 50 | 30 | ||||
| Транзакция А | Время | Транзакция В | ||||
| — | — | |||||
| — | — | |||||
| ^ FETCH СЧЕТ 1 (40): СУММА == 40 | t1 | — | ||||
| — | — | |||||
| ^ FETCH СЧЕТ 2 (50): СУММА = 90 — | t2 | — | ||||
| — | — | |||||
| — | t3 | ^ FETCH СЧЕТ 3 (30) | ||||
| — | — | |||||
| — | t4 | ^ UPDATE СЧЕТ 3: 30®20 | ||||
| — | — | |||||
| — | t5 | ^ FETCH СЧЕТ 1 (40) | ||||
| — | — | |||||
| — | t6 | ^ UPDATE СЧЕТ 1: 40®50 | ||||
| — | — | |||||
| — | t7 | COMMIT | ||||
| — | ||||||
| FETCH СЧЕТ 3 (20): СУММА=110, а не 120 | t8 | |||||
Рис. 11.4. Транзакция А осуществляет анализ на противоречивость