איך מתבצע JOIN בפועל - חלק 2
פרקי ההרצאה: איך מתבצע JOIN בפועל - חלק 2
תמלול ההרצאה: איך מתבצע JOIN בפועל - חלק 2
הטקסט המלא של הדקות הראשונות בהרצאה «איך מתבצע JOIN בפועל - חלק 2» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, בשיעור אלה היום נכיר אלגוריתם חדש שהדאטאבס משתמש בו על מנת לבצע ג'וין בין שתי טבלאות על בסיס עמודה משותפת. נזכיר ונאמר שבשיעור האחרון התמודדנו מול אלגוריתם קודם של נסטדלופ, בנסטדלופ הדאטאבס בוחר להשתמש כאשר מדובר בטבלאות שאינן מאונדקסות, טבלאות שאינן ממויינות ולכן לא ניתן להשתמש במיון על מנת לבצע את join ביניהם.
יצרנו טבלה בשם itable for nested לו ומכיוון שאינה ממויינת ואין בגינה שום אינדקס אז הדאטאבס בחר להשתמש ב-join שיש בו overhead גדול מאוד כיוון שהוא צורך מעבר על שתי הטבלאות זו כפול זו אולם אין לו ברירה מאחר שטבלה זו לא הייתה ממויינת כאשר בחרנו
לעבוד עם טבלאות ממויינות טבלת employees וטבלת orders שתיהן ממויינות בגין העמודה employeeid בעוד שב-employees employeeid הוא קלאסטרד אינדקס כלומר הוא ממויין ומכיל את כל הנתונים בגינותה שורה.
בטבלת orders employeeid יש אינדקס בגינו ולכן הוא ממויין לפי העמודה employeeid אולם עדיין זה לא קלאסטרד אינדקס ובכל זאת כאשר שניהם ממויינים הדאטאבייס מנצל את המיון הזה בין הטבלאות ועובד לפי האלגוריתם של מרג' לופ מיזוג על פי תוך שימוש במיון של שתי הטבלאות.
בשיעור הזה אנחנו רוצים להכיר את האלגוריתם של האש ג'וין אותו אנחנו נראה בדוגמה הבאה. שימו לב בדוגמה שלפנינו האש ג'וין בין שתי טבלאות מימין אנחנו רואים טבלה קטנה כאשר משמאל אנחנו רואים טבלה קטנה יותר בה יש שלוש מפתחות אותה אנחנו עושים לג'וין עם טבלה רחבה יותר בגין הערכים הללו אנחנו
יכולים לראות כאן שיש לנו הרבה הרבה יותר שורות ביחס לטבלה השמאלית וביניהם אנחנו מבצעים כרגע האש ג'וין מהו האש ג'וין כיצד הוא מתבצע כיצד הוא עוזר לי לשפר ביצועים את זה אנחנו נראה בדקות הקרובות דבר ראשון שהדאטאבס יוצר באלגוריתם של האש ג'וין זו טבלה טבלה שנקראת hash table,
hash table מורכבת כפי שאנחנו יכולים להבין מאינדקסים של הערכים של הטבלה הקטנה. אנחנו יכולים לראות כאן שבגין כל כניסה ב-hash table שמתנהג כמו מערך, תיווצר לנו שורה מתוך הטבלה הקטנה על בסיס פונקציה של hash function, כל שורה כאן מתורגמת לערך בתוך הטבלת hash table.
כבר שגמרנו להמיר את כל השורות מתוך הטבלה הקטנה ונתנו להם אינדקסים על בסיס המפתח של ה-Hash Function אנחנו יכולים כבר להתקדם לטבלה הגדולה יותר.
לטבלה הגדולה יותר ברגע שאנחנו נפעיל עליה שוב פעם את הפונקציה של ה-Hash Function אנחנו נגיע בגישה ישירה למקום הרלוונטי והמתאים בטבלה ועם מקום מספר 2 הערך 2 בטבלה הממוזגת השנייה הגדולה על ידי שימוש ב-hash function אנחנו נגיע בדיוק לאותו אותה שיכוון
אותנו לערך של 2 בטבלה שאיתה אנחנו מבצעים join כנ"ל לגבי 2 כנ"ל לגבי 3 לגבי כל אחד ואחד מהערכים שלי גם אחד ברגע שאנחנו נפעיל עליהם את הפונקציה של ה-hash function אנחנו נגיע בגישה ישירה למקום שבו כרגע שמור לנו הערך מתוך הטבלה שאיתה אנחנו מבצעים join.
בואו נראה כיצד הדברים הללו עובדים בפועל, נחזור לתוך הsql server. אנחנו כאמור מדברים כאן על hash join ונריץ את אותה שאילתה כפי שיצרנו אותה מקודם, כפי שיצרנו ב-merge-loop אולם עם שינוי קטן.
שימו לב לדוגמה הבאה: Select first name, seek last name, seek city. נוסיף גם את region כפי שציינו אבל אנחנו מוסיפים כאן עמודה נוספת.
בתרגול הקודם אנחנו בחרנו עמודות רק מטבלת employees שכפי שאני ציינתי היא מאונדקסת אבל כ-clustered index. כאן אנחנו בוחרים גם נתונים מתוך טבלת orders.
נבחר את order day אפשר גם להוסיף את order ID אבל once בחרנו מספיק עמודה אחת מתוך orders שזו טבלה גדולה מאוד. והיא כבר לא מאונדקסת כ-clustered index, כלומר שהמידע נמצא לי ב-cash שאני יכול כבר להביא אותו.
כאן כבר אנחנו נגלה להפתעתנו דבר אחר. From employees orders where employees.employeeid שווה ל-orders.employeeid השאילתה לפנינו השאילתה מוכנה שימו לב היא זהה לחלוטין לשאילתה שראינו בה מרג'לו.
אולם כאן אנחנו הוספנו שתי עמודות שהן מתוך טבלת orders. זו טבלה גדולה וזה דבר אחד ודבר נוסף שמאפיין אותה ששני הנתונים הללו אינם כרגע כ-clustered index כלומר הם לא נמצאים ב-clustered index לפי Employee ID ולכן אנחנו נדרשים ללכת ולהביא אותם מתוך הטבלה
עצמה ואשר על כן שימוש באינדקס כאן של Employee ID לעומת שימוש באינדקס ב-orders.employee ID לא עוזר לי כי זה שהשתמשתי באינדקס שלי עם pre-id עזר לי לבצע את המצ'ינג, את הג'וינט ביניהם.
אולם אחר שהשתמשתי בג'וינט נדרשתי לשוב ולחזור לכתת רגלי לטבלה על מנת להביא את העמודות הללו. אחר שאני צריך ללכת ממילא לטבלה ולהביא את העמודות הללו, מה שיוצר תקורה נוספת, אומר הדאטאבס אוקיי, אני הבנתי אותך.
אז אני מלכתחילה כבר לא משתמש בג'וינט, לא משתמש באינדקס, יוצר לעצמי את ה-Temporary Table כפי שראינו את ה-Hash Table. קונטרול L על מנת לקבל את ה-Execution Plan כפי שהסברנו ואנחנו מגלים את הדבר הבא.
ראשית כל Clustered Index לא השתנה ללא שינוי אנחנו עדיין עובדים על תגרת Employees וכיוון שהיא Clustered וממוינת ממנה אנחנו שולפים את התנאי שאיתו אנחנו עושים join,