49. Многоверсионные протоколы управления транзакциями.

4-consistency, слайд 30, 31

transactions, слайд 76

Database Management Systems, Raghu Ramakrishnan, Johannes Gehrke, p. 563-564;

MVSG-планировщики отсюда: http://citforum.ru/database/articles/multiversion/

http://en.wikipedia.org/wiki/Multiversion_concurrency_control

[Ru]

Управление конкурентным доступом с помощью многоверсионности (англ. MVCC — MultiVersion Concurrency Control) — один из механизмов обеспечения одновременного конкурентного доступа к БД, заключающийся в предоставлении каждому пользователю т. н. «снимка» БД, обладающего тем свойством, что вносимые данным пользователем изменения в БД невидимы другим пользователям до момента фиксации транзакции. Этот способ управления позволяет добиться того, что пишущие транзакции не блокируют читающих, и читающие транзакции не блокируют пишущих.

[Eng]

Multiversion concurrency control (abbreviated MCC or MVCC), in the database field of computer science, is a concurrency control method commonly used by database management systems to provide concurrent access to the database and in programming languages to implement transactional memory.

For instance, a database will implement updates not by deleting an old piece of data and overwriting it with a new one, but instead by marking the old data as obsolete and adding the newer "version." Thus there are multiple versions stored, but only one is the latest. This allows the database to avoid overhead of filling in holes in memory or disk structures but requires (generally) the system to periodically sweep through and delete the old, obsolete data objects. For a document-oriented database such as CouchDB it also allows the system to optimize documents by writing entire documents onto contiguous sections of disk—when updated, the entire document can be re-written rather than bits and pieces cut out or maintained in a linked, non-contiguous database structure.

MVCC also provides potential "point in time" consistent views. In fact read transactions under MVCC typically use a timestamp or transaction ID to determine what state of the DB to read, and read these "versions" of the data. This avoids managing locks for read transactions because writes can be isolated by virtue of the old versions being maintained, rather than through a process of locks or mutexes. Writes affect future "version" but at the transaction ID that the read is working at, everything is guaranteed to be consistent because the writes are occurring at a later transaction ID.

In other words, MVCC provides each user connected to the database with a "snapshot" of the database for that person to work with. Any changes made will not be seen by other users of the database until the transaction has been committed.

50. Оптимистические протоколы управления транзакциями.

Database Management Systems, Raghu Ramakrishnan, Johannes Gehrke, p. 559-560;

Роб, стр. 580

4-consistency, слайд 34

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

Перед завершением выполнения транзакции выполняется проверка с целью определения, имел ли место конфликт. Если конфликт найден, то транзакция отменяется и перезапускается. Оптимистический протокол управления параллельностью включает три фазы:

1. Фаза чтения. Она охватывает транзакцию от ее начала и вплоть до момента фиксации результатов. Транзакция считывает значения всех необходимых элементов и помещает из в локальные переменные. Любые обновления применяются только к локальной копии данных, но не к информации в основной БД.

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

3. Фаза записи. Эта фаза выполняется для транзакций, обновляющих данные. Она заключается в перенесении изменений локальных переменных в основную БД.

51. Объектные истории и расписания. Сериализуемость в объектной модели транзакций.

transactions, слайд 90-107

4-consistency, слайд 35

52. Условия корректности объектных расписаний и протоколы управления в объектной модели транзакций.

transactions, слайд 101, 112-...

53. Обрывы транзакций: восстановимые расписания.

конспект, стр. 52

4-consistency, слайд 45

transactions, слайды 149-

молина, стр. 952

54. Протоколы, обеспечивающие восстановимость.

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

4-consistency: “S2PL (Двухфазный протокол с удержанием замков на запись до конца транзакции) гарантирует восстановимость.”

55. Защита от отказов системы: правила ведения журнала.

4-consistency, слайд 37, 38

конспект, стр. 52, 53

