Hatékony gyorsítótár használata legrövidebb

utak kereséséhezBodnár István, Fodor Krisztián, Gyimesi Gábor

Jeppe Rishede 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

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.

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ésWebes 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ár felépítéseWeb 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égeHa nem találjuk a gyorsítótárban a 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.

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.

Alapfogalmak

Gráf modell: Legyen egy 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 (Google Directions).

Gyorsítótár modellek

DinamikusHa 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.

StatikusA 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.

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.

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?

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)

Gyorsítótár előállítása

Ki kell küszöbölni a redundanciát (részutak).

Méret alapú növekedés fogalmának bevezetése.

E = 1 esetén

Algoritmus

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.

Köszönöm a figyelmet!