Cache pre kompilovany jazyk a transakcie?

Mam program v ktorom mam CRUD vrstvu pre pracu s db(mysql).
Chcel by som don implementovat staticku(in-memory) cache aby som odlahcil napor na db a zrychlil operacie, avsak narazam na problem s transakciami.

Ide o to ze ak transakcia nie je comitnuta tak zmeny v cache sposobia invalidny stav. Takze by sa musela cache neustale mazat, co by bol casty jav nakolko aj v transakcii sa casto stava ze kvoli logike alebo validacii sa musi transakcia zastavit a revertnut a operacia zlyha a ked ma clovek stovky alebo tisice rq/s tak to je skratka blbost.

Logicky teda nie je mozne pouzivat jednu cache.

Je tu teda moznost snapshotnut celu cache ktora bude platna len pre kontext transakcie. Pocas toho by sa zaznamenal kazdy prikaz(get,set,delete) a po comitnuti transakcie by sa tieto prikazy prehrali na hlavnu cache.

Problem je ze ak bude mat cache niekolko giga tak sa velmi rychlo odfajci cely server. Realne to nie je proste mozne nasadit taketo riesenie i ked je najidealnejsie.

Tretia moznost je zabalit cache do read-only wrapperu ktory by simuloval cache ale zmeny by realne nevykonal, iba by si zaznamenal lokalny stav a spominane prikazy a po comite by ich prehral na hlavnu cache. Citanie by prebiehalo z hlavnej cache ale zmeny by boli iba simulovane.

Skoncil som pri tomto poslednom rieseni, nakolko je to jedine mozne ktore ma napadlo, avsak narazm na problem ze zmeny ktore su vykonane na hlavnej cache mimo transakcie budu stale premietnute do cache v transakcii nakolko citanie prebieha z hlavnej cache, naproti kopii kde vsetky udaje su lokalne pre transakciu.

Takze som sa na to vykaslal lebo proste nevidim nejake relane riesenie tohto problemu.

Ale nez to vzdam tak sa chcem spytat ci niekto nema nejaky napad ako toto riesit? Ale aj nieco realisticke, co sa da nakodit do hodiny a kde nemusim studovat zaklady funkcnosti databaz a doktorandske prace od 70. rokov po dnesok :)

a není lepší necachovat? :) DB by několik tisíc req/s měla utáhnout.

Jinak samozřejmě nejjednodušší je mít do commitu sql pouze privátní cache a až poté ji mergnout.

Cache na aplikačním kódu není nikdy dobrý nápad.

Cachovanie vo veľkých enterprise systémoch s terabajtami dát sa typicky rieši cez master-slave databázy:
- master databázy sú optimizované na zápis (t.j. zápis v konštantnom čase a čítanie lineárnom čase)
- slave databázy sú read-only repliky master databázy optimalizované na čítanie (t.j. logaritmický čas na čítanie a lineárny čas na zápis repliky)

To kde sú dáta uložené (t.j. či ide o pevný disk alebo RAM) ti polynomiálne čas nezlepší. Väčšina enterprise databáz používa apriori kombináciu oboch.

Príklad:
Povedzme, že máš systém ktorý potrebuje 100 zápisov za sekundu a 100.000 čítaní za sekundu. Vytvoríš si master databázu, do ktorej budeš iba zapisovať. Zmeny v master databáze budeš napr. každých 5 sekúnd replikovať na 10 slave databáz, kde budú nastavené indexy a materializované pohľady pre rýchle vyhľadávanie a každá z tých slave databáz bude obsluhovať 10.000 čítaní za sekundu. Slave databázy môžu byť geograficky rozmiestnené po kontinentoch na spoločnom klustri s aplikačným serverom pre minimálny overhead.

v enterprise systémech dokonce se ty databáze i dělí na věci jako ODS, (E)DWH a další super zkratky. Mít asynchronní replikaci se zpožděním 5s nesplňuje ACID (nekonzistence pro čtení), ale je možné, že to tak ještě někde je :).

Hlavně cache se řeší až na konec, pokud jedu ACID (v relační databázi nic jiného smysl asi nedává), právě to A mi řiká, že nebudu přece cachovat ještě dříve než je transakce commitnutá, tím se vyhneš tvému problému. Cache vlož na jinou doménovou úroveň.

o cqrs viem, aj pouzivam :)
len ma zaujimalo ci je mozne koncept statickej cache preniest z interpretovaneho jazyku aj do kompilovaneho.

v tom případě nerozumím otázce, v tomhle přece není žádný rozdíl mezi, intepretovaný a staticky kompilovaný je jen o tom, kdy dojde k převodu do byte kódu.

Řada jazyků podporuje dokonce oba způsoby použití.

"v tom případě nerozumím otázce" - ak si vezmes PHP, napriklad, tak staticka cache pre entity ma zivotnost iba pocas requestu. lenze pri kompilovanom jazyku(resp. ak ostanem pri php tak povedzme reactphp, swoole, amphp...) ostava cache stale v ramke a je nutne riesit prave tie veci ktore som pisal. tak ma zaujimalo ako na to, ak to vobec ide.

to ale není o tom, jestli jazyk je kompilovaný, ale jestli běží jako daemon nebo jednorázový worker. Do php mohu také píšu moduly v C, což je kompilovaný jazyk a stejně má jeho běh díky php jepičí život. Python je třeba také nekompilovaný jazyk, ale běží jako deamon na pozadí.

Nevím jak to máš postavené, ale dělat v php těžké objekty a třídy, které potřebují mnoho paměti k inicializaci a jejich naplnění trvá dlouho, není dobrý nápad. Možná máš jen špatně postavenou aplikaci.

V doctrine máš možnost např. mít entitemanager a ten s entitecache nechat persistovat v redisu. V rámci cache redisu můžeš doplnit kd klíči hodnotu aktuální sesssion/context a mít tak cache s contextem. Po uzavření transakce můžeš cache znovu uložit pod generickým klíčem, aby byla dostupná pro všechny.

Pořád bych si ale kladl otázku jak to napsat bez cache :)