Уровни изоляции в терминах MVCC, часть 2: индексы и латентность

SQL> create table t1 (f1 integer);
SQL> insert into t1 values (1), (3), (5), (7), (9);
SQL> select * from t1;
 F1  
 --- 
  1  
  3  
  5  
  7  
  9  

Обновите Obscura и проиндексированные обновления

Без дальнейших церемоний, давайте разберемся с примерами.

Пример 1 , ВЫБРАТЬ ДЛЯ ОБНОВЛЕНИЯ

Выбор для обновления — интересная конструкция SQL. Выглядит так, как будто это чтение (в конце концов, оно содержит «SELECT») и возвращает набор результатов. Однако SELECT FOR UPDATE фактически является формой записи. По сути, SELECT FOR UPDATE записывает каждую строку, соответствующую предложению WHERE, но перезаписывает его точным значением, которое оно имело ранее. Затем он возвращает перезаписанные строки как набор результатов. Поскольку стандарт требует, чтобы эффективные «блокировки» на строках удерживались до фиксации транзакции, SELECT FOR UPDATE полезен, когда пользователям необходимо выполнить собственную двухфазную блокировку. Давайте рассмотрим пример SELECT FOR UPDATE в действии:

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

READ_COMMITTED блокирует, потому что не может решить, какую версию записи записать, пока не закончится Txn 1

CONSISTENT_READ блокирует, потому что он обнаружил одновременное обновление и не знает, завершится ли сбой или обновление, пока txn 1 не закончил

WRITE_COMMITTED блокируется, потому что он просто ожидает установки новой версии записи поверх записи версии Txn 1

Вот где обоснование WRITE_COMMITTED может быть интуитивно понятно . WRITE_COMMITTED позволяет выполнять последовательную семантику коммутативных записей более эффективно, чем другие уровни изоляции. Рассуждения здесь аналогичны рассуждениям о существовании ПОСЛЕДОВАТЕЛЬНОСТИ. Если я, как разработчик приложения, знаю, что обновление (или набор обновлений) коммутирует с обновлениями, которые другие транзакции будут выполнять для той же таблицы, то WRITE_COMMITTEDэто единственный уровень изоляции, который позволяет всем обновлениям транзакции накапливаться одновременно. Осложняющим фактором является то, что строгая семантика SQL требует, чтобы UPDATE (или DELETE) не мог вернуть, пока его изменения не будут согласованы. Следовательно, улучшение производительности будет на уровне единого оператора. В настоящее время это также относится к хранимым процедурам, однако здесь существует большая семантическая гибкость.

Пример 2. Индексированные обновления

Некоторые из вас, возможно, заметили, что все примеры были выполнены для таблицы без индексов. Это означает, что выбор записей является неточным. Несмотря на то, что UPDATE может потребоваться изменить одну строку, транзакция не имеет другого выбора, кроме как сканировать каждую строку в таблице, чтобы найти все совпадения. Конечно, именно это и должно помочь индексам. Давайте посмотрим, что (если что-нибудь) изменится, если мы прикрепим индекс к таблице:

> CREATE INDEX idx1 ON t1(f1);

В этом примере транзакция 2 не должна была блокироваться для фиксации транзакции 1, потому что индекс позволил обоим запросам на обновление выбрать точно совпадающие записи. Поскольку наборы записей для обновлений Txn 1 и Txn 2 не перекрываются, конфликта записи не существует, поэтому обе транзакции могут продолжаться. Важно отметить, что неблокирующее и блокирующее поведение соответствуют определению READ_COMMITTED . Разница в том, что неблокирующее поведение — это повышение производительности, обеспечиваемое индексами. Если бы обе транзакции 1 и 2 пытались обновить одну и ту же версию записи (независимо от точности выбора набора записей), все равно возник бы конфликт обновления.

Что это значит? CONSISTENT_READ (изоляция моментального снимка) обеспечивает точность по определению, поэтому индексы не ускоряют запись туда. Но если ваше приложение использует READ_COMMITTED или WRITE_COMMITTED , вы можете уменьшить конкуренцию, добавив индекс, который увеличивает точность выбора набора для записи. Это хорошее эмпирическое правило, которое необходимо учитывать при диагностике проблем с производительностью.

Производительность и задержка:

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

Читает :
CONSISTENT_READ и WRITE_COMMITTED как сделать СНАПШОТ версий для обычного ЗЕЬЕСТА. Следовательно, чувствительность к задержке для этих уровней изоляции отсутствует. Таким образом, независимо от того, насколько медленным является соединение между двумя половинами базы данных, читатели по обе стороны от ссылки не будут испытывать снижение производительности из-за задержки.

Интуиция такого поведения заключается в том, что это является прямым следствием релятивистской логики распределенной системы. В NuoDB транзакционный контроль является локальным для одного узла. Поэтому, когда транзакция начинается на TE, набор транзакций «произошло до» на этом узле точно известен. Это именно тот набор транзакций, который, как известно, совершается на этом узле в данный момент. Следовательно, не имеет значения, что такое «глобальный» порядок (и, следовательно, нет необходимости в атомных часах), любая транзакция, о которой еще не известно, что она зафиксирована, затем считается выполняющейся одновременно, и вычисления видимости выполняются соответствующим образом.

READ_COMMITTED — это отдельная история. Поскольку определение уровня изоляции заключается в чтении только самых последних зафиксированных версий записи, поведение чтения READ_COMMITTED зависит от времени сообщений фиксации, которые поступают в TE, обрабатывающий транзакцию READ_COMMITTED . Конечно, никто, пишущий приложение READ_COMMITTED, не может ожидать, что любые два выполнения одного и того же SELECT вернут одно и то же значение (согласно стандарту SQL). В зависимости от семантики приложения, READ_COMMITTEDможет связывать время завершения локальной транзакции с временем завершения удаленной транзакции. Любой данный SELECT всегда будет возвращать самые последние зафиксированные версии, но если локальная транзакция вращается в ожидании распространения удаленной фиксации, она будет страдать задержкой. Это ситуация, когда локальность данных определенно улучшит задержку транзакции.

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