abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 17:00 | Nová verze

Byl vydán Docker 1.13. Přehled novinek na YouTube a v poznámkách k vydání na GitHubu. Docker umožňuje běh aplikací v softwarových kontejnerech (Wikipedia).

Ladislav Hagara | Komentářů: 0
včera 15:51 | Komunita

Mozilla.cz informuje, že nástroje pro webové vývojáře se možná oddělí od Firefoxu a stanou doplňkem. Nástroje pro webové vývojáře prošly velkým přepisem a tým, který se stará o jejich vývoj, by uvítal možnost jejich častějších aktualizacích nezávisle na vydávání nových verzí Firefoxu.

Ladislav Hagara | Komentářů: 1
včera 07:00 | Humor

Čtenářům AbcLinuxu vše nejlepší k dnešnímu Dni zvýšení povědomí o tučňácích (Penguin Awareness Day).

Ladislav Hagara | Komentářů: 0
včera 06:00 | Komunita

Bylo spuštěno hlasování o přednáškách a workshopech pro letošní InstallFest, jenž proběhne o víkendu 4. a 5. března v Praze. Současně byla oznámena změna místa. InstallFest se letos vrací zpět na Karlovo náměstí do budovy E.

Ladislav Hagara | Komentářů: 0
včera 02:48 | Komunita

Greg Kroah-Hartman potvrdil, že Linux 4.9 je jádrem s prodlouženou upstream podporou (LTS, Long Term Support). Podpora je plánována do ledna 2019. Aktuální jádra s prodlouženou podporou jsou tedy 3.2, 3.4, 3.10, 3.12, 3.16, 3.18, 4.1, 4.4 a 4.9.

Ladislav Hagara | Komentářů: 0
včera 00:11 | Zajímavý článek

Výrobce síťových prvků, společnost Netgear, spustila nový program, který slibuje vývojářům, expertům, ale i běžným uživatelům vyplacení finanční odměny za nalezení bezpečnostních chyby v jejich produktech. Za nalezení zranitelnosti v hardware, API nebo mobilní aplikaci nabízí odměnu od 150 do 15 tisíc dolarů (dle závažnosti).

Michal Makovec | Komentářů: 0
včera 00:08 | Pozvánky

V sobotu 18. 2. se v Praze v prostorách VŠE uskuteční od 9:30 již 4. ročník největší české konference o open source redakčním systému WordPress (WP) - WordCamp Praha 2017.

… více »
smíťa | Komentářů: 0
19.1. 23:58 | Komunita

Kryptoměnová komunita zahájila nový rok spuštěním projektu Blockchain.cz, jehož cílem je kolektivně nalézt ideální překlad pro čím dál frekventovanější slovo „blockchain“. Přispět návrhem může kdokoli. Sběr bude trvat až do konce září 2017. Následně bude probíhat dvoutýdenní veřejné hlasování, které bude zakončeno výběrem toho nejlepšího návrhu.

xHire | Komentářů: 8
19.1. 15:55 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno je celkově 270 bezpečnostních chyb. V Oracle Java SE je například opraveno 17 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 16 z nich. V Oracle MySQL je opraveno 27 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 5 z nich.

Ladislav Hagara | Komentářů: 0
19.1. 02:48 | Nová verze

Po půl roce od vydání verze 9.0 (zprávička) byla vydána verze 10.0 zvukového serveru PulseAudio. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 35
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (74%)
 (3%)
 (11%)
Celkem 342 hlasů
 Komentářů: 24, poslední 17.1. 10:14
    Rozcestník
    Reklama

    Dotaz: Pětiminutový průměr

    15.5.2014 13:29 Pavel | skóre: 17
    Pětiminutový průměr
    Přečteno: 1151×
    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

    15.5.2014 15:15 iKoulee | skóre: 19
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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.
    Even if you fall on your face, you’re still moving forward
    wamba avatar 15.5.2014 15:33 wamba | skóre: 37 | blog: wamba
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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
    This would have been so hard to fix when you don't know that there is in fact an easy fix.
    15.5.2014 15:24 Ivan
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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 avatar 23.5.2014 23:06 Josef Kufner | skóre: 66
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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).
    Hello world ! Segmentation fault (core dumped)
    23.5.2014 23:18 Pavel | skóre: 17
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Rozumná odpověď, proč zbytečně několikrát počítat to samé, když jde pohodlně výsledek uložit.
    24.5.2014 13:29 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Pětiminutový průměr

    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…

    .
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    Josef Kufner avatar 24.5.2014 13:35 Josef Kufner | skóre: 66
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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.
    Hello world ! Segmentation fault (core dumped)
    24.5.2014 15:22 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Pětiminutový průměr

    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í)

    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    Heron avatar 12.6.2014 16:52 Heron | skóre: 50 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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.

    24.5.2014 17:57 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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.
    24.5.2014 20:45 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Pětiminutový průměr

    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

    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    24.5.2014 01:01 Pavel | skóre: 17
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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 avatar 24.5.2014 02:04 Josef Kufner | skóre: 66
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Já bych to počítal až když je něco bude chtít.
    Hello world ! Segmentation fault (core dumped)
    24.5.2014 11:08 Zopper | skóre: 14
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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.
    "Dlouho ještě chcete soudit proti právu, stranit svévolníkům?" Ž 82,2
    24.5.2014 17:54 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    Pokud se budou průměry ukládat "průběžně", tak timeout nezahodí vypočtenou práci.
    24.5.2014 18:00 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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ší.
    24.5.2014 19:33 VM
    Rozbalit Rozbalit vše Re: Pětiminutový průměr
    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í.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.