Adatbázis kérés eredményének előtöltése
Sziasztok!
Gondolkoztam azon, hogy hogyan lehetne egy nagyobb terhelésű oldalnál a bonyolultabb kereséseket (pl. ügyfelek különböző paraméterek alapján történő keresése) gyorsítani.
Arra gondoltam, hogy lehetne esetleg azt csinálni, hogy ha az ügyfél elindít egy keresést, akkor ha nekem az első 10 rekordra van szükségem, akkor mi lenne ha nem 10 hanem mondjuk 20-30 rekordot kérdeznék le.
Az eredmény többletet (a +10-20 rekord)pedig fognám és eltárolnám mondjuk memcache-be, session-ba, stb.
Amikor az oldalt görgeti tovább az ügyfél, és szüksége lenen a következő 10 rekordra, akkor ebben az esetben megnézném, hogy ismerem -e már a kért adatot, vagy sem.
Ha nem, akkor természetesen ugyanazt csinálnám mint az előbb.
Ha viszont ismerem, akkor minden féle (my)SQL művelet nélkül, mindenféle bonyolult SQL QUERY futtatása nélkül oda tudom adni az ügyfélnek. Miután ezt megteszem, akkor pedig valami háttér folyamatnak átadnám azt, hogy amikor van szabad kapacitás, akkor töltsön előre nekem további újabb rekordokat, hogy amikor vélhetőleg pár másodperc múlva jön az ügyfél a kéréssel, akkor már az is elő legyen költve.
Ugye fontos, hogy egy külön folyamat végezze az előtöltést, mert különben be kellene várni az előtöltés eredményét a kiszolgálás előtt.
Az érdekelne, hogy szerintetek ilyen módszerrel lehet valós teljesítménynövekedést elérni?
A másik kérdés, hogy ha ez egy járható út, akkor szerintem biztos nem én vagyok az első aki ezzel foglalkozott. Lehet hogy erre már vannak kész megoldások is. Én kerestem, de nem igazán találkoztam. Tehát a másik kérdés, hogy ilyennel már találkozott -e valaki? Ha igen, akkor hol?
Segítségeteket előre is köszönöm.
Zoli
■ Gondolkoztam azon, hogy hogyan lehetne egy nagyobb terhelésű oldalnál a bonyolultabb kereséseket (pl. ügyfelek különböző paraméterek alapján történő keresése) gyorsítani.
Arra gondoltam, hogy lehetne esetleg azt csinálni, hogy ha az ügyfél elindít egy keresést, akkor ha nekem az első 10 rekordra van szükségem, akkor mi lenne ha nem 10 hanem mondjuk 20-30 rekordot kérdeznék le.
Az eredmény többletet (a +10-20 rekord)pedig fognám és eltárolnám mondjuk memcache-be, session-ba, stb.
Amikor az oldalt görgeti tovább az ügyfél, és szüksége lenen a következő 10 rekordra, akkor ebben az esetben megnézném, hogy ismerem -e már a kért adatot, vagy sem.
Ha nem, akkor természetesen ugyanazt csinálnám mint az előbb.
Ha viszont ismerem, akkor minden féle (my)SQL művelet nélkül, mindenféle bonyolult SQL QUERY futtatása nélkül oda tudom adni az ügyfélnek. Miután ezt megteszem, akkor pedig valami háttér folyamatnak átadnám azt, hogy amikor van szabad kapacitás, akkor töltsön előre nekem további újabb rekordokat, hogy amikor vélhetőleg pár másodperc múlva jön az ügyfél a kéréssel, akkor már az is elő legyen költve.
Ugye fontos, hogy egy külön folyamat végezze az előtöltést, mert különben be kellene várni az előtöltés eredményét a kiszolgálás előtt.
Az érdekelne, hogy szerintetek ilyen módszerrel lehet valós teljesítménynövekedést elérni?
A másik kérdés, hogy ha ez egy járható út, akkor szerintem biztos nem én vagyok az első aki ezzel foglalkozott. Lehet hogy erre már vannak kész megoldások is. Én kerestem, de nem igazán találkoztam. Tehát a másik kérdés, hogy ilyennel már találkozott -e valaki? Ha igen, akkor hol?
Segítségeteket előre is köszönöm.
Zoli
Ennyi erővel ki is küldhetnéd
Másrészt érdemes előbb feltérképezni, hogyan használják a keresőt, az is lehet, hogy a legtöbb esetben az első tízben megtalálják a szívük vágyát, és akkor nem kell csinálni semmit.
Szia! Köszi a
Köszi a választ.
Valóban ez egy előre gondolkodás csak, mert tényleg majd a használat nagyon sok mindent eldőlt.
Csak ha véletlen valaki hallott már ilyenről, vagy hasonló kész megoldásról, akkor inkább azt tanulmányozza az ember, mint nulláról próbálja végigjátszani.
Ez a kis szám amúgy csak a példa kedvéért volt. Természetesen sokkal nagyobb számokról lenne szó, és nem is feltétlen a teljes adatsor lenne betárazva, hanem csak mondjuk az ID-k. Azt gondoltam, hogy ha 10 helyett egyszerre 30-40 rekordot kérek egy összetett SQL-ből, és azt nem is feltétlen minden mozzanattál tölteném elő (lehet minden 2. 3. alkalommal töltenék csak elő adatot), akkor az jóval kevesebb erőforrásba és jóval gyorsabb működést eredményez, ha az oldal működése modellje miatt az ügyfelek folyamatosan kattogtatni fognak mint az állat.
Abból indultam ki, hogy a szűrés az lehet hogy egy kritikus pont (mert az oldal működése modellje miatt az ügyfelek folyamatosan kattogtatni fognak mint az állat), ahol különböző tulajdonságok szerinti szűrés egy lassabb működést okozhat.
Azt gondoltam, hogy ha 10 helyett egyszerre 30-50 rekordot kérek egy összetett, bonyolult SQL-ből, valamint az a tény, hogy nem is biztos, hogy minden szerver kéréskor rögtön fontos a tárat utántölteni (lehet minden 2. 3. alkalommal töltenék csak elő adatot), akkor az jóval kevesebb erőforrásba kerül és jóval gyorsabb működést eredményezhet.
Természetesen ha a keresett ügyfelek, vagy termékek (stb.) előre lennének tárazva (csak az ID lenne előtárazva), akkor ilyenkor már csak a jól indexelt ID alapján kell kikeresni, és kiírni az adatokat az ügyfél képernyőjére.
Mondhatnám ez lenne az elméletem, ami persze lehet hibás, de az is lehet, hogy létezik már kész megoldás is ilyenre, vagy hasonlóra.
Kicsit olyan mint CPU, HDD, stb. esetén amikor megpróbálja az adott rendszer megjósolni, hogy mi lesz a következő szükséges adat, és azt előkészítni/előtölti.
Gyorsítótár
Poetro! Nem jártam utána
Nem jártam utána annyira a dolognak. Tudom, hogy van a pl. a mySQL-nek is gyorsítótára, csak azt nem tudom, hogy ott a már lekérdezett adatokat lehet újra visszaolvasni gyorsabban, vagy valóban akár előre is olvas, hátha kell még rekord az elsőre lekért 10-en túl is.
Bár ha nem olvas előre, akkor is lehet ki lehet kényszeríteni, ha jegyzem, meddig kértem le, és időnként többet kérdezek annak érdekében, hogy azt előtárazza a mySQL.
Amúgy a meglátásod jogos. Nagyon könnyű gyorsítótárazni, de egy jó gyorsítótárnak tudnia kell azt is mikor érdemes az adatokat dobni. Ezért érdekelne, hogy hátha valaki látott már valamilyen kész megoldást.
Ha olyan bonyolult a
Jó indexek elhelyezésével szerintem többet lehet nyerni teljesítményben. Ha az előző példánál maradunk: ha a feltétel elsődleges kulcsra vonatkozik, akkor pl rendezni sem kell(!), hiszen fizikailag rendezett. Ha másodlagos indexet használsz, akkor is csak az indexeket kell beolvasni, magukat a rekordokat nem (ez is sokat tud dobni rajta).
Előre optimalizálás
Ahogy Poetro írja a 3-asban, először érdemes az adatbázis gyorstárait belőni. Az innodb pool nem dedikált szerver esetén a teljes memória 50%-a lehet, továbbá lehet játszani a query cache-sel, bár ez csak akkor hatékony, ha viszonylag kevés lekérdezést használnak véges időn belül.
Ha sok adattal dolgoztok, a rendezéshez használt puffermérettel is lehet próbálkozni, bár ezzel eléggé el lehet szállni (ha gyakoriak a lekérdezések, sok memóriát eszik).
Emellett azt is meg kell nézni az
EXPLAINsegítségével, hogy a táblák rendesen be vannak-e indexelve.Ha izzad a vas, a mai árak mellett előbb érdemes annyi memóriát tömni a szerverbe, amennyit csak elbír, aztán szabad csak bármilyen fejlesztést elkezdeni.
Létezik ez a nagy terheltségű
Viszont ha mégis valós a gond, akkor írhatsz egy daemon-t mondjuk PHP-ban, ami bizonyos paraméterek alapján feltölti a cache-t. Ha a felhasználód elkezd keresni, eljut az első oldalra, a háttérben küldesz egy parancsot a daemon-nak a keresés fontosabb paramétereivel, hogy töltse be memcache-be a következő oldalak eredményeit.
php daemon
Köszönöm
Lehet nem derült teljesen ki, de nem feltétlenül ennek kifejlesztésével szeretném tölteni az időt, mert tényleg nagyon sok nyitott kérdés van, hogy az esetleges előnyök mellett nehogy több hátrány legyen belőle.
Az elgondolás abból jött, hogy összetett keresésnél már most az elején van egy kritikusabb pont (ami nagyságrendekkel lassabban fog futni mint más), és ha van valahol már egy kész kidolgozott eljárás a neten, akkor miért ne készülhetnék fel az adott rész a tehermentesítésére.
Tehát nem feltétlen az a cél, hogy most erre egy külön fejlesztést induljon a nulláról. Nem azzal szeretném az időt tölteni, hogy tesztelve legyen mi a jó megoldás. Külön daemon dolgozzon -e alá, vagy elég ha minden 4., 5. lekérdezéskor 10 helyett 40-50 rekordot kérek le (mert ezzel minimálisan növekedik csak a futásidő), és cserébe a következő 4-5 kéréskor 3km hosszú SQL helyett csak egy egyszerű SQL kell csak használnom amibe memcache-ból beleírom azt a 10 profil ID-t amire kíváncsi vagyok...
A rendszer még a végleges specifikáció lezárása előtt van, és ha létezik elérhető kész megoldás ami nem hátráltatja a fejlesztést, akkor miért ne tenném bele mint megoldandó feladat (legyen az a megoldás beleépítése, vagy az, hogy eleve tudja egy mozdulattal fogadni azt).
Ezért volt az eredeti kérdés inkább az, hogy ismer -e valaki olyan kész projectet a neten, amit szabadon, vagy akár fizetősen fel lehet használni a leírt problémára ha az bekövetkezne.
Azt láttam neten, hogy nem én vagyok az első akinek mindez eszébe jutott.
Optimalizálás