Керування паралельним доступом за допомогою багатоверсійності (з англ. MVCC — MultiVersion Concurrency Control) - це метод керування паралельним доступом, який зазвичай використовується системами керування базами даних (СКБД) та в мовах програмування, щоб реалізувати технологію транзакційної пам’яті.
Без керування паралельного доступу, якщо хтось зчитує дані бази даних в той же час, коли хтось записує, є можливість, що читач побачить напів написану або непослідовну інформацію. Наприклад, коли виконується банківський переказ між двома банківськими рахунками, то якщо читач подивиться баланс, коли гроші були зняті з оригінального рахунку та перед тим як вони були нараховані на потрібний рахунок, це буде виглядати нібито гроші зникли з банку. Ізоляція – це властивість, що гарантує паралельний доступ до даних. Ізоляція реалізується за допомогою протоколу керування паралельним доступом. Найпростішим методом буде змусити всіх читачів чекати поки записувач не закінчить, що відомо як блокування читання-запису. Такі блокування часто викликають суперечки, особливо між довгими транзакціями читання та обновлення. Задумка MVCC в тому, щоб зберігати декілька копій кожного елементу даних. Таким чином, кожен користувач, що під’єднаний до бази даних в конкретний період часу бачить лише т.н. «знімок» бази даних. Будь-які зміни зроблені записувачем не будуть показані іншим користувачам до їх завершення.
Коли база даних, що використовує MVCC, потребує оновити елемент даних, вона не перепише оригінальний елемент даних новою інформацією, а створить новішу версію елементу даних. Таким чином зберігається декілька версій. Версія, що кожна транзакція бачить, залежить від того який рівень ізоляції реалізується. Найбільш часто з MVCC використовують т.н. «знімкову» ізоляцію. З такою ізоляцією, транзакція бачить стан інформації в той час, коли ця транзакція почалась. Але виникає проблема видалення версій, що стали застарілі та ніколи не будуть прочитані. В деяких випадках, виконується процес періодичного очищення застарілих версій. Зазвичай цей процес проходить через всю таблицю та переписує її останньою версією кожного елементу даних. PostgreSQL використовує цей підхід з його VACUUM процесом. Інші бази даних ділять блоки зберігання на дві частини: інформаційну та резервну. Інформаційна завжди зберігає останню версію. Резервна дає можливість відтворення минулих версій даних. Основне обмеження останнього підходу в тому, що при великій кількості оновлень, у резервної частини закінчується місце і транзакції припиняються, бо не можуть отримати їх «знімок».
MVCC має узгоджені перегляди. Транзакції читання в MVCC зазвичай використовують мітку часу або ID транзакції, щоб визначити який стан БД прочитати, та прочитати ці версії даних. Транзакції написання та читання таким чином ізольовані без потреби блокування.
Реалізація
MVCC використовує мітки часу та інкрементуючі ID транзакцій, щоб досягти узгодженість транзакцій. MVCC забезпечує те, що транзакції ніколи не буде потрібно чекати, щоб прочитати об’єкт бази даних завдяки зберіганню декількох версій об’єкту. Кожна версія об’єкту має мітку часу для читання та мітку часу для запису, що дозволяє конкретній транзакції прочитати останню версію об’єкту, яка існує перед міткою часу читання.
Якщо транзакції 1 потрібно записати щось до об'єкта та в цей час існує інша транзакція 2 до цього об’єкту, то мітка часу читання першої транзакції повинна бути перед міткою часу читання другої транзакції, щоб операція запису відбулася вдало. Запис не може бути зроблений, якщо існують транзакції у яких мітка часу читання раніше для цього ж об’єкту.
Тобто: кожен об’єкт має мітку часу, але якщо транзакція хоче записати щось до об'єкта і транзакція має мітку часу, що раніша ніж теперішня мітка часу читання об'єкта, то транзакції скасовується та починається заново. ( Оскільки ця транзакція опирається на застаріле значення) В іншому випадку така транзакція створить нову версію об’єкту та встановить мітку часу запису/читання нової версії до мітки часу транзакції.
Недолік цієї системи в тому що, необхідно зберігати декілька версій об’єктів в базі даних. З іншого боку, читання ніколи не блокується, тому що може бути важливим для роботи, що переважно потребує читання значень з бази даних. MVCC особливо майстерний в реалізації справжньої «знімкової» ізоляції, в той час як інші методи керування паралельним доступом часто реалізують її не повністю, або з високими витратами ресурсів комп’ютера.
Примітки
- . clojure.org. Архів оригіналу за 12 квітня 2019. Процитовано 12 квітня 2019.
- Ramakrishnan, R., & Gehrke, J. (2000). Системи управління базами даних. Осборн / Макгроу-Хілл.
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Keruvannya paralelnim dostupom za dopomogoyu bagatoversijnosti z angl MVCC MultiVersion Concurrency Control ce metod keruvannya paralelnim dostupom yakij zazvichaj vikoristovuyetsya sistemami keruvannya bazami danih SKBD ta v movah programuvannya shob realizuvati tehnologiyu tranzakcijnoyi pam yati Bez keruvannya paralelnogo dostupu yaksho htos zchituye dani bazi danih v toj zhe chas koli htos zapisuye ye mozhlivist sho chitach pobachit napiv napisanu abo neposlidovnu informaciyu Napriklad koli vikonuyetsya bankivskij perekaz mizh dvoma bankivskimi rahunkami to yaksho chitach podivitsya balans koli groshi buli znyati z originalnogo rahunku ta pered tim yak voni buli narahovani na potribnij rahunok ce bude viglyadati nibito groshi znikli z banku Izolyaciya ce vlastivist sho garantuye paralelnij dostup do danih Izolyaciya realizuyetsya za dopomogoyu protokolu keruvannya paralelnim dostupom Najprostishim metodom bude zmusiti vsih chitachiv chekati poki zapisuvach ne zakinchit sho vidomo yak blokuvannya chitannya zapisu Taki blokuvannya chasto viklikayut superechki osoblivo mizh dovgimi tranzakciyami chitannya ta obnovlennya Zadumka MVCC v tomu shob zberigati dekilka kopij kozhnogo elementu danih Takim chinom kozhen koristuvach sho pid yednanij do bazi danih v konkretnij period chasu bachit lishe t n znimok bazi danih Bud yaki zmini zrobleni zapisuvachem ne budut pokazani inshim koristuvacham do yih zavershennya Koli baza danih sho vikoristovuye MVCC potrebuye onoviti element danih vona ne perepishe originalnij element danih novoyu informaciyeyu a stvorit novishu versiyu elementu danih Takim chinom zberigayetsya dekilka versij Versiya sho kozhna tranzakciya bachit zalezhit vid togo yakij riven izolyaciyi realizuyetsya Najbilsh chasto z MVCC vikoristovuyut t n znimkovu izolyaciyu Z takoyu izolyaciyeyu tranzakciya bachit stan informaciyi v toj chas koli cya tranzakciya pochalas Ale vinikaye problema vidalennya versij sho stali zastarili ta nikoli ne budut prochitani V deyakih vipadkah vikonuyetsya proces periodichnogo ochishennya zastarilih versij Zazvichaj cej proces prohodit cherez vsyu tablicyu ta perepisuye yiyi ostannoyu versiyeyu kozhnogo elementu danih PostgreSQL vikoristovuye cej pidhid z jogo VACUUM procesom Inshi bazi danih dilyat bloki zberigannya na dvi chastini informacijnu ta rezervnu Informacijna zavzhdi zberigaye ostannyu versiyu Rezervna daye mozhlivist vidtvorennya minulih versij danih Osnovne obmezhennya ostannogo pidhodu v tomu sho pri velikij kilkosti onovlen u rezervnoyi chastini zakinchuyetsya misce i tranzakciyi pripinyayutsya bo ne mozhut otrimati yih znimok MVCC maye uzgodzheni pereglyadi Tranzakciyi chitannya v MVCC zazvichaj vikoristovuyut mitku chasu abo ID tranzakciyi shob viznachiti yakij stan BD prochitati ta prochitati ci versiyi danih Tranzakciyi napisannya ta chitannya takim chinom izolovani bez potrebi blokuvannya RealizaciyaMVCC vikoristovuye mitki chasu ta inkrementuyuchi ID tranzakcij shob dosyagti uzgodzhenist tranzakcij MVCC zabezpechuye te sho tranzakciyi nikoli ne bude potribno chekati shob prochitati ob yekt bazi danih zavdyaki zberigannyu dekilkoh versij ob yektu Kozhna versiya ob yektu maye mitku chasu dlya chitannya ta mitku chasu dlya zapisu sho dozvolyaye konkretnij tranzakciyi prochitati ostannyu versiyu ob yektu yaka isnuye pered mitkoyu chasu chitannya Yaksho tranzakciyi 1 potribno zapisati shos do ob yekta ta v cej chas isnuye insha tranzakciya 2 do cogo ob yektu to mitka chasu chitannya pershoyi tranzakciyi povinna buti pered mitkoyu chasu chitannya drugoyi tranzakciyi shob operaciya zapisu vidbulasya vdalo Zapis ne mozhe buti zroblenij yaksho isnuyut tranzakciyi u yakih mitka chasu chitannya ranishe dlya cogo zh ob yektu Tobto kozhen ob yekt maye mitku chasu ale yaksho tranzakciya hoche zapisati shos do ob yekta i tranzakciya maye mitku chasu sho ranisha nizh teperishnya mitka chasu chitannya ob yekta to tranzakciyi skasovuyetsya ta pochinayetsya zanovo Oskilki cya tranzakciya opirayetsya na zastarile znachennya V inshomu vipadku taka tranzakciya stvorit novu versiyu ob yektu ta vstanovit mitku chasu zapisu chitannya novoyi versiyi do mitki chasu tranzakciyi Nedolik ciyeyi sistemi v tomu sho neobhidno zberigati dekilka versij ob yektiv v bazi danih Z inshogo boku chitannya nikoli ne blokuyetsya tomu sho mozhe buti vazhlivim dlya roboti sho perevazhno potrebuye chitannya znachen z bazi danih MVCC osoblivo majsternij v realizaciyi spravzhnoyi znimkovoyi izolyaciyi v toj chas yak inshi metodi keruvannya paralelnim dostupom chasto realizuyut yiyi ne povnistyu abo z visokimi vitratami resursiv komp yutera Primitki clojure org Arhiv originalu za 12 kvitnya 2019 Procitovano 12 kvitnya 2019 Ramakrishnan R amp Gehrke J 2000 Sistemi upravlinnya bazami danih Osborn Makgrou Hill