Grafikon php-val

Üdv!

PHP-ban szeretnék megjeleníteni egy grafikont (chart) SQL adatokból.
Az adatok pl.:
dátum (időbélyeg) --> érték
2015-07-01 15:05:30.000 --> 34.3
2015-07-01 15:05:35.000 --> 35.6

Mivel érdemes megjeleníteni? Ezeket találtam:
http://jpgraph.net
http://graphpite.sourceforge.net
http://pchart.sourceforge.net
http://www.highcharts.com

A highcharts egész jónak tűnik, a többi - ha jól néztem - nem nagyon frissül.
Használ valaki hasonlót?

Hozzászólások

+1 highcharts, nekem azért esett rá a választásom, mert könnyen lehet dinamikusan lehúzni jó sok adatot hozzá (http://www.highcharts.com/stock/demo/lazy-loading), illetve egyszerre 50-100 megányi adattal is megbirkózik (persze ilyenkor böngésző is eszi a memóriát közben, meg várni kell, de nem hal szét).

Kissé pepecsmunka, de a html-be pakolt svg-t megeszi a legtöbb böngésző. Sem szerver, sem kliens oldalra nem kell semmiféle lib, plugin, stb... Valamikor probálgattam, grafikára jó, elvileg grafikon is gyártható vele.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Fél-off:
Ilyen időbélyeges logok tárolására amúgy lehet, hogy hosszabb távon érdemes az rrdtool-nak utánanézni, az grafikont is tud készíteni.

A témaindítóban leírtakra szeretném használni. Kicsit konrétabban, SQL-ben tárolt mérési eredmények grafikus megjelenítésére (grafikon). Ez lehet hogy esetenként nagy rekordszám (n*10000) is lehet.
Egyelőre a highcharts tűnt befutónak, de a többi javasolt megoldás is nagyon jó!

"Az rrdtool adatbázisának inicializálásakor kell erre odafigyelni, tarthatsz nagyobb felbontást hosszabb távon is, ha szükséges."

Lehetni lehet, csak messze nem gyors és kb. értelmetlen azzal az eszközkészlettel, amire az rrdtool ki van találva... :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A gyujtesnek nem is kell gyorsnak lennie, a PNG generalas viszont piszok gyors, azzal nincs problema. Ertelmetlen: hat, attol fugg. Mondj egy masik adatbazis tipust, ami ugyanarra jo, mint az rrdtool, es nem olyan overkill, mint pl. egy noSQL adatbazis.
--
Blog | @hron84
Üzemeltető macik

Use-case függő, ugye azt írtam, hogy "ha kell az x perces felbontás egy napon túl, akkor az rrdtool nem megoldás". Erre nem az a jó válasz, hogy beállítható rrdtool esetén az évekre visszamenőleg tárolás perces felbontással, mert nem arra van kitalálva a sémája és a működésmódja. Ha vissza kell nézni egy három évvel ezelőtti nap perces adatait és korrelálni kell a tegnapi naphoz, akkor arra alkalmatlan az rrdtool.

"Mondj egy masik adatbazis tipust, ami ugyanarra jo, mint az rrdtool, es nem olyan overkill, mint pl. egy noSQL adatbazis."

Ha kell évekre visszamenőleg az adat (és bányászni is kell, mert az ember ritkán gyűjt elemzés nélkül sok adatot), akkor a NoSQL marad... vagy valamelyik - még erőforrásigényesebb - DWH szoftver.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

En azt tapasztalom, hogy az a jellemzo use case, hogy evekre visszamenoleg nem kell percre pontos adat, eleg az orara pontos - es az rrdtool pontosan igy mukodik. Tudom, hogy ez nem boldogitja azokat, akiknek evekig kell percre pontos adat, de az az igazsag, hogy ez a ritkabb use case.

Ami a noSQL-t illeti: IMHO kicsit overkill a feladatra, mert technikailag meresi adatok rogzitesere van szukseg, amit egy txt fajllal megoldok mindenfele noSQL adatbazis telepitese nelkul. Az rrdtool pont azert jo, mert az elemzesekhez szukseges algoritmusokat nem nekem kell kitalalnom es megirnom, hanem kiadom a parancsot, hogy gyartson PNG-t es gyart PNG-t.

Ami engem illet, en inkabb megeroszakolom az rrdtool semajat az ilyen ritka use casekben, mintsem hogy beleoljek Y ora fejlesztesi effortot, ami sokkal dragabb, mint egyuttelni az rrdtool korlataival. De persze ez privat velemeny.
--
Blog | @hron84
Üzemeltető macik

Te olvasol is vagy csak írsz? :)

"2015-07-01 15:05:30.000 --> 34.3
2015-07-01 15:05:35.000 --> 35.6"

Ez a példa majdnem két hónapos adat a téma pedig három napos... én ebből gyanítom, hogy nem lehet eldobni a korábbi adatokat.

Aztán írtam, hogy "Ha kell az x perces felbontás egy napon túl, akkor az rrdtool nem megoldás..."

Erre Te: "En azt tapasztalom, hogy az a jellemzo use case, hogy evekre visszamenoleg nem kell percre pontos adat, eleg az orara pontos - es az rrdtool pontosan igy mukodik. Tudom, hogy ez nem boldogitja azokat, akiknek evekig kell percre pontos adat, de az az igazsag, hogy ez a ritkabb use case."

És nem lehet, hogy ez nem egy rrdtool-ra jellemző use-case? :)

"Ami a noSQL-t illeti: IMHO kicsit overkill a feladatra, mert technikailag meresi adatok rogzitesere van szukseg, amit egy txt fajllal megoldok mindenfele noSQL adatbazis telepitese nelkul."

Ez is adatmennyiségtől, feladattól, kapcsolt rendszerektől és feldolgozási igényektől is függ... örülök neki, hogy megoldod a saját problémáidat egy txt fájllal, de mindent nem lehet egy txt fájllal megoldani. :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Ez a példa majdnem két hónapos adat a téma pedig három napos... én ebből gyanítom, hogy nem lehet eldobni a korábbi adatokat."

Az rrdtool sem dobja el a regi adatokat, hanem atlagolja, es atalakitja ora pontos adatta, nem arrol van tehat szo, hogy X ev utan mar nincs semmi info arrol, hogy mi tortent korabban, ha ez igy lenne, senki nem hasznalna rrdtool-t. Ahogy elnezem, ez egy homerseklet-grafikon lehet, annal pedig boven jo, ha ket honap utan mar csak az latszik, hogy a nap elejen 28 fokrol 35-ig kuszott fel a higany, majd visszamaszott 27-re ejszaka. Nyilvan egy tozsdei reszveny monitoringjanal ez tok maskeppen alakul.
--
Blog | @hron84
Üzemeltető macik

Egészen pontosan tudom, hogy mit tud az rrdtool:
http://linuxvilag.pbk.hu/content/files/cikk/61/cikk_61_54_59.pdf
http://linuxvilag.pbk.hu/content/files/cikk/63/cikk_63_44_46.pdf

"Ahogy elnezem, ez egy homerseklet-grafikon lehet, annal pedig boven jo, ha ket honap utan mar csak az latszik, hogy a nap elejen 28 fokrol 35-ig kuszott fel a higany, majd visszamaszott 27-re ejszaka."

Ha meg arra kell, hogy éveken át milyen volt egy adott napon a hőmérséklet ötperces változása, akkor nem jó...

...szóval mielőtt információhiány miatti prekoncepciók alapján eszközöket ajánlunk, érdemes megtudni, hogy mi a az üzleti igény, illetve mi az a probléma, amit meg akarnak oldani. Utána lehet eszközöket keresni és választani.

Nem a gombhoz vesszük a kabátot, bár sok helyen ez a céges kultúra.

Én használom az rrdtool-t egy napkollektoros rendszer adatainak megjelenítésére, nem rossz dolog - tervezhető (fix) adatbázisméret, körkörös round-robin felépítéssel.
Monitorozó eszközök (pl. Munin) is előszeretettel használják.

SQL forráshoz persze nem jó - nem tudom, mennyire fix pont ez a kérdezőnél, ill. mennyire bonyolult lekérdezésből kerülnek elő az adatok (nyilván ezért lett fél-off).

Nem olyan régen keresgettem hasonló megoldásokat. Talán itt is hasznos lehet:
20 best js chart lib