Dotaz: Pětiminutový průměr

[Pavel]

Zdravím, do DB ukládám každou minutu data, která pak zobrazuju v jpgraphu. Pokud ještě zobrazuju data za celý den (1440 záznamů) tak to ještě jde, ale pokud chci zobrazit celý týden, tak jak dotaz, tak následné vykreslení grafu trvá dlouho. Jde nějak v MySQL rovnou číst data jako pětiminutový, nebo hodinový průměr? Pokud ne, tak bych asi musel data zrcadlit do druhé DB a tam ten průměr počítat.

Odpovědi

[iKoulee]

Asi bude zalezet na schematu tabulky, teoreticky by to slo za pomoci AVG a GROUP BY.

Ale jinak myslim ze lepsi by bylo pouzit misto mysql, rrd databazi, ta je na takovehle ukoly primo navrzena.

[wamba]

v sqllite to jde takhle (průměr za hodinu),

select datetime(avg(strftime('%s',hod)),'unixepoch') from cas group by strftime('%Y-%m-%d %H',hod);

přímo z času to průměr nepočítalo

[Ivan]

Podivej se na Exponential_moving_average. Ten se pouziva skoro vsude. Pokud bys' to chtel pocitat primo v databazi, tak v Oracle by se na to pouzila MODEL clause.

Vetsinou se takovy data ukladaji to rrd.

[Josef Kufner]

Dělal jsem nějaké podobné statistiky a došel jsem k tomu, že nejlepší je si ty data pro zvolené intervaly spočítat a uložit vedle. Tedy udělat nějaký ten pomalý výpočet, ale udělat ho jen na tom posledním kousku dat, co se ještě nepočítal. Navíc pak můžeš velmi stará podrobná data zahodit/archivovat a ponechat si jen souhrnné statistiky (např. pro roční pohled).

[Pavel]

Rozumná odpověď, proč zbytečně několikrát počítat to samé, když jde pohodlně výsledek uložit.

[Šangala]

Je to jedna a dobrá možnost, ukládat si mezivýsledky to pomocné permanentní tabulky. Tyto mezi výsledky lze generovat na pozadí (třeba cron-em) nebo jen na vyžádání, a pro zobrazení tahat vždy z této tabulky.

Druhá, nevím jak dobrá možnost, ale pokud je to dobře/abstraktně udělané snadno se implementuje kdykoliv za chodu, a to je udělat cache na SQL dotazy (třeba jejich SHA1 otisk) a SQL výsledek uložit v nějakém serializovaném formátu, s logikou neexistuje provedu SQL/seraializuji/uložím/přečtu/vrátim, existuje-li přečtu/vrátím. Tato cache lze periodicky čistit, tím nic nebobtná a data jsou vždy buď rychle nebo pomalu (samozřejmě to lze i uprvního). Výhoda tohoto to řešení je, že nemusíš vědět co chceš předpřipravit a nemusíš na to nic speciálně chystat jakýkoliv obskurní dotaz pak vytvoříš, je to tam. Nevýhodou je trochu přemýšlení prvotní pracnost s vytvořením rozhraní, kde se musí myslet jak na dotaz, tak i případě připravených dotazů i na data a identifikátor (SHA1) musí být tvořen jak z SQL dotazu tak s dat, a taky je potřeba myslet na to, že ne každý dotaz pracuje s neměnnými daty (při volání dotazu současně přidat jeho platnost). Tato možnost se mi právě u statik osvědčila…, freqventované dotazy jsou přes cron předpřipraveny a potřebné se chystají in-time a není to zatížené změnami požadavků, jakýkoliv výstup přidáš automaticky je poprvé pomalý a pak v cache.

Poslední možnost (která lze kombinovat s oběma, je správné navržení dotazu a případně doplnění pomocných polí, či vytvoření pomocné tabulky). Obecně jakákoliv práce s časem a datem je záludná a náročná, lepší je si třeba ukládat přímo konkrétní pětimunutu od nějakého pevného bodu a nedopočítávat ji, pak lze udělat pomocnou tabulku s číselnou řadou či řadami a provázat a group-ovat podle ní, ale to záleží jak přesně (jaká je struktura) to máš.

Ono to vychází ze zvláštnosti statistiky, že se často pracuje s neměnnými daty, takže lze jakýmkoliv způsobem výsledky předpočítat, takže finálně třeba nemusíš nic jen generuješ až finální statický výsledek (html/graf apod.), tedy máš aktuální data na výstupu s nějakým definovaným zpožděním a možní nějaký náhled na živá data, ale jen kousek do zadu…

.

[Josef Kufner]

SQL dotazy a jejich výsledky kešuje už databázový server. Občas stačí jen přidat paměť použitou na cache (někde v konfiguráku). Aby takové kešování fungovalo lépe, je potřeba počítat se zvláštními vlastnostmi dané úlohy, což databáze nebo vlastní kešování na úrovni SQL dotazů dělat nemůže.

[Šangala]

Statistika je často o tom, že z velkého množství dat je třeba získat „nečetný“ výsledek. Velmi často kešování takových úloh na straně DB serveru je sci-fi až pro stovky MiB RAM vyhrazenou pro DBE cache, která je aplikačně neovldatelná, user-cache je plně ovladatelná a zajistí že výsledek žádaný dnes a včera, je dnes vrácen z toho včerejšího a netrvá 2 min. Co jsem tak vyšmíroval, tak ve velkém se to dělá na tři úrovně, první jsou vytvořené plně statické výsledky, druhá úroveň se pracuje na pomocnými a||nebo omezenými předpřipravenými daty a třetí úroveň jsou živá data (která nemusí být v DB, ale třeba v souborech) a o ty úlohy se „žádá“ (řadí se do fronty).

Běžné malé věci jsem měl dřív vždy nad živými daty a nechal to nad DB, ale jednou jsem udělal řešení, které pracovalo s velkým objemem dat a podávalo de-facto jen statistické výsledky. Jakmile jsem doplnil tuto cache a předgenerování expandovaných dotazů v mrtvém čas a hlavně sériově, tak se to mohlo odsunou na virtuál s 2GiB RAM (db několik GiB, možná na jednom místě to už budou vyšší desítky GiB přímo na železe - nemám to ve správě, nevím) a pohoda a mohlo s tím pracovat i více lidí. Takové řešení je velká úspora zdrojů (tedy nad neměnnými daty, nebo kde jsou výsledky relevantní pro deleší dobu), takže to už aplikuji častěji a věci co těžce nesl DB server, zvládne lokání mini DB konfigurace (píšu o MySQL a MSSQL - s PostgreSQl jsem to ještě nedělal, jen testoval, MySQL je šetrnější na tyto věci a MSSSL bylo prostě zadání)

[Heron]

SQL dotazy a jejich výsledky kešuje už databázový server.

Jak který. PostgreSQL query cache nemá (z dobrých důvodů) a i u MySQL se doporučuje to s její velikostí moc nepřehánět (256MB), protože režie spojená s invalidací cache může být větší, než přínos té cache. Netuším, zda se něco změnilo, ale MySQL vylejvala z cache všechny querry, které se týkaly měněné tabulky, takže v praxi se ta cache často ani nenaplnila. (Nevím co je v této oblasti nového, MySQL už mi nesmí přes práh.)

Pokud nějaký proces cache využije, je mnohem lepší, když si ji řídí sám (protože ví jak, což ta obecná query cache nikdy neví). A může na to použít věci jako memcached apod.

[ebik]

Hmm, jenže tady výsledek toho dotazu se mění každou minutu. Takže cache se hodí, jen když stejných dotazů bude více do minuty. IMHO se zde jedná o méně časté, zato náročnější dotazy.

[Šangala]

To je otázka, mění se přece jen aktuální data, tedy poslední 5-ti minuta/hodina… Právě proto, že se jedná (jestli se tedy jedná - těch dat, tak jak je to popisované, je trocha, tak by to mělo být hned) o náročné dotazy, je na místě cache nebo dopočítaná tabulka

[Pavel]

A ještě dotaz. Je lepší průměry počítat v php ihned při zadávání, nebo každých pět minut spouštět script, případně zjistit kolik je toho potřeba spočítat a činit tak až když se to potřebuje?

Dle mého názoru bych to počítal okamžitě...

[Josef Kufner]

Já bych to počítal až když je něco bude chtít.

[Zopper]

Jen pokud bude chtít něco relativně často. Pokud se bude na graf koukat jednou za dva týdny, tak to pak potrvá strašně dlouho a co když přijde timeout...

Takže záleží na konkrétní situaci.

[ebik]

Pokud se budou průměry ukládat "průběžně", tak timeout nezahodí vypočtenou práci.

[ebik]

Já jsem také pro okamžité počítání, když tam budeš mít "if" na "pátou" minutu, tak je to ekvivalentní tomu pětiminutovému skriptu, jen to bude vše na jednom místě (v jednom zdrojáku), což je IMHO pro jednoduché úlohy přehlednější.

[VM]

Vzhledem k tomu že týden má nějakých 10 tisíc minut, tak by se to nemělo číst zas tak dlouho, jinak je někde něco shnilého. Začal bych tím.

Také bych výsledné grafy kešoval na disk, aby dva přístupy během pěti vteřin nezpůsobily dvojí nové generování. Případně se dá graf generovat cronem, a klientovi se jen pošle výsledný soubor.

To zda ukládat minutová nebo pětiminutová data bych nechal čistě na tom, která mě zajímají.