Efficient Keyword Search over Virtual XML Views

1. Efficient Keyword Search over Virtual XML Views Feng Shao Lin Guo Chavadar Botev Anand Bhaskar Muthiah Chettiar Fan Yang

2. רקע: מהו XML? • מסמך XML מורכב מאלמנטים מקוננים, החל באלמנט השורש • כל אלמנט יכול להכיל תכונות וערכים • ניקוד לשאילתה המבוצעת על מסמך XML יוחזר עבור כל אלמנט ואלמנט, ולא עבור כל המסמך • - במסמך זה נתייחס לניקוד לפי שיטת TF-IDF: • tf(e,k) – מספר המופעים של מילת המפתח k באלמנט e וצאצאיו • - יחס מספר האלמנטיםב view למספר האלמנטים שמכילים את k

3. Dewey ID – שיטת מספור לאלמנטים בה המספור של האלמנטים הינו היררכי כך ש ID של אלמנט מסויים מכיל את ה ID של אביו בתור prefix

4. רקע: מהו View? • View הוא טבלה וירטואלית, המוגדרת בעזרת שאילתה. • דומה מאוד לטבלה אמיתית, מלבד העובדה שהוא לא שומר מידע • הנתונים שבו מחושבים דינאמית כאשר פונים אליו • עלות גבוהה של זמן חישוב ושל משאבי חישוב בעת חישוב שאילתות מעל views

5. הצגת הבעיה • הבעיה הינה בעת חיפוש ב view לפי keyword, פעולה זו יקרה בגלל ההנחה שמבצעים חיפוש על דף "מוכן" • בשביל לבצע את החיפוש, דרוש מימוש ה view. זה יקח זמן רב. • מפריע במיוחד בעת ביצוע פעולות בזמן אמת • בד"כ מחזירים את K הערכים הטובים ביותר, וכדי לעשות את זה צריך לתת ניקוד למסמך (לדוגמה TF-IDF). הניקוד דורש מסמך ממשי. View איננו כזה, ומימוש כולו רק לשם הצגת K ערכים יקר ובזבזני • המאמר מציג דרך לחיפוש יעיל מעל views ב XML, והחזרת K הערכים הטובים (בהתאם לשיטת הניקוד)

6. דוגמה שילוב מידע אתר מסויים שומר מידע על ספרים, אתר שני על ביקורות לספרים. נרצה לאחד בין ספר לביקורות עליו ולבצע שאילתות על התוצאה המתקבלת

7. יצירת ה view והכנסת השאילתה ע"י XQuery

8. הגדרה פורמלית לבעיה עבור שאילתה: • מבט V • ומסד נתונים D • תוצאת החיפוש ע"פ keywords היא הסדרה s כך ש: • כל אלמנט ב s הוא אלמנט ב view • עבור כל אלמנט e ב s, וכל מילת חיפוש q ב Q: e מכיל את q • לכל אלמנט e ב view, אם הוא מכיל את כל s מכיל את e • הערה: s מכיל את k התוצאות בעלות הניקוד הגבוה ביותר

9. רעיון הפתרון המרכזי שימוש באינדקסים המבוססים על נתוני הבסיס נחשב את השאילתה מעל הנתונים הדרושים בלבד, ולא מעל כל ה view

10. האינדקסים הקיימים • Inverted list index - משמש לביצוע חיפוש לפי keywords • path index – משמש להערכת נתיב ב XML

11. מהן הבעיות העומדות בפנינו? • כיצד פותחים במדויק את השדות שדרושים לנו, בלי לפתוח את כל המסד? • כיצד נותנים ניקוד לכל מסמך בשאילתה שנבצע על ה view, כך שהתוצאות תהיינה זהות למצב בו מימשנו את ה view וחיפשנו בו?

12. האלגוריתם המוצע מורכב משלושה שלבים: • יצירת QPT (query pattern tree) – עץ אשר מייצג במדוייק אילו חלקים מנתוני הבסיס דרושים לחישוב התוצאה הפוטנציאלית. לשם יצירתו, האלגוריתם מנתח את הגדרת ה view ואת ה keywords מהשאילתה. • מחושב עבור כל מסמך XML בנפרד • יצירת PDT – pruned document tree - מכיל חלקים קטנים מנתוני הבסיס. חלקים אלו הם החלקים הדרושים לשם מענה על השאילתה, לפי ה QPT שחושב בשלב הקודם. ה PDT נבנה אך ורק ע"י אינדקסים, ללא כל גישה למסד הבסיס. • כמו כן, בשלב זה נשמרות סטטיסטיקות לגבי ה keywords. • מחושב עבור כל מסמך XML בנפרד • פיתוח השאילתה מעל ה PDT (במקום מעל ה view) ומימוש K התוצאות הטובות ביותר. • זה השלב היחיד בו יש גישה לנתוני הבסיס, וגם היא, רק עבור מי שמחזיר את K התוצאות הטובות ביותר.

