Fórum Root.cz
Hlavní témata => Server => Téma založeno: kandri 18. 06. 2017, 23:08:52
-
Ahoj, asi to tu nepatri, no nemam sa velmi koho spytat a uistit sa. Pripravujem sa na test, a vo vzorovom teste sa objavila otazka, na ktoru odpoved som si nie isty. Hadam sa najde niekto kto mi odpovie. Znenie otazky
Dve paralelne zpracovavane transakcie nemozu poskodit konzistenciu dat prave vtedy ak:
1.) su vykonavane seriovo
2.) su vykonavane na stupni izolovanosti serializable
3.) nedojde k ich vzajomnemu uviaznutiu.
Mam vybrat spravne odpovede, podla mna je spravna len 1cka, no nie som si isty. Vie mi niekto poradit? Dakujem velmi pekne a este raz sa ospravedlnujem.
-
Dve paralelné transakcie vykonávané sériovo, to vymyslel ktorý huncút?
-
správně je (2) a i nejspíš (1), podrobnosti máš třeba na wiki https://en.wikipedia.org/wiki/Serializability
(1) je dost strašidelná formulace vzhledem k otázce, ona je totiž podmnožinou (2) a popisuje interní implementaci a osobně bych jí také zvolil. Jedná se právě o běžný způsob jak navrhnout paralelní aplikace - příjmout více požadavků, ale vykonat je ve frontě jeden po druhém a (2) právě popisuje stav, kdy jednotlivé transakce nejsou na sobě závislé - výsledek není závislý na pořadí vykonání jednotlivých transakcí.
-
Dve paralelné transakcie vykonávané sériovo, to vymyslel ktorý huncút?
A pak proč chodí Slováci studovat do Čech (nebo na Moravu (nebo do Slezska)) :)
-
Dve paralelné transakcie vykonávané sériovo, to vymyslel ktorý huncút?
Mně to přijde v pohodě. Představím si pod tím situaci, kdy do DB pošlu druhý požadavek ještě než první doběhl, a ona ho interně pozdrží.
Správně jsou podle mě odpovědi 1 i 2 :).
-
Mně to přijde v pohodě. Představím si pod tím situaci, kdy do DB pošlu druhý požadavek ještě než první doběhl, a ona ho interně pozdrží.
To pak není "paralelně zpracovávaná", ale "paralelně přijatá" :)
Když přijdu s kámošem na úřad a stoupnem si za sebe do fronty, tak nás taky úřednice neobsluhuje paralelně :)
-
A pak proč chodí Slováci studovat do Čech (nebo na Moravu (nebo do Slezska)) :)
A proč ne? Jaký je v tom rozdíl?
-
Pokud se jedná o klasické ACID transakce, není správně ani jedna odpověď. To „C“ v „ACID“ znamená „consistency“, konzistenci dat tak musí zajišťovat samotná databáze (tak, jak je konzistence definována ve struktuře databáze – pomocí cizích klíčů, unikátnosti a dalších omezení). Pokud je myšlena konzistence dat na úrovni aplikace, to nezachrání ani sériové zpracování transakcí, protože i s tím lze snadno vyrobit nekonzistentní data, pokud se to nepoužívá správně.
Jedná se právě o běžný způsob jak navrhnout paralelní aplikace - příjmout více požadavků, ale vykonat je ve frontě jeden po druhém
Běžný způsob možná pro aplikace, kde vůbec nejde o výkon, a když se náhodou sejdou dva uživatelé, tak si holt jeden počká.
kdy jednotlivé transakce nejsou na sobě závislé - výsledek není závislý na pořadí vykonání jednotlivých transakcí
Stačí, že někde máte čítač, který se s každou transakcí zvedne o jedničku – a na pořadí transakcí hned záleží. Nebo jedna transakce jeden záznam aktualizuje a druhá ten samý maže – opět záleží na pořadí, pokud se provedou v opačném pořadí, než jsme uvedl, druhá transakce skončí chybou.
-
Stačí, že někde máte čítač
Žádné stačí, žádný čítač. "Serializability" je terminus technicus - viz ta výš odkazovaná stránka na Wiki.
Je to takový způsob provedení transakcí, že výsledek je ekvivalentní tomu, kdyby byly transakce spuštěné za sebou v libovolném pořadí. Čili např. jedna transakce nastaví hodnotu "surname" v řádku 123 na "Prýmek" a druhá hodnotu "name" v řádku 456 na "Mirek". Je jedno, jestli je spustím po sobě jako A,B nebo B,A, nebo je pustím paralelně. Nijak se vzájemně neovlivňují.
Čítač tam být může, ale jenom za nějakých podmínek - např. jeho aktuální hodnota se v transakci nepoužívá, čítač se jenom zvyšuje/snižuje o nějakou hodnotu.
-
kdy jednotlivé transakce nejsou na sobě závislé - výsledek není závislý na pořadí vykonání jednotlivých transakcí
Stačí, že někde máte čítač, který se s každou transakcí zvedne o jedničku – a na pořadí transakcí hned záleží. Nebo jedna transakce jeden záznam aktualizuje a druhá ten samý maže – opět záleží na pořadí, pokud se provedou v opačném pořadí, než jsme uvedl, druhá transakce skončí chybou.
Druhá transakce neskončí chybou. Prostě se inkrementace neprovede, protože není na čem, ale chyba to není.
-
Dakujem velmi pekne vsetkym za odpovede. :) Na tu jednicku som prisiel prave vdaka prednaskam. 3ka som vedel, ze asi bude skor blbost, no nebol som si isty 2kou. Mimochodom aspon jedna odpoved musi byt spravna. Fakt dakujem velmi pekne, a keby sa este niekto nasiel, kto by mi pomohol s dvoma otazkami, tiez tykajucimi sa databaz, bolo by to skvele. Chcem sa len uistit, ci to je spravne.
Mame entitne typy STUDENT a PREDMET. Znamku udelenu pri skuske z daneho predmeu danemu studentovi budeme na urovni konceptualneho modelu modelovat:
A: Samostatnym entitnym typom
B: Atributom entitneho typu STUDENT
C: Atributom vztahu medzi entitnymi typami PREDMET a STUDENT
D: Atributom entitneho typu PREDMET
E: Inak
Tu to podla mna staci atribut v PREDMETe, cize D, nie?
Mame zadanu relaciu tvorenu spojenim dvoch tabuliek T1 a T2. Primarny kluc tabulky T1 je reprezentovany atributom PK, odpovedajuci cudzi kluc tabulky T2 je reprezentovany atributom FK. Definicia referencnej integrity zaisti, aby pri zmene hodnoty primarneho kluca tabulky T1 doslo aj k prislusnej zmene hodnoty cudzieho kluca tabulky T2.
A: je vlastnostou primarneho kluca, a teda je sucastou definicie tabulky T1
B: je vlastnostou cudzieho kluca, a teda je sucastou definicie tabulky T2
C: vzhladom k tomu, ze je vlastnostou paru tabuliek T1 a T2, nemoze byt sucastou definicie jednotlivych tabuliek T1 a T2
Tuto si nie som vobec isty, s databazami som doteraz na bakalarskom studiu do styku nedosiel, a tieto otazky v prijmackach nie su pre mna velmi jednoduche. Ale dal by som C.
Dakujem este raz velmi pekne vsetkym za ochotu. Ak by ste mi pomohli este s tymto, boli by ste fakt skveli :)
-
Je to napsané tak, aby studentovi vytekl mozek ušima, ale samozřejmě A.
-
Je to takový způsob provedení transakcí, že výsledek je ekvivalentní tomu, kdyby byly transakce spuštěné za sebou v libovolném pořadí. Čili např. jedna transakce nastaví hodnotu "surname" v řádku 123 na "Prýmek" a druhá hodnotu "name" v řádku 456 na "Mirek". Je jedno, jestli je spustím po sobě jako A,B nebo B,A, nebo je pustím paralelně. Nijak se vzájemně neovlivňují.
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ží.
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.
-
Mimochodom aspon jedna odpoved musi byt spravna.
Možná v kontextu daného předmětu, kdy se „konzistencí dat“ myslí bůhvíco. Pokud se to zadání vezme jako obecné tvrzení o databázích, není pravdivá ani jedna odpověď, protože konzistenci dat (z hlediska interních databázových struktur i z hlediska omezení definovaných nad daty) musí zajišťovat ACID databáze sama o sobě, bez ohledu na úroveň izolace transakcí. Kdybyste zvolil izolaci transakcí třeba „repeatable read“ a při vhodné konstelaci by se vám podařilo zapsat dva řádky se stejnou hodnotou unikátního sloupce, nebo dokonce poškodit interní strukturu databázových souborů, byla by ta databáze k ničemu.
Samozřejmě databáze nemusí zajišťovat plný ACID (zejména u NoSQL databází je to oblíbené), ale to by pak muselo být součástí zadání, jaké předpoklady vlastně databáze splňuje.
Tu to podla mna staci atribut v PREDMETe, cize D, nie?
Určitě ne, vždyť je to známka studenta z předmětu. Kdybyste známku zapisoval k předmětu, bude ta známka jedna pro předmět, tedy všichni studenti by měli stejnou známku. Správně je tedy C, ale mohlo by být i A.
Mame zadanu relaciu tvorenu spojenim dvoch tabuliek T1 a T2. Primarny kluc tabulky T1 je reprezentovany atributom PK, odpovedajuci cudzi kluc tabulky T2 je reprezentovany atributom FK. Definicia referencnej integrity zaisti, aby pri zmene hodnoty primarneho kluca tabulky T1 doslo aj k prislusnej zmene hodnoty cudzieho kluca tabulky T2.
A: je vlastnostou primarneho kluca, a teda je sucastou definicie tabulky T1
B: je vlastnostou cudzieho kluca, a teda je sucastou definicie tabulky T2
C: vzhladom k tomu, ze je vlastnostou paru tabuliek T1 a T2, nemoze byt sucastou definicie jednotlivych tabuliek T1 a T2
Tuto si nie som vobec isty, s databazami som doteraz na bakalarskom studiu do styku nedosiel, a tieto otazky v prijmackach nie su pre mna velmi jednoduche. Ale dal by som C.
Je to vlastností cizího klíče – při definici cizího klíče je možné uvést klauzuli ON UPDATE nebo ON DELETE.
-
Tu to podla mna staci atribut v PREDMETe, cize D, nie?
Použij selský rozum, není to nic složitého, jen je to složitě naformulované (proč netuším, ale mezi akademiky už to tak bývá).
Známku dostal student z předmětu. Když to dáš přímo k předmětu, bude to pro všechny studenty. Takže musíš vytvořit vztah (v relačních DB tabulku) "studoval předmět" mezi studentem a předmětem a k tomu přidáš atribut (v relačních DB sloupec) "s výsledkem" s hodnotou známky. Taky bys k tomu vztahu (tabulce) mohl mít další atributy (sloupce) např. "kolikrát nebyl na hodině", "výsledek zápočtové práce", atd.
-
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.
-
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.
-
Databaze, Letní semestr, to zní jak FIT CVUT, pokud ano, to se fakt nemáš koho zeptat?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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“?
-
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í.
-
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í.
-
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".
-
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ž".
-
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.
-
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 :-)))