Dotaz: MYSQL generovanie štatistických prehľadov

[adrinko]

Zdravím,

prosím o vaše názory, čo je najvhodnejšie v takomto prípade. Mám v phpčku spravený systém, kde si registrovaní užívatelia zadávajú svoje tasky na dnešný deň. Chcel by som teraz, vypísať povedzme mesačnú (alebo aj dlhšiu) krivku pre užívateľa, koľko taskov mal v ktorý deň a z toho by sa mu zobrazila krivka podobne, ako google analytics. Následne ja ako admin by som chcel tiež podobnú krivku, kde by zobrazilo sumár taskov v jednotlivé dni pre všetkých užívateľov.

Otázka teraz je - ako je to najlepšie spraviť s ohľadom na databázu? Je mi jasné, že keby sa to spočítavalo vždy na základe dotazu stránky, tak by sa rôzne výpočti na konkrétne dni opakovali a zbytočne tak viackrát zaťažovali celý systém. Mne sa zdá najlepšie, keď sa pre každý deň uloží do db výsledok a pokiaľ znova nastane potreba zobraziť daný deň, tak sa už nebudú všetky tasky pre daného užívateľa znovu spočítavať, ale sa len jednoducho už predtým spočítaný výsledok načíta z db. Čo poviete? (niečo na spôsob "cachovania" jednotlivých dotazov..) Ešte som také niečo nikdy nepotreboval spraviť, preto uvítam vaše názory. Vďaka!

Odpovědi

[Kit]

O potřebné cachování se stará přímo SQL server.

Pokud bys měl problém s výkonem při poskytování výstupů, můžeš optimalizovat SELECT, případně doplnit potřebné indexy. Nebo můžeš při ukládání záznamů aktualizovat pomocí triggeru nějakou agregační tabulku (i více) s předzpracovanými výstupy.

Každé řešení má své výhody i nevýhody. Záleží na tom, zda se častěji zapisuje nebo čte. Pokud by i nadále byly problémy s výkonem, sáhl bych po jiné databázi.

[okbob]

záleží na zátěži - na objemech dat - na tom, jak budete mít omezené reporty v historii

Od určitých objemů je nutné dělat preagregace - tam sama o sobě žádná relační databáze nepomůže - nicméně chce to řešit pokud počítáte, že se dostanete nad milióny řádků a budete růst. Vytvořte si databázi a naplňte jí, tak jak bude vypadat za cca 7 let provozu - a vyzkoušejte si rychlost dotazů (pokud možno paralelně). Pokud budou dostatečně rychlé, tak nic nemusíte řešit - jinak buďto přemýšlejte nad zadáním (např. omezit rozsah reportu na poslední 3 měsíce) nebo nad formou materializace - preagregace.

[l0gik]

IMHO rychlejší než dělat testy je udělat si tu preagregaci rovnou - jde o tři triggery a jednu tabulku, to je hotový za chviličku.

[adrinko]

vďaka za typy. l0gik, z tvojho príspevku to vyzerá fakt jednoducho:) aké 3 triggery si myslel? viete o nejakom návode na toto...? je síce fakt, že o triggeroch som už čítal, ale ešte som ich nikdy nepoužil. vďaka!

[l0gik]

Tabulka: klíč(uživatel, den), počet operací No jednoduchej trigger: při insertu inkrementovat záznam v tabulce, popř. založit novej při delete dekrementovat a při updatu, pokud se změní den nebo uživatel províst obojí.

Nepíšeš, kterej je to sql server, tak těžko dám návod, dělá se to v každym trochu jinak, ale když hodíš např. mysql (nebo co máš) trigger do nápovědy, tak to najdeš hned.

Třeba k mysql najdeš nápovědu tady: http://dev.mysql.com/doc/refman/5.0/en/create-trigger.html

Řešil bych to takhle tak řádově od stotisíc záznamů, desettisíc Ti db spočítá jak nic.

[Kit]

Do 10k záznamů nemá moc smysl řešit ani indexy, ani triggery. Do 1M vystačíš s indexy.

Záleží tedy na objemu dat. Podle popisu soudím, že preagregaci zřejmě potřebovat nebudeš.

[kuka]

To je myslim prilis zjednodusujici. Pokud jde o hodne zatizeny system (nebo se to do budoucnosti predpoklada), tak pro 1M (a i mene) zaznamu bude hodne velky rozdil, jestli se data prectou z pripravene tabulky, nebo se museji online naagregovat. Co kdyby si napriklad statistiku soucasne zobrazovalo 100 konkurentnich uzivatelu?

[Kit]

Je to zjednodušující. Nevíme vůbec nic o budoucí zátěži. Řešit tuto záležitost triggery na několika stovkách záznamů je overkill, zejména pokud se statistiky budou zobrazovat třeba jen 1x denně.

Denormalizace se má dělat až když je patrné, že to bude líné.

[Josef Kufner]

V zádadě máš dvě možnosti:

1. Udělat select a počítat to na požádání.

2. Každý den posčítat včerejšek a uložit si to. Postupem času staré záznamy agregovat do méně podrobných (posčítat dny do týdnů či měsíců).

Nedávno jsem si naprogramoval do jednoho systému tu první možnost a výsledný select není vůbec hezký. Pokud bude uživatelů více a dat hodně, nebude to stíhat a indexy to nezachrání.

Na cachování v SQL serveru se nespoléhej, než si tytéž data vyžádá uživatel znovu, ostatní je z cache vypláchnou.