Kyselinové transakce. Transakce. Vlastnosti ACID transakcí. Správa obnovy. Algoritmus ARIES. Dvoufázová fixace. Podívejte se, co je "ACID" v jiných slovnících
Není žádným tajemstvím, že za přítomnosti formulovaného heuristického pravidla zvaného CAP Theorem, na rozdíl od obvyklého systému RDBMS, třída řešení NoSQL nemůže poskytnout plnou podporu KYSELINA. Je třeba říci, že u řady úkolů to není potřeba a podpora jednoho z prvků vede ke kompromisu při řešení ostatních, ve výsledku je to široká škála existujících řešení. V tomto článku bych chtěl zvážit různé architektonické přístupy k řešení problémů částečného splnění požadavků na transakční systém."A" atomicita
Atomicita zajišťuje, že žádná transakce není částečně zavázána systému. Buď budou provedeny všechny jeho dílčí operace, nebo nebude provedena žádná.Obvykle se volí systémy NoSQL vysoký výkon ne v zájmu transakční sémantiky, protože její dodržování přináší dodatečné náklady na zpracování. Mnoho systémů stále poskytuje záruky na úrovni klíče nebo řádků (Google BigTable) nebo poskytuje rozhraní API pro atomické operace (Amazon DynamoDB), ve kterém může záznam upravit pouze jedno vlákno, pokud například chcete mít počítadlo přístupů uživatele distribuováno napříč shluk . Většina systémů dodržuje neblokující smyčky čtení-úpravy-zápisu. Cyklus se skládá z tři etapy- číst hodnotu, upravovat, zapisovat. Jak vidíte, ve vícevláknovém prostředí se může pokazit mnoho věcí, například co když někdo změní záznam mezi fázemi čtení a zápisu. Hlavním mechanismem pro řešení takových konfliktů je použití algoritmu Porovnat a vyměnit - pokud někdo změnil záznam během cyklu - musíme pochopit, že se záznam změnil, a opakovat cyklus, dokud nebude stanovena naše hodnota, takový algoritmus se zdá být vhodnější než zcela blokující mechanismus zápisu. Počet takových cyklů může být velmi velký, takže pro operaci potřebujeme určitý časový limit, po kterém bude operace zamítnuta.
Konzistence "C".
Transakce, která dosáhne svého normálního dokončení a tím potvrdí své výsledky, zachovává konzistenci databáze. Vzhledem ke specifičnosti NoSQL na distribuci informací mezi servery to znamená, zda všechny repliky obsahující kopii dat obsahují vždy stejnou verzi dat.Moderní NoSQL si vzhledem ke svým specifikům musí vybrat vysoká dostupnost a schopnost horizontální měřítko cluster - ukazuje se, že systém nemůže zajistit úplnou konzistenci dat a vytváří určité předpoklady při definování pojmu konzistence. Existují dva přístupy:
Přísná konzistence
Takové systémy zajišťují, že repliky jsou vždy schopny se dohodnout na jedné verzi dat vrácených uživateli. Některé repliky tuto hodnotu obsahovat nebudou, ale když systém zpracuje požadavek na hodnotu podle klíče, stroj se bude vždy moci rozhodnout, kterou hodnotu vrátí – jen to nebude vždy poslední. Jak to funguje - například máme N repliky stejného klíče. Když přijde požadavek na aktualizaci hodnoty klíče, systém nevrátí výsledek uživateli, dokud W repliky neodpoví, že obdržely aktualizaci. Když uživatel požaduje hodnotu, systém vrátí uživateli odpověď, když je to alespoň R repliky vrátily stejnou hodnotu. Pak považujeme systém za přísně konzistentní, pokud je podmínka splněna R+W>N. Výběr hodnot R A W ovlivňuje, kolik počítačů musí reagovat, než se odpověď vrátí uživateli, obvykle vybírá podmínku R+W=N+1- minimální nutná podmínka aby byla zajištěna přísná konzistence.Možná konzistence
Některé systémy ( Voldemort, Cassandra, Riak) vám umožní vybrat R A W při kterém R+WŘešení tohoto konfliktu se na různých systémech liší, Voldemort vrací několik kopií hodnoty, takže konflikt nechává vyřešit uživatel. Dvě verze nákupního košíku uživatele na webu lze sloučit bez ztráty informací, zatímco sloučení dvou verzí stejného upravitelného dokumentu vyžaduje zásah uživatele. Cassandra, která ukládá časové razítko každého záznamu, vrací poslední, pokud je zjištěn konflikt, tento přístup neumožňuje sloučení dvou verzí bez ztráty informací, ale zjednodušuje klientskou část.
Cassandra od verze 1.1 zajišťuje, že pokud upgradujete:
AKTUALIZACE uživatelů
SET login="login" AND password="password"
WHERE key="key"
Pak při žádném souběžném čtení nedojde k částečné aktualizaci dat (přihlášení se změnilo, ale heslo se nezměnilo), a to pouze na úrovni řádků, které jsou ve stejném rodina sloupců a mít společný klíč. To může odpovídat úrovni izolace transakcí číst nezávazně, ve kterém se řeší konflikty ztracená aktualizace. Ale Cassandra neposkytuje mechanismus vrácení zpět na úrovni clusteru, například je možná situace, kdy přihlašovací jméno a heslo bude uloženo na určitém počtu uzlů, ale nestačí W aby uživatel dostal správný výsledek, je uživatel nucen tento konflikt vyřešit sám. Mechanismus zajištění izolace spočívá v tom, že pro každý pozměněný záznam je vytvořena neviditelná izolovaná verze pro klienty, která následně automaticky nahradí starou verzi prostřednictvím výše popsaných mechanismů Porovnat a Zaměnit.
"D" Spolehlivost
Bez ohledu na problémy na nižších úrovních (například výpadek systému nebo selhání hardwaru) by změny provedené úspěšně dokončenou transakcí měly zůstat uloženy i po návratu systému do provozu. Jinými slovy, pokud uživatel obdržel potvrzení ze systému, že transakce byla dokončena, může si být jistý, že změny, které provedl, nebudou kvůli nějakému selhání vráceny.Nejpředvídatelnějším scénářem selhání je výpadek napájení nebo restart serveru. Plně spolehlivý systém by v tomto případě neměl uživateli vracet odpověď, dokud všechny změny nezapíše z paměti na pevný disk. Zápis na disk trvá příliš dlouho a mnoho systémů NoSQL dělá kompromisy kvůli výkonu.
Zajištění spolehlivosti v rámci jednoho serveru
Standardní disk vydrží 70-150 operací za vteřinu, což je propustnost až 150 MB/s, ssd - 700 MB/s, DDR - 6000 - 17000 MB/s. Proto zajištění spolehlivosti v rámci jednoho serveru při současném zajištění vysokého výkonu znamená snížit počet zápisů s náhodným přístupem a zvýšit sekvenční zápisy. V ideálním případě by měl systém minimalizovat počet záznamů mezi hovory fsync(synchronizace dat v paměti a na disku). K tomu se používá několik technik.Ovládání frekvence fsync
Redis nabízí několik způsobů, jak nakonfigurovat, kdy volat fsync. Můžete jej nakonfigurovat tak, aby byl volán po každé změně záznamu – což je nejpomalejší a nejbezpečnější volba. Chcete-li zlepšit výkon, můžete spustit vyprázdnění disku každé N sekund, v nejhorším případě přijdete o data N posledních sekund, což může být pro některé uživatele docela přijatelné. Pokud spolehlivost není vůbec kritická, můžete fsync vypnout a spolehnout se na to, že systém v určitém okamžiku synchronizuje paměť s diskem.Zvýšení sekvenčního zápisu pomocí protokolování
Aby bylo možné efektivně vyhledávat data, systémy NoSQL často používají další struktury, například B-stromy pro vytváření indexů, což způsobuje mnohonásobné náhodné přístupy k disku. Aby se to snížilo, některé systémy ( Cassandra, HBase, Riak) přidat aktualizační operace do sekvenčně zapisovaného souboru s názvem předělat protokol. Zatímco některé struktury se zapisují na disk poměrně zřídka, protokol se zapisuje často. Po havárii lze chybějící záznamy obnovit pomocí protokolu.Zvýšení propustnosti seskupováním záznamů
Cassandra seskupuje více současných změn v rámci krátkého okna, které lze sloučit do jednoho fsync. Tento přístup, tzv skupinový závazek, zvyšuje dobu odezvy pro jednoho uživatele, protože je nucen čekat na několik dalších transakcí, aby zaznamenal svou vlastní. Výhoda se zde získá zvýšením celkové propustnosti, protože více náhodných záznamů lze kombinovat.Zajištění spolehlivosti v rámci serverového clusteru
Kvůli možnosti neočekávaných selhání disku a serveru je nutné distribuovat informace mezi několik počítačů.Redis představuje klasiku pán-otrok architektura pro replikaci dat. Všechny operace spojené s hlavním serverem jdou dolů do replik ve formě protokolu.
MongoDB je struktura, ve které daný počet serverů ukládá každý dokument a je možné nastavit počet serverů W
HBase dosahuje spolehlivosti více serverů díky použití distribuovaného systému souborů HDFS.
Obecně lze u moderních nástrojů NoSQL zaznamenat určitou tendenci k poskytování větší konzistence dat. Ale přesto mohou nástroje SQL a NoSQL existovat a vyvíjet se paralelně a řešit úplně jiné problémy.
Možná jste už slyšeli termín jako transakce . Pokud ne nebo jste zapomněli, pak vám připomeňme, že pod transakce odkazuje na určitou sekvenci operací (akce vložení, aktualizace nebo odstranění) v databázi, které musí být provedeny jako součást jednoho celku.
Všichni využíváme služeb bank a provádíme různé transakce s finančními prostředky. Jak v tomto případě dosáhnout spolehlivosti? Požadavky na zabezpečení pro provádění operací v takových systémech se zvyšují. Nyní si představte, že převádíte peníze někomu, koho znáte. Chcete, aby byly prostředky odepsány z vašeho účtu a převedeny na účet příjemce. Co se ale stane v případě výpadku proudu, jako je výpadek proudu nebo jiná nouzová situace? Kdo vám zaručí, že se neocitnete v situaci, kdy peníze z vašeho účtu odešly, ale k převodu na účet příjemce nedošlo. Pomozte takovým situacím předcházet transakce.
Potvrzení a vrácení transakce.
Transakce kombinuje několik příkazů SQL. Pokud dojde k jakémukoli selhání v důsledku provedení alespoň jednoho z požadavků, transakce je okamžitě vrácena zpět ( vrácení zpět). Pokud je vše v pořádku a všechny akce v rámci jedné transakce byly úspěšně dokončeny, provede se potvrzení ( spáchat) transakce a pouze v tomto případě jsou odpovídající změny zapsány do databáze.
Nyní si ukažme příklad použití transakcí v MySQL DBMS(v nejoblíbenějších DBMS tento mechanismus se zásadně neliší):
Dáme si testovací stůl účty, který uchovává informace o uživatelských účtech. A jeden obor, který nás zajímá, se jmenuje váhy. Při převodu z jednoho účtu na druhý by měly být finanční prostředky odepsány na jeden účet a připsány na druhý (pro cvičné účely si můžete sami vytvořit malou databázi).
Transakce začíná klíčovým slovem ZAČÍT. Dva operátoři AKTUALIZOVAT vnitřní transakce jsou součástí stejné transakce a mohou být provedeny buď obě současně, nebo žádná z nich (musí dojít k rollbacku). Tým SPÁCHAT slouží k označení konce transakce a provedení změn. Pokud je odevzdání úspěšné, zobrazí se všechny změny ve zdrojové databázi.
Chcete-li vrátit transakci zpět, můžete příkaz výslovně napsat NÁVRAT.
ACID vlastnosti.
Seznámili jsme se tedy s pojmem transakce, potvrzení a vrácení zpět. Nyní se podívejme na čtyři velmi důležité vlastnosti transakce, na které se lidé často rádi ptají na pohovorech. Požadavky KYSELINA na konci 70. let formuloval Jim Gray (vítěz Turingovy ceny za přínos k rozvoji databází). A takhle znějí:
- Atomicita- atomicita. O čem jsme mluvili výše. transakce je atomická, to znamená, že všechny akce provedené v rámci jedné transakce jsou jedním celkem.
- Konzistence— důslednost. Každá nová transakce přesune databázi z jednoho konzistentního stavu do druhého. Pokud je vaše databáze distribuována, musí všechny její repliky obsahovat stejnou verzi dat, aby byla zajištěna dostupnost. Toto pravidlo mnozí často porušují NoSQL databází.
- Izolace- izolace. Transakce se navzájem neovlivňují. V případě paralelního provádění by nemělo docházet k částečné aktualizaci dat.
- Trvanlivost— spolehlivost. Chcete, aby byly všechny změny provedené touto transakcí v případě selhání uloženy? Proto má tento seznam vlastnost spolehlivosti.
Požadavky ACID
Atomicita - Atomicita
Atomicita zajišťuje, že žádná transakce není částečně zavázána systému. Buď budou provedeny všechny jeho dílčí operace, nebo nebude provedena žádná. Protože v praxi není možné současně a atomicky provádět celou sekvenci operací v rámci transakce, zavádí se pojem „rollback“: pokud transakci nelze zcela dokončit, výsledky všech dříve provedených akcí budou zrušeny a systém se vrátí do původního stavu.
Konzistence - Konzistence
Jedna z nejsložitějších a nejednoznačných vlastností čtyř kyselin. Podle tohoto požadavku je systém v konzistentním stavu před zahájením transakce a musí zůstat v konzistentním stavu po dokončení transakce. Požadavek konzistence by neměl být zaměňován s požadavkem integrity. Poslední pravidla jsou užší a v mnoha ohledech specifická pro relační DBMS: existují požadavky na integritu typu, referenční integritu a integritu entity, které nelze fyzicky narušit kvůli implementačním funkcím systému.
Konzistence je širší pojem. Například v bankovním systému může existovat požadavek, aby se částka odepsaná z jednoho účtu rovnala částce připsané na jiný účet. Toto je obchodní pravidlo a nemůže být zaručeno pouze kontrolami integrity, ale programátoři jej musí dodržovat při psaní transakčního kódu. Pokud se nějaká transakce odečte, ale neodepíše, systém zůstane v nesprávném stavu a vlastnost konzistence bude narušena.
Na závěr ještě jedna poznámka se týká skutečnosti, že během konzistence provádění transakce není vyžadováno. V našem příkladu budou odepsání a připsání s největší pravděpodobností dvě různé dílčí operace a mezi jejich provedením v rámci transakce bude viditelný nekonzistentní stav systému. Nesmíme však zapomínat, že pokud je splněn požadavek na izolaci, nebude tato nekonzistence viditelná pro žádné další transakce. A atomicita zaručuje, že transakce bude buď kompletně dokončena, nebo nebude provedena žádná z transakcí. Tato mezilehlá nekonzistence je tedy skryta.
Izolace - Izolace
Zatímco transakce probíhá, souběžné transakce by neměly ovlivnit její výsledek. Tato vlastnost není respektována na úrovni izolace Read Committed a nižší.
Trvanlivost - Spolehlivost
Bez ohledu na problémy na nižších úrovních (například výpadek systému nebo selhání hardwaru) by změny provedené úspěšně dokončenou transakcí měly zůstat uloženy i po návratu systému do provozu. Jinými slovy, pokud uživatel obdržel potvrzení ze systému, že transakce byla dokončena, může si být jistý, že změny, které provedl, nebudou kvůli nějakému selhání vráceny.
Literatura
- P.A. Bernstein, N. Goodman, V. Hadzilacos.Řízení a obnova souběžnosti v databázových systémech. - Addison-Wesley, 1986.
Poznámky
Nadace Wikimedia.
2010.
Podívejte se, co je „ACID“ v jiných slovnících: kyselina
- ACÍD, Ă, acizi, de, s.m., adj. 1. s.m. Chemická látka, s poryvem vzduchu a miros bránicí, péče o modrou hârtia de turnesol a péče, v kombinaci se základnou, formou nebo sare. 2.příd. (obr. Adesea) Péče je vhodná pro kyseliny (1),… … Dicționar Român Kyselina
Podívejte se, co je „ACID“ v jiných slovnících:- Productions (ACiD) je součástí skupiny scénických uměleckých skupin v roce 1990, které jsou založeny na ANSI Art für Mailboxen spezialisiert hat. V den letzten Jahren fand mit dem Niedergang der Mailbox Szene ein Wechsel zu anderen Hauptaktivitäten wie… … Deutsch Wikipedia
- ACÍD, Ă, acizi, de, s.m., adj. 1. s.m. Chemická látka, s poryvem vzduchu a miros bránicí, péče o modrou hârtia de turnesol a péče, v kombinaci se základnou, formou nebo sare. 2.příd. (obr. Adesea) Péče je vhodná pro kyseliny (1),… … Dicționar Român- Od 60. let, kdy byla kyselina poprvé použita ve významu halucinogenní drogy LSD, toto slovo vyvinulo všechny konotace subkultury. Těmto braným drogám se začalo říkat kyselinové hlavy nebo kyselinové zrůdy; a jejich způsob života závisel na... ... moderním anglickém použití
- Productions ACiD Productions (ACiD) je skupina umělců a čísel underground. Fondé v roce 1990, skupina vytvořená ze speciálních grafických prvků ANSI pro BBS. Plus récemment, ils ont étendu leur domaine d application vers d… … Wikipédia en Français
Podívejte se, co je „ACID“ v jiných slovnících:- (anglicky „acid“): V hudbě jsou acid house, acid techno hudebními žánry. Acid je japonská rocková skupina. Acid je belgická speed/thrash metalová kapela. Acid Narkotická látka LSD 25. V informatice Sony ACID Pro audio editor ACID set... ... Wikipedia
- hořká, kyselá v chuti kyselá, kyselá, kousavá, pikantní, štiplavá, ostrá, kyselá, octová, octová; koncepce 613 Ant. nevýrazná, sladká kyselina s kyselými, žíravými vlastnostmi kyselá, kyselá, štiplavá, antialkalická, kousavá,… … Nový tezaurus Kyselina
- hořká, kyselá v chuti kyselá, kyselá, kousavá, pikantní, štiplavá, ostrá, kyselá, octová, octová; koncepce 613 Ant. nevýrazná, sladká kyselina s kyselými, žíravými vlastnostmi kyselá, kyselá, štiplavá, antialkalická, kousavá,… … Nový tezaurus- ID, a. 1. Kyselé, ostré nebo kousavé podle chuti; dortík; mající chuť octa: jako kyselé ovoce nebo likéry. Dále obr.: Kyselé temperované.
Atomicita - Atomicita
Atomicita zajišťuje, že žádná transakce není částečně zavázána systému. Buď budou provedeny všechny jeho dílčí operace, nebo nebude provedena žádná. Protože v praxi není možné současně a atomicky provádět celou sekvenci operací v rámci transakce, zavádí se pojem „rollback“: pokud transakci nelze zcela dokončit, výsledky všech dříve provedených akcí budou zrušeny a systém se vrátí do „externě počátečního“ stavu – zvenčí se bude zdát, že k transakci nikdy nedošlo. (Čítače, indexy a další vnitřní struktury se samozřejmě mohou změnit, ale pokud je DBMS naprogramován bez chyb, neovlivní to jeho vnější chování.)
Konzistence - Konzistence
Transakce, která dosáhne svého normálního konce (EOT - konec transakce), a tím potvrdí své výsledky, zachovává konzistenci databáze. Jinými slovy, každá úspěšná transakce podle definice zaznamenává pouze platné výsledky. Tato podmínka je nezbytná pro podporu čtvrté vlastnosti.
Konzistence je širší pojem. Například v bankovním systému může existovat požadavek, aby se částka odepsaná z jednoho účtu rovnala částce připsané na jiný účet. Toto je obchodní pravidlo a nemůže být zaručeno pouze kontrolami integrity, ale programátoři jej musí dodržovat při psaní transakčního kódu. Pokud se nějaká transakce odečte, ale neodepíše, systém zůstane v nesprávném stavu a vlastnost konzistence bude narušena.
Na závěr ještě jedna poznámka se týká skutečnosti, že během konzistence provádění transakce není vyžadováno. V našem příkladu budou odepsání a připsání s největší pravděpodobností dvě různé dílčí operace a mezi jejich provedením v rámci transakce bude viditelný nekonzistentní stav systému. Nesmíme však zapomínat, že pokud je splněn požadavek na izolaci, nebude tato nekonzistence viditelná pro žádné další transakce. A atomicita zaručuje, že transakce bude buď kompletně dokončena, nebo nebude provedena žádná z transakcí. Tato mezilehlá nekonzistence je tedy skryta.
Izolace - Izolace
Zatímco transakce probíhá, souběžné transakce by neměly ovlivnit její výsledek. Izolace je nákladný požadavek, proto ve skutečných databázích existují režimy, které transakci zcela neizolují (úrovně izolace Opakovatelné čtení a níže).
Trvanlivost - Trvanlivost
Bez ohledu na problémy na nižších úrovních (například výpadek systému nebo selhání hardwaru) by změny provedené úspěšně dokončenou transakcí měly zůstat uloženy i po návratu systému do provozu. Jinými slovy, pokud uživatel obdržel potvrzení ze systému, že transakce byla dokončena, může si být jistý, že změny, které provedl, nebudou kvůli nějakému selhání vráceny.
Viz také
Napište recenzi na článek "ACID"
Literatura
- P.A. Bernstein, N. Goodman, V. Hadzilacos.Řízení a obnova souběžnosti v databázových systémech. - Addison-Wesley, 1986.
Poznámky
|
||||||||||||||||||||||||||
Úryvek popisující ACID
Nataša mlčela, jak si Marya Dmitrievna myslela, ze ostychu, ale v podstatě bylo Nataše nepříjemné, že se vměšovali do jejího milostného vztahu s princem Andrejem, který se jí zdál tak výjimečný ze všech lidských záležitostí, že podle jejích představ nikdo mohl to pochopit. Milovala a znala jednoho prince Andreje, on ji miloval a měl jednoho z těchto dnů přijít a vzít si ji. Nic jiného nepotřebovala."Vidíš, znám ho už dlouho a miluji Mashenku, tvou švagrovou." Švagrové jsou šikulky, ale tohle mouše neublíží. Požádala mě, abych ji s vámi spojil. Zítra k ní půjdeš ty a tvůj otec a pořádně ji obejmeme: jsi mladší než ona. Nějak ten tvůj dorazí a ty už znáš svou sestru a otce a oni tě milují. ano nebo ne? Určitě to bude lepší?
"Lepší," odpověděla Natasha neochotně.
Následujícího dne na radu Maryy Dmitrievny šel hrabě Ilya Andreich s Natašou k princi Nikolai Andreichovi. Hrabě se na tuto návštěvu připravil s ponurým duchem: v srdci se bál. Poslední setkání během domobrany, kdy si hrabě v reakci na své pozvání na večeři vyslechl žhavou důtku za nedoručování lidí, bylo pro hraběte Ilju Andreje památné. Natasha, oblečená ve svých nejlepších šatech, byla naopak v nejveselejší náladě. "Je nemožné, aby mě nemilovali," pomyslela si: všichni mě vždy milovali. A jsem tak připraven udělat pro ně, co chtějí, jsem tak připraven milovat ho – protože on je otec a ona, protože je sestra, že není důvod, proč by mě nemilovali!“
Zajeli do starého, ponurého domu na Vzdvizhence a vešli do chodby.
"Nuže, Bůh žehnej," řekl hrabě napůl žertem, napůl vážně; ale Nataša si všimla, že její otec spěchal, vstoupil do síně a nesměle se tiše zeptala, zda jsou princ a princezna doma. Po hlášení o jejich příjezdu nastal mezi princovými služebníky zmatek. Lokaj, který je běžel nahlásit, byl zastaven jiným lokajem v hale a o něčem si šeptali. Do síně vyběhla dívka, služebná, a také spěšně něco řekla a zmínila se o princezně. Nakonec vyšel jeden starý lokaj s rozzlobeným pohledem a oznámil Rostovovým, že ho princ nemůže přijmout, ale princezna žádá, aby přišel k ní. Jako první přivítala hosty M lle Bourienne. Zvláště zdvořile se setkala s otcem a dcerou a vzala je k princezně. Princezna s vzrušeným, vyděšeným obličejem pokrytým červenými skvrnami vyběhla, těžce vykročila, směrem k hostům a marně se snažila vypadat svobodně a přívětivě. Princezně Marye se Natasha na první pohled nelíbila. Připadala jí příliš elegantní, frivolně veselá a ješitná. Princezna Marya nevěděla, že než spatřila svou budoucí snachu, byla k ní již špatně nakloněná z nedobrovolné závisti na její krásu, mládí a štěstí a ze žárlivosti na lásku svého bratra. Kromě tohoto neodolatelného pocitu antipatie vůči ní byla v tu chvíli princezna Marya vzrušena i tím, že při hlášení o příjezdu Rostovových princ vykřikl, že je nepotřebuje, ať je princezna Marya přijme kdyby chtěla, a že by jim nemělo být dovoleno ho vidět . Princezna Marya se rozhodla Rostovy přijmout, ale každou minutu se bála, že princ udělá nějaký trik, protože se zdál být z příchodu Rostových velmi nadšený.
"Nu, drahá princezno, přinesl jsem ti svého pěvce," řekl hrabě, šoural se a neklidně se rozhlížel, jako by se bál, že by mohl starý princ přijít. "Jsem tak rád, že jste se potkali... Škoda, škoda, že princi stále není dobře," a po několika obecnějších frázích vstal. „Kdybyste mi, princezno, umožnila, abych vám na čtvrt hodiny představil svou Natašu, šel bych, jen dva kroky odtud, na Psí hřiště za Annou Semjonovnou a vyzvedl ji. “
Charakteristiky transakce jsou popsány v pojmech ACID (Atomicity, Consistency, Isolation, Durability).
· Transakce je nedělitelná v tom smyslu, že se jedná o jeden celek. Všechny jeho součásti se buď konají, nebo ne. Nic takového jako částečná transakce neexistuje. Pokud lze dokončit pouze část transakce, je odmítnuta.
· Transakce je konzistentní, protože nenarušuje obchodní logiku a vztahy mezi datovými prvky. Tato vlastnost je velmi důležitá při vývoji systémů klient-server, protože datový sklad přijímá velké množství transakcí z různých systémů a objektů. Pokud alespoň jeden z nich naruší integritu dat, všechny ostatní mohou způsobit nesprávné výsledky.
· Transakce je vždy izolovaná, protože její výsledky jsou samostatné. Jsou nezávislé na předchozích nebo následujících transakcích – tato vlastnost se nazývá serializovatelnost a znamená, že transakce v sekvenci jsou nezávislé.
· Transakce je stabilní. Po jejím dokončení se uloží do systému, který již nic nemůže vrátit do původního (před zahájením transakce) stavu, tzn. Transakce je potvrzena, což znamená, že její účinek je trvalý, i když systém selže. To znamená určitou formu ukládání informací do trvalé paměti jako součást transakce.
Úrovně izolace transakcí
V ideálním případě by transakce mezi různými uživateli měly být prováděny tak, aby vznikla iluze, že uživatel aktuální transakce je jediný. Ve skutečnosti však z důvodů výkonu a pro provádění některých speciálních úkolů poskytují DBMS různé úrovně izolace transakcí. Úrovně jsou popsány v pořadí zvyšující se izolace transakcí a spolehlivosti dat
0 - Nepotvrzené čtení (Nepotvrzené čtení, Nečisté čtení, Nečisté čtení) - Čtení nepotvrzených změn vaší transakce a konkurenčních transakcí, nečisté, neopakovatelné čtení a fantomy jsou možné
1 - Potvrzené čtení (Read Commited) - čtení všech změn ve vlastní transakci a potvrzených změn v konkurenčních transakcích, nečisté čtení jsou nemožné, neopakovatelné čtení a fantomy jsou možné
2 - Opakovatelné čtení (opakovatelné čtení, snímek) - čtení všech změn vaší transakce, jakékoli změny provedené konkurenčními transakcemi po zahájení vaší vlastní nejsou dostupné, nečisté a neopakovatelné čtení je nemožné, jsou možné fantomy
3 - Objednané - (Serializovatelné, serializovatelné) - objednané (serializovatelné) transakce. Totožné se situací, ve které jsou transakce prováděny přísně sekvenčně jedna po druhé. Tedy transakce, jejichž výsledek nezávisí na pořadí, ve kterém jsou kroky transakce prováděny (čtení všech dat změněných od začátku transakce, včetně vlastní transakce, je zakázáno). Přízraky jsou nemožné.
Čím vyšší je úroveň izolace, tím více zdrojů je zapotřebí k jejich udržení.
V DBMS lze úroveň izolace transakcí vybrat jak pro všechny transakce najednou, tak pro jednu konkrétní transakci. Ve výchozím nastavení používá většina databází úroveň 1 (Read Committed). Úroveň 0 se používá především ke sledování změn v dlouhotrvajících transakcích nebo ke čtení dat, která se mění jen zřídka. Úrovně 2 a 3 se používají pro zvýšené požadavky na izolaci transakcí.
Atomicita - Atomicita
Hlavní článek: Atomicita
Atomicita zajišťuje, že žádná transakce není částečně zavázána systému. Buď budou provedeny všechny jeho dílčí operace, nebo nebude provedena žádná. Protože v praxi není možné současně a atomicky provádět celou sekvenci operací v rámci transakce, zavádí se pojem „rollback“: pokud transakci nelze zcela dokončit, výsledky všech dříve provedených akcí budou zrušeny a systém se vrátí do původního stavu.
[upravit]
Konzistence - Konzistence
Hlavní článek: Konzistence dat
Jedna z nejsložitějších a nejednoznačných vlastností čtyř kyselin. Podle tohoto požadavku je systém v konzistentním stavu před zahájením transakce a musí zůstat v konzistentním stavu po dokončení transakce. Požadavek konzistence by neměl být zaměňován s požadavkem integrity. Poslední pravidla jsou užší a v mnoha ohledech specifická pro relační DBMS: existují požadavky na integritu typu, referenční integritu a integritu entity, které nelze fyzicky narušit kvůli specifikům implementace systému.
Konzistence je širší pojem. Například v bankovním systému může existovat požadavek, aby se částka odepsaná z jednoho účtu rovnala částce připsané na jiný účet. Toto je obchodní pravidlo a nemůže být zaručeno pouze kontrolami integrity, ale programátoři jej musí dodržovat při psaní transakčního kódu. Pokud se nějaká transakce odečte, ale neodepíše, systém zůstane v nesprávném stavu a vlastnost konzistence bude narušena.
A konečně další poznámka je, že během provádění transakce není vyžadována konzistence. V našem příkladu budou odepsání a připsání s největší pravděpodobností dvě různé dílčí operace a mezi jejich provedením v rámci transakce bude viditelný nekonzistentní stav systému. Nesmíme však zapomínat, že pokud je splněn požadavek na izolaci, nebude tato nekonzistence viditelná pro žádné další transakce. A atomicita zaručuje, že transakce bude buď kompletně dokončena, nebo nebude provedena žádná z transakcí. Tato mezilehlá nekonzistence je tedy skryta.
Izolace - Izolace
Zatímco transakce probíhá, ostatní procesy by neměly vidět data v přechodném stavu. Pokud například transakce upraví více polí v databázi najednou, jiný dotaz provedený v průběhu transakce by neměl vrátit některá z těchto polí s novými hodnotami a jiná s jejich původními hodnotami.
Trvanlivost - Trvanlivost
Bez ohledu na problémy na nižších úrovních (například výpadek systému nebo selhání hardwaru) by změny provedené úspěšně dokončenou transakcí měly zůstat uloženy i po návratu systému do provozu. Jinými slovy, pokud uživatel obdržel potvrzení ze systému, že transakce byla dokončena, může si být jistý, že změny, které provedl, nebudou kvůli nějakému selhání vráceny.
