Hatékony gyorsítótár használata legrövidebb utak kereséséhez

1. Hatékony gyorsítótárhasználata legrövidebb utak kereséséhez BodnárIstván, Fodor Krisztián, Gyimesi Gábor JeppeRishede Thomsen, Man Lung Yiu, Christian S. Jensen. 2012. Effective Caching of Shortest Paths for Location-Based Services. http://www4.comp.polyu.edu.hk/~csmlyiu/conf/SIGMOD12_spcache.pdf

2. Gyorsítótár (cache) Webes keresések a mindennapok részét képezik. Rengeteg kérés a szerverek felé. Sok részben vagy teljes egészében azonos kérés. Megoldás: gyorsítótár A tárolt adatokat visszaadhatjuk „azonnal” a szerver kihagyásával. Jelenleg nincs hatékony megoldás az útkeresések eredményeinek gyorsítótárazására.

3. A webes és az útvonal keresés gyorsítótárazásának meghatározó különbségei Pontos egyezés vs. Részút egyezés Webes lekérdezéseknél ritkán kapjuk vissza ugyanazt az eredmény különböző kulcsszóra. Útvonal keresésnél nem szabad figyelmen kívül hagyni a részútvonalakat. (<v1, v3, v4, v5, v7>) Gyorsítótárfelépítése Web keresésnél általában hasító táblát használnak. Gyors elérés. Hasítással nem lehet megtalálni a részutakat. <v1, v3, v4, v5, v7>, <v2, v3, v4, v5, v6> Ki kell használni az esetleges átfedéseket. Szükséges egy speciális struktúra kialakítása. Lekérdezés költsége Ha nem találjuk a gyorsítótárbana keresett útvonalat, akkor meg kell hívnunk egy kereső algoritmust. Egyes lekérdezések költsége nagyobb mint másoké. Jelenlegi ismereteink alapján nem tudjuk meghatározni két pont közötti legrövidebb út várható költséget.

4. Célkitűzések Modell kialakítása a gyorsítótárazásból fakadó előny felmérésére. Statisztikák előállítása a naplófájlokból. Ennek segítségével megbecsülhetővé válik a legrövidebb utak számítási költsége. Olyan algoritmus tervezése, amely eldönti, hogy milyen eredményeket érdemes eltárolnunk. Hatékony gyorsítótár szerkezet kialakítása, ami alkalmas legrövidebb utak tárolására. Felmérni a felsoroltak hatékonyságát valós adatokkal.

5. Alapfogalmak Gráf modell: Legyenegy irányítatlan gráf, ahol V a csúcsok halmaza és E a súlyozott élek halmaza. Részút: Gyorsítótár: Legyen Ψ egy gyorsítótár és β pedig a kapacitása. Ψ legrövidebb út lekérdezések eredményeit tárolja. Lekérdezési napló: Legyen QL egy naplófájl, ami időponttal ellátott lekérdezések gyűjteményét tartalmazza. Külső útkereső API (GoogleDirections).

6. Gyorsítótár modellek Dinamikus Ha nincs a keresés a gyorsítótárban, akkor lekérdezzük a szervertől, és eltároljuk. Ha megtelt, akkor a legrégebbit töröljük és az újat beírjuk (LRU). Hátrány: Költséges a folyamatos karbantartás. Statikus A leggyakoribb lekérdezéseket tartalmazza. A lekérdezés pillanatában minimális költség. Bizonyos időközönként újra kell építeni. Csak offline állapotban lehetséges az újraépítés. Nem mindig a legfrissebb adatokat tartalmazza. A lekérdezések egy kis részének lényegesen nagyobb a „népszerűsége”, mint a többinek.

7. Gyorsítótár modellek - példák a leggyakoribb. mégis jobb választás. A probléma mindkettővel: Nem veszik figyelembe a számítási költséget.

8. Hasznossági modell Mely lekérdezéseket tudunk megválaszolni –vel? Részút fogalma: lekérdezéssel mennyi költséget takaríthatunk meg? megválaszolása költséggel bír, illetve a gyakorisága. Teljes gyorsítótár hasznossága? Mi a helyzet azonos hasznosságú elemekkel?

9. Gyakoriság és költség becslése Gyakoriság Régiópár gyakoriság Particionáljuk a gráfot Táblázat felépítése Elem gyakorisága: Költség A költség erősen korrelál az út hosszával. Földrajzi koordináták alapján becsüljük a távolságot. Költség hisztogram felépítése teszt lekérdezésekkel (S darab véletlen lekérdezés, H távolság kategória)

10. Gyorsítótár előállítása • E = 1 esetén Ki kell küszöbölni a redundanciát (részutak). Méret alapú növekedés fogalmának bevezetése.

11. Algoritmus

12. Gyorsítótár struktúrája Biztosítani kell egy hatékony elérést garantáló adatszerkezetet. Építsünk egy útvonaltömböt és egy csúcslistát. Ha a két végponthoz tartozó listának a metszete nem üres, akkor biztosak lehetünk, hogy az eredményt megtaláljuk a gyorsítótárban.

13. Köszönöm a figyelmet!