Indizierung von Graphen durch häufige Subgraphen (2)

1. Indizierung von Graphen durch häufige Subgraphen (2) Maria Tsitiridou (tsitirid@informatik.hu-berlin.de) Indizieren und Anfragen von Graphen in Datenbanken Seminar, WS 2007/8 19.02.2008

2. Überblick • Einführung • d-ToleranceClosedFrequentsubGraphs (d-TCFGs) • Index-Konstruktion • Abfrage-Verarbeitung • Performanz-Bewertung • Schlussfolgerung und zukünftige Arbeiten

3. Einführung Graph: • Immer mehr Graphendatenbanken => effiziente Abfrageverarbeitung notwendig!! • Neuer effizienter Index für die Verarbeitung von Graphabfragen

4. Einführung Grundlegende Begriffe: • Größe von g size(g):= Die Anzahl der Kanten in g • Subgraph:= g Subgraph von g‘, (g Í g‘), wenn eine Subgraph-Isomorphie von g nach g‘ existiert. • FG abgeschlossen (closed):= g ist abgeschlossen, wenn Ø$g‘ÎF: g‘Ég und freq(g‘)=freq(g) • FG maximal := g ist maximal, wenn Ø$g‘ÎF : g‘Ég

5. Einführung Graph-Abfrage: • Sei D={g1,…,gn} eine Graphdatenbank • Eine Graph-Abfrage : Gegeben sei ein Graph q, finde alle giÎD so, dass gi Übergraph von q, giÊq

6. Einführung

7. Einführung

8. Einführung Bisherige Lösungen: • Filtern: Nutze einen Index um einen Teil von falschen Ergebnissen auszusortieren und erzeuge eine potentielle Antwortmenge (Kandidat) • Kandidaten-Überprüfung: Überprüfe, ob jeder Kandidat ein Übergraph von q ist. • Die Kandidaten-Menge ist kleiner als die DB => effizienter als die sequentielle Überprüfung , aber immer noch teuer!

9. Einführung FG-Index [SIGMOD07]: • wurde konstruiert auf der Basis von häufigen Subgraphen (FGs) • FG: FrequentsubGraph • g ist ein häufiger Subraph(FG), wenn g ein Subgraph von mindestens ( s|D|) Graphen in einer Datenbank D, wobei 0£s £1 • s ist ein vordefinierter Grenzwert

10. Einführung Fallunterscheidung bei der Verwendung vom FG-Index: • q ist häufiger Subgraph (FG) Antwort sofort  ohne Kandidaten-Verifikation

11. Einführung Fallunterscheidung bei der Verwendung vom FG-Index: • q ist kein häufiger Subgraph Kandidatenmenge wird erzeugt • Beachte: • q kein FG => q Subgraph von sehr wenigen Graphen in D • => Wenige Isomorphie-Tests!!

12. Einführung

13. Einführung Herausforderung: Die Menge der FGs ist groß , wenn s klein. • Viele FGs => großer Index => Hohe Zugriffskosten, wenn der Index zu groß für den Hauptspeicher=>Schlechte Abfrage-Performanz Lösung: Kompressionstechnik anwenden (d-TCFGs) • Über d die Größe des Index regeln • Jedes d-TCFG ist ein stellvertretender Übergraph von einem Cluster von FGs.

14. d-TCFGs d-TCFGs : Gegeben sei d ein benutzerdefinierter Faktor mit 0£d£1. Ein häufiger Subgraph g ist ein d-TCFG, wenn Ø$g‘ÎF : g‘Ég und freq(g‘) ³ (1-d)freq(g)

15. d-TCFGs • de= 1- freq(g‘)/ freq(g) • wenn de³ d  d-TCFG • Sonst keind-TCFG Bsp.: d=0.04 T={f1,f4,f5,f8,f9,f13}

16. Abschluß (closure) eines d-TCFGs Nächster (closest) d-TCFG Übergraph gt ist der nächste d-TCFG Übergraph von g, wenn • gt ein d-TCFG und g kein d-TCFG ist • gtÉg und Ø$g‘tÎT : g‘tÉgt

17. Abschluß (closure) eines d-TCFGs

18. Abschluß (closure) eines d-TCFGs closure eines d-TCFGs: Gegeben sei ein d-TCFG gt , CLOS(gt )={g: gt ist der nächste d-TCFG Übergraph von g } • Der nächste d-TCFG Übergraph von einem FG ist eindeutig. • Bsp.: CLOS(f13)={f7,f10, f11, f12}

19. Index-Konstruktion Invertierter Graph Index (IGI): Ein invertierter Index erstellt über eine Menge von Graphen G • Ein Hash-Index aus der Menge der eindeutigen Kanten in G • Jede Kante ist mit einer Menge von ID‘s von Graphen in G verknüpft, die die Kante enthalten. • Die ID‘s sind nach der Graphengröße weiter klassifiziert, um effiziente Suche zu erzielen

20. Index-Konstruktion Invertierter Graph Index (IGI):

21. Index-Konstruktion Zwei-Level-Index-Struktur: • Im Hauptspeicher gehalten: Ein (IGI) erstellt aus der Menge der d-TCFGs • Auf Festplatte gespeichert: Ein (IGI) erstellt aus dem Abschluss von jedem d-TCFG.

22. Vollständigkeit des Index • Der Index sollte in der Lage sein , jede Abfrage zu beantworten. • Allerdings deckt der FG-Index nur die Abfragen ab, die häufige Subgraphen sind. Edge-Index (Hash-Index) : gebildet aus der Menge der nicht-häufigen eindeutigen Kanten in der Datenbank.  Abfragen, die keine häufigen Subgraphen sind, können durch Zusammenfügen dieser Kanten beantwortet werden.

23. Abfrage-Verarbeitung Abfrage q ist ein FG • Den Hash-Index verwenden, um die Menge der Kanten von q im FG-Index zu finden • Den Durchschnitt von den Graph-ID‘s-Arrays bilden, die mit den Kanten verknüpft sind

24. Abfrage-Verarbeitung Abfrage q ist ein FG • Der erste Übergraph, den wir über den Durchschnitt erhalten, ist entweder q oder q‘s nächster d-TCFG Übergraph. • Wenn q immer noch nicht gefunden wurde  auf den verschachtelten IGI-Index von q‘s nächsten d-TCFG Übergraphen zugreifen • Wiederhole rekursiv bis q gefunden wird.

25. Abfrage-Verarbeitung Abfrage q ist kein FG • Verwende den FG-Index, um eine Menge von maximalen Subgraphen von q, Gs, zu finden. • Verwende Edge-Index, um die Menge der nicht-häufigen Kanten von q, Ge, zu finden

26. Abfrage-Verarbeitung Abfrage q ist kein FG • Man erlange die Kandidaten-Menge von q, indem man den Durchschnitt von der Antwortmenge von den Graphen in Gs und Ge bildet • Überprüfe für jeden Kandidat, ob er ein Übergraph von q ist.

27. Performanz-Bewertung Datenmengen • Reale Datenmenge: 10K Graphen einer Menge von chemischen Molekülen aus der AIDS-Forschung • Künstliche Datenmengen für Skalierbarkeits-Tests bzgl. • Datenbankgröße: von 10K bis 100K Graphen • Graphengröße: von 20 bis 100 Kanten • Graphendichte: 0.1, 0.15, 0.2

28. Performanz-Bewertung Algorithmus Vergleiche mit gIndex [YYH05] Index-Konstruktions-Performanz (reale Datenmenge) • s=0.1 , FG-Index 20 mal schneller • s=0.01, FG-Index 5 mal langsamer Grund: Bei s=0.1 : |F|= 455, während bei s=0.01 |F|=59.120.

29. Performanz-Bewertung Algorithmus Vergleiche mit gIndex [YYH05] Index-Konstruktions-Performanz (reale Datenmenge) • s=0.1 , FG-Index 20 mal schneller • s=0.01, FG-Index 5 mal langsamer Grund: Bei s=0.1 : |F|= 455, während bei s=0.01 |F|=59.120.

30. Performanz-Bewertung Abfrage-Antwortszeit(reale Datenmenge) • Qi: Menge von 1000 Abfragen • Jede Abfrage enthält i Kanten

31. Performanz-Bewertung Abfrage-Antwortszeit(reale Datenmenge) • Qi: Menge von 1000 Abfragen • Jede Abfrage enthält i Kanten

32. Performanz-Bewertung Speicherverbrauch (div. Abfrage-Größen) • Speicherverbrauch • ( FG-Index ) • gering und stabil • viel geringer als gIndex

33. Schlussfolgerung FG-Index: • Im Hauptspeicher abgelegt: • Menge der d-TCFGs • Größe gesteuert über d • auf Festplatte gespeichert: • Andere FGs (keine d-TCFGs) indiziert mit verschachtelten invertierten Indexes, die effiziente Suche erlauben.

34. Schlussfolgerung Abfrage-Verarbeitung: • Abfrage q ist FG: • Antwortmenge ohne Kandidaten-Verifikation • Abfrage q ist kein FG: • Minimale Kandidaten-Verifikation

35. Schlussfolgerung In der Zukunft: Abfrage-Verarbeitung bei großen einzelnen Graphen. • Effiziente Abfrage bei div. Sozialen Netzwerken, Web usw. • Was indizieren und wie? Ähnlichkeitssuche in Graph-Datenbanken • Exakte Übereinstimmung einschränkend f. manche Anwendungen • Ähnlichkeitsabfragen: Weglassen von manchen Kanten in der Query