Podmínky konzistence dat v databázi

Kit

Re:Konzistencia dat - databaza
« Odpověď #15 kdy: 19. 06. 2017, 12:40:25 »
Druhá transakce neskončí chybou. Prostě se inkrementace neprovede, protože není na čem, ale chyba to není.
Chyba to samozřejmě je – když aplikace chce updatovat jeden řádek, musí si zkontrolovat, že se jeden řádek updatoval, a pokud tomu tak není, transakci odroluje. Představte si to na klasickém příkladu s bankovními účty – v jedné transakci 1. update sníží zůstatek na účtu odesílatele a 2. update zvýší zůstatek na účtu příjemce. Pokud druhý update „promáchne na prázdno“, protože účet příjemce byl mezi tím zrušen, musí se celá transakce odrolovat – jinak by došlo k ukázkové chybě, že peníze byly z účtu odesílatele strženy, ale následně zmizely v černé díře.

Teď je otázkou, zda taková transakce má být v databázové nebo v aplikační vrstvě. Většinou se to tlačí přes aplikační vrstvu a mohou z toho vznikat docela vážné kolize.

"Promáchnutí naprázdno" samozřejmě v databázi chybou není. Je na business vrstvě, aby z toho chybu udělala, provedla rollback a vygenerovala patřičnou výjimku.


Re:Konzistencia dat - databaza
« Odpověď #16 kdy: 19. 06. 2017, 13:05:04 »
Teď je otázkou, zda taková transakce má být v databázové nebo v aplikační vrstvě. Většinou se to tlačí přes aplikační vrstvu a mohou z toho vznikat docela vážné kolize.

"Promáchnutí naprázdno" samozřejmě v databázi chybou není. Je na business vrstvě, aby z toho chybu udělala, provedla rollback a vygenerovala patřičnou výjimku.
Transakce je jenom jedna a jde přes aplikační i databázovou vrstvu. Nepsal jsem, že „promáchnutí na prázdno“ je chybou v databázi (i když může být, pokud bude logika v databázových procedurách). Ale i když ten výsledek kontroluje business vrstva, dělá to v rámci běžící transakce, a když zjistí, že došlo k chybě, transakci odroluje. Z pohledu databáze j eto tedy stále jedna transakce, ve které dojde k chybě a je odrolována – to, že tu chybu musí do transakce z venku polsat aplikace je jen implementační detail. Teoreticky se to samozřejmě dá řešit i mimo transakce, tedy řešit transakčnost až v aplikaci, ale většinou k tomu není důvod a celou věc by to jen zbytečně zkomplikovalo.

Balba

Re:Konzistencia dat - databaza
« Odpověď #17 kdy: 19. 06. 2017, 13:20:29 »
Databaze, Letní semestr, to zní jak FIT CVUT, pokud ano, to se fakt nemáš koho zeptat?

Kit

Re:Konzistencia dat - databaza
« Odpověď #18 kdy: 19. 06. 2017, 13:38:17 »
Teď je otázkou, zda taková transakce má být v databázové nebo v aplikační vrstvě. Většinou se to tlačí přes aplikační vrstvu a mohou z toho vznikat docela vážné kolize.

"Promáchnutí naprázdno" samozřejmě v databázi chybou není. Je na business vrstvě, aby z toho chybu udělala, provedla rollback a vygenerovala patřičnou výjimku.
Transakce je jenom jedna a jde přes aplikační i databázovou vrstvu. Nepsal jsem, že „promáchnutí na prázdno“ je chybou v databázi (i když může být, pokud bude logika v databázových procedurách). Ale i když ten výsledek kontroluje business vrstva, dělá to v rámci běžící transakce, a když zjistí, že došlo k chybě, transakci odroluje. Z pohledu databáze j eto tedy stále jedna transakce, ve které dojde k chybě a je odrolována – to, že tu chybu musí do transakce z venku polsat aplikace je jen implementační detail. Teoreticky se to samozřejmě dá řešit i mimo transakce, tedy řešit transakčnost až v aplikaci, ale většinou k tomu není důvod a celou věc by to jen zbytečně zkomplikovalo.

Jistě se shodneme na tom, že tu transakci má na starosti business vrstva a je vcelku jedno, zda se nachází v databázi nebo v aplikaci. Výsledkem business vrstvy je provedení nebo odmítnutí požadavku.

