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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 5
dnes 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

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

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 5
včera 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

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

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 9
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 25
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 18
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 6
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 774 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Pětiminutový průměr

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