Операции с базами данных. Как они работают?

Ответ 1

• Существует множество различных способов, включая порядок транзакций, оптимистичный контроль concurrency и т.д. На самом деле это очень сложный вопрос, есть книги, написанные об этом:

  http://www.amazon.co.uk/Databases-Transaction-Processing-Application-Oriented-Approach/dp/0201708728/ref=sr_1_3?ie=UTF8&s=books&qid=1281609705&sr=8-3

• Это зависит от уровня ведения журнала в базе данных. Если строгие журналы с записью сохраняются, то в случае сбоя системы база данных может быть набрана обратно в согласованное состояние.

• Это зависит от типа concurrency. Оптимистичный concurrency не содержит блокировок, но если состояние db изменилось после завершения транзакции, оно заброшено и перезапущено. Это может ускорить dbs, где столкновения редки. Существуют также различные уровни блокировки: строка, таблица или даже весь db.

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

Ответ 2

Фактические данные, вероятно, будут зависеть в некоторой степени от того, на каком сервере БД он есть, но эта статья может вас заинтересовать: Обработка обходных листов

Ответ 3

Несколько определений ваших определений:

Atomic - это одна единица работы и не зависит от предыдущих и последующих транзакций.

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

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

Согласованные данные передаются или откат, нет "промежуточный" случай, когда что-то обновлено, а что-то не имеет.

Эта интерпретация совершенно неверна. Согласованное означает, что процессор транзакций (в данном случае, движок СУБД) не может оставить систему (базу данных) в состоянии нарушения любого объявленного ограничения, о котором ему известно (процессор транзакций). См., Например, "Введение в системы баз данных", Chpt 16.

Изолирован - транзакция не видит промежуточные результаты текущей транзакции.

Nitpicking: никакая транзакция, отличная от текущего, не позволяет видеть промежуточные состояния (состояния, а не результаты). Обратите внимание, что "уровни изоляции" механизмов обработки транзакций обычно определяют степень, в которой свойство я может быть нарушено!

Durable - значения сохраняются, если данные были зафиксированы, даже если система сработала сразу после.

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

Ответ 4

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

• Точность в конечном итоге зависит от блокировки или других атомных операций для обмена данными, модифицированными в транзакции (созданной в I) с исходными данными в общем представлении.

  Как база данных обрабатывает параллельные транзакции, сохраняя при этом еще одно правило Atomic?

  См. I.

• C oncistency полагается на более фундаментальные свойства A и I и больше распространяется на прикладной уровень, а не внутренне службы базы данных.

  Обеспечение правил (при использовании A и I) достаточно просто, выполнив их по модифицированным данным.

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

  Являются ли обновления для таблиц, выполненных в памяти, поэтому, если произошел сбой перед фиксацией, нет изменений в базе данных?

  См. I.

  Обратите внимание, что C onsistency в ACID является чисто логическим, статическим и не имеет уровней или оценок, связанных с распространением данных, предложенных позже теорема CAP.

• I исправление универсально достигается путем первоначального изменения копий исходных данных (прежде чем совершать изменения в общем представлении).

  Пока выполняется транзакция, запрещен ли доступ для чтения и записи к затронутым таблицам?

  Как правило, если только одна копия данных изменяется в одной транзакции, другие тривиально не будут видеть эти изменения. Однако уровни изоляции могут быть разными.

  Это единственное свойство ACID, которому разрешено иметь несколько уровней и градусов, не будучи просто черно-белым.

  В конечном счете, I solation является самым глубоким в его реализации и возможными компромиссами среди всех ACID. И подробнее > об этом свойстве является первой наиболее важной темой о том, какие гарантии службы базы данных (даже в контексте теорема CAP, где компромиссы снова эволюционируют вокруг согласованности изолированных представлений относительно распределенных данных).

• D, скорее всего, это скорее SLA.. p >

  Какая долговечность ( "записанная на поврежденный диск" или "избыточно распределенная по ОЗУ серверов с питанием плутонием" ) обычно согласовывается вне обычной логики транзакций.

  Реализация также довольно тривиальна и сводится к подтверждению успешной транзакции только после сброса всех возможных буферов.

Два аспекта реализации, имеющих решающее значение для производительности (в которых ACID явно не заботятся):

• Обнаружение конфликтов

  Должен быть способ (эффективно) обнаруживать конфликтующие изменения, выполненные одновременно в другой транзакции.

  Один крайний момент - заблокировать все, что не требует обнаружения конфликтов (не возможно concurrency).

  Другая крайняя точка оптимистична concurrency (по крайней мере частично). Затем необходимо знать, были ли вообще изменения. Это может быть реализовано с помощью счетчиков (номеров версий) или контрольных сумм для разных объектов в базе данных. Затем это становится тесно связанным с реализацией I.

• Процедура отката

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

Дополнительная дополнительная информация:

• краткое объяснение реализации транзакций в базах данных.
• answer, чтобы избежать транзакций с транзакциями без транзакций.
• answer, как реализовать отказоустойчивые методы в приложении.

Ответ 5

Согласовано - данные либо совершаются или откат, нет "промежуточного" случая где что-то обновлено и что-то не имеет.

Я не согласен с представлением Эрвина Смута о том, что означает "Согласованные" - ваша интерпретация ближе к деньгам. По моей интерпретации Ramakrishnan and Gehrke, согласованное состояние выходит за пределы объявленных ограничений системы.

В случае перевода денег между двумя учетными записями путем дебетования одного счета и кредитования другого система может находиться в нескольких состояниях:

• Оба счета сохраняют свои первоначальные балансы;
• Сумма вычитается из одного остатка на счете, но не добавляется к другому;
• Сумма добавляется с одного счета, но не вычитается из другого;
• Оба счета сохраняют свои окончательные балансы.

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

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

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

Ответ 6

"Что такое вердикт по вложенным транзакциям"

Нет вердикта. Вложенные транзакции существуют. Свойства ACID существуют. Они вынуждены сосуществовать. Абсолютов нет. Конечно, не ACID.