Re:Konzistencia dat - databaza
« Odpověď #19 kdy: 19. 06. 2017, 14:15:09 »
Jistě se shodneme na tom, že tu transakci má na starosti business vrstva a je vcelku jedno, zda se nachází v databázi nebo v aplikaci. Výsledkem business vrstvy je provedení nebo odmítnutí požadavku.
Na tom se shodneme. Pro původní dotaz je ale jedno, kdo má na starost transakci a kde se ta transakce nachází. Podstatné je, že když máte dvě transakce, jedna maže jeden konkrétní záznam, druhá ten samý záznam aktualizuje (a když se aktualizace nepodaří, např. protože záznam neexistuje, tak transakce selže a odroluje se), záleží na pořadí provedení transakcí. Není podstatné, kdo kontroluje, zda se aktualizace provedla či neprovedla a případně způsobí odvolání transakce.


Jenda

Re:Konzistencia dat - databaza
« Odpověď #20 kdy: 19. 06. 2017, 16:20:57 »
Databaze, Letní semestr, to zní jak FIT CVUT, pokud ano, to se fakt nemáš koho zeptat?
Na matfyzu jsou taky databáze v letním semestru.

Re:Konzistencia dat - databaza
« Odpověď #21 kdy: 19. 06. 2017, 16:45:35 »
Dakujem velmi pekne vsetkym za rady a odpovede, ste super :)

Databaze, Letní semestr, to zní jak FIT CVUT, pokud ano, to se fakt nemáš koho zeptat?
Nie, ing. prijmacky FEL CVUT, doteraz som studoval na slovensku.

Re:Konzistencia dat - databaza
« Odpověď #22 kdy: 19. 06. 2017, 20:52:48 »
Nikoli. Výsledek je ekvivalentní tomu, jako by transakce byly spuštěné postupně, tj. nejprve začne jedna, skončí, a teprve po ní začne druhá. Ale neznamená to, že nezáleží na pořadí. Pokud budou obě transakce měnit příjmení, tak samozřejmě na pořadí transakcí záleží a zvítězí ta druhá. To, že na pořadí záleží, není vlastností izolace transakcí, ale závisí to na tom, co ty transakce provádějí. Klidně můžete spustit transakce s izolací serializable, které dělají takové změny v datech, že na pořadí záleží.
Ano, dík za opravu, není to "any serial order", ale "some serial order", v tom jsem se zmýlil. Díky.

Re:Podmínky konzistence dat v databázi
« Odpověď #23 kdy: 19. 06. 2017, 21:48:05 »
Mimochodem, na tu první otázku tu bylo několik odpovědí, že správná odpověď je 1), 2) nebo obojí. Mohl by mi někdo z těch, kdo tak odpověděli, vysvětlit, co se podle něj myslí tou „konzistencí dat“? Já si pod tím představuju C z ACID, a to to evidentně není, protože to zajišťují i všechny ostatní běžné úrovně izolace transakcí. Napadá mne ještě aplikační konzistence dat, ale to zase nezajistí žádná úroveň izolace transakcí, to musí zajistit správně napsaná business logika. Nebo jinak – co z toho, co odlišuje úroveň izolace transakcí serializable dejme tomu od repeatable read nazýváte „konzistencí dat“?

andy

Re:Podmínky konzistence dat v databázi
« Odpověď #24 kdy: 20. 06. 2017, 13:21:29 »
Mohl by mi někdo z těch, kdo tak odpověděli, vysvětlit, co se podle něj myslí tou „konzistencí dat“? Já si pod tím představuju C z ACID, a to to evidentně není, protože to zajišťují i všechny ostatní běžné úrovně izolace transakcí. Napadá mne ještě aplikační konzistence dat, ale to zase nezajistí žádná úroveň izolace transakcí, to musí zajistit správně napsaná business logika. Nebo jinak – co z toho, co odlišuje úroveň izolace transakcí serializable dejme tomu od repeatable read nazýváte „konzistencí dat“?
To je dobrá otázka :) Ale ta originální otázka se nemusí nutně ptát na ACID systémy. Asi bych to interpretoval tak, že se ptá na obecné transakční systémy s tím, že předpokladem je, že jednotlivá transakce zachovává konzistenci (aplikační), a ta otázka zní, jak zaručíme, aby totéž bylo zaručeno, když ty transakce poběží paralelně.
Odpověď 1) by pak byla správně tak nějak z definice. Odpověď 2) pak asi chce po studentovi vědět, že serializable je ekvivalentní "nějaké možné serializaci" a tím pádem to opět bude konzistentní.

Re:Podmínky konzistence dat v databázi
« Odpověď #25 kdy: 20. 06. 2017, 14:09:02 »
Pokud je to obecná otázka, nedá se na ní podle mne odpovědět, protože u obecných transakčních systémů znám ještě méně předpokladů, než u ACID. Navíc „stupeň izolace serializable“ podle mne dost jasně odkazuje k ACID relačním databázím. A pokud by „stupeň izolace serializable“ v té otázce zahrnovalo třeba i „read commited“ a „read uncomitted“, nechápu, proti čemu by se to vlastně vymezovalo – co by měl být ten stupeň izolace, který konzistenci nezajistí.

