CYBERWOLF: ad to srovnání, to přece záleží na tom jakým dotazem ty data bereš ... jednoduchý dotaz to moc urychlit nemůže, ale takový většinou necachuješ. A jakmile je to dotaz ošklivý tak ten výsledek bude někde úplně jinde. (samozřejmě je tu i možnost cachovat zpátky do DB :) ).

A co se týče těch 2GB, to už hodně záleží na povaze aplikace a těch dat, ale opravdu v tom nevidim problém, webový server u takové hry pravděpodobně až tolik paměti žrát nebude a databázový bude zvlášť :)

TENCOKACISTROMY: celá DB v paměti je pochopitelně základ, pokud to jde.

Nooo, 2GB do pameti, to uz bych se asi trochu bal. Pokud by toho frcelo tolik, ze by bylo potreba cachovat tolik dat, tak ta pamet bude asi spis potreba nekde jinde.

Kazdopadne, tady jde o neco trochu jineho - query cache je tak nejak transparentni zalezitost. DB server si to resi sam a kdyz ma validni cache, tak sahne misto do tabulky do ni a vrati vysledek zdibec rychleji a kdyz nema, tak vrati vysledek a to same si nacpe do cache. Jenze pokud se do te cache nestaci podivat driv, nez ta cache vyexpiruje, tak to dela uplne zbytecne a kdyby to nedelal, tak by mohl jet o neco lip (a do dneska jsem to jeste nevyzkousel, hmmm).



Kdyz uz mluvime o cachovani, tak pred nejakym casem jsme v praci zkouseli, jak by se dala cachovat aplikacni data (celkem velky balik), aby se odlehcil SQL serveru. Celkem prekvapive (alespon pro me) jsme dospeli ke zjisteni, ze akorat memcache dokaze ta data vratit rychleji a to jeste ne o moc. Moduly pro cachovani dokazali cache vratit v case srovnatelnem s MySQL (bez cache). Cachovani do souboru bylo dokonce znatelne pomalejsi.

Ukazalo se, ze vyrazny podil na pomalosti cache ma rekonstrukce dat, protoze neni mozne ukladat rovnou pole, je potreba ho prevest do nejakeho ulozitelneho formatu (serializovat,csv,json, xml...) a prave rozparsovani po nacteni je nejkritictejsi bod.

Zaver, ktery z toho experimentu plyne je, ze prakticky nema cenu cachovat data a jedine co se vyplati cachovat je hotovy vystup (ktery se tedy nemusi porad generovat a hlavne se da ulozit/nacist tak jak je).

CYBERWOLF: tak to je ale v případě query cache to samé, někde to uložit musíš :) ... mít 2gb memcache neni dneska problém a zase tolik těch dat aby se tam to důležité nevešlo ta hra mít nebude :)

YAWGMOTH: memcache je fajn, ale ta pamet taky neni nafukovaci :)

CYBERWOLF: proto se reálně používá ještě cachování na úrovni aplikace, třeba s memcached, a do databáze vůbec nelezeš :)

TENCOKACISTROMY: Tak to je jesny, ze zalezi na situaci, ale ja bych prave rekl, ze zrovna webove hry jsou ten typ aplikace, kde tech insertu a updatu v pomeru k selectum docela dost (a proto tu o tom mluvim:) ).

Ale jak o tom tak prubezne premyslim, napadlo me, ze by mozna mohlo pomoct v pripadech kdy je nepriznivy pomer select/zmeny, tak jednoduse query cache vypnout a zbavit se tak overheadu s overovanim a ukladanim cache, ktera se stejne v 99.9% pripadu nevyuzije.

CYBERWOLF: Tak to je samozrejme o tom, v jakym scenari to pouzivas. Kdyz mas naopak velkej pocet selectu a malej pocet zmen, tak se ti to vyplati.

Resit query cache jsem nikdy nemusel, pac mi skoro porad vychazej dotazy pokazdy trochu jiny a casto se mi menej data. Ale vim, ze treba MSSQL umi notifikovat, ze se zmenily data pro tebou zaslanej dotaz. Doporucuje se to ale pouzivat v omezeny mire, aby si prave tim porovnavanim jak rikas, nezabrdil celej stroj. Jak to maj reseny uvnitr netusim, ale tipuju ze je to delany podobne jako Change Data Capture.

TENCOKACISTROMY: nebo takhle, vis o nejakem db serveru, ktery tohle skutecne dela?

TENCOKACISTROMY: nj, ale predstav si, ze mas cachovanych par stovek (tisic, desetitisic...) dotazu a pri kazdem insertu musis proverovat, jestli by se vlozeny zaznam do nektereho nevesel aby se cache zinvalidovala. To mi neprijde realne, rekl bych, ze overhead bude daleko vetsi, nez zisk, obzvlast pokud budou inserty/updaty casto.

CYBERWOLF: Jak kdy. Kdyz bys mel napriklad "SELECT a,b,c FROM tbl WHERE d > 10", tak pri "INSERT INTO tbl (a,b,c,d) VALUES (1,2,3,4)" docela jasne vis, ze to invalidovat nepotrebujes.

TENCOKACISTROMY: tohle konkretne MySQL, ale pochybuju, ze to jinde bude jinak. Logicky, kdyz zmenim obsah tabulky, tak se meni i to, co muzu vybrat a musi se invalidovat cache. Tezko by mohlo byt zjistovani, jestli do ktereho nacachovaneho dotazu by se vlozeny/upraveny zaznam vesel efektivnejsi, nez invalidace cache pro danou tabulku

CYBERWOLF: A to se tyka kteryho db stroje?

Jen tam mimochodem, trochu jsme ted resili cachovani SQL dotazu a tak nejak vyplynula takova (nakonec docela zrejma) vec a to ze query cache se invaliduje pokazde, kdyz se tabulka zmeni (struktura, nebo obsah). Me tak napadlo, ze to je v pripade webovych her docela pruser, protoze pripadu, kdy se nejaka data pouziji vic nez jednou do chvile, nez do tabulky nekdo zapise bude opravdu malo.

Je tedy pravda, ze pokud bude dotaz dobre napsany, probehne rychle i bez cache, ale i tak mi to pripada jako oskliva neprijemnost :(

CYBERWOLF: Nojo, klikaci :D Tak tam bych udelala rozdil mezi "posledni refresh" vs "posledni skutecna zmena"

WEWERKA: To vypada jako docela dobry napad, ale pokud jde o pocitani neprihlasenych hracu, tak pocitej s tim, ze lidi hrajici z prace (obzvlast ti pracujici na nejakych mene frekventovanych mistech nebo statni sprave) budou prihlaseni porad a pokud nekdo vymysli nejaky helper, tak nebude ani ta minutova neaktivita:)

Tak jsem na to asi prisla :) Vsechny subjekty patri nekam na mapu. Pokud se zmeni na nekom, kdo ma uz vypocitanou predikci, jednodusse vezmu vsechny subjekty se vztahem na dane policko v mape a uplne vsechny prepocitam. Teoreticky by se melo jednat o 50-200 radku, worst case scenario max 1000. A pokud to predelam na paralelni vypocet, tak by to mohlo byt dopocitane za chvili.
K tomu optimalizace stylu a) pocitej neprihlasene hrace b) pocitej par minut po hracove neaktivite.
Tahy budou radove 1-2h, v rychlem rezimu treba 30 minut. Takze cas na propocet urcite bude.

CYBERWOLF: Ja mam zkusenosti hlavne s MSSQL, ale tenhle pristup mi pripada pomerne jednoduchej a efektivni, tak jsem si rikal, ze by to mohli implementovat i ostatni stroje. Ale hlavu na spalek, bych za to nedal :)

Hm, diky za tipy. Dedeny tabulky v praci pouzivame a ani vlastne nevim proc :)

TENCOKACISTROMY: mam za to, ze tohle dela jenom MSSQL :)

CYBERWOLF, CYBERWOLF: Jj, s tim souhlasim.

WEWERKA: Nemyslim radky, ale stranky. Napr. MSSQL (ale u ostatnich to bude imho stejne) si tu tabulku rozdeli na jednotlivy casti (= stranky) o velikosti X radku. Kdyz pak delas nejakej update zamykaj se jen ty stranky, kde se neco updatuje. Kdyz updatujes na zaklade sloupcu, ktery maj indexy tak se ti i rychle vyhodnotej stranky, ktery se maj zamknout. Navic si u transakci muzes (zase - neznam moc dobre postreges, ale urcite to bude umet) nastavit, aby se ti to lockovalo jenom pro zapis, ne pro cteni.

Jestlize mas velky mnozstvi ruznejch typu objektu, spis nez nejakou univerzalni strukturu o par tabulkach pro ulozeni vseho bych pouzil "dedeny tabulky", ktery by byly jakoby tridy (class v OOP). Tim by jsi cekani na zamky docela dost omezila.