Tabulka s velkym mnozstvim cteni > problem se zapisem

16. 6. 2013 17:24:28

hele četli jste tu chlapci vůbec, že ty servery jsou oddělené? že tady pořád mácháte tou databazi v ramdisku? navíc opravdu bych vám nepřál vidět, co dělá replikovaná databáze v ramdisku ;)

16. 6. 2013 17:24:28

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Petr Zachrdla

(1 hodnocení)

16. 6. 2013 17:29:51

Napsal Riedl;962840
hele četli jste tu chlapci vůbec, že ty servery jsou oddělené? že tady pořád mácháte tou databazi v ramdisku? navíc opravdu bych vám nepřál vidět, co dělá replikovaná databáze v ramdisku ;)

Jaký je problém mít na DB serveru master DB na jednom portu na klasickém SAS disku (čti jako RAID) a slave DB v ramdisku na jiném portu?

Koneckonců jaký by byl problém kdyby slave DB byla na aplikačním serveru a master DB na serveru na kterém je? To úzké hrdlo může být klidně ta síť.

16. 6. 2013 17:29:51

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Riedl

16. 6. 2013 17:39:46

no technicky jistě žádný :)

1) neřešíte tím problém přistupování k databázi - jen jste dvojnásobně zatížil běžícím mysql stávající server

2) vyzkoušejte zapnout replikaci mysql databází na jednom stroji s tím, že slave máte v ramdisku, použijte mysqlnd_ms driver do php, a změřte, jestli jste si pomohl.. například já jsem si akorát pohoršil a to znatelně, ale zkuste to Vy a můžeme si o tom následně pohovořit při výměně zkušeností.. vyměňovat teorie si nehodlám

16. 6. 2013 17:39:46

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Petr Zachrdla

(1 hodnocení)

16. 6. 2013 17:52:10

Napsal Riedl;962845
no technicky jistě žádný :)
1) neřešíte tím problém přistupování k databázi - jen jste dvojnásobně zatížil běžícím mysql stávající server
2) vyzkoušejte zapnout replikaci mysql databází na jednom stroji s tím, že slave máte v ramdisku, použijte mysqlnd_ms driver do php, a změřte, jestli jste si pomohl.. například já jsem si akorát pohoršil a to znatelně, ale zkuste to Vy a můžeme si o tom následně pohovořit při výměně zkušeností.. vyměňovat teorie si nehodlám

ad.1) to si nemyslím. stix psal, že zápisy se dějí jen výjimečně, takže hlavní slovo by měla slave DB na ramdisku. celý problém stojí na navýšení RAM v DB serveru a delší době startu DB serveru (v řádu sekund)

ad.2) viz. ad.1) + psal jsem, že by slave DB mohla být na aplikačním serveru, což sice jde proti obvyklé strategii a zvyšovala by transakční režii na zpracování dotazů do databáze, ale jelikož je to v paměti RAM, jsou tyto transakční režie výrazně menší než dotazování na druhý DB server. U externího serveru to jde na úkor zvýšené spotřeby CPU prostředků a zmenšení datového toku pro reálné uživatele, protože se karta musí dělit o čas s dotazy do databáze.

ad.teorie - máme vyzkoušeny v praxi oba způsoby. inspirovali jsme se u Amazon Cloudu, který běží v ramdisku.

16. 6. 2013 17:52:10

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Riedl

16. 6. 2013 17:59:55

v tom případě je to super zpráva, že pooling mysqlnd_ms přestal sestavovat ve vaší verzi spojení pro oba servery (jak master tak slave), dělá to jen pro slave a globální transakční identifikátory si zřejmě tahá z časoprostoru či křišťálové koule.. jakou že verzi to požíváte? já mám 1.5...

16. 6. 2013 17:59:55

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Petr Zachrdla

(1 hodnocení)

16. 6. 2013 18:31:29