Karel

Re:Podmínky konzistence dat v databázi
« Odpověď #26 kdy: 20. 06. 2017, 14:55:00 »
Pokud je to obecná otázka, nedá se na ní podle mne odpovědět, protože u obecných transakčních systémů znám ještě méně předpokladů, než u ACID. Navíc „stupeň izolace serializable“ podle mne dost jasně odkazuje k ACID relačním databázím. A pokud by „stupeň izolace serializable“ v té otázce zahrnovalo třeba i „read commited“ a „read uncomitted“, nechápu, proti čemu by se to vlastně vymezovalo – co by měl být ten stupeň izolace, který konzistenci nezajistí.

To je otázka na VŠ. Ti lidé mívají vlastní slovník a musíte si proto načíst jejich skripta. Když vám dávají úkoly k přijímačkám, tak je to holt problém. Co jsem se já setkal se slovníkem učitelů, tak pod pojmem "konzistence" si obvykle z toho ACID představují kombinaci A a I. V jejich světě je to o "založím hlavičku a detail, druhá úloha založí také hlavičku a detail a konzistencí je myšleno to, že se nepomíchají hlavičky a detaily a nic se mi neztratí". Jiný příklad ze stejného soudku je "transakce převodu z A na B a zároveň běžící transakce převodu z B na C, konzistencí je myšleno to, že B má ve výsledku správnou hodnotu".

Re:Podmínky konzistence dat v databázi
« Odpověď #27 kdy: 20. 06. 2017, 15:45:00 »
Ja si myslím, že je to trick question, protože: "prave vtedy ak:".

Dál se zkusím omezit na co nejmíň předpokladů a rozebrat možnosti.

Větev 1: konzistenci dat může poškodit už jedna transakce běžící samostatně - v tom případě konzistenci dat nemůže zajistit 1 2 ani 3. Stačí aby transakce běžely v sérii a konzistenci rozbila ta poslední.

Větev 2: jedna transakce sama o sobě konzistenci nerozbije. V tom případě konzistenci nemůže rozbít víc transakcí běžících v sérii (každá z nich zachová prerequisite že konzistence není rozbitá), a nemůžou jí rozbít ani paralelní transakce n aúrovni serializable (protože jejich běh má výsledek ekvivalentní nějakému sériovému běhu, čímž je převedeno na předchozí podpřípad).
A protože tyhle dva body nejsou ekvivalentní (seriální vykonání může nastat na jakékoli úrovni izolace, a naopak existují serializovatelné transakce které nemusí běžet v sérii), tak "právě když" neplatí ani pro 1, ani pro 2.

Takže zbýva možnost "nedojde k deadlocku" ... no a já si dokážu představit celkem velkou třídu užitečných transakcí které se navzájem zadeadlockujou, ale konzistenci porušit nemůžou (nejdří pozamykají co můžou ve špatném pořadí, a pak teprve něco dělají). Takže ani tady neplatí "právě když".

j

Re:Podmínky konzistence dat v databázi
« Odpověď #28 kdy: 20. 06. 2017, 16:28:02 »
Tyhle otazky jsou naprosto typickou ukazkou tech trotlu, ktery pak maj nekoho neco naucit, aniz by tomu sami rozumeli ... Neumej se ani zeptat.


Protoze pokud je rec o konzistentnich datech, tak aspon ja to beru tak, ze jde o konzistenci nejvyssi urovne, a pak neni spravne odpoved ani jedna. Pokud jde "jen" o konzistenci na urovni databaze ... tak je ta otazka naprosto spatne polozena.

Kdyz do databaze poslu rekneme (zaroven) select -> insert (delam kopii) a zaroven update ...tak na poradi provedeni kurevsky zalezi, ale databaze sama to vyresit nemuze, protoze nevi, jestli chci nejdriv aktualizovat a pak kopirovat, nebo naopak. Pricemz to naprosto vpohode rozbije prave konzistenci dat.

BTW: Podotykam,ze podobne kretensky dotazy jsou trebas u maturit.

Cek

Re:Podmínky konzistence dat v databázi
« Odpověď #29 kdy: 21. 06. 2017, 10:10:51 »
Za mne, databazoveho neodbornika, je to normalne polozeny dotaz, ktery bych si prelozil jako stav, kdy si transakce navzajem nepolezou v jednu chvili do zeli, tedy seriove nebo serializable v poho.

O to, jaky je vysledek, se tenhle dotaz z meho hlediska nezajima, tedy neresi jestli ma udelat nejdriv update a pak copy nebo naopak, resi jenom to, aby se tyhle dve veci nedelaly najednou, tedy abys nezkopiroval pulku dat pred update a pulku po nem....

Tak a ted me muzete ukrizovat :-)))