Bezpečnosť dát bez DB

29. 1. 2011 15:26:26

Napsal Aleš Jiříček;619822
ze to funguje neznamena ze se cas od casu naka chybka stat nemuze ;)

Jistě, tak jako v čemkoliv. Třeba při práci s DB může dojít k výpadku spojení zrovna při ukládání dat...třeba...

Jde hlavně o to, že když někdo napíše problém s tím že nemůže používat DB a já podám informaci o tom, že na né moc navštěvovaných stránkách lze používat i zápis do souborů bez problémů, tak se tu začnou oběvovat rady typu "to je blbost" nebo "prostě použij databázi". Bez databáze funguje bez problémů spousta projektů, jak už sem psal, a pokud není programátor prase který ošetřuje chyby @ tak s tímhle opravdu problém nemá.

29. 1. 2011 15:26:26

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598255

(20 hodnocení)

29. 1. 2011 15:36:58

jj jako ty obavy jsou vetsinou neopravnene a pri nizsich navstevnostech je to vazne tak nepravdepodobne ze to snad ani nema cenu resit... a pri vyssich navstevnostech je zase souborove ukladani idiocie z uplne jinych ohledu, takze jo, nema cenu tot ak hrotit

29. 1. 2011 15:36:58

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598254

Pavel Mička

29. 1. 2011 21:33:33

Lukenzi:

checkování otevření == neco ve stylu if(!soubor.jeOtevren()) zapis();

netvrdim, ze je ta pravdepodobnost kdovijak velika, ale je tady...a pokud pises aplikace, ktery vetsinou fungujou, tak bys zaslouzil zprerazet hnaty... :-)...a jen tak mimochodem...ja zkousel testovat veci, ktery nejsou thread safe pomoci jednotkovejch testu v Jave...a netrva dlouho, kdyz proti sobe pustis dve vlakna na nezabezpecenej zdroj, nez se poperou...

btw: co ty, zkousel jsi to nekdy? :-)

tohle je proste podobna idiocie jak tvrdit, ze transakce jsou k nicemu, protoze databaze nespadne (a nevyskytne se nikdy zadna chyba...)

jinak k tve otazce: pokud to nepouziva mutex ani uvnitr (nebo nejakou obdobu, ktera zajisti atomicitu...trebas pres compare and set), tak fungujou ciste nahodou...s postupem casu uz spis omylem...

29. 1. 2011 21:33:33

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598253

Lukenzi

30. 1. 2011 05:32:21

"checkování otevření" - psal jsem v cyklu, který se opakuje, ne v podmínce, to se nedivím že sis o tom myslel že to je blbost (to teda je :) Já myslel něco na způsob spinlocku...

Co se týče testování, tak v javě ne vystačím si bohatě s PHP a kdybych to nezkoušel tak to nepíšu...

Co se týče CMS tak atomicitu ti nezajistí ani lock, protože IMHO ten už sám o sobě není atomicitní...

Tahle debata je už ale trochu OT, jen bych dodal, že pokud vím co si vzhledem k návštěvnosti webu (klidně i 1000 UIP) můžu dovolit a pokud u práce přemýšlím hlavou tak používání souborů je někdy mnohem rychlejší a spolehlivější než u DB, jinak pěkná věcička co tohle jen potvrzuje je třeba toto doporučuji prostudovat :)

30. 1. 2011 05:32:21

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598252

Pavel Mička

30. 1. 2011 10:09:19

Napsal Lukenzi;620046
"checkování otevření" - psal jsem v cyklu, který se opakuje, ne v podmínce, to se nedivím že sis o tom myslel že to je blbost (to teda je :) Já myslel něco na způsob spinlocku...
Co se týče testování, tak v javě ne vystačím si bohatě s PHP a kdybych to nezkoušel tak to nepíšu...
Co se týče CMS tak atomicitu ti nezajistí ani lock, protože IMHO ten už sám o sobě není atomicitní...
Tahle debata je už ale trochu OT, jen bych dodal, že pokud vím co si vzhledem k návštěvnosti webu (klidně i 1000 UIP) můžu dovolit a pokud u práce přemýšlím hlavou tak používání souborů je někdy mnohem rychlejší a spolehlivější než u DB, jinak pěkná věcička co tohle jen potvrzuje je třeba toto doporučuji prostudovat :)

Fakt by mě zajímalo, jak to myslíš s tím cyklem, protože cyklus je podmínka + něco málo navíc...pořád se nevyhneš situaci, kdy vlákno projde podmínkou, scheduler přepne kontext, druhý vlákno projde podmínkou, scheduler vrátí kontext, první vlákno otevře soubor a hrábne do něj, scheduler přepne kontext, druhý vlákno hrábne již do otevřenýho souboru a poškodí data....

leda bys skutečně dělal na tý podmínce něco atomickýho ve smyslu instrukce compare-and-set...pak by to dávalo smysl...takhle jsou mj. implementovaný concurrent kolekce v Javě....

zámky samozřejmě jsou postavené tak, aby skrz ně neprošlo víc vláken najednou (jinak by prostě nefungovaly...)...pokud si dobře pamatuju, tak je to zajištěné pomocí atomických operací na procesoru a "aktivní" smyčky, nebo přes vynucení nepřepnutí kontextu...

ten safe stream odhadem vnitřně implementuje zámky...ale cokoliv škálovatelného bych se v tom napsat nepokoušel...je přecijenom rozdíl zamknout řádek tabulky (při updatu v DB) a zamknout celej soubor (celou DB) pri updatu do souboru...

...popravdě mi stejně furt nedochází, proč zapisovat do souboru, když existuje tolik krásných embedded databází....(snad i pro PHP...:-D)

30. 1. 2011 10:09:19

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598251

(20 hodnocení)

30. 1. 2011 10:14:55

Napsal malejpavouk;620078
...popravdě mi stejně furt nedochází, proč zapisovat do souboru, když existuje tolik krásných embedded databází....(snad i pro PHP...:-D)

nejlepsi pripominka v celem tematu ;)

30. 1. 2011 10:14:55

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598250

Kamil Tomšík

(3 hodnocení)

30. 1. 2011 11:51:44

1. pouzivej databazi protoze http://en.wikipedia.org/wiki/ACID

2. pokud nemuzes pouzit databazi (ani SQLite - a ta se da pouzit temer vzdy, operuje totiz v ramci jednoho prenositelneho souboru), tak pouzij reseni od DGX - je zakomponovane do nette frameworku a dostupne take tady http://latrine.dgx.cz/atomicke-operace-jeste-jednou pro zapis napriklad cache staci neco jednodussiho - http://php.vrana.cz/atomicita-operaci.php

Kontrola otevrenosti souboru je blbost, potrebujes zamek na konkretni soubor a ten ti muze vratit jenom system, nemuzes si ho nijak simulovat, navic cyklus neni nic jineho nez podminka + goto... systemovy scheduler si muze delat cokoliv, muze vlakna prerusit kdykoliv a taky si na ruznych platformach cokoliv dela (BSD, linux, winxp, win7, a hlavne na RTOS ikdyz na tech servery nebezi)

30. 1. 2011 11:51:44

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598249

Lukenzi

30. 1. 2011 13:05:12

Napsal vedouci;620115
1. pouzivej databazi protoze http://en.wikipedia.org/wiki/ACID
2. pokud nemuzes pouzit databazi (ani SQLite - a ta se da pouzit temer vzdy, operuje totiz v ramci jednoho prenositelneho souboru), tak pouzij reseni od DGX - je zakomponovane do nette frameworku a dostupne take tady http://latrine.dgx.cz/atomicke-operace-jeste-jednou pro zapis napriklad cache staci neco jednodussiho - http://php.vrana.cz/atomicita-operaci.php Kontrola otevrenosti souboru je blbost, potrebujes zamek na konkretni soubor a ten ti muze vratit jenom system, nemuzes si ho nijak simulovat, navic cyklus neni nic jineho nez podminka + goto... systemovy scheduler si muze delat cokoliv, muze vlakna prerusit kdykoliv a taky si na ruznych platformach cokoliv dela (BSD, linux, winxp, win7, a hlavne na RTOS ikdyz na tech servery nebezi)

Omg a co asi dělá script těsně před tím než nastaví zámek? Testuje jestli soubor není používaný (jinak by ho logicky nemohl zamknout) takže vlastně dělá úplně to samé, ale když je to podle tebe blbost...

Jinak když se pokládáš za takového profíka v oblasti PHP byl bych rád kdybys mi uvedl jaká je šance na kolizi dvou ve stejnou chvíli zapisujících uživatelů (např. při přidávání komentáře) na webu s průměrnou denní návštěvností 500 UIP ...rád se zasměju.

A je hezké že najednou odkazuješ na něco na co sem odkázal já po tom co si to smazal, vidím že na webtrhu se to začíná obracet jiným směrem...

Nebo můj dotaz na tebe taky smažeš?

30. 1. 2011 13:05:12

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598248

(20 hodnocení)

30. 1. 2011 13:10:07

nerozciluj se, procisteni to chtelo. A co se znalosti tyka tak neutocis zrovna na spravneho cloveka, vedouciho povazuji za znalce ktery by mohl i me ucit (a to sam sebe povazuji za velmi pokrocileho programatora)

30. 1. 2011 13:10:07

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598247

Kamil Tomšík

(3 hodnocení)

30. 1. 2011 13:46:12

Napsal Lukenzi;620155
Omg a co asi dělá script těsně před tím než nastaví zámek? Testuje jestli soubor není používaný (jinak by ho logicky nemohl zamknout) takže vlastně dělá úplně to samé, ale když je to podle tebe blbost...
Jinak když se pokládáš za takového profíka v oblasti PHP byl bych rád kdybys mi uvedl jaká je šance na kolizi dvou ve stejnou chvíli zapisujících uživatelů (např. při přidávání komentáře) na webu s průměrnou denní návštěvností 500 UIP ...rád se zasměju.
A je hezké že najednou odkazuješ na něco na co sem odkázal já po tom co si to smazal, vidím že na webtrhu se to začíná obracet jiným směrem...

Nebo můj dotaz na tebe taky smažeš?

procistil jsem to - bylo to potreba - na co presne jsi upozornil? pridam te do zavorky

a rozcilujes se zbytecne, proste jenom nemas pravdu, ty popisujes neco jako:

if ( soubor_otevreny ( $soubor ) )

zapis_data ( $soubor, $data );

jenze nemas garantovane, ze if a zapis_data probehnou dohromady bez preruseni - sance je mala a v pripade stejneho souboru jeste mensi, ale je tam. je to jako kdybys ridil opily, sance, ze te chytnou je dost mala, ale nemas jistotu, kdezto kdyz pouzijes if ( ziskej_zamek ( $soubor ) ), tak mas garantovane, ze to probehne atomicky - v php je to bohuzel trosku komplikovanejsi, protoze k tomuto ucelu existuje http://php.net/flock - na windows platforme to ale moc nefunguje.

dgx kdysi prisel na to, ze otevreni v r+ modu ziska exclusive lock na vsech platformach, ale je to takove polovicate reseni, nebylo to takhle zamyslene a klidne se to muze v pristich verzich zmenit.

proste: pouzivejte databaze a mate pokoj, tyhle chyby se strasne spatne odhaluji...

30. 1. 2011 13:46:12

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598246

Martin Schlemmer

(36 hodnocení)

4. 2. 2011 02:07:04

Napsal Lukenzi;620155
byl bych rád kdybys mi uvedl jaká je šance na kolizi dvou ve stejnou chvíli zapisujících uživatelů (např. při přidávání komentáře) na webu s průměrnou denní návštěvností 500 UIP

To je dobrá otázka. Zkusil jsem ji vypočítat.

Předpoklady:

- Zámek trvá setinu sekundy (1 / $lockspersecond). V magnetických HDD je to trochu optimistické, protože 10ms je pouze access time. Pro SSD jsme zase o dva řády pomalejší.

- 80% všech pěti set návštěvníků ($reads) přijde během 8 hodin ($hours).

- Návštěva je buď jedno čtení nebo jeden zápis

- 1% všech čtenářů napíší komentář ($writes). Může to být o řád až o dva nižší, záleží na typu stránky.

V takovém případě nastane kolize cca jednou za 500 let. Pokud by se ale návštěvnost zvedla 10x, kolize by nastala už jednou za 5 let. To už je čas, kterého by se i malá stránka mohla dožít.

Atomicitu a konkurenčnost má tedy smysl řešit i pro stránky s relativně nízkou návštěvností.

4. 2. 2011 02:07:04

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598245

Kamil Tomšík

(3 hodnocení)

4. 2. 2011 09:42:08

dam vam priklad, kde je to opravdu dulezite - urcite znate klikaci aukce - funguje to tak, ze se odpocitava cas a ten kdo ma posledni prihoz vyhrava, kazdy prihoz zvysi cas o 30s... kdyz se hraje napriklad o zajezd, tak aukci sleduje minimalne 100 lidi, a vsichni se snazi prihazovat v posledni vterine.

klikaci aukce ale nebyvaji programovane v souborech, tak proc to zminuju? protoze vyuzivaji ajax pro obnovovani toho casu, kdyz nekdo prihodi, vsichni ostatni to okamzite vidi (resp. behem jedne vteriny), aby databaze nepadla na drzku, tak se cachuje, a vetsinou bohuzel do souboru -> tzn. 100 lidi kazdou vterinu cte jeden soubor, a posledni vterinu vetsina z nich provede prihoz, coz znamena vymazat soubor, provest db update, nacist vysledek, ulozit do cache, a pro vsechny co se rozhodli prihodit...

BTW: proc se cachuje do souboru: je to jednoduche, neni potreba zadne php rozsireni a navic operacni system sam o sobe sleduje casto otevirane soubory a ty nejcastejsi automaticky mapuje do pameti, takze po nekolika otockach, je to jenom o trosku pomalejsi nez cachovani do pameti

4. 2. 2011 09:42:08

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/strana/2#reply598244