Napsal Riedl;962856
v tom případě je to super zpráva, že pooling mysqlnd_ms přestal sestavovat ve vaší verzi spojení pro oba servery (jak master tak slave), dělá to jen pro slave a globální transakční identifikátory si zřejmě tahá z časoprostoru či křišťálové koule.. jakou že verzi to požíváte? já mám 1.5...

Obávám se, že se každý bavíme o jiném způsobu přístupu k DB. Vy přistupujete přes plugin k DB. My přímo podle toho jestli jde o zápis nebo čtení. Vaše řešení má výhodu přístupu, protože plugin sám rozhodne na který server (master, slave) se připojí. My se připojujeme k aplikaci přímo, mimo plugin mysqlnd_ms.

16. 6. 2013 18:31:29

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Riedl

16. 6. 2013 18:47:29

Souhlasím, rozdíl je v tom, že já mám výhodu v nepřepisování aplikace - driver sám rozhodne kterou použije na základě toho, jestli se jedná o select, nebo insert/update a podle toho ho vykoná na příslušném stroji. Pokud jak popisujete, máte v aplikaci řešení které si nativní spojení na master otevře jen v případě, kdy to vynutíte, je to určitě super, jen portace takového řešení na stávající velké aplikace je problém a navíc to vyžaduje aby budoucí "štourači" ve vašem kódu toto věděli a neinsertovali vám do slave "protože je po ruce" :) - to druhé je možná paranoia, ale všichni víme, že se to bohužel stává :(

Nicméně přivedl jste mě na zajímavou myšlenku vyrobit podobný pooling jako má driver ve své vrstvě ve vrstvě aplikační ... pouhým obalením stávajícího DB connectoru - zkusím to vyrobit a nasadit na nějaký z větších projektů, kterým mám k dispozici.. proměřím a porovnáme :)

16. 6. 2013 18:47:29

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Petr Zachrdla

(1 hodnocení)

16. 6. 2013 18:51:01

Napsal Riedl;962872
Souhlasím, rozdíl je v tom, že já mám výhodu v nepřepisování aplikace - driver sám rozhodne kterou použije na základě toho, jestli se jedná o select, nebo insert/update a podle toho ho vykoná na příslušném stroji. Pokud jak popisujete, máte v aplikaci řešení které si nativní spojení na master otevře jen v případě, kdy to vynutíte, je to určitě super, jen portace takového řešení na stávající velké aplikace je problém a navíc to vyžaduje aby budoucí "štourači" ve vašem kódu toto věděli a neinsertovali vám do slave "protože je po ruce" :) - to druhé je možná paranoia, ale všichni víme, že se to bohužel stává :(
Nicméně přivedl jste mě na zajímavou myšlenku vyrobit podobný pooling jako má driver ve své vrstvě ve vrstvě aplikační ... pouhým obalením stávajícího DB connectoru - zkusím to vyrobit a nasadit na nějaký z větších projektů, kterým mám k dispozici.. proměřím a porovnáme :)

S budoucími šťourači problém nemáme, protože drtivá většina našeho kódu je proprietární :) Ano vlastní pooling by byl velmi triviální. My z historických důvodů zatím nepoužíváme. Dejte vědět jak jste dopadl.

16. 6. 2013 18:51:01

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Martin

(7 hodnocení)

17. 6. 2013 12:21:59

tak APC problem vyresilo velice efektivne. pri nacitani zjistim jestli je nastaveni polozky v apc a nactu, kdyz tam neni tak nactu z db a ulozim. pri zmene nastaveni zase z apc odmazu. pocet dotazu a zatizeni db vyrazne kleslo. ted by me zajimalo, pokud bych se to rozhodl pouzit pro vic tabulek kde je velky pocet dotazu a prevazne na cteni, tak je nejaky rozumny limit kolik user variables si v apc drzet ulozenych? nebo zalezi jen na velikosti ram?

17. 6. 2013 12:21:59

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Petr Zachrdla

(1 hodnocení)

17. 6. 2013 12:23:53

RAM je klíčem k úspěchu :)

17. 6. 2013 12:23:53

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Martin

(7 hodnocení)

17. 6. 2013 12:44:29

pokud teda nehrozi ze by se apc sesypalo pri nejakych extremnich cislech tak je to vyhra. ram je dostatek (64gb, vyuzitych 13gb + kernel cache) :)

edit: za cca hodinu provozu sem usetril 60M dotazu a data v APC berou jen 40mb v ram, nadhernej vysledek :)

17. 6. 2013 12:44:29

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Petr Zachrdla

(1 hodnocení)

17. 6. 2013 12:51:35

Napsal stix;963067
pokud teda nehrozi ze by se apc sesypalo pri nejakych extremnich cislech tak je to vyhra. ram je dostatek (64gb, app si bere 13gb) :)
edit: za cca hodinu provozu sem usetril 60M dotazu a data v APC berou jen 40mb v ram, nadhernej vysledek :)

přiznám se, že nevím co se stane, když APC vyčerpá paměť (EDIT: jestli se zastaví nebo začne swapovat), ale asi bych to neřešil (EDIT: při uvedené velikosti paměti). nastavil bych si hlídání na cca 80% paměti a pak by se vidělo jak s tím naložit. použít můžeš např. http://newrelic.com/ je tam základní hlídání cpu, disku, paměti zdarma.

17. 6. 2013 12:51:35

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

duben

(49 hodnocení)

18. 6. 2013 00:20:55

Mě tedy přijde, že je něco hodně špatně s databázovým modelem nebo přístupem na data. Pokud má tabulka 20k záznamů, tak to není tabulka co má "hodně" záznamů. To je tabulka, která má normálně záznamů. Tabulka s hodně záznamy je tabulka s daty v řádech milionů, nikoliv jednotek desetitisíců.

Otázka tedy je v jak složitých SQL dotazech tabulka figuruje, zda je o prostý dotaz, jestli jsou data správně omezena (nepředpokládám, že na každý dotaz uživatele se musí vypsat kompletně 20k záznamů), pokud trvá takhle dlouho zápis vypadá to na špatně udělané indexy.

Co bych prověřil jako první:

- Jak vypadají SELECT dotazy, zda jsou udělané limity, aby se tahalo jen potřebné množství řádků

- Jak vypadají indexy, jakého jsou tipu a jestli nemohou ovlivňovat výkon zápisu

- Ujistit se, že v kódu nevznikají cykly, nebo deadlocky, že jsou správně uzavírané konexe na DB

- SELECT dotaz na 20k řádky by měl trvat v řádu 0,000x sekund, pokud trvá déle třeba se blíží sekundám, hledal bych problém v dotazu

- INSERT bez triggeru, propojení na další tabulky a nějaké složité kalkulace musí trvat taky v řádu milisekund, pokud netrvá opět bych prověřil jak vypadá dotaz, prohnal profilerem proř trvá dlouho a na čem vázne.

- při vysokém množství načtení bych v SELECT používal vynucené NOLOCK, pro jistotu

Předpokládám, že v tabulce nejsou BLOB objekty o velikosti megabajtů a víc.

18. 6. 2013 00:20:55

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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

Martin

(7 hodnocení)

18. 6. 2013 01:38:31

- ze ma tabulka "hodne" zaznamu sem nezminoval, psal sem ze je na ni extremni pocet pozadavku na cteni :)

- select samozrejme s limitem je

- indexy sem overoval a zkousel si s nima trochu pohrat jeste nez sem tu psal

- cykly ani deadlocky nevznikaji

- 0,000x sekund - to ano, konkretne 0,0002 ale pred pouzitim user variables v apc kam to ted ukladam a co problem vyresilo, tak bylo selectu v prumeru 15k/s - jedna se o aplikaci s hodne velkym provozem

- insert by par ms trvat mel ale v pripade myisam to padlo uz pri ukladani, v pripade innodb po ulozeni a nezjistil sem proc

- nolock by v tomto pripade pouzit sel, predtim sem o jeho existenci ale nevedel. kazdopadne reseni co je ted kdy se mysql uplne vynecha mi pripada nejidealnejsi

18. 6. 2013 01:38:31

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

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