Fórum Root.cz
Hlavní témata => Server => Téma založeno: NovacekVIt 12. 05. 2014, 10:35:37
-
Zdravím všechny,
Jsem v tomto ještě nezkušený. Řeším problém kdy mám projekt v PHP a mysql. Dvě tabulky v db jsou hodně vytěžováne (hodně zápisu a ověřování), chtěl bych tyto tabulky a náročný proces dat na druhy VPS ale netuším jak spojit druhou db s první db abych mohl používat inner join atd. Četl jsem něco o replikaci ale nejsem si jisty zda je to správný směr.
Všem předem děkuji za nakopnuti
-
Zdravím všechny,
Jsem v tomto ještě nezkušený. Řeším problém kdy mám projekt v PHP a mysql. Dvě tabulky v db jsou hodně vytěžováne (hodně zápisu a ověřování), chtěl bych tyto tabulky a náročný proces dat na druhy VPS ale netuším jak spojit druhou db s první db abych mohl používat inner join atd. Četl jsem něco o replikaci ale nejsem si jisty zda je to správný směr.
Všem předem děkuji za nakopnuti
Vubec nevis kde presne mas problem. Jaky mas storage? Jakou verzi mysql? Zkousel jsi nejakym zpusobem resit nastaveni?
Kdyz to poladis tak ty mene vytezovane tabulky pofrci z cache a ty zapisy to nebudou prilis ovlivnovat.
-
Zdravím všechny,
Jsem v tomto ještě nezkušený. Řeším problém kdy mám projekt v PHP a mysql. Dvě tabulky v db jsou hodně vytěžováne (hodně zápisu a ověřování), chtěl bych tyto tabulky a náročný proces dat na druhy VPS ale netuším jak spojit druhou db s první db abych mohl používat inner join atd. Četl jsem něco o replikaci ale nejsem si jisty zda je to správný směr.
Všem předem děkuji za nakopnuti
Ver mi urcite to neni to co chces. Sice to mozne je ale zpusobis si stim vic trablu nez uzitku. Doporucuji spis poladit nastaveni db a poupravovat indexy atd.
-
Zdravím,
děkuji za odpovědi ale rád bych věděl jak se tento problém řeší, server není nafukovací. Optimalizaci chápu ale prosil bych vás všechny s radou popřípadě nějakou zkušenosí jak je to moc problemové rozdělit db na dva servery.
Díky všem :)
-
Záleží na tom, co myslíte tím „tento problém“. Pokud myslíte ten váš, to už tady napsali jiní – optimalizace aplikace, optimalizace použití databáze, optimalizace konfigurace databáze, optimalizace konfigurace operačního systému, použití jiného databázového systému, použití jiného hardware.
Pokud myslíte, jak se řeší spojení více databází tak, aby bylo možné pracovat s ní jako s jednou logickou databází, např. v Oracle se to řeší pomocí Database Links.
-
S mysql je to temer nerealne. Existuji sice veci jako mysql gallera, mysql cluster apod, ale tam jsou zase jine prekazky a osobne doporucuju se vam temto resenim vyhnout : ).
Za prve, nejdrive udelejte optimalizace db jak radi kolegove, pokud uz optimalizace mate, tak rozdelte db a aplikacni server. Nasadte cachovani vysledku sql v aplikaci.
Az potom bych mozna zacal zvazovat nasazeni replikace master <-> slave, kde aplikace muze pouzivat x slave serveru ke cteni a jeden master server pro zapis.
Kazdopadne si nejdrive neco nastudujte, pak vam s mysql prijde rozumnejsi to vyskalovat nahoru nez horizontalne : )
-
Zdravím,
děkuji za odpovědi ale rád bych věděl jak se tento problém řeší, server není nafukovací. Optimalizaci chápu ale prosil bych vás všechny s radou popřípadě nějakou zkušenosí jak je to moc problemové rozdělit db na dva servery.
Díky všem :)
Jaksi nezminujes ani zakladni fakta - pocet zaznamu, mnoztvi IO ... a serverovy cluster se resi az v situaci, kdy neexistuje jeden server kterej by to vykonostne zvladnul. Rozhodne pak zapomen na mysql. To je pro podobny situace asi tak vhodny, jako bagrovat metro tim, cim bagrujou deti na piskovisti ...
A vis proc to tak je? Prave proto, ze (ac to mnozi budou tvrdit bijice se v prsa) serverovej cluster se nikdy navenek nechova stejne jako jeden server, aplikaci s tim musi pocitat ... a neni uplne trivilani to uchodit. Nekdy je to spis takova cerna magie, jelikoz stejny veci na ruznych mistech ... davaji ruzny vysledky ;D.
Jinak "nejblbejsi reseni" by mohly napadnout i tebe ... jenze ty zjevne nevis co chces.
1) ... pripojim vic databazi => v kazdy je jen cast zaznamu => ziskam odpoved za (teoreticky) 1/N casu
2) ... databazi pripojim pres DNS ... pricemz mi DNS predhodi pokazy jiny IPcko jinyho serveru => X klientu rozlozim na N serveru
Problem je, ze ve vsech pripadech to funguje velmi dobre ... jen pro cteni dat. Jakmile potrebujes zapisovat, mas problem. Tim vetsi, cim vetsi cluster stavis. A existujou dokonce situace, ktery nejsou nijak resitelny.
-
Pokud nedokazes dodat aspon zakladni fakta, nedokazes aspon detekovat bottleneck tak kde beres odvahu se poustet do vetsich veci?
-
Zdravím všechny,
Jsem v tomto ještě nezkušený. Řeším problém kdy mám projekt v PHP a mysql. Dvě tabulky v db jsou hodně vytěžováne (hodně zápisu a ověřování), chtěl bych tyto tabulky a náročný proces dat na druhy VPS ale netuším jak spojit druhou db s první db abych mohl používat inner join atd. Četl jsem něco o replikaci ale nejsem si jisty zda je to správný směr.
Všem předem děkuji za nakopnuti
Obvykle stačí dát celou databázi na samostatný server, Apache s PHP na druhý server. Kolik je "hodně zápisu a ověřování"? Stovky tisíc za sekundu?
-
No a jestli je problem se zapisem tak to se resi dneska SSD :-)
-
premigrovat na ciste distribuovane riesenie. ak to riesis dnes, bud to risit znova o rok :) takto ich skasni hned a mas pokoj
-
S mysql je to temer nerealne. Existuji sice veci jako mysql gallera, mysql cluster apod, ale tam jsou zase jine prekazky a osobne doporucuju se vam temto resenim vyhnout : ).
Za prve, nejdrive udelejte optimalizace db jak radi kolegove, pokud uz optimalizace mate, tak rozdelte db a aplikacni server. Nasadte cachovani vysledku sql v aplikaci. book
Az potom bych mozna zacal zvazovat nasazeni replikace master <-> slave, kde aplikace muze pouzivat x slave serveru ke cteni a jeden master server pro zapis.
Kazdopadne si nejdrive neco nastudujte, pak vam s mysql prijde rozumnejsi to vyskalovat nahoru nez horizontalne : )
samozrejme ze to mozne je, dokonce je v nekterych vecech mysql vykonnejsi, nez nektere jine enginy... nicmene spis nez o master <-> slave replikaci mu jde asi o shardovani, coz je s mysql taky mozne
-
Kdyz jsem pred par lety resil vyhledavac souboru na kolejich tak reseni zvladajici tisice klientu hledajicich v milionech zaznamech bylo "nehledat, ale vedet kde vysledek je", tj. indexace na aplikacni urovni, segmentace dat do X tabulek, zapis pres dve urovne k zabraneni r/w kolizim a jine zdanlive slozitosti. Ale melo to vyznam - aplikace bezela na jednom fyzickem serveru (mysq/php/apache).
U VPS bych se obaval problemu s garantovanim dostupnosti zdroju (procesor, pamet), jelikoz to je dost dulezity faktor pri optimalizaci nastaveni (nejen) sql serveru.
-
Napisu to co mnoho lidi prede mnou. To co pises neni vhodne reseni problemu a zpusobis si vic novych problemu nez vyresis. Vetsinou je chyba v navrhu aplikace nebo v konfiguraci OS, mySQL atd.
Musel by jsi nam presne popsat jak vypada tabulka, kolik ma zaznamu, jake ma indexy jaka je konfigurace OS, mySQL a hlavne jaka je aplikacni logika co se s tou tabulkou deje.
Ziju ve svete Oracle DB kde tabulky maji radove stovky milionu zaznamu a vse funguje kdyz je to dobre napsane a nakonfigurovane. Netusim jestli ve svete mySQL existuje ekvivalent Oracle AWR nebo podobneho nastroje.
-
Vzhledem k tomu, ze pise o problemech pri zapisech jsou veci ktere me napadaji:
- jednou jsem po nekom neco optimalizoval a stacilo jen zmenit insert 1, insert 2, insert 3 na insert 1,2,3 a bylo po problemu.
- uz jen rozdil MyISAM vs InnoDB...
- potom na InnoDB je to treba o buffer pool size ktery je v defaultu nesmyslne maly.
- nastaveni InnoDB file per table taky udela hodne v tomhle pripade
- jak uz jsem vzpominal vys - diskovy system bude tady alfa a omega.
-
Než se pustíš do nějakých harakiri, projeď si mysql server mysqltunerem: http://mysqltuner.com/