Размещено на http://www.allbest.ru/

Проектирование транзакционной изолированности в различных типах приложений на примере базы данных Microsoft SQL Server

Герасимов А.А.,

Тихомирова А.Н.

Аннотации

В данной работе представлено проектирование транзакционной изолированности в различных типах приложений на примере базы данных Microsoft SQL Server. В данной статье представлены случаи применения транзакций, показаны стратегии изоляции, их преимущества и недостатки. Также в работе проанализированы случаи применения транзакций для различных типов приложений, показаны преимущества одних типов транзакций по отношению к другим.

Ключевые слова: Microsoft SQL Server, транзакции, изолированность транзакций. транзакция стратегия применение

DESIGNING TRANSACTIONAL ISOLATION IN VARIOUS TYPES OF APPLICATIONS USING THE EXAMPLE OF A MICROSOFT SQL SERVER DATABASE

Gerasimov A.A., Tikhomirova A.N.

This paper presents the design of transactional isolation in various types of applications using the example of the Microsoft SQL Server database. This article presents the cases of application of transactions, shows isolation strategies, their advantages and disadvantages. Also, the work analyzes cases of application of transactions for various types of applications, shows the advantages of some types of transactions in relation to others.

Keywords: Microsoft SQL Server, transactions, transaction isolation.

Введение

Почти во всех приложениях, работающих с базой данных, используются транзакции. Данный механизм позволяет настраивать корректную работу приложения для большого количества пользователей. Правильное проектирование транзакций позволяет приложению обрабатывать множество подключений без ущерба для производительности и корректности информации. Вообще, под транзакцией понимается какое-то неделимое действие, но механизм работы транзакций гораздо шире. Чаще всего под термином транзакции подразумевается аббревиатура ACID, который расшифровывается, как: А - atomicity (неделимость), С - consistency (согласованность), I - isolation (изоляция), D - durability (долговечность). В работах авторов [1],[6] описаны существующие типы изоляции транзакций, но не рассмотрены случаи применения транзакционной изолированности под различные типы разрабатываемых систем. В данных работах не показано, какой уровень изоляций подходит для какой системы, в связи с чем, разработчики не всегда знают какой уровень изоляции использовать в приложении. В этой статье будет подробна рассмотрена изоляция транзакций, описаны случаи, когда нужно их использовать и какой уровень изоляции предпочтительнее для различного рода систем.

Цель

Показать случаи использования транзакций. Рассмотреть изолированность транзакций, показать их преимущества и недостатки, а также описать применение транзакций для различных типов приложений.

Случаи использования транзакций

Стоит отметить, что транзакции не всегда нужны в базе данных в явном виде (Explicit transaction). В большинстве случаев пользователи баз данных работают с транзакциями даже не замечая этого (AutoCommit transaction). Простая операция удаления является транзакций и это легко проверить. Как уже было сказано выше, транзакция - это неделимое действие. Если операцию удаления спроектировать так, что один из параметров был не корректный, то не выполнится удаление для всех параметров. Это сделано для надежности работы баз данных. Такое же правило работает для всех запросов в Microsoft SQL Server [1]. Ниже приведем случаи, когда в приложениях начинают работать транзакции:

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

2. Менее распространенный случай использования транзакций - это последовательное выполнение каких-то действий по работе с базой данных, которые должны либо выполниться все, либо не выполниться ни одного. Примером такой работы является перевод денег с одного счета на другой.

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

Когда в приложении появляется потребность использования одной таблицы для множества пользователей, возникает необходимость в транзакциях. Контролирование корректности взаимодействия пользователей называется изоляцией транзакции. Если быть точнее, то под изоляцией подразумевается такая работа базы данных, при которой любой пользователь не ощущает присутствия кого-то ещё, иными словами, база данных является изолированной лишь для него одного, отсюда и пошло данной понятие [3].

Стратегии изоляций

Существует два подхода (стратегии) реализации изоляции: оптимистический и пессимистический. В каждой из стратегии существует несколько подходов к реализации. На рисунке 1 представлена структура данных стратегий.

Рисунок 1 - Стратегии изоляции

