ugrás a tartalomhoz

MySQL terhelés csökkentés

vtsoftware · 2012. Dec. 7. (P), 02.48
Üdv mindenkinek.

Készítettem egy statisztikai naplózót MySQL alapokra helyezve.
Van benne több mint 40.000 sor, összesen majd' 50MB.

A hozzáfűzés, új sor hozzáadás gyerekjáték, nem úgy a kiolvasás.
Ahhoz, hogy egy adott hét adatait egy diagramra rajzoljam ki, beletelik 1 percbe.
A kiolvasáson valahogy gyorsítani szeretnék, mivel elkezdtem írni egy kezelőfelületet ahhoz, hogy ezt a statisztikai adatbázist használni is lehessen valamire, ne csak adathalmaz legyen.

Mivel lehet egyszerűsíteni egy ilyen adatbázist, vagy milyen struktúrában érdemes dolgozni az adatokkal?

Gondoltam arra, hogy esetleg fájlba mentem a havi adatokat, mikor szükség van rá feltöltöm, miután már nem kell, kitörlöm.
Ezt aztán elvetettem mivel szükségem van éves adatokra is. Mivel az van most, lassú a dolog. Nagyon is.
De ha fájlba is menteném, a sok I/O művelet lehet lassabb, de ha nem lassabb terhelőbb lenne... bár nem próbáltam.

Elrőe is köszönöm
‹ Oracle XE és PDO PHP-ban. Valakinek sikerült? sqlite - mennyire érdemes használni? ›
 ■
1

index?

pp · 2012. Dec. 7. (P), 07.41
"A hozzáfűzés, új sor hozzáadás gyerekjáték, nem úgy a kiolvasás."
Ilyenkor az a gyanú, hogy nincsenek indexek, vagy amik vannak azokat nem tudja használni a mysql(rosszak).

EXPLAIN mit mond?

pp
2

40 000 sor és 50 MB nem tűnik

tihi · 2012. Dec. 7. (P), 09.04
40 000 sor és 50 MB nem tűnik olyan soknak. Az indexeket mindenképpen nézd meg, de elképzelhető, hogy inkább a kiolvasással módjával vagy a rajzolással lesz a gond, nem?
3

Hol fut mindez? Saját gépen

eddig bírtam szó nélkül · 2012. Dec. 7. (P), 10.02
Hol fut mindez? Saját gépen vagy szolgáltatónál? Az a 40000 sor, pláne, ha mindez egyetlen tábla, még akkor sem sok, ha egyáltalán nincs indexed. 50MB-nak 1:1-ben el kellene férnie a cache-ben.
Szóval valami nagyon nem kerek.
Select-et esetleg meg tudod osztani velünk?
4

Kereső

Hidvégi Gábor · 2012. Dec. 7. (P), 10.45
Kereső
5

Aggregalas

janoszen · 2012. Dec. 7. (P), 11.00
Alapvetoen a statisztikagyartasnal (hacsak nem akarsz folyamatosan uj queryket futtatni) nincs szukseged az osszes adatra, hanem idonkent (mondjuk orankent) aggregalhatod oket olyan formaba, ahogy meg fogod jeleniteni. Ennek az etalonja, ha mondjuk minden oraban nyitsz egy uj tablat es a regi tablat aggregalod, igy szep gyors lesz az egesz folyamat. Az eredmenyt beteszed a stat tabladba, a nyers adatokat meg kidumpolod es gzip-elve orzod meg, igy keves helyet foglal.
6

Ha nem zárom le a kapcsolatot

sandrosdj · 2013. Feb. 22. (P), 18.56
Ha nem zárom le a kapcsolatot a php kód végén mysql_close()-zal, akkor is lezáródik a mysql kapcsolat a generálás végén?
7

Olvastad a függvény leírását?

Hidvégi Gábor · 2013. Feb. 22. (P), 19.13
Olvastad a függvény leírását?
8

Olvastam, viszont amikor nem

sandrosdj · 2013. Feb. 22. (P), 19.25
Olvastam, viszont amikor nem használom, nő a kapcsolatok száma az adatbázishoz minden egyes frissítéssel. Bizonyos időközönként persze nullázódik.
9

Gondolom, hogy nem

Hidvégi Gábor · 2013. Feb. 22. (P), 20.51
Gondolom, hogy nem perzisztensen kapcsolódsz a szerverhez, ugye? Akkor viszont elképzelhető, hogy valami hiba folytán nem jut el a vezérlés a php shutdown függvényekig, bár erre nem sok esélyt látok.
10

Nem. Van viszont egy sajátos

sandrosdj · 2013. Feb. 22. (P), 22.18
Nem. Van viszont egy sajátos hibaoldal szerűségem, amelyet a register_shutdown_function()-nal hívok meg. Elképzelhető, hogy ebben van a hiba?
11

register_shutdown_function

Hidvégi Gábor · 2013. Feb. 23. (Szo), 08.49
A kézikönyv szerint ha ezt a függvényt exit()-tel fejezed be, akkor teljesen leáll a script futása, és akkor valószínűleg nem jut el a mysql kapcsolat bontásáig.
12

Ott kezdődik, hogy nem kell

inf · 2013. Feb. 24. (V), 18.28
Ott kezdődik, hogy nem kell mysql_ kezdetű függvényeket használni.