Главная Обратная связь

Дисциплины:

Архитектура (936)
Биология (6393)
География (744)
История (25)
Компьютеры (1497)
Кулинария (2184)
Культура (3938)
Литература (5778)
Математика (5918)
Медицина (9278)
Механика (2776)
Образование (13883)
Политика (26404)
Правоведение (321)
Психология (56518)
Религия (1833)
Социология (23400)
Спорт (2350)
Строительство (17942)
Технология (5741)
Транспорт (14634)
Физика (1043)
Философия (440)
Финансы (17336)
Химия (4931)
Экология (6055)
Экономика (9200)
Электроника (7621)


 

 

 

 



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



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. [28] Оптимистические протоколы управления транзакциями.

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

Роб, стр. 580

4-consistency, слайд 34

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

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

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

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

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

 



Просмотров 736

Эта страница нарушает авторские права




allrefrs.su - 2025 год. Все права принадлежат их авторам!