http://en.wikipedia.org/wiki/Transaction_log

Роб, 9.1.4, стр. 563 (579/1040)

56. Защита от отказов: ведение журнала во время нормальной работы системы.

конспект, стр. 53

4-consistency, слайд 39

57. Защита от отказов: трехпроходный алгоритм восстановления.

конспект, стр. 53

4-consistency, слайд 40

58. Защита от отказов: трехпроходный алгоритм восстановления.

вопрос-fail, смотреть конспект где-то там же, стр 53, 4.4.3

http://invinciblellama.files.wordpress.com/2010/04/llama_8x10_3440.jpg

59. Алгоритм восстановления повторением истории.

4-consistency, слайд 44

Здесь мы сначала накатываем ВСЁ, что есть в журнале, потом откатываем ненужные. Фича в том, что сразу после наката система, по сути, может продолжать функционировать, то есть доступность повышается. А при откате ненужных просто ставим на них замочки, чтобы новые транзакции ничего не напортачили.

60. Ведение журнала: контрольные точки.

конспект, стр. 54, “Можно ускорить - запоминать контрольные точки.”

4-consistency, слайд 45, 46

Молина, стр. 852, 861, 867 (эта, последняя, наверное, нужнее всего)

Контрольные точки малого веса - наверное, имеется в виду: Молина, стр. 854 “Динамическое введение контрольных точек” + стр. 813, 867 (эта тоже).

61. Распределенные СУБД: фрагментирование и раскопирование.

Определение: Параллельная система: в конфигурации системы есть параллельно работающее

оборудование: процессоры и дисковые устройства. Память процессоров может быть как собственная

у каждого, так и общая. Компьютеры, где находятся базы, соединены быстрой сетью. База данных

— единый объект для приложений (параллелизм внутренний).

Определение: Распределенная система: сервер базы данных использует несколько компьютеров,

соединенных сетью, и БД размещена на нескольких компьютерах.

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

Определение: Доступность - отношение времен: система способна реагировать на запросы / общее календарное время.

Цели создания распределенных систем:

• Доступность

• Надежность

Типы распределенных систем:

• Фрагментация (fragmentation)

  • вертикальная

  • горизонтальная

• Раскопирование (replication)

Определение:

1. Некоторый хранимый объект (например, таблица) «раскопирован», если он

хранится в нескольких экземплярах на нескольких компьютерах в составе распределенной системы.

2. Объект «фрагментирован», если разные его части хранятся на разных узлах распределенной

системы.

Для каждого объекта вопрос о том, раскопировать его или фрагментировать, можно решать отдельно. То есть может быть одновременно и раскопированный, и фрагментированный объект. Может быть даже так, что фрагменты объекта раскопированы. Замечание. Нет необходимости, чтобы при раскопировании копия находилась на всех серверах — можно просто на нескольких.

Определение: Фрагментация бывает вертикальная и горизонтальная.

1. Вертикальная — разрежем таблицу по вертикали и разместим часть колонок на одном сервере,

а часть на другом.

2. Горизонтальная — разбиение таблицы на сегменты по строкам: часть строк в одном месте,

часть в другом. Фрагмент, размещенный на одном сервере - partition. Разделы полезны и в централизованных

системах

Распределенность нужна для увеличения доступности базы. Недоступность возникает из-за отказов. Нам важно, чтобы система была доступной вне зависимости от того, есть отказы или нет.

Виды отказов:

• отказы узлов;

• отказы сети (сеть может распадаться на части или могут изолироваться отдельные компьютеры).

Если сеть ненадежна и отказы частые, то надо размещать данные близко (в сетевом смысле) от тех

клиентов, которые эти данные используют. Если же менее надежны сами узлы, то для повышения доступности нужно раскопирование — причем не важно, на какие узлы. Чем больше степень раскопированности данных, тем выше степень доступности.

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

Cтратегии поддержки раскопированности:

1. немедленное распространение изменений;

2. периодическое обновление.

Протоколы обновления:

1. Простейший протокол:

   1. одновременное обновление всех копий.

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

2. Мажоритарный протокол:

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

   2. Чтение разрешается в любом случае, для обновления необходимо предварительно получить последнее состояние элемента данных.

   3. Корректность: для любого элемента данных последнее состояние имеется не менее чем на половине копий.

Отложенная согласованность:

• Ассинхронное отложенное распространение обновлений раскопированных данных

• Выполнение обновлений и фиксация транзакций выполняются без задержек

• Любые изменения могут быть потеряны, последний записавший выигрывает

• Ответственность за согласованность переносится на приложение

Нельзя путать 2 phase locking и 2 phase commit.

Предположим, что некоторая таблица имеется в нескольких копиях. Критерий распределенной системы —

доступность при наличии отказов сети/узлов. Есть два подхода.

1. При раскопировании используется первичная копия. Она устроена как обычная таблица (возможно,

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

вносятся в первичную таблицу — она самая свежая. Здесь 2 phase commit не требуется. Все изменения

выполняются на первичной копии. Минус: система становится не симметричной. Меньшее количество

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

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

обновление. Мгновенная копия используется только для чтения. Отставание не является критическим

для многих классов задач. Например, бизнес- аналитика (анализ торговой деятельности за много лет). В

остальное время использование копий не нагружает сеть. Отказы не сильно вредят. Факт распространенности

увеличивает факт доступности на чтение. Но не на обновление.

2. Есть стратегия обновления для любой копии данных. Изменения распространяются мгновенно. Все

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

этом случае ничего, кроме 2 phase commit, использовать нельзя. Немедленное распространение изменений

плохо по следующим причинам:

(a) медленная работа 2PC;

(b) медленная работа протокола;

(c) если хотя бы одна из копий недоступна, то обновление нельзя выполнить.

Но хорошая доступность на чтение (система доступна, если хотя бы одна из копий доступна). Таким

образом, доступность системы меньше, чем без распределенности. Вероятность неработоспособности

выше (см. п.3). Метод решения проблемы: синхронное обновление. Не будет первичной копии, но не

все копии будут одинаковы. Некоторые копии будут не самыми свежими. Обновлять можно только

самую свежую. Чтобы выполнить обновление, нужно получить согласие не менее чем половины сайтов

+ 1. Каждый раз, когда выполняется обновление, сайт должен убедиться, что его копия является самой

свежей. Затем опрашивает n/2 +1 систему. Если они все доступны, то обновление возможно и выполняется

2PC. В этом случае всегда можно найти систему, имеющую последнее корректное состояние, и оно будет

не менее чем в половине сайтов. Реализация: необходимо хранить номера состояний. Необходимо иметь

возможность обновить свое состояние по состоянию другого сайта. В этом случае, получив запрос на

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

такое же, значит, у нас актуальное. Если не так, то среди опрошенных сайтов есть по крайней мере один

с более свежим. Это следует из построения. Нужно получить это состояние, обновить и распространить

на все остальные сайты, с которыми удалось договориться. Используем 2PC, но требуется согласие не

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

недоступна. Рассмотрим потерю связности сети. Пусть часть работает, но менее чем половина. Они

могут продолжать чтение, но не обновление (нет кворума). Получаем высокую степень доступности.

После восстановления связности сети будет доступно обновление. Нет необходимости принудительного

обновления (оно будет произведено автоматически в момент, когда понадобится выполнить обновление

этого сайта). Если произойдет restart, то каждый узел может быть восстановлен автоматически. Данные

будут в согласованном состоянии, будет отставание, но при сборе кворума это будет исправлено. Степень

доступности: осталось менее половины — доступ на чтение, более половины — и на обновление. Неизвестно,

поддерживается ли такая техника какой-либо промышленной системой.

конспект, стр. 55

4-consistency, слайд 52, 53, 57-59