Как видно из рисунка 1, в пессимистическом режиме увеличение надежности приводит к уменьшению быстродействия. Также стоит отметить, что блокировки можно наложить на различные области: блокировка строк, блокировка страницы, блокировка таблицы, блокировка схемы, блокировка базы данных. Чем меньшая область блокируется, тем база данных работает быстрее, потому что существует меньшая вероятность столкновения транзакций [2].

Для рассмотрения механизма работы стратегий транзакций будем считать, что существует два пользователя: первый пишет в базу данных и его называют "писатель", второй читает из базы данных и его называют "читатель" (данная терминология является общепринятой, поэтому для понятности будем использовать именно её). Также для ясности рассмотрения ситуации будем считать, что "писатель" начисляет деньги на карточку своему сотруднику, а "читатель" это и есть сам сотрудник. По сути, рассмотрим обычную ситуацию с начислением зарплаты на карточку, где "читатель" вставляет карточку в банкомат и пытается посмотреть средства на ней, а "писатель 2 переводит деньги на карточку "читателю" в этот момент.

Пессимистические стратегии

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

Таблица 1 - Запрос при использовании read uncommitted

В таблице 1 показана последовательность действий при взаимодействии "читателя" и "писателя". "Читатель" вставляет карточку в банкомат и видит на своем счету определенную сумму денег. В этот момент "писатель" решил перевести деньги "читателю" на счет, но транзакцию не закончил, то есть не написал commit или rollback. "Читатель" решил снова посмотреть свои средства и увидел на 5 рублей больше, чем было. Но на самом деле у него пока этих денег нет, так как "писатель" не закончил транзакцию. В итоге "писатель" решил откатить транзакцию, и при новом просмотре своего счета "читатель" видит первоначальную сумму. Данный случай называет "грязным чтением". При "грязном чтении" пользователи могут увидеть информацию, которой на самом деле в базе данных нет, они видят какую-то промежуточную или неподтвержденную информацию. Преимуществом данной стратегии изоляции является то, что не возникает блокировок, то есть база данных работает быстро. Такая стратегия подходит сервисам, в которых важна скорость работы и обслуживание большого количество пользователей. Даже если информация будет неверной, то это не будет проблемой. К программам такого вида можно отнести сервис прогноза погоды или новостную ленту.

Read committed

Перед описанием данного уровня изоляции стоит отметить, что именно его по умолчанию используют самые популярные в наше время базы данных: Oracle, Microsoft SQL Server, PostgreSQL и др. Данный тип изоляции позволяет избежать множественных блокировок, что является ключевым показателем для больших и средних систем, но также позволяет работать с актуальными данными. Как видно из рисунка 1, данный уровень изоляции находится немного выше по ступени надежности, это подразумевает, что при использовании read committed пользователи не увидят "грязных" данных.

Таблица 2 - Запрос при использовании read committed

Ситуация абсолютно такая же, как и в прошлом случае. В данном случае, если "писатель" начал работать со счетом "читателя", а "читатель" решил посмотреть свой счет, то он попадёт в блокировку. Другими словами, до тех пор, пока "писатель" не закончит свою транзакцию, "читатель" не сможет увидеть никакой информации о своем счете. Такой механизм работы избавляет пользователей от "грязных данных". Но как видно из рисунка 1, данный режим изоляции не является самым надежным. Причина заключается в следующей ситуации. Если "читатель" начал смотреть свой счёт и увидел определенную сумму денег, а "писатель" решил перевести деньги в этот момент, то при повторном просмотре своего счета "читатель" увидит уже другую сумму денег. С точки зрения "читателя" произошло нарушение базового принципа работы транзакций: пользователь увидел, что не он один работает сейчас со своим счетом. Такой механизм работы транзакций плох тем, что пользователь может несколько раз прочитать данные со своего счета, и каждый раз видеть абсолютно разные цифры. Данная ситуация называется "неповторяющееся чтение". Данная стратегия изоляции подходит для программ или приложений, которым важна эффективность работы, а также реальные данные, а тот факт, что они будут постоянно меняться не является большой проблемой. Примером таких программ являются приложения, работающие с фондовыми биржами, потому что режим read uncommitted не подходит из-за "грязного" чтения (происходят постоянные переводы и изменения данных, поэтому можно увидеть совершенно неверную информацию), а увеличение надежности ещё на один уровень приводит к медленной работе программы [4].

Repeatable read

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

Табл. 3 - Запрос при использовании repeatable read.

В данной ситуации "читатель" начал работать со своим счетом, а "писатель" пытается положить деньги на счет "читателя". При данном режиме изоляции "писатель" попадет в блокировку и будет там находиться до тех пор, пока "читатель" будет работать со своим счетом. В данном режиме изоляции тот, кто начал работать с какой-то информацией, блокирует любые подключения к данной информации. Как видно из рисунка 1, данная стратегия не является самой надежной. Рассмотрим ситуацию, когда пользователь в данном режиме работает с целой таблицей. Данные в этой таблице не могут меняться, но могут добавляться новые строки. Появление новых строк в таком режиме изоляции называется "фантомные записи".

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

Serializable

Это самый строгий и редкий режим изоляции.

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

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

Таблица 4 - Запрос при использовании Serializable.

Оптимистические стратегии

Оптимистичный способ исходит из того, что в большинстве случаев конфликтов не происходит. Поэтому никаких блокировок на записи не устанавливается. Данная стратегия не приобрела большую популярность из-за того, что при работе с данными пользователю выдается копия данных. Когда пользователь поработает с данными, то происходит изменение данных уже в реальной таблице. Но если несколько пользователей одновременно будут работать с одними и теми же данными, а потом добавлять их в таблицу, то только у первого, кто будет добавлять, добавление произойдет успешно, а у остальных произойдет ошибка 3960 или другими словами Update conflict, и случится откат транзакции. По сути, под этим подразумевается, что при данной стратегии изоляции лишь один пользователь должен работать с информацией, иначе будут происходить ошибки обновления. Также стоит отметить, что при использовании данной стратегии нужно всю базу данных перевести на эту стратегию, то есть все транзакции будут работать в оптимистическом режиме.

Snapshot

При данном виде блокировок копия живет до конца транзакции. Если пользователь начал работать с какими-то данными, то они останутся неизменными до конца работы транзакции, даже если в исходной таблице они уже изменились. Данный режим похож на режим read committed.

Данная стратегия очень редко используется на практике, потому что она не обладает какими-то преимуществами перед read uncommitted или read commited snapshot.

Read commited snapshot

При данном виде блокировок копия живет до конца select, другими словами, при каждом новом считывании данных из исходной таблицы, данные в копии будут обновляться. Если пользователь начал работать с какими-то данными в данном режиме, то при каждом новом select пользователь будет получать реальные данные из таблицы. Данный режим изоляции очень похож на read committed, и подойдет лишь для тех систем, в которых важно отсутствие блокировок.

Результаты анализа стратегий изоляции транзакций

В таблице 5 приведены результаты анализа стратегия изоляции транзакций на основе проанализированной ранее информации.

Таблица 5 - Результаты анализа стратегий изоляции транзакций

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

Заключение

В рамках данной статьи было рассмотрено проектирование транзакционной изолированности в различных типах приложений на примере базы данных Microsoft SQL Server. Рассмотрены случаи применения транзакций, описаны оптимистическая и пессимистическая стратегии проектирования транзакций, описаны их преимущества и недостатки, а также показан выбор конкретных транзакций для эффективной работы различного рода приложений.

Список литературы

1. Бен-Ган, Ицик. Основы T-SQL, Microsoft SQL Server 2012. Эксмо,2015. --399с.

2. Грофф Дж. Р., Вайнберг П.Н., Оппелъ Э. Дж. QL: The Complete Reference Третье издание.Вильямс, 2015. - 387 с.

3. В.В. Кириллов, Г.Ю. Громов. Введение в реляционные базы данных. БХВ-Петербург, 2009. - 528 с.

4. Б.А. Новиков, Г.Р. Домбровская. Настройка приложений баз данных. БХВ-Петербург, 2006. - 412 с.

5. Питер Роб, Карлос Коронел. Системы баз данных: проектирование, реализация и управление, 5-е издание. БХВ-Петербург, 2004. - 501 с.

6. Л.В. Рудикова. Базы данных. Разработка приложений. БХВ-Петербург, 2006. - 415 с.

Размещено на Allbest.ru