Fce SUM pro vic tabulek naraz

22. 12. 2011 11:40:08

zdravim, potreboval bych pomoct s dotazem. puvodne sem mel jednoduse:

SELECT id,SUM(data1) AS data1,SUM(data2) AS data2 FROM table WHERE `date`='$date' AND type='0' GROUP BY id ORDER BY data1 DESC

nastala ale nutnost tabulku rozdelit na nekolik mensich se stejnou strukturou a ted nevim jak dotaz prepsat abych dostal stejny vysledek.

jeste nez se tu zacne resit proc to nezustalo v jedne tabulce tak to situace opravdu neumoznuje, muj dotaz je jak dosahnout stejnyho vysledku kdyz nebudu vybirat z jedne tabulky ale treba s 5ti ze stejnou strukturou.

dokud sem nepotreboval group a order, tak sem to resil cyklem v php co prosel postupne vsechny tabulky a bylo to bez problemu ted sem ale uz dva dny zaseklej na tomhle a nevim jak dal, nejspis to pujde pres nejakej join ale ty tak uplne nechapu a nepovedlo se mi to dat dohromady

22. 12. 2011 11:40:08

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709497

(20 hodnocení)

22. 12. 2011 11:46:22

na tohle v databzich existuje partitioning (rozdelovani dat do ruznych tabulek podle klice, pricemz se dotaz ale dela pouze na hlavni zakladni tabulku) pokud se nemylim... zda se ze si zbytecne pridelavate praci s necim co uz je vyresene

(snad tu o tom nekdo napise vic, protoze osobne jsem s tim jeste nepracoval)

22. 12. 2011 11:46:22

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709496

duben

(49 hodnocení)

22. 12. 2011 11:49:52

Hodně pomůže pokud uvedeš struktury tabulek, nicméně možné řešení je třeba:

Pokud nemáš pevný počet tabulek, tak si to SQL generuj dynamicky.

Je to sice z hlediska záteže serveru prasárna, ale při rozdělení co máš to asi hezčí udělat moc nepůjde.

---------- Příspěvek doplněn 22.12.2011 v 11:51 ----------

Jinak souhlas s Alešem, nedovedu si představit důvod, proč rozdělit 1 tabulku na víc naprosto stejných. Nedovedu si ten důvod představit ani pro tabulku v řádech stamilionů záznamů a velikosti desítek terabajtů.

22. 12. 2011 11:49:52

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709495

Martin

(7 hodnocení)

22. 12. 2011 12:04:43

abych to teda priblizil, slo o tabulku s miliony zaznamu na kterou bylo extremni mnozstvi dotazu co se tykali jen male casti dat. po rozdeleni klesla zatez serveru o 90% a funguje to nadherne, spocitat data napric vsema tabulkama je potreba jen parkrat za den takze behem toho se vetsi zatez prezije. pevnej pocet neni, dynamicky sql dotazy generuju uz ted. du vyzkouset tohle reseni a dam vedet

22. 12. 2011 12:04:43

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709494

(20 hodnocení)

22. 12. 2011 12:07:14

dotazy se spravnym indexem, pokud to nejsou nejake hodne specialni dotazy by meli byt v radech milisekund a temer bez zateze i na velkych tabulkach :) resit to roztristenim dat tedy pomuze, ale v podstate tim jen resite problem ktery maji resit indexy ikoliv tristeni dat

22. 12. 2011 12:07:14

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709493

duben

(49 hodnocení)

22. 12. 2011 12:17:51

Pokud na tabulku bylo extrémní množství dotazů na menší množství dat a pomohlo rozdělení na malé tabulky svědčí to o jediném. Máte špatně udělné indexy a neumíte s nimi pracovat. Indexy jsou různých druhů. Správně naindexovaná tabulka se správně udělanými dotazy vrací i z milionů záznamů výsledky v milisekundách až vteřinách.

22. 12. 2011 12:17:51

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709492

Martin

(7 hodnocení)

22. 12. 2011 12:19:38

praveze ani indexy nestacily, na te tabulce je opravdu extremni provoz, v prumeru 30 milionu dotazu za hodinu. az po rozdeleni kdy uz dotazy smerujou na konkretni mensi tabulky to jede i s touhle zatezi perfektni rychlosti. pokud to pujde pres ten join tak i kdyz to bude prasarna tak si vysledek ulozim do cache a staci mi aktualizovat jen parkrat za den coz se da prezit

22. 12. 2011 12:19:38

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709491

duben

(49 hodnocení)

22. 12. 2011 12:43:32

Buď cache, nebo si udělej jednu tabulku, kde budou předpočítané hodnoty a párkrát za den jí aktualizuj. Záleží co bude rychlejší, v cache máš výsledky, ale předpočtenou tabulku jde indexovat a joinovat.

8333 dotazů za vteřinu by pořád mělo jít na dostatečně dimenzovaném serveru rozumně zvládat. Je to už trošku výzva, ale pořád nic co by bylo nutné řešit rozdělením tabulek.

22. 12. 2011 12:43:32

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709490

takatom

(2 hodnocení)

22. 12. 2011 13:44:43

SELECT id,SUM(data1) AS data1,SUM(data2) AS data2 FROM

(

SELECT id,data1,data FROM table1 WHERE `date`='$date' AND type='0' union all

SELECT id,data1,data FROM table2 WHERE `date`='$date' AND type='0' union all

...

SELECT id,data1,data FROM table3 WHERE `date`='$date' AND type='0'

) GROUP BY id order by data1 desc

22. 12. 2011 13:44:43

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709489

Martin

(7 hodnocení)

22. 12. 2011 13:58:11

du vyzkouset, jen dotaz pro pochopeni, proc v te posledni uz neni union all?

---------- Příspěvek doplněn 22.12.2011 v 14:08 ----------

tak uz sem ten union pochopil, musel sem jeste za konec te zavorky pridat alias a pocita to bezchybne :) diky moc :)

22. 12. 2011 13:58:11

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709488

takatom

(2 hodnocení)

22. 12. 2011 14:15:45

union all je mezi první a druhou, druhou a třetí,...,předposlední a poslední

22. 12. 2011 14:15:45

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709487

duben

(49 hodnocení)

22. 12. 2011 15:00:54

několikanásobný UNION ALL mezi tabulkami kde je v součtu několik milionů řádků ... uff, to bude peklo. Ten můj dotaz nevypadá tak pěkně, ale nebude zatěžovat DB tak moc.

---------- Příspěvek doplněn 22.12.2011 v 15:01 ----------

Tím nechci říct, že je ten UNION špatně, je to funkční řešení, akorát pro tyhle podmínky bude nevhodné z hlediska zátěže.

22. 12. 2011 15:00:54

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709486

Tomáš Burda

(1 hodnocení)

22. 12. 2011 19:38:24

UNION nemusi byt vubec spatne reseni. Pocitam ze tam stejne pouziva nejaky limit (nebo pracuje s milionem zaznamu?). Kdyz prida odpovidajici nasobky limitu, do tech union selectu a zaroven i tam bude radit...

Provedou se dva, tri, podle poctu tech tabulek, velice rychle selecty, ktere se pak dotridi bez indexu, ale tam uz bude malo zaznamu...

Stejne si myslim, ze ty indexy nebyli optimalni... Ale jinak bych mel stejne nejakou master tabulku, kde bude vse. A z ni se daji pres triggery generovat specificke slave tabulky. Pak se jen pouzije pozadovana tabulka.

22. 12. 2011 19:38:24

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709485

Martin

(7 hodnocení)

22. 12. 2011 20:22:22

uz to mam v provozu a ten union me opravdu zachranil, i kdyz spojuje hromadu tabulek s hodne daty tak to funguje uzasne rychle :)

22. 12. 2011 20:22:22

https://webtrh.cz/diskuse/fce-sum-pro-vic-tabulek-naraz#reply709484

Pro odpověď se přihlašte.

Přihlásit