Mají tabulkové databáze v dnešní době smysl?

[Ondra Satai Nekola]

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.

Dotaz do cache přímo v aplikaci je mnohonásobně rychlejší než dotaz do cache v databázi (protože tam to velmi zpomaluje komunikace po síti). A i na to aby se aplikace opakovaně neptala na hodnoty které už má se dá využít právě cache v aplikaci.

To zalezi na spouste okolnosti. Cim dale posunes cache od dat, tim to bude rychlejsi, ale zase mas vic problemu s invalidaci cache.

[Reklama]

[n]

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.

Dotaz do cache přímo v aplikaci je mnohonásobně rychlejší než dotaz do cache v databázi (protože tam to velmi zpomaluje komunikace po síti). A i na to aby se aplikace opakovaně neptala na hodnoty které už má se dá využít právě cache v aplikaci.

A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?

[Ondrej Nemecek]

Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.

Mě se docela líbí taková ta úplně lehká ORM jako třeba http://javalite.io/activejdbc#design-principles, akorát mě tam štve ten zápis sloupců jako string (dá se řešit tím, že si člověk napíše gettery a settery ručně).

Proč se víc nerozšířili objektové databáze, to netuším. Asi že chybí ta standardizace...?

[dustin]

A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?

Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...

Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.

[Někdo]

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.

Dotaz do cache přímo v aplikaci je mnohonásobně rychlejší než dotaz do cache v databázi (protože tam to velmi zpomaluje komunikace po síti). A i na to aby se aplikace opakovaně neptala na hodnoty které už má se dá využít právě cache v aplikaci.

A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?

Cache nic nezjistí, to musí zaručit programátor správnou implementací. Buď mu starší data nevadí nebo musí použít databázový zámek (pessimistic locking) nebo verzování (optimistic locking).

[Reklama]

[Někdo]

A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?

Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...

Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.

Zásdaní dotaz: jak řešíte pokud aplikace běží v clusteru na různých serverech?

[Kit]

A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?

Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...

Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.

Co když do té databáze zapisuje spousta aplikací zároveň? Pro mne je to velmi častý případ a nějaké zámky by mohly skončit i deadlockem.

[Někdo]

A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?

Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...

Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.

Co když do té databáze zapisuje spousta aplikací zároveň? Pro mne je to velmi častý případ a nějaké zámky by mohly skončit i deadlockem.

Správně používané zámky nikdy deadlockem neskončí - předpokládá to ovšem že všichni kdož mají právo zámky vytvářet (obvykle jsou to všichni kdož mají právo měnit data) se chovají správně. Není důvod zámky opovrhovat jenom kvůli tomu že je je možno používat špatným způsobem.

[dustin]

Co když do té databáze zapisuje spousta aplikací zároveň?

Ještě jednou - Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Přímo do DB jen při shozené aplikaci nebo při startu, kdy ještě nemá keš inicializovanou (děláme tak větší updaty DB). Je jenom jedna RW keš. Opakuji - má to výhody i nevýhody. U nás převažují výhody, proto to takhle používáme.

[j]

...Správně používané zámky nikdy deadlockem neskončí....

Fakt? Tak to bych chtel videt jak udelas ... fakt bych chtel videt, jak vyresis to, ze dva uzivatele/aplikace/... hodlaji poslat update na stejny zaznam. Nechas je to udelat oba? Pekne potichu?

[agent]

Pokud je to důležité, aby to nemohlo nastat (což u spousty app neplatí), tak si záznam zamknu na začátku editace a uvolním po update nebo po odpadnutí spojení. A nedovolím otevření pro editaci nebo přímo zápis (v situaci kdy se zámek uvolil automaticky) nikomu, kdo nevlastní lock.
Pokud tohle dostatečně dobře nejde na DB úrovni, můžu si to zajistit na aplikační úrovni (a předpokládat, že nikdo nepůjde natvrdo na data přes nastavený aplikační zámek). 

[Olda]

...Správně používané zámky nikdy deadlockem neskončí....

Fakt? Tak to bych chtel videt jak udelas ... fakt bych chtel videt, jak vyresis to, ze dva uzivatele/aplikace/... hodlaji poslat update na stejny zaznam. Nechas je to udelat oba? Pekne potichu?

Ja si myslim, ze 'Nekdo1' si vyzada zamek na zaznam, precte ten zaznam, provede zmeny a zapise to. Pak ten zaznam zase uvolni a na to uz ceka 'Nekdo2', ktery si take vyzadal na ten zaznam zamek a nyni se precte on ten prave zmeneny zaznam , provede sve zmeny a zapise a uvolni to.
Takovehle situace ale k deadlocku nikdy nevedou. Jinak to bude, kdyz se Nekdo1 a Nekdo2 budou hadat o 2 ruzne zaznamy - pak b ta deadlock situace mohla nastat, ale ja se vsadim, ze nas kolega=Nekdo to ma osetrene a kdyz si tedy vyzada v te nesikovne situaci zamek, tak dostane od systemu navratovou hodnotu=DEADLOCK a on (a nebo ten locking system) to zkusi po par milisekundach znova.   

[O]

Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.

Já myslel, že se tady bavíme o ORM jako o programovací technice, ne o tom, že v reálu si ORM frameworky jen s ORM přístupem nevystačí a musí k tomu přilepit funkčnost, která už nemá s ORM prakticky nic společného a která zcela zásadně narušuje tu úroveň abstrakce, na které pracuje ORM.

[Kit]

Co když do té databáze zapisuje spousta aplikací zároveň?

Ještě jednou - Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Přímo do DB jen při shozené aplikaci nebo při startu, kdy ještě nemá keš inicializovanou (děláme tak větší updaty DB). Je jenom jedna RW keš. Opakuji - má to výhody i nevýhody. U nás převažují výhody, proto to takhle používáme.

Jistě, takovou propracovanou RW keš má databáze v sobě a poskytuje veřejně dokumentované API. Další mezičlánky jsou kontraproduktivní a zbytečné.

[andy]

Co to tu riesite zas? Deadlock nastava ak v grafe cakania na zamky existuje cyklus. Preto ak lockujete zaznamy v rovnakom poradi, deadlock nastat nemoze. Deadlocky su iba znak toho, ze mate v IT bordel.
Cachovanie je dobra vec na rozne ciselniky ktore sa nemenia casto. Robit 300 sql requestov v jednom http requeste aby som zobrazil jednu tabulku, to je taky php pristup, ale inak totalna kravina. Ohladom platnosti dat, kazda normalna DB vie posielat eventy.