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

dnes 15:17 | Pozvánky

Od pátku 25. 5. proběhne na Fakultě informačních technologií ČVUT v Praze openSUSE Conference. Můžete se těšit na spoustu zajímavých přednášek, workshopů a také na Release Party nového openSUSE Leap 15.0. Na stejném místě proběhne v sobotu 26. 5. i seminář o bezpečnosti CryptoFest.

Jendа | Komentářů: 0
dnes 13:33 | Zajímavý software

Drawpile je svobodný multiplatformní program pro kreslení podporující společné kreslení několika uživatelů. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv3+. Drawpile i Drawpile Server jsou ke stažení také ve formátu AppImage. Stačí tedy nastavit právo na spouštění a spustit.

Ladislav Hagara | Komentářů: 0
dnes 09:44 | Zajímavý software

Kalifornskému Muzeu počítačové historie (Computer History Museum) se po pěti letech vyjednávání se společností Qualcomm podařilo získat veškerá práva na poštovního klienta Eudora (Wikipedie), tj. kromě zdrojových kódů muzeum získalo také ochranní známku Eudora nebo domény eudora.com a eudora.org. Po pročištění byly zdrojové kódy Eudory uvolněny pod licencí BSD.

Ladislav Hagara | Komentářů: 3
včera 15:00 | Nová verze

Byla vydána nová stabilní verze 5.11 toolkitu Qt. Přehled novinek v příspěvku na blogu a na wiki stránce. Další dnešní příspěvek na blogu Qt je věnován Qt pro WebAssembly umožňujícímu běh Qt aplikací ve webovém prohlížeči. K vyzkoušení jsou příklady.

Ladislav Hagara | Komentářů: 0
včera 12:22 | Nová verze

Po 7 měsících vývoje od verze 0.12.0 byla vydána verze 0.13.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v oznámení o vydání a v příspěvku ve fóru.

Ladislav Hagara | Komentářů: 12
včera 12:11 | Pozvánky

V úterý 29. května v 18:00 se v Brně koná pátý přednáškový večer o webovém vývoji. Čeká vás povídání o frameworku v Elixiru, vydávání nové kryptoměny přes ICO, component trees v Reactu. Na místě bude lehké občerstvení; vstup zdarma pro registrované. Více informací na Facebooku nebo se rovnou registrujte na Meetup.

dejvik | Komentářů: 0
včera 12:00 | Pozvánky

V pátek 25. května 2018 v Praze proběhne společné setkání komunity kolem Drupalu a překladatelů softwaru – tématem bude právě lokalizace svobodného softwaru (nejen Drupalu). Program začíná v 9.30 v budově Českého rozhlasu (Vinohradská 12), ale můžete přijít i později během dne.

Fluttershy, yay! | Komentářů: 0
včera 06:55 | Zajímavý software

Operační systém 9front, zřejmě nejaktivněji vyvíjený neoficiální fork systému Plan 9 (více informací), se dočkal nové verze nazvané „Ghost in the Minesweeper Shell“. K novým vydáním obvykle dochází každé jeden až tři měsíce.

Fluttershy, yay! | Komentářů: 0
včera 02:00 | Bezpečnostní upozornění

Byly zveřejněny (Project Zero, Intel, AMD, Arm) informace o dalších 2 bezpečnostních chybách v procesorech: variantě 3a aneb CVE-2018-3640 - Rogue System Register Read (RSRE) a variantě 4 aneb CVE-2018-3639 - Speculative Store Bypass (SSB). Podrobnosti o chybě CVE-2018-3639 například v příspěvku na blogu Red Hatu. Princip vysvětlen pomocí videa na YouTube.

Ladislav Hagara | Komentářů: 3
21.5. 19:44 | Zajímavý software

Spolek vpsFree.cz na svém blogu informuje, že přechází z OpenVZ na vpsAdminOS. Distribuce vpsAdminOS je založena na NixOS a not-os. Pokud provozujete OpenVZ Legacy a nevíte co dál, můžete zvážit vpsAdminOS, který je na migraci kontejnerů z OpenVZ připraven.

Ladislav Hagara | Komentářů: 4
Používáte pro některé služby inetd?
 (34%)
 (23%)
 (43%)
Celkem 147 hlasů
 Komentářů: 5, poslední včera 16:46
    Rozcestník

    Dotaz: Pětiminutový průměr

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