Tabulka s velkym mnozstvim cteni > problem se zapisem

16. 6. 2013 00:33:06

resim problem se zapisem do tabulky z ktere je velky pocet cteni (uplne jednoduche selecty). tabulka ma 6 sloupcu, 2 indexy (ne-unikatni) a neco pres 20k radku (narustaji, ale hodne pomalu, tato hodnota je za rok provozu). puvodne byla tabulka v myisam - tzn. nejsou potreba transakce, foreign keys atd...provoz je na ni hodne velky, ve spicce az 200k uzivatelu online a kazde nacteni stranky vyzaduje cteni z teto tabulky. zkousel sem zmenu na innodb kvuli row-level locku, zkousel sem pridat unikatni index ale problem to nevyresilo. ve chvili kdy se do tabulky maji vlozit data tak nastane tato situace:

1) myisam - kazdy novy radek se vklada nekolik sekund, behem toho cekaji selecty a jak se zacnou hromadit tak ve finale spadne cela aplikace

2) innodb - data se ulozi celkem rychle a na prvni pohled bez problemu ale tak 3s po ulozeni nastane stejna situace jako u myisam kdy selecty zacinaji zamrzat, hromadi se thready na mysql az nakonec aplikace spadne

- pres mytop sem odsledoval ze to opravdu zacne zamrzat a padat jen na selectech z teto tabulky po ulozeni novych dat, nezpusobuje to nic jineho. u tabulek kde neni pocet cteni tak velky tak stacila zmena na inno a vsechno bezi paradne ale s touhle situaci si nevim rady.

ma nekdo zkusenosti s podobnou situaci? jak byste zapis do takoveto tabulky resily?

16. 6. 2013 00:33:06

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913301

Jersák Martin

(23 hodnocení)

16. 6. 2013 01:04:19

Zacni cashovat nebo buransky tip:

Udelej duplicitni tabulku kde vsechny zaznamy kartezsky skombinuj a na vsechny pouzivane sloupce dej indexy. Dotazy smeruj na duplicitni tabulku a zapisy delej jenom do puvodni tabulky. Cronem v casovych intervalech dle potreby vytvor kartezakem treti tabulku. Druhou dropni a treti prejmenuj na druhou a tak furt dokola. Pro koncoveho uzivatele vse pojede furt, akorat zelezo se pekne opoti.

Pak uz je to jenom o castosti aktualizace a vykonu serveru.

16. 6. 2013 01:04:19

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913300

Martin

(7 hodnocení)

16. 6. 2013 01:17:07

zacni cachovat je docela sirokej pojem :) query cache se samozrejme vyuziva a kde to pomaha a nemusi byt realtime data tak prepocitavam mimo spicku cronem a cachuju ale to nema vliv na tuto tabulku. tahle tabulka se tyka nastaveni polozek, nastaveni musi byt k dispozici hned po pridani polozky. tim odpada i "buranskej tip", nad necim takovym sem taky premyslel ale ono se muze stat ze za cely den neprida nikdo nic ale taky v jednu chvili toho muze pridat nekolik uzivatelu vic a potom to nebude moc efektivni.

moc nechapu tu situaci s innem. mel sem za to ze diky moznosti row-level locku se pri pridani radku nemusi tabulka locknout a tim padem to nebude mit efekt na probihajici selecty.

16. 6. 2013 01:17:07

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913299

Riedl

16. 6. 2013 01:28:58

no jestli se to často nemění, tak bych ty data nacpal do APC..

16. 6. 2013 01:28:58

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913298

Martin

(7 hodnocení)

16. 6. 2013 01:41:01

praveze jak kdy, nekdy vubec za celej den, jindy vicekrat behem par minut. ale apc bych mohl zkusit, snad nebudou nutny moc velky zmeny v kodu

---------- Příspěvek doplněn 16.06.2013 v 01:46 ----------

jeste sem zapomel na dulezitou vec. nad mysql bezi jeste flashcache v modu writearound.

---------- Příspěvek doplněn 16.06.2013 v 01:58 ----------

a jeste jedno doplneni. mysql a web server sou oddeleny. je jeden server kde bezi nginx a php a druhej server kde bezi mysql (konkretne fork mariadb). takze ani apc asi nebude nejlepsi. mozna memcached ale co se ted divam na nejaky porovnani tak je memcached o dost pomalejsi oproti apc. nejradsi bych to vyresil na urovni mysql ale vypada to ze to asi nepujde

16. 6. 2013 01:41:01

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913297

Riedl

16. 6. 2013 02:10:15

to prece nevadi, ze jsou oddeleny, ne? to je jen dobře.. cron udrzuje APC aktualni, aplikace z APC zobrazuje..

pripadne pokud bys to mohl balancovat, tak jsem si nedavno hral s mysqlnd_ms - principiálně zapneš replikaci na mysql a do masteru insertujes a updatujes a ze slave selectujes - krasa je v tom, ze ten driver sam detekuje co je to za dotazy, takze nemusíš prepisovat aplikaci.... ty slave servery samozrejme muzes zase balancovat nejakym pooling driverem a jsi za vodou :)

Rozdil v apc a memcache je v tom, ze APC je na jednom stroji, memcache se sdili vramci session, která muze byt balancovana na vice app strojích - tam by takove reseni byla samozrejme kravina, ale to není tvůj pripad :)

16. 6. 2013 02:10:15

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913296

Martin

(7 hodnocení)

16. 6. 2013 02:28:40

teorie zni dobre, zitra musim apc nastudovat, promyslet jak to efektivne pouzit a vyzkouset :) ted uz sem u monitoru 19h v kuse a prestava mi to myslet :D

16. 6. 2013 02:28:40

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913295

Riedl

16. 6. 2013 02:29:07

chápu.. mám to podobně :)

16. 6. 2013 02:29:07

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913294

Martin

(7 hodnocení)

16. 6. 2013 09:38:59

tak sem to promyslel, udelal par vypoctu a vypada to ze bych nejen vyresil problem se zapisem ale zaroven usetril podstatny pocet celkovych dotazu na db. ted je otazka jestli jen nepresunu problem jinam a nenaroste o hodne zatez na web serveru. prepsat aplikaci bude vzhledem k jejimu rozsahu trochu narocnejsi, uvidim jestli to stihnu dnes a potom se podelim o vysledky

16. 6. 2013 09:38:59

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913293

Martin Bárta

(28 hodnocení)

16. 6. 2013 11:39:05

Je potřeba, aby ty data zůstávali při každém načtení aktuální?

Já to dělal tak, že to generoval jednou za pět minut automaticky přes cron a každý uživatel tak nemusel zatěžovat databázi, zavolal se vlastně jen soubor s vygenerovaným HTML obsahem.

16. 6. 2013 11:39:05

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913292

Martin

(7 hodnocení)

16. 6. 2013 11:48:10

jj, aktualni bohuzel musi byt, navic tohle je jen mala cast z celyho procesu behem kteryho se rozhodne jaky obsah se vlastne zobrazi a co se s nim bude dit. ono se to tezko popisuje kdyz nemuzu pustit ven detailnejsi informace :D uvidim jak dopadnu s apc, to se zatim zda jako idealni reseni pokud to moc nezatizi web server.

16. 6. 2013 11:48:10

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913291

Martin Bárta

(28 hodnocení)

16. 6. 2013 11:52:11

Aha, tak to je potom i s cache složitější.

16. 6. 2013 11:52:11

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913290

(22 hodnocení)

16. 6. 2013 12:11:03

nevim jakou povahu ma obsah tech dat a jak mas reseno zelezo, nicmene co tu casto nacitanou tabulku mit typu ram?

Muzes delat jednou denne dump (jakoze asi delas..) a vytvoris navic treba myisam tabulku, do ktere se budou pridavat jen novy zaznamy za ten den (a samozrejme do ty ram tabulky taky), ale budes timhle chranenej proti vypadku elektriny a zaroven insert do te denni tabulky bude rychlej, pac tam bude minimum dat.. Pak pripadne mysql tmp pokud nemas, taky narvat do ramdisku a pak cele by to melo svihat jako blesk.

---------- Příspěvek doplněn 16.06.2013 v 12:13 ----------

+ pokud pouzivas mysql, prejdi na mariadb :)

16. 6. 2013 12:11:03

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913289

Martin

(7 hodnocení)

16. 6. 2013 12:32:44

uz sem to tu psal. mariadb pouzivam + flashcache v modu writearound. pri nacitani stranky se rozhoduje podle cele rady kriterii kterou polozku zobrazit a tato tabulka obsahuje vetsinu jejich nastaveni takze je z ni v 99.9% jenom cteni, pridava se tam vyjimecne ale kdyz se prida tak musi byt data ihned k dispozici. nevim jestli ulozeni tabulky do ram by pomohlo, myslim ze uz sem to driv zkousel ale ted nevim urcite jestli to bylo za stejne situace. kazdopadne s rychlosti disku problem neni, pred nasazeni flashcache se pohyboval iowait kolem 10-15, po nasazeni flashcache je iowait kolem 0.07

16. 6. 2013 12:32:44

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913288

Petr Zachrdla

(1 hodnocení)

16. 6. 2013 17:19:11

zkusil bych otestovat tři varianty

1. apc

2. mysql na disku jako master a v ramdisku jako slave (data pro select jdou z ramdisku)

3. mysql na disku jako master a na ssd(nebo alternativa do pci slotu) disku jako slave (data pro select jdou z ssd)

16. 6. 2013 17:19:11

https://webtrh.cz/diskuse/tabulka-s-velkym-mnozstvim-cteni-problem-se-zapisem/#reply913287