ugrás a tartalomhoz

SQL lekérések csökkentése

jeti · 2007. Jan. 26. (P), 22.54
Sziasztok!

Le szeretném csökkenteni egy oldalon az SQL lekéréseket. Ti hogy oldanátok ezt meg?

Összegzem milyen lekéréseim lennének:
Állandó elemek:
- új munkamenet folyamat regisztrálása (új látogatónként)
- meglévő munkamenet folyamat dátumának módosítása (mindig)
- a honlapon lévő vendégek + felhasználók listája (mindig)
- aktuális hirdetés lekérdezése (mindig)
- aktuális apróhirdetés lekérdezése (mindig)
(opcionális)
- felhasználó név + jelszó ellenőrzése (mindig)
- felhasználó adatának a lekérdezése (alkalmanként)
- felhasználó adatának módosítása (alkalmanként)
- felhasználó utolsó bejelentkezési dátumának módosítása (mindig)
Tartalom: (pl.: fórum)
- fórum cím lekérdezése
- fórum téma lekérdezése
- témának megfelelő összes fórumi hozzászólások számának lekérdezése (lapozgatáshoz)
- fórumi hozzászólások (limit-tel) lekérdezése

Hirtelen most ennyi jutott eszembe, de nyilván az összes szolgáltatással el lehet így játszani. Ez a legjobb esetben is 10 SQL kérés minden oldal letöltésekor, és a látogatottság mérőmodult (+2) ki is akarom szedni, ezért nem is számoltam bele.
Tehát hol lehetne itt spórolni?

A másik kérdésem, ha a php futatása során már megállapítottam, hogy a jelszó és a felhasználó név párosítás jó, akkor a továbbiakban abban már megbízhatók? (Pl.: globális változó $hiteles=true;) Vagy minden egyes akciónál újra ellenőrizzem le?
Előre is köszönöm a segítségeteket.
‹ Felhasználók azonosítása, beléptetése Vesszőkkel elválasztott értékre lekérdezés SQL-ben ›
 ■
1

$_SESSION['hiteles'] = true

Joó Ádám · 2007. Jan. 26. (P), 23.38
A másik kérdésem, ha a php futatása során már megállapítottam, hogy a jelszó és a felhasználó név párosítás jó, akkor a továbbiakban abban már megbízhatók? (Pl.: globális változó $hiteles=true;) Vagy minden egyes akciónál újra ellenőrizzem le?


Elküldi a név-jelszó párost, leellenőrzöd, és, ha stimmel, akkor az adatait sessionbe teszed. A későbi kérésekkor már nyugodtan használhatod ezt. (Esetleg érdemes megnézni az erről szóló Weblabor cikket, ha nem bízol eléggé a beépített munkamenetkezelésben.)
2

Pár ötlet

saxus · 2007. Jan. 27. (Szo), 03.18
- fórum cím lekérdezése
- fórum téma lekérdezése

Esetleg ezeket össze lehet vonni valamilyen JOIN műveletté, azzal már spórolsz egy kérést.

- új munkamenet folyamat regisztrálása (új látogatónként)
- meglévő munkamenet folyamat dátumának módosítása (mindig)

Ezt én úgy szoktam, hogy először megpróbálom frissíteni, ha nem található, akkor beszúrok egyet. Csak arra vigyázni kell, hogy a mysql_affected_rows() a ténylegesen módosíott sorokat adja vissza, szoval, ha egy felhasználó ideges, és folyamatosan nyomkodja az F5-t, akkor elhet hogy morcos lesz rá. (-> mysql_info()).

Ezen kívül esetleg valamilyen cachelési módszert tudnék még javasolni, például hírek kiíratása fájlba, memcached -be, stb.
3

Gyorstárazás, JOIN, pici gondolkodás

pp · 2007. Jan. 27. (Szo), 07.34
- új munkamenet folyamat regisztrálása (új látogatónként)

- meglévő munkamenet folyamat dátumának módosítása (mindig)
- felhasználó adatának a lekérdezése (alkalmanként)
- felhasználó adatának módosítása (alkalmanként)
- felhasználó utolsó bejelentkezési dátumának módosítása (mindig)
Ezeket ha ügyes vagy akkor 1 lekérdezésbe gyúrhatod. A felhasználó utolsó bejelentkezésének dátuma meg fog egyezni a session indításának idejével.

- a honlapon lévő vendégek + felhasználók listája (mindig)
- aktuális hirdetés lekérdezése (mindig)
- aktuális apróhirdetés lekérdezése (mindig)
Mit jelent az aktuális? Napi, óránkénti, percenkénti frissítést? Ha nem minden pillanatban változnak ezek akkor tudsz gyorstárazni, így a formázás költségét megspórolhatod.

(opcionális)
- felhasználó név + jelszó ellenőrzése (mindig)
ez felesleges, és kivitelezhetetlen is, vagy mindig bekéred a név jelszó párost?

Tartalom: (pl.: fórum)
- fórum cím lekérdezése
- fórum téma lekérdezése
- témának megfelelő összes fórumi hozzászólások számának lekérdezése (lapozgatáshoz)
- fórumi hozzászólások (limit-tel) lekérdezése
Itt is gyorstárazással sokat dobhatsz az ügyön, hisz csak akkor kell kidobnod a gyorstár tartalmát, ha valaki hozzászólt.

pp
4

JOIN, USING, UNION ???

jeti · 2007. Jan. 27. (Szo), 20.14
Köszönöm a válaszokat. Sajnos csak a legminimálisabb SQL parancsokat ismerem. Valaki le tudná írni, hogy kell használni az alábbi parancsokat (JOIN, USING, UNION), vagy amire még szükségem lehet.
Olvastam egy cikket, de nem világos teljesen, hogy miért jobb a második megoldás, ha az eredményen nem változtat.

SELECT szamla.szamlaszam, tetelid, cikkszam, menny, ar 
FROM szamla, tetel 
WHERE szamla.szamlaszam = tetel.szamlaszam;


SELECT szamla.szamlaszam, tetelid, cikkszam, menny, ar 
FROM szamla 
JOIN tetel 
WHERE szamla.szamlaszam = tetel.szamlaszam;
Ezeket ha ügyes vagy akkor 1 lekérdezésbe gyúrhatod. A felhasználó utolsó bejelentkezésének dátuma meg fog egyezni a session indításának idejével.


pp: Hogy tudom egybe gyúrni? Egy lekérdezéssel lehet több adatot is módosítani? (Az egy lekérdezés az ugye az első pontosvesszőig tartó parancs?)
6

Nem tudok egyszerűen válaszolni a kérdésedre

pp · 2007. Jan. 27. (Szo), 21.03
pp: Hogy tudom egybe gyúrni? Egy lekérdezéssel lehet több adatot is módosítani? (Az egy lekérdezés az ugye az első pontosvesszőig tartó parancs?)


Pontatlanul fogalmaztam. Egy lekérdezéssel (update) egy tábla mezőit tudod változtatni, de nem biztos, hogy szükséges a user tábla utolso_aktivitas és a session tábla utolso_aktivitas mezőjét külön külön updete-lned, hisz valószínűleg a session táblában tárolod azt, hogy melyik felasználóhoz tartozik a session (user_id pl). Ekkor a két mező adata meg fog egyezni, tehát felesleges külön tárolnod.

Jelentős sebesség növekedést lehet elérni, ha az egész user objektumodat a felhasználó különböző adataival, jogaival, mindennel együtt serializálva tárolod az adatbázisba, kvázi gyorstárazod a felhasználóhoz tartozó adatokat. Ilyenkor nagymértékben elbonyolítod a dolgodat, hisz figyelned kell arra, hogy ha a felhasználó adataiban változás történi, akkor azt mindig újra töltsed.

De a téma ugye az volt, hogy hogyan tudod csökkenteni az adatbázis műveleteket, hát úgy, hogy csökkented őket ;) a feleslegeseket elhagyon, amit lehet összevonsz és gyorstárazol.

Ajánlom keress rá az "adatbázis tervezés", "normál forma" "sql lekérés optimalizálás" "sql sebesség növelés" szókapcsolatokra. Fontos, hogy nem csak az adatbázis műveletek (mysql_query függvényhívások) számát kell csökkentened, hanem magukat az sql lekérdezéseket is optimalizálnod kell, valamint nem árt, ha az adatbázisod sem egy szemétdomb és van benne pár jól elhelyezett index ;)

mondjuk elsőre ezt találtam:
http://www.agt.bme.hu/szakm/adatb/adatb.htm

meg itt van ez is:
www.freeweb.hu/jataka/sala/sqlopt.pdf

Mivel elég általános kérdést tettél fel nehéz segíteni az elindulásban, de azért remélem sikerült.

pp
10

Köszönet

jeti · 2007. Jan. 28. (V), 13.59
Nincsenek meg az alapok, ezért kérdeztem általánosan. Pont ilyen alapvető dolgokra van szükségem, mint ami a belinkelt cikkekben vannak. Köszönöm a segítséget.

Igen, már tudom is, hogy fogom megoldani. A munkamenet függvényben tárolom a felhasználó nevet (mint eddig is), és a jelszót, amelyek csak akkor kerül be, ha hitelesítette magát (bejelentkezett). Tehát nem fogom minden egyes esetben leellenőrizni, csak ahol más jogosultság szükséges. A cookie-ba beteszem a felhasználó nevet, és a jelszót is szórva, ha előzőleg bejelölte a „jegyezz meg” stb. négyzetet.
Ha a munkamenet azonosító megérett a törlésre, vagy kijelentkezik, akkor a munkamenet alapján módosítom az utolsó bejelentkezés időpontját.
5

Gyorstárazás

jeti · 2007. Jan. 27. (Szo), 20.34
A gyorstárazás alatt mi értesz pontosan? Állítsak be egy megadott lejárati dátumot, és ha az utolsó látogatás időpontja óta nem történt változás, akkor töltse be a gyorstárból? Ezt hogy lehet befolyásolni, ez nem a böngésző feladata? Ha túl hosszú lejáratot adok meg, akkor a változás után, hogy értesítem a böngészőt, hogy látogassa már meg a szervert, és ne gépről töltse be az oldalt?
7

Gyorsítótár egy módszer amit nem csak böngészők használn

pp · 2007. Jan. 27. (Szo), 21.13
Az adat előállításának idejét tudjuk csökkenteni vele. Több helyen alkalmazhatjuk. Pl a webalkalmazásod összerak egy bonyolult menüt, amit minden oldalon megjelenítesz. Ezt nem kell mindig összeraknod, minden lekérésnél végrehajtanod a millió adatbázis műveletet, hanem egyszer összerakod és szépen eltárolod az adatbázisba. Legközelebb megvizsgálod, hogy van-e már ilyen menü összeállításod, ha van akkor szépen kiírod azt, ha nincs előállítod és beteszed a gyorstárba. Ha változott a menü, akkor természetesen törölnöd kell a gyorsítótárból is, hisz akkor már nem egy jó összeállítást tartalmaz a gyorsítótár.
Azért vettem példának a menüt, mert az általában jóval ritkábban változik, mint ahányszor megnézik. Tehát érdemes a hosszú összerakási időt megspórólni és kiváltani egy egyszerű lekérdezéssel.

Tehát a gyorstárazás az egy technika amivel gyorsítani tudjuk az adatok előállítását úgy, hogy ha már egyszer előállítottuk akkor eltároljuk és a lekérésekkor ezt a tárolt változatot adjuk vissza. Persze ezt a technikát csak körültekintően lehet használni, hisz számos olyan új kérdést vet fel a használata ami "normál" működésnél nem jönne elő.

Remélem érthető voltam ;))
8

Körültekintően ...

Max Logan · 2007. Jan. 27. (Szo), 21.33
Persze ezt a technikát csak körültekintően lehet használni, hisz számos olyan új kérdést vet fel a használata ami "normál" működésnél nem jönne elő.

Például?
9

cache lejárata

gex · 2007. Jan. 27. (Szo), 22.01
pl: mikor törlöd a cache-t, amikor eltelik x idő, vagy egy esemény hatására...
12

Elévül az adata a cache-ben

pp · 2007. Jan. 28. (V), 19.27
Felhasználó belép, lekéred mely csoportokba tartozik, meg mindenféle infót róla, hogy ne kelljen mindig ezeket előállítanod. Amikor egy olyan felhasználót beteszel egy csoportba aki be van jelentkezve, akkor ez csak akkor fog érvényre jutni, ha kijelentkezik és újra bejelnetkezik, vagy törlöd a gyorstárból ezeket az adatokat, kikényszerítve az újboli előállítást.
Ez a probléma nem jön elő, ha nem használsz gyorsítótárat. Olyankor csak fogod és bedobod a megfelelő csoportba a juzert és már működik is minden.
Mivel a változtatás és a felhasználás két külön helyen van a kódban ezért mondom, hogy oda kell figyelni a használatra, és körültekintően kell használni.
13

konkurencia

Hodicska Gergely · 2007. Jan. 29. (H), 03.07
Például?
Cache használata esetén érdekes lehet a konkurencia kérdésköre. Elévül a cache, és beesik egyszerre több kérés. Ha mindegyik csak egyszerűen elkedene írni egy megadott nevű fájlt, akkor abból gond adódhat. Ezen és hasonló problémák kezelését meg kell oldani.


Üdv,
Felhő
11

fájlba?

jeti · 2007. Jan. 28. (V), 14.47
Ez nagyon jó ötlet. Az olyan adatokat, amit én határozok meg (nem a látogató), azokat előre le tudnám gyártani. Pl.: a fórumok listái, a vicc kategóriák stb.
Úgy képzelem el, hogy fájlokba kiírom az adatokat, és azt csak egyszerűen beolvasnám. (include) Ha nem létezik a megadott fájl, akkor létre hozza. A webes felületről egy jelszóval tudnám törölni egyszerre mindegyiket. (Ha valaki megszerzi a jelszó, akkor mégse tud kárt okozni, csak maximum lassítani az oldal előállítását. De ezt persze úgyis naplózni fogom.) Ez a kézi megoldás. Az automatikus mondjuk, az lenne, hogy naponta egy időzített php program megnézi, hogy történt-e változás.
Ezeket csak azért írom le, hogyha valamit nagyon félreértelmezek, akkor tudjatok szólni. :-)