13. PDT תואם עבור כל QPT • מכיל רק אלמנטים שמתאימים לצמתים ב QPT • מכיל רק ערכים שהכרחיים בעת הערכת השאילתה

14. תרשים המערכת • QPT מזהה בדיוק את החלקים הדרושים לביצוע השאילתה ומשכתב את השאילתה המקוריתכך שתיקרא מה PDT ולא מנתוני המקור • אין כל שינוי ל query evaluator. השאילתה המשוכתבת מוערכת על ה PDT • התוצאות מקבלות ניקוד, ורק אלו עם התוצאות הגבוהות ביותר ממומשות

15. מבנה ה QPT • קו רגיל – אב/בן • קו כפול – צאצא/אב קדמון • קו מקווקו – קשר אופציונאלי • קו רציף – קשר הכרחי • לצמתים יכולה להיות תכונה • V – דרוש ליצירת ה view • C – שייך לפלט ה view, משתמשים בו רק בזמן המימוש

16. 3 האילוצים של ה PDT • אלמנט e במסמך, שתואם לצומת n ב QPT, ייבחר ל PDT רק אם יעמוד בשלושת האילוצים הבאים: • Ancestor constraint – אלמנט שהוא אב קדמון של e, שתואם לאביו של n ב QPT, ייבחר גם הוא • Descendant constraint – עבור כל קשת חובה בין n לעבר בנו, לפחות אלמנט ילד או צאצא אחד של n ייבחר גם הוא • Predicate constraint - אם e עלה, הוא יעמוד בכל התכונות הדרושות

17. PDT – הגדרה פורמלית

20. האלגוריתם המוצע • מאופיין ע"י: • מספר ה lookups באינדקסים פרופורציוני לגודל השאילתה ולא לנתוני הבסיס

21. אלגוריתם Prepare Lists • מטרתו: הכנת רשימות של dewey ID’s ושל ערכי האלמנטים הדרושים ל PDT: • - ערכים שאין חובה שיהיה להם בן • - ערכי V • תחילה נעשה lookup לצמתי QPT שאין חובה שיהיה להם בן (כולל עלים). הם יכולים להיות ב PDT מבלי למלא את דרישת ה descendant (למעשה ממלאים אותה באופן ריק). • אם האלמנט מקושר ב QPT עם תכונה (predicat) – נחפש רק אלמנטים שמקיימים את התכונה • נעשה lookups נפרדים עבור צמתי V annotation (ניתן לשלב עם ה lookups הקודמים) • ב lookups נקבל את הרשימות עבור כל בעל המסלול אותו נחפש. נמזג את הרשימות ונקבל רשימה ממוזגת וממוינת לפי dewey ID, המקשרת לכל ID את הערך שלו (כאשר קיים ערך) • (לדוגמה, נקבל רשימה ממוזגת עבור books//book/isbn) • לבסוף, עוברים על ה inverted index לקבלת tf עבור הניקוד

22. עבור books נקבל:

24. יצירת ה PDT • האלגוריתם עושה מעבר מיזוג יחיד על הרשימות שהכנו ב prepareLists, ומייצר את ה PDT • ה PDT ישמור על תנאי descendant/ancestor ויכיל אלמנטים וערכים (כפי שהשגנו ב preparedLists) ו tf עבור ה keywords • הרעיון המרכזי: עיבוד האלמנטים לפי סדר ה dewey ID • - יעיל עבור דרישת ה descendant

25. CT.MinIDPath – האלמנט המתאים ל ID המינימלי ואבותיו הקדומים

26. פונקציית AddCTNode • Candidate tree: כל צומת cn בעץ זה מכיל מספיק מידע כדי לבדוק דרישות descendant/ancestore • ID – מזהה ייחודי לצומת. Prefix של Dewey ID ב pathLists • QNode – הצומת התואם ב QPT • PL – ancestors של הצומת כך שה QNode שלהם הוא אביו של cn • DM – ממפה כל בן/צאצא חובה ל 1 אם הוא קיים, 0 אם לא • PdtCache – צאצאי cn שמספקים את דרישת descendant אבל עדיין יש לבדוק את דרישת ה ancestor

29. הלולאה הראשית באלגוריתם • מוסיפה ID’s חדשים ל CT (לפי pathlists) • מייצרת בעזרת צמתי CT את צמתי ה PDT • תמיד נשמר העיקרון שכל צומת שעיבדנו וידוע שהוא צומת ב PDT, יהיה או ב CT או ב PDT התוצאה

30. שלושת הצעדים בלולאה הראשית • הוספת ה ID המינימלי הבא ב pathlists ל CT • העתקת ה ID’s ב minIDPath (ID מינימלי וה ancestor שלו) מהשורש כלפי מטה ל PDT הסופי או ל PDT cache • מחיקת הצמתים ב minIDpath שאין להם ילדים

31. צעד 1 הוספת ה ID המינימלי הבא ב pathlists ל CT

32. צעד 2 שימוש בצמתי CTב CT.minIDPath ליצירת צמתי PDT באופן כללי, ה PDTCache של צומת CT מכיל id’s של צאצאים המקיימים את דרישת ה descendant

33. כעת נלך מהעלים לכיוון השורש, ו"נקפל" צמתים * לדוגמה, אחרי שנקפל את isbn ואת title, נקפל את book 1.1 כי אין לו ילדים והוא לא מקיים את דרישת descendant (אין לו year) צעד 3 • כיוון שמעבדים צמתים לפי dewey ID, דרישת descendant לעולם לא תמולא בעתיד • * כל מי שנמצא ב PDT cache של השורש, עובר ל PDT התוצאה

34. לפני שמוחקים צומת, יש להתייחס ל PDT cache שלו - לדוגמה, isbn, title נמצאים ב PdtCache לכן מקיימים דרישת descendant - צריך לבדוק האם הם מקיימים דרישת ancestor - נבדוק את ה Parent List שלהם - הצמתים הרשומים שם, ידוע לגביהם שהם לא צמתי PDT. לכן אפשר להוציאן מה cache - אחרת, נעביר את הצמתים ל PDT Cache של האב - לדוגמה, הסרת book 1.2: כשנסיר את book, כל מי שב cache שלו יועבר ל PDT הסופי

36. ניקוד • tf עבור כל keyword, כאמור, נשמר ב pdt • בעזרת tf ניתן לחשב את ערך tf-idf עבור כל אלמנט ב PDT • נחשב את k התוצאות הטובות ביותר, ונממש רק אותן

37. הרחבות ואופטימיזציות • האלגוריתם תמיד שם את מי שממלא תנאי descendant ב PDTCache • - ניתן לשפר את זה ע"י כך שמי שממלא גם תנאי ancestor, יכנס ישירות ל PDT הסופי • - לשם כך, נוסיף דגל InPdt לצומת ה CT • - נקבע את הדגל ל 1 כאשר הצומת יכנס ל PDT הסופי • - בנים יכנסו ל PDT הסופי כאשר לאחד מהוריהם InPdt = 1 • כשיש טאג-ים בשמות שחוזרים על עצמם, Dewey ID יכול להתאים לכמה צמתי QPT • - לדוגמה, אם ב QPT יש “//a//a” והנתיב המלא התואם הוא “/a/a/a”, ה a השני מתאים לשני הצמתים ב QPT • - כדי לפתור זאת, ניתן לשמור בצומת CT במקום את ה QNode התואם, אוסף של כל ה QNodes שיכולים להיות תואמים, לכל אחד מהם את ה Parent List ו DescendantMap שלו

38. ניסויים לשם בדיקה, השתמשו בנתונים בגודל 500MB לקחו articles ושמו אותם מתחת ל authors (au) שלהם מעבד 3.4GHZ, זיכרון 2MB Windows XP

41. # of keywords

43. סיכום • בניית מערכת אשר מבצעת חיפוש מעל xml views וירטואלים • אלגוריתם ייחודי לשימוש במידע חלקי בלבד הרלוונטי לשאילתה ול view • נבדק בניסוי והתגלו תוצאות מהירות ביותר מאשר פי 10 מאלטרנטיבות אחרות

44. תודה רבה!