אי שפיות באינדקס: כיצד להימנע מתוהו ובוהו בבסיס הנתונים

על ידי צוות Techopedia, 5 באוקטובר 2016

טייק אוויי: המארח אריק קוואנה דן באינדקס של מסד נתונים עם ד"ר רובין בלור, דז בלנשפילד וברט סקאלזו של IDERA.

אינך מחובר כרגע. התחבר או הירשם כדי לראות את הסרטון.

שותף תוכן Techopedia

צוות Techopedia מסונף לקבוצת Bloor וניתן ליצור איתו קשר באמצעות האפשרויות מימין. למידע על האופן בו אנו עובדים עם שותפים בתעשייה לחץ כאן.

• פרופיל
• אתר אינטרנט

אריק קוואנה: גבירותיי ורבותיי, שלום, וברוך שוב שוב. זה יום רביעי, בשעה ארבע מזרחית, ואלה מכם שמכירים את התוכנית, יודעים מה זה אומר, הגיע הזמן לפרק נוסף של הוט טכנולוגיות. אכן כן. שמי אריק קוואנה, אני אהיה המנחה שלך לישיבה של היום: "אי שפיות באינדקס: איך להימנע מכאוס במאגר נתונים." או כפי שהתייחסתי אליו בהפצת הדוא"ל האחרונה כדי לצאת, "להתפתל בבסיסי נתונים." טווח חם בימינו, "להתפתל." כולם עושים את זה. יש שקופית שלך באמת. ודי בי.

אז, סדרת Hot Technology באמת תוכננה להגדרת מרחב מסוים, בניגוד לחדר התדרוך שהוא רק תדריך אנליסטים חי אחד על אחד, עבור הוט טק אנו מקבלים שני אנליסטים. היום זה יהיה הרופא שלנו רובין בלור משלנו ומדען הנתונים שלנו דז בלנשפילד. ואנחנו מדברים על נושא שלדעתי באמת די סמלי של מה שקורה כיום בשוק.

בשורה התחתונה אנו נמצאים בעולם של מורכבות בימינו. באמת, אם אתם חושבים חמש עשרה שנה, או עשרים שנה, זה היה עולם שונה בהרבה אז, במיוחד ביחס לטכנולוגיית מסד הנתונים. בסיסי נתונים היו פשוטים למדי. היו רק קומץ מהם; רובם היו יחסיים. כעת, יש לנו את כל הפאנפולי הזה של טכנולוגיות מסד נתונים. פשוטו כמשמעו עשרות אפשרויות על השולחן לכל מי שרוצה לבנות אפליקציה או לעשות משהו עם נתונים. הכל משתנה וזה משפיע על האנשים שמנסים לנהל מערכות אלה. אנו נדבר היום עם ברט סקלזו, שהוא מומחה אמיתי בתחום; הוא ניהול המוצר הבכיר של IDERA, על מה אתה יכול לעשות כדי להתמודד עם כל הנתונים האלה. עם זה אני הולך למסור אותו לדוקטור רובין בלור שייקח אותו. רובין, הרצפה היא שלך.

רובין בלור: אוקיי, תודה על ההקדמה הזו. אני חושב את זה - מכיוון שזה דבר דו-ידני, אני חושב שהייתי מדבר על אופטימיזציה של מסד נתונים באופן כללי כהקדמה לתוכנית ההוט-טק הזו. התחלתי את החיים - בטכנולוגיה וניתוח - התחלתי את החיים לעשות את זה כי פעם כתבתי מאמרים על היכולות של מסדי נתונים בפלטפורמת DEC VAX. ומסיבה זו, בעבר היו מבלים על בסיס הנתונים. והדבר שקורה לי סוג זה הוא, מדוע יהיה לך בסיס נתונים? כלומר, בימים ההם הרבה אנשים נוראים יצרו קבצי ערך מפתח ומשתמשים בכאלה כדי לקבל מעין שגיאה רציפה באינדקס כפי שאנו מכנים אותם, אבל כדי ליצור סוג של יכולת בסיס נתונים, ואתם יודעים, מדוע היה לכם עוד משהו?

והתשובה לכך, אני חושב שמייקל סטונברקר נתן את התשובה הטובה ביותר לכך, והוא אמר, "מסד נתונים יכול לדעת יותר איפה הנתונים וכמה מהר ניתן להשיג אותם, מכפי שכל תוכנית יכולה לדעת אי פעם." ולדעתי זה מעניין; זה אופי המשחק. אבל ב -19 - ובכן בערך 1989 שהתחלתי בניתוח טכנולוגי ואתם יודעים, בנקודת הזמן ההיא, מסדי נתונים היו פשוטים מאוד ומאגרי מידע יחסיים היו פשוטים מאוד. הייתה להם כל כך מעט יכולת, כלומר, הם יכולים לאחסן נתונים, כמובן, ואתה יכול לגבות והיה להם, הם היו תואמי חומצה, אבל באמת שהיו להם מיטבי אופטימיזציה חלשים מאוד. למעשה, יהיה קשה לטעון שיש להם יכולת מיטוב בכלל.

ומאוחר יותר הם פשוט השתפרו ונעשו טובים יותר, אבל, אתם יודעים, כאשר מסד נתונים לא מתפקד - כפי שנראה שהקנגורואים האלה בדרך זו או אחרת מעידים - יכולות להיות הרבה מאוד סיבות למה זה הולך לאט. וזה מביא אותי לנקודה: למאגרי נתונים יש הרבה פונקציות, אך החשוב ביותר הוא אופטימיזציה של שאילתות. אם הם לא היו עושים זאת, לא הייתם משתמשים בהם. זה קשור לקבלת מידע במהירות, מדובר על היכולת לעשות זאת כשיש הרבה משתמשים במקביל וזו בעיה קשה. וכאשר אתה מסתכל למעשה, בוא נקרא להם מסדי נתונים בוגרים, אם תרצה - אבל בהחלט אורקל, במידה מעט פחות, Microsoft SQL Server, בוודאי Teradata ו- DB2 - האופטימיזציה של מסדי נתונים אלה התקיימה עשרות שנים ב- בניין. אתה יודע, הם לא - מישהו לא התיישב עליהם - שישה בחורים על שני איש, שנה, פרוייקט ופשוט דפקו אחד יחד. זה לא עובד ככה. יכולת האופטימיזציה גדלה בהדרגה, והיא דורשת הרבה צמיחה. בכל מקרה, בואו נדבר על הרקע למסד הנתונים. ובכן, יש הרבה דברים שנאמרו על מסד הנתונים של NoSQL עכשיו, ויש אפילו הרבה התלהבות ממסד הנתונים הגרפי. והשימוש ב- SQL על פני Hadoop ודברים כאלה. אבל, האמת היא שאם אתה רוצה מסד נתונים ברגע זה, אם אתה מעוניין במלאכה פונקציונלי לחלוטין, המסוגל ל- OLTP ולתעבורת שאילתות גדולה, זהו מסד נתונים יחסי, או שהוא כלום.

מבין מאגרי המידע היחסים, אורקל דומיננטית בפופולריות. שרת SQL של ​​מיקרוסופט, לדעתי, הוא שני. שניהם מסוגלים לשמש ל OLTP ולעומסי עבודה בשאילתה, אך למעשה אינך יכול להתחמק עם ערבוב עומסי העבודה האלה. אתה זקוק לאירועים שונים עבור עומסי עבודה של עומסי עבודה ועומסי שאילתה. יש חלופות ל- SQL ולגרף. רוב החברות מתקבלות על בסיס נתונים ספציפי אחד, וזו הסיבה - אני מתכוון לאחר עשרות שנים של מאבק זה עם כל שאר השחקנים, אורקל הפכה לדומיננטית ביותר. פשוט מכיוון שבסופו של דבר הצליחו למכור רישיונות עסק, ולכן חברות ישתמשו רק במוצרים אלטרנטיביים במוצרים חריגים שאורקל פשוט לא הייתה עושה אותם. ובסיסי נתונים הם אסטרטגיים בכך שהם גם מתפתחים. ואתה יודע שעשיתי קצת מחקר עבור המצגת הזו, וזה סוג של - אני אגיע לזה בעוד זמן מה, אבל זה די מעניין איך הם מתפתחים, מבחינת ההתבוננות בעמדה של DBA. זה מה שאני מכנה את המגמה הבלתי נראית. החוק מור מורכב. זה בערך ככה: המאגר הגדול ביותר הוא ובסיסי נתונים חדשים, אין בסיס נתונים ישן שיש לו הרבה יותר נתונים לצריכה. בדרך כלל זה בסיס נתונים שמיושם על בעיה חדשה. והם למעשה גדלים מבחינת נפחי הנתונים. בערך בקובייה של מור חוק. אז החוק של מור הוא גורם של פי עשר בכל שש שנים. VLDBs נוטים לגדול גורם של אלף כל שש שנים. בשנת 1991, 1992, נמדדים בסיסי הנתונים הגדולים במונחים של מגה-בייט. בשנת 97 'ו- '98 ג'יגה-בייט. 2003, '4, טרה-בתים. 2009, '10, התחלת לראות מסדי נתונים של פטיבה. אני חושב שהיה אולי מסד נתונים אחד או שניים שם בחוץ כרגע, אבל הגדול ביותר ששמעתי עליו הוא 200 הפטאטים בזמן, ואתה יודע, לא לקבל נתונים למסדי נתונים של פטה. אבל, רוב זה כמובן יהיה חברות החדשות הגדולות ב- Web 2.0, אולי יש לך פייסבוק לכיוון זה.

אבל בכל מקרה, אם אתה באמת מסתכל על זה, מצפה ממסד נתונים שיעבור סוג כזה של הסלמה בנפח, הוא מבקש הרבה. וראוי לציון, בוודאי עד לרמת הפטבט, נראה שהם הצליחו בצורה סבירה. כלומר, אני מדבר על המוצרים הישנים ולא על שום דבר חדש. נראה שהם הצליחו בצורה יוצאת דופן. אם אנו מסתכלים על ביצועי בסיס הנתונים, צווארי בקבוק, הדבר מחזיר אותי לתקופה שהייתי ממש דואג להם ונאלצתי לדאוג לגביהם. אתה יודע שזו מהותית פירוט החומרה. ישנם צווארי בקבוק של המעבד, יתכן שיש צווארי בקבוק בזיכרון, יתכן וישנם צווארי בקבוק של הדיסק, אולי. זו יכולה להיות הרשת הגורמת לך צער, ואתה יכול גם לגרום לבעיות בנעילה, תלוי במה שאתה עושה, אך בדרך כלל זה מכיוון שהתוכנית לא יודעת למי להתקשר לנעילה. לכן, אם אתם מתכוונים לכוונן מסד נתונים, אתם בעצם מנסים לכוון אותו כך שהוא ירקוד בין חמשת צווארי הבקבוק האפשריים האלה כמו שהוא יכול לעשות. וזה לא דבר קל, מכיוון שכמות הזיכרון שתוכלו להגדיר בכל שרת נתון מוגברת באופן דרמטי. ואז המעבדים הפכו לריבוייים, דיסק, ובכן אנו יכולים כעת, אני חושב, אפילו על שרתי סחורות, אני חושב שאתה יכול לעשות מאות ומאות טרה-בתים, רבע פטה, אולי, אפילו בשרת סחורות. אז מכל הדברים האלה אתם יכולים לשחק איתם, הרשת כמובן יכולה לעבור במהירויות שונות, אבל בעיקר כשאתם מתעסקים עם מסדי נתונים, אתם באמת רוצים שיהיו כבלים סיביים בין השרתים ושום דבר אחר לא פועל על זה, במיוחד בצורה זו.

גורמי ביצוע למסד נתונים. זאת אומרת, אני משמיט מה כל זה הולך להיות, כי אני יודע שדז ידבר על זה, אבל עיצוב מסד נתונים גרוע פירושו בסיס נתונים בעל ביצועים לא טובים. תכנון תכנות גרוע יכול להיות פירושו השלכת SQL מטופשת מאוד למסד נתונים, מה שייקח הרבה יותר זמן. במקביל לערבוב עומסי עבודה, יותר מדי במקביל יגרמו לבעיות בצוואר הבקבוק. עומס העבודה בערבוב, כאשר יש לך שאילתות גדולות עם שאילתות קטנות מאוד, קצרות וחדות, זה גורם לבעיות. יש בעיית איזון עומסים. רוב בסיסי הנתונים דואגים לכך, אבל אם אין לך מוצר מתוחכם, אתה יודע, רק הוספת כמה שרתים, זה לא כל מה שאתה עושה אם אתה באמת רוצה להגדיל את גודל האשכול. למעשה אתה צריך לאזן עומס לפני שתשיג את הביצועים האופטימליים. אתה צריך לעשות תכנון קיבולת. בהחלט. במיוחד עכשיו בימים אלה, כאשר נפחי הנתונים גדלים בצורה דרמטית יותר ממה שהם היו בעבר עבור מסדי נתונים. וישנן סוגיות שלמות בשכבת נתונים לגבי האופן שבו אתה מכניס את הנתונים, כיצד אתה מעביר נתונים עליהם. אי קבלת נתונים למסד נתונים בזמן יכולה להיות בעיה בביצועים בהמשך מכיוון שעברנו ממאגרי מידע העובדים ב- Windows, לעשרים וארבע על שבע על ידי שלוש מאות ושבעים וחמישה פעולות ואין חלונות שבהם אתה יכול להאט את בסיס נתונים למטה או שלא סביר שיהיו בימינו.

בעיית אורקל DBA. זה מה שחשבתי עליו. הייתי ב- DBA של אורקל עם אורקל 7, ואני זוכר איך לכוונן את זה. ואם אתה באמת מסתכל על אורקל עכשיו, זה דרך, דרך - יש לזה דרך, דרך יותר יכולת. יש לזה אינדקס של מפת סיביות ודברים כאלה, אבל אני למעשה לקחתי את הזמן להסתכל ולראות כמה פרמטרי כוונון יש כרגע במסד נתונים של Oracle. ויש יותר משלוש מאות וחמישים פרמטרים של כוונון ויש עוד מאה פרמטרים נסתרים, ש- DBA מומחים עשויים לדעת עליהם, אך DBAs רגילים של אורקל אינם יודעים עליהם. וזה אומר שכוונון בסיס נתונים זה דבר קשה. זה בכלל לא דבר פשוט. אתה צריך להרגיש את זה, אתה צריך לעשות את זה הרבה זמן, ואתה צריך לדעת בדיוק מה הבעיה שאתה חושב שאתה פותר, כי הכוונון מתחיל כאשר הביצועים נעשים גרועים, אך יתכן שזה לא הביצוע של הכל. יכול להיות שביצועי שאילתות ספציפיות חשובות, וייתכן שתוכל לתקן זאת על ידי הצמדת נתונים וזיכרון מסוימים, או שתצטרך לתקן אותם באמצעות אינדקס, או שתצטרך להתחיל לבצע חלוקה בדרך אחרת. יש הרבה דברים שאתה יכול לעשות, זה העניין. לכן, הם לא מתכוונים לעשות זאת בראשם - DBAs צריכים כלים. אני אעבור לדז שעתיד לספר לכם על אינדקס, אני חושב.

אריק קוואנה: בסדר דצמ, קח אותו משם.

דז בלנשפילד: תודה, רובין ואני אוהבת את עמוד השער. אני חושב שזרקת את הכפפה למטה בשבילי להתקרב אפילו להתקרב מרחוק למשהו מרגש. אבל השתמשתי בדימוי של הגלקסיה הקטנה שלנו, כפי שהפכה התפיסה שלי לגבי מה שהפך האתגר של היום למנהלי מסדי נתונים, מכיוון שזו הדימוי הנפשי שאני נוטה להעלות כאשר אני נכנס לסביבה ואני כבר לא. בעולם ניהול מאגרי מידע או עיצוב מאגרי מידע ברמה זו כבר. אבל כמוך, רובין ואני היינו שנים רבות של מעורבות בעולם בסיסי הנתונים, אם כמנהל או כמפתח, או בסופו של דבר כאדריכל, ואז הבנו שאני יכול לעשות דברים טובים יותר כדי להרוויח קרום. אבל זה אכן נוטה להרגיש שאתה בוהה בגלקסיית הנתונים הזו, ויתרה מכך היום, כשאנחנו עוברים, כפי שתיארנו, עברנו ממגה-בייט לפט-בייט והיקף-אקס-סקאו בזמן קצר מאוד., בתכנית הגדולה של הדברים. אבל הביטוי שעלה על דעתי הוא שאינדקסים של מסדי נתונים הם עכשיו אמנות שחורה והם לא באמת סוג הדברים שרק בני תמותה צריכים לסדר עליהם, ליישומים עסקיים ברמה העסקית וסוג הניסוח שלך פשוט דיברו על. אבל, רציתי לעבור סקירה מהירה של סוג ההיסטוריה שהייתה לי עם עולמות בסיסי נתונים ולהביא לקונטקסט למקום בו אנו עומדים להסיק מסקנה, ואז לעבור על חומר כלשהו היום עם החברים שלנו ב IDERA, כי אני חושב שיש הרבה חשיבה אחרת כיצד להשיג כוונון ביצועי מסד נתונים ואחד מהם זורק פח על הדבר. עבור הרבה חנויות שאני נתקל בהן, הן בדרך כלל לא מגיעות לביצוע כוונון ביצועים בשכבת מסד הנתונים ובמיוחד בשכבת האינדקס עד שהם עברו את הדרך הקשה לחשוב שהם יכולים לזרוק על זה מקלט. .

הרבה אנשים פשוט נוקטים בגישה ברזל גדולה בזה, בראשי, ויש לי כאן תמונה של ה- Flash כי אם אי פעם צפית בסרטים ישנים כלשהם או בהחלט בתוכנית הטלוויזיה האחרונה עם ה- Flash, כמו ב פלאש גורדון הדמות הישנה, ​​ועכשיו כשהוא מכנה "הפלאש", הוא נוטה ללכת מאוד מאוד מהר, ובלא הפסק האנרגיה שלו אוזל. וזה מה שקורה כשזורקים ברזל גדול על ביצועי בסיס הנתונים. באופן בלתי הפיך, מניסיוני, אתה יכול לשים ביצועים גבוהים, עבודה קשה במשחק, אתה יכול לייעל את מערכות ההפעלה שלך ולכוונן אותם לנקודה מסוימת. אתה יכול להבטיח שיש לך מעבדים רב-ליבתיים מרובי-שלבים, כך שהיישום יפעל מהר יותר, תוכל לזרוק עליו הרבה זיכרון RAM, יש לך מטוסים אחוריים בעלי תפוקה גבוהה, אתה יכול לעבור מכוננים קשיחים לכוננים קשיחים במטמון למצב מוצק., ומערך אחסון בעל ביצועים גבוהים. ואפילו עכשיו, אנשים זורקים דברים כמו פלאש ו- NVMe למנועי בסיס הנתונים שלהם, במחשבה שהם הולכים להשיג כניסה זו כפול שני ביצועים. ובאופן בלתי נמנע הם כן משיגים קצת רווח. עם זאת, הכל חוזר לאותן בעיות כוונון ביצועים בסיסיות. המון חיבורי רשת בעלי זמן אחוי נמוך, כך שהאשכולות עובדים מהר. ושל תשתיות מסדי נתונים לאשכול, כך שיש לך יותר ממכונה אחת שעושה את כל העבודה. אבל אתם נוטים לחזור לאותה בעיית ביצועים בסיסית, וזה קריאת נתונים. כתיבת נתונים היא לרוב אתגר ליניארי למדי, אלא אם כן זה נעשה כראוי.

ואז יש לנו את האתגר בעולם של ימינו: לא כל בסיסי הנתונים נוצרים שווים. יש מאגרי נתונים ו"מאגר נתונים "מציטוט אחר ציטוט. וכשאנחנו חושבים על מנועי מסדי נתונים, אנשים חושבים לעתים קרובות על החשודים המסורתיים והרגילים כפי שהיו בעולם ה- SQL. אתה יודע, יש לנו Oracle ו- Microsoft SQL Server, ויש זוג סביבו בעולם הקוד הפתוח עם MySQL, שנמצאת כעת בבעלות Oracle, אך היא עדיין קוד פתוח. ואז יש לנו את החשודים שאינם כה רגילים, מנועי ה- NoSQL, שעדיין יש בעיה סביב אינדקס וניהול ביצועים, ואני לא אתייחס אליהם בהרבה פרטים, אבל יש מספר הולך וגדל של אלה דברים צצים כל יום והם נראים ומרגישים כמו מנועי מסד נתונים מנקודת המבט של היזמים ומנקודת מבט של ביצועים, אבל הם חיות מאוד שונות מאוד ויש להם נישה קטנה משלהן בעולם לחצוב ביצועי זיכרון או סולם ליניארי בדיסק. אבל כך נראה העולם בעולם בסיס הנתונים. זה 2016, זו הגרסה השלישית של המפה של, על ידי מגוון אנשים שמייצרים את מפת הנוף המתמשכת הזו של איך נראים מסדי נתונים, וכאן זה - אפילו אדריכל מסדי נתונים על-אנושי או מנהל מסד נתונים לא יכול היה להיות הגיוני מזה. פשוטו כמשמעו מאות, ומאות, ומאות דגמים שונים, יצרנים של מסדי נתונים, תמיד תואמי SQL. והעניין המעניין הוא שכולם חוזרים לאותו אתגר. כוונון ביצועים וביצועים סביב מנוע בסיס הנתונים, ובמיוחד לפי האופן שבו נתונים באינדקס.

אז בואו נסתכל במהירות על אינדקס מסדי נתונים, מכיוון שזה נושא מעניין, ועליכם להיכנס אליו ביתר פירוט עם ההדגמה, אני מאמין. אבל, אני חושב שזה מקובל ורגיל בתעשייה, כי כוונון ביצועי אינדקס של מסדי נתונים הוא המקום בו העולם מתחיל ומסתיים ככל שמבטיח שהנתונים שלך יהיו נגישים בפורמט מהיר ומהיר. אבל מה זה אינדקס של מסד נתונים? אם אנו חושבים על אינדקסים בצורה שאנו רגילים אליהם כבני אדם יומיומיים, חשוב על דף אינדקס בספר. אם אתה רוצה למצוא משהו בספר - במיוחד כמו אנציקלופדיה, או משהו כמו חומר עזר מסוג כלשהו - אם אתה מחפש משהו כמו דף זה, שם אני מחפש דברים כמו נושא הסכרים באנציקלופדיה. אני רוצה למצוא כל התייחסות לסכרים, לשטף מים ולאזור הצטברות גדול, מעשה ידי אדם באופן כללי. אני אלך אחורה, אמצא אותה ברשימה ממוינת לפי אלף-בית, א 'עד ת', משמאל לימין, ואמצא את ד '. אני אמצא את המילה "סכרים" ואני יכול לראות את זה ב- עמודים 16, 38, 41 יש התייחסות אליהם ואז אוכל לעבור לדפים האלה, אני יכול לסרוק את עיניי ואמצא את ההתייחסות למילה "סכר". זה בעצם אותו מושג בבסיס נתונים, אבל זה עכשיו מדע טילים במובנים רבים. עד כדי כך, שבאמת כל מנהל מסדי נתונים שהכרתי אי פעם טוב, מחשיב אינדקסים ככלי הקריטי ביותר לכוונון ביצועים בכל בסיס מסד נתונים, ללא קשר לחוויה שעשויה להיות לזרוק עליו פח, או יהיה אשר יהיה.

באופן כללי כשאנחנו מדברים על אינדקס של בסיס נתונים, יש מספר גישות נפוצות. וככל שמדדי מסדי נתונים מורכבים יותר, הגישה לנתוני אינדקס מורכבת יותר. אבל בעיקרון כשאתה חושב על אינדקס נתונים - דמיין שיש לנו קובץ שיש בו רשימת שמות; הם עשויים שלא להיות ממוינים לפי סדר אלפביתי. בואו נדמיין שיש עשרים כאלה. אם אנחנו הולכים למיין - אם אנחנו הולכים לחפש נתונים ברשימה ההיא, מלמעלה למטה, ונניח שזו רשימת שמות. אם אני בוחר שם אקראי ואני מתחיל לגלול במורד הרשימה ההיא, מלמעלה למטה, בפורמט ליניארי וזו רשימה לא מסודרת, ישנם שני קריטריונים שאני חושב עליהם כזמן החיפוש הממוצע שלי וזמן החיפוש המקסימלי שלי - יש לי שגיאת הקלדה בשורה השנייה, צריכה להיות "זמן חיפוש מקסימלי", סליחה - אבל זמן החיפוש הממוצע שלי הוא בעצם N פלוס אחד, חלקי שניים, וזה בממוצע, זה לוקח לי חמישים אחוז מהזמן לסרוק מראש הרשימה, לתחתית הרשימה כדי למצוא כל דבר אקראי ברשימה. והשורה השנייה שם, מתחת ליניארית, צריכה להיות "זמן חיפוש מקסימלי." אבל זמן החיפוש המקסימלי הוא בעצם מספר הפריטים, וזה שאם יש לי רשימה של עשרים דברים, הכי הרבה זמן זה יכול לקחת לי לחפש משהו במאגר זה הוא לעבור מלמעלה למטה, כלומר נניח 20 פריטים בדוגמה הפשוטה הזו. וזה תהליך איטי מאוד וממש אין דרך לבצע כיוון זה. ואז, ישנם סוגים אחרים של דרכים לקחת נתונים אלה וליצור אינדקס, שהוא למעשה רשימה קצרה של מצביעים למקום שבו נמצאים הנתונים בפועל, כגון בינארי, B-tree, מפת סיביות, hashing, מקובצים ולא מקובצים, ואז ישנם סוגים שונים של נתונים כמו מרחביים, מסוננים, XML וטקסט מלא.

בינארי הוא דבר שנפוץ מאוד לדברים שבהם הנתונים נותנים את עצמם אליו. עץ B הוא ככל הנראה הסינגל הנפוץ ביותר במובן כללי, מבחינה היסטורית, בכך שהוא דרך נפוצה לבנות אינדקס לכל סוג של נתונים ומאפשר לוגיסטים, בחירות והתוספות ומחיקות קל יחסית כשאתה מעביר מצביעים סביב התייחסות למצביעים, לנקודות. ישנם סוגים אחרים, כמו מפת סיביות, שבהם סוגי נתונים נוגעים למשל אם יש לנו טווח משויך כלשהו. Hashing עובד טוב מאוד עבור חפצים גדולים, במיוחד בלוגים ותמונות. ותוכלו לראות שיש מספר סוגים שונים של גישות מדעיות, גישות מתמטיות, לאינדקס נתונים. עבור בני תמותה גרידא, הם אתגר מעניין לדבר עליו ברמה זו. כשאתה מדבר על זה ברמת ביצועים עבור מנהל מסד נתונים, הם באמת הופכים למדען טילים ואנשים עושים בהם תארים, ואני יודע שהדוקטור רובין בלור בהחלט עשה את זה, וכתב עליו ספרים כמו אוהבי יבמ ו מותגים גדולים אחרים במהלך העשורים האחרונים. וכך, ההשקפה שלי - היא שבעצם עברנו זמן שבו, אתה יודע פעם אחת הייתי באופן אישי יכול לשבת מול מערכת והייתי מסוגל לפרק אותה ולהראות לך איפה בדיוק בעיות הביצועים היו בשורת פקודה או בכלי התחלה של ממשק משתמש גרפי, ולהתחיל להתעמק בנתונים ולספר היכן היו הבעיות, ולבנות אינדקסים, או תת-אינדקסים, או אינדקסים ראשוניים ומשניים נתונים ולהתחיל להשתמש בהם כדי למצוא דברים. אבל כשאתה חושב על הנוף ההוא שהראיתי לך, איפה שיש לנו מאות ומאות מותגים, יצרנים ודגמים, ויצרנים וסוגים של מסדי נתונים, אנו נמצאים היטב ובאמת עברנו באותה תקופה, בה יכול אדם ליצור תחושת הסוגים של מנועי בסיס הנתונים שיש לנו. במיוחד, אפילו אם רק נחזור לחבביהם של אורקל, מותגים בולטים בימינו בפלטפורמות מסדי נתונים יחסיות.

מספר מאגרי המידע שהם צריכים להתמודד איתם מפלטפורמה קניינית כמו ERP או HR או מערכת פיננסים, או שמא מדובר בפלטפורמה אפויה ביתית מסיבות שונות, מספר בסיסי הנתונים וטבלאות מסדי נתונים ורישומים שבסופו של דבר ההתמודדות עם הם פשוט אסטרונומיים ואתה פיזית לא יכול לעשות את זה ביד. ועכשיו עברנו סיבוך נוסף, שבו פעם יכול שרת מסדי נתונים פשוט לשבת מתחת לשולחן העבודה שלך. אתה יודע, כילד צעיר אחרי הלימודים, נהגתי לעבוד על תוכנת מסד נתונים על, במקור, Apple IIes ואז מערכות מבוססות מחשב DOS, כמו dBase II, dBase III, עברו עידן עם מסגרות מרכזיות ואמצע- טווח ואפילו VAXs ו- PDPs וקובץ יומן על זה. וכדומה לסאבר, ואז בסופו של דבר כשהגיעו כמה ממאגרי המידע של SQL. אך בימינו כאשר אנו חושבים על מנועי מסד נתונים, הם נראים כמו הפינה השמאלית התחתונה. שרת מסד נתונים הוא לא רק מכונה אחת שיושבת על הרצפה מתחת לשולחן; מדובר במאות מכונות שמפעילות עותקים של מנועי מסד נתונים ואשכולות, והן עוסקות בהיקף של עד מאות ומאות טרה-בייט של נתונים, אם לא פט-בייט של נתונים, שהם אלפי טרה-בתים. ואפילו עד קיצוני, כפי שציין הרופא רובין בלור, כי כמה מקרי שימוש ספציפיים - חברות תעופה, סוכנויות ממשלתיות בפרט - יכולים להגיע לנפחים. הם עדיין די נישה, אבל מאות טרה-בייט ואפילו עשרות פט-בייט כבר לא יוצא דופן, במיוחד מהבום של דוטקום עד עכשיו, מעין מה שאנחנו מכנים חברות אינטרנט 2.0, כמו פייסבוק, גוגל, יאהו וכן הלאה.

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

וכך אנו מצליחים ובאמת - בעיניי - בנקודה בה אפילו גורואים של מסדי הנתונים הטובים בעולם, למעשה אדריכלי מסד הנתונים ומנהלי בסיסי הנתונים שלנו ובסיסי הביצועים שלהם, לדעתי הם מאוד צריכים להתחיל למנף את הכלים הנכונים. כדי לספק כוונון מדד ביצועים מיטבי עבור כל מנוע בסיס נתונים. מכיוון שהקנה המידה בו אנו מתמודדים והמהירות בה דברים נעים, אנו פשוט לא יכולים לעשות זאת ביד, וניסיון לעשות זאת באופן בלתי הפיך יכול להכניס בעיות ביצועים אחרות, מכיוון שאולי אין לנו ניסיון במרחב הזה אנו מנסים לפתור בעיה בה. ואני מאמין שכאן אנו עומדים למסור לברט, ואנחנו עומדים לדבר על איך הם פתרו את הבעיה המגוונת הזו ועל סוג הדברים שהכלי שלהם יכול לעשות זאת, במיוחד עבור עולם האורקל. ועם זה שם, ברט, אני אעבור אליך.

ברט סקלזו: תודה. ברוך הבא לכולם, קוראים לי ברט סקלזו, אני עובד בחברת IDERA. אני מנהל המוצר הבכיר של חלק ממוצרי מסד הנתונים שלנו. אדגים כמה מאלו היום. אבל אני רוצה לדבר על אינדקסים, כי אני מסכים עם כל מה שכולם אמרו כאן, במיוחד השקופית האחרונה, שהאינדקסים כל כך מורכבים עכשיו שאתה צריך כלי, ואני מקווה לשכנע אותך. אז עיצוב אינדקס של אורקל, זה לא קל כמו פעם בימים עברו. הרבה אנשים לא יהיו בטוחים בעצמם כאשר הם בוחנים את האפשרויות, ואני אוהב את האמירה הזו שהוצאתי מההיסטוריה, "בעניינים האלה, הוודאות היחידה, היא ששום דבר לא בטוח." וככה אני סוג של תחושה של אינדקסים בימינו, מכיוון שגם אם אתה חושב שאתה יודע שהתשובה שלך צריכה להוסיף לאינדקס X, Y או Z, אתה באמת לא יכול להיות בטוח עד שתנסה את זה, מכיוון שמיטבי האופטימיזציה האלה לפעמים מתנהגים אחרת כמו שאתה מצפה. וכך יש הרבה ניסויים וטעויות בעיצוב אינדקס. עכשיו, בימים הטובים, אם היית זקוק לאינדקס היו בדרך כלל רק שתי שאלות, או שאלה אחת. האם זה היה ייחודי או שהוא לא היה ייחודי? ויכול להיות שחשבת על דברים אחרים כמו "כמה אינדקסים אוכל לקבל מקסימום על שולחן בודד?" מכיוון שיותר מדי אינדקסים מאטים את התוספות, העדכונים והמחיקות שלך. יתכן גם שהיית במערכת מסד הנתונים שלך, היו לך מגבלות על כמה עמודות יכולות להיות באינדקס מרובה עמודות, מכיוון שלפעמים היו מגבלות על בסיס העמוד או גודל החסימה של מנוע בסיס הנתונים שלך, אבל במציאות זה היה די פשוט אחורה בימים הטובים. אתה צמדת אותו לאינדקס או שלא. ובאמת, הכל היה בעץ B. יכולנו לאפשר את הכפילויות או לא, וזה בערך. החיים היו טובים, החיים היו פשוטים.

ובכן, היום החיים לא כל כך טובים או כל כך פשוטים. הנחתי את שלט מכסחי השדים האדום בדרך שבה נהגנו לעשות זאת, מכיוון שעכשיו יש לנו עץ B- לעומת מפת סיביות, לעומת מפת סיביות. ואני הולך להסביר מהם כמה מהם ברגע. מקובץ ולא מקובץ, ייחודי או כפילויות, סדר קדימה או הפוך, מבוסס פונקציה, מחולק או לא מחולק. אם מדובר בחלוקה, האם זו חלוקה גלובלית או מקומית? אני אסביר גם את זה. ואז יש גם משהו שנקרא טבלה מסודרת באינדקס. ולמעשה יש חצי תריסר אחרים שהפסקתי מכאן, כי אני חושב שיש לי מספיק כאן עכשיו שצריך לשכנע אתכם שהאינדקסים הם הרבה יותר קשוחים ממה שאולי חשבתם. בשקופית הספציפית הזו, אני הולך להתחיל בחלק השמאלי העליון של התרשים ויש לי שולחן. והדבר הראשון שעלי להחליט הוא, תלוי בגרסת מסד הנתונים וספק בסיס הנתונים שלך, האם הם מאפשרים טבלאות אובייקטים או שהם רק קשורים? אני הולך לרדת מצד ימין ואומר שאנחנו בונים שולחן יחסי. כעת השאלה הבאה שעלי לשאול את עצמי היא האם היא נמצאת באשכול? והרבה מכם שעשיתם את אורקל במשך זמן מה, יזכרו שהאשכולות חזרו ל- Oracle 6 ימים. הם כנראה כבר לא בשימוש כבד יותר היום, אבל הרשו לי לרדת קודם לסניף הזה.

אם הייתי מתכוון להכניס את השולחן שלי לאשכול, הייתי צריך להיות אינדקס מקובץ על השולחן. עכשיו, באורקל, כשקבצת שולחן, אתה בעצם אחסן את השורות או שהשורות היו קרובות זו לזו במקום שהערכים דומים. וכך, צריך שיהיה לך אינדקס מקובץ ואת האינדקס המקבץ ניתן לא מחולק. במילים אחרות, לא היו ממש שיטות חלוקה לאופן בו תעשה טבלה מקובצת. זה בהחלט לא היה מחולק. ומכיוון שהוא לא היה מחולק, הוא היה גלובלי. אני אסביר מה זה גלובלי בעוד דקה. וזה תמיד היה עץ B. במילים אחרות, כשירדתי בסניף הזה, זה היה די פשוט, לא היו לי הרבה אפשרויות. עכשיו, אם עשיתי אינדקס לא מקובץ בטבלה מקובצת, שמותר בכמה גרסאות, שוב הוא לא היה מחולק; כאשר הוא לא מחולק, הבחירה היחידה שלך היא גלובלית. וכך, יש לך אפשרות לבחור עץ B או מפת סיביות. שוב, זה היה תלוי בגירסת מסד הנתונים שלך. אבל עכשיו, בואו ונחזור לשולחן ההתייחסות ונתחיל לרדת לצד הימני שוב ועכשיו פשוט יהיה לנו שולחן רגיל, ישן, רגיל, ערום: יחסי. זה יהיה בחלל שולחן. אני סוג של ראשון לרדת מצד ימין כאן. אז זה ארגון, ערימה. השאלה הבאה שעלי לשאול את עצמי היא, "האם אני רוצה לחלק את הטבלה הזו או שלא?" עכשיו, לפעמים היית מחיצה בגלל שחשבת, "היי, האופטימיזציה תהיה חכמה יותר כיצד היא יכולה לייעל את השאילתות. "אבל הרבה DBA יגידו לך שהסיבה שאתה עושה זאת היא למטרות אדמיניסטרטיביות. אם יש לך טבלה של מאה מיליארד שורות, אם אתה מפרק אותה למחיצות או לדליים, כאשר אתה רוצה להוסיף נתונים לדלי האחרון, אתה יכול להוריד ולאינדקס את זה רק כמה מיליוני שורות. אתה יכול להכניס נתונים אלה ואז תוכל לבנות מחדש את האינדקס הזה רק על הדלי הזה.

למרות שזו הייתה טכניקה טובה עבור חלק, טכניקות אופטימיזציה כמו ביטול מחיצה, הערך האמיתי שלה היה היכולת לנהל או לבצע משימות ניהול על חלקים קטנים יותר. כשאני הולך לערימה הארגונית, השאלה הראשונה הייתה "האם חלקתי את זה או לא?" בוא נלך שמאלה, אני לא מתכוון לחלק את השולחן. עכשיו זה אולי נראה מוזר כשאני אומר לך את זה, אבל אתה יכול לקבל טבלה לא מחולקת ואז אתה לא יכול לחלק את האינדקס כמו שאתה רגיל אליו, או שאתה יכול לחלק את האינדקס. תעצור ותחשוב. השולחן שלך כולל בעצם דלי אחד, כמו שחשבת תמיד, ובכל זאת באינדקס שלך יהיו דלים מרובים. כשזה קורה, איפה שיש אי התאמה בין מספר הדליים לטבלה, ומספר הדליים במדד, זה מה שאומר הגלובלי. וכך, אם הטבלה לא מחולקת, ואם המדד מחולק, היא נחשבת גלובלית, מכיוון שיש חוסר התאמה. עכשיו, הרשה לי לחזור על ערימת הארגון שלי, ולרדת במקום זאת בצד המחיצה. עכשיו, אם יש לי שולחן מחיצה, ובואו נגיד שלשולחן יש ארבעה דליים, ארבע מחיצות, האינדקס שלי יכול להיות בעל ארבעה דליים כך שהאינדקס שלי יתאים לעיצוב השולחן שלי. וכך זה נגמר, דרך מעבר, מצד ימין. זה ייחשב למקומי. פירושו של אינדקס מקומי הוא בעצם כי חלוקת הטבלה והמדד נעשית באותה צורה ויש לה אותו מספר דליים. ואז ברגע שיש לי את האינדקס המקומי, זה יכול להיות עץ B או מפת סיביות, והחץ הירוק שהסוג הזה עולה למעלה מראה לך שגם אם זה עץ B, עדיין יש אפשרויות שניתן לעשות. זה יכול להיות מבוסס פונקציה. וגם, אם זה מפת סיביות, ישנם סוגים שונים של מפת סיביות. יש משהו שנקרא אינדקס הצטרפות של מפת סיביות. אם אתה מבצע אחסנת נתונים, זה סוג פופולרי מאוד של אינדקס לסכימת כוכבים או לעיצוב. מה שקורה זה שבאינדקס יש מזהי השורות עבור מה שהוא מצביע בטבלה, אבל יהיו לו גם מזהי שורה עבור טבלאות האב כך שכשאתה - אתה צריך לעצב סכימת כוכבים ואתה מחפש בשולחן עובדות, המדד בטבלת העובדות מצביע על הנתונים שאתה מעוניין בהם ומצביע על כל שורה בממדים שלך, כך שתצטרך לקבל אינדקס אחד בלבד.

ולמעשה, זה קם בגלל Red Brick שהיה מאגר נתונים לפני שנים רבות - הרבה אנשים אולי זוכרים את זה. וכך, אם מסתכלים על תמונה זו - וזכרו שלא הכנסתי את הכל לתמונה הזו מכיוון שהתמונה תהיה גדולה בהרבה - ישנם עדיין סוגיות נוספות, שיש לי כאן בטקסט מעל החלק הימני העליון. . האם זה אינדקס בסדר הפוך? ואתה יכול לומר "מדוע אני רוצה מדד בסדר הפוך? זה לא הגיוני בכלל. "ובכן, אם אתה נמצא בסביבה מקובצת באורקל, אם אתה עושה אשכולות יישומים אמיתיים, אם אתה שומר על האינדקסים שלך בסדר, אז לא הפוך, אם יש לך הרבה עיבוד זה מכה אותם ערכים או אותם ערכי אינדקס, מה היה קורה, היו לך אזורים חמים בעץ B שלך. כלומר יהיה לך מחלוקת ואולי נעילה כדי לנסות לגשת לדברים האלה, ואתה עושה את זה על פני צמתים ברשת. ובכן, אם תכניס אינדקס בסדר הפוך, עכשיו אתה יכול לבטל את זה. אתה יכול לומר, "ובכן, הערכים הדומים נמצאים באזורים שונים של העצים, כך שאין לי הצמתים הנפרדים שלי שמתחרים על אזורים חמים בעץ." ואז שימו לב שגם הייחודי לא עובד עם חלק מהאפשרויות. . אם אתה מסתכל, אני מספרתי שלוש, חמש, שמונה ואחת עשרה, כך שיש מקרים שאני לא יכול לקבל אינדקס ייחודי. באופן דומה, ישנם מקרים שבהם איני יכול לקבל אינדקס הפוך, ואז יש בעיות נוספות כמו רישום או בלי רישום, ומקבילים ולא מקבילים. אני יכול להקצות דברים לאזור מסוים בזיכרון.

וזה משאיר עדיין לא מעט תכונות באורקל. הייתי אומר שכשמסתכלים על אורקל 12, כנראה שיש עוד כחצי תריסר דברים שיכולתי להוסיף לתמונה הזו. אינדקס הוא ממש מורכב ואני ממש מסכים עם הדובר הקודם, בכדי לנווט בזה ולעשות בחירה טובה, אתה צריך כלי. אתה סוג של צורך, אולי, תמונה כזאת, וסוג של מתודולוגיה כיצד היית בוחר דברים ובתקווה שהכלי יעזור לך להגיע לשם. ואז זה יהיה ניסוי וטעייה. אני תמיד אומר לאנשים באינדקס, "תסתכל לפני שאתה מזנק." ואז אתה יכול לראות את הכלב הקטן כאן, הוא קופץ בלי להסתכל, הוא ייגמר במים עם הכריש, או את הבחור שמתכונן לקפוץ למים, והוא הולך להתנשף. אתה צריך לחשוב על האינדקס שלך, כי יצירת אינדקס לא תמיד אומרת שדברים ישתפרו. למעשה, יצירת אינדקס יכולה להאט את העניינים. וביצועי שאילתה יכולים להיות בסדר גודל טוב יותר עם בחירה אחת על פני אחרת. ואני אתן לך דוגמא טובה. אם אתה עושה סכימת כוכבים של עיצוב, ובטבלאות הממדים שלך אתה משתמש באינדקסים של מפת סיביות במקרה אחד, ובמקרה אחר אתה אומר "אני אשתמש באינדקסים של עץ B", יש לך מפת סיביות לעומת B- עץ. אני יכול לומר לך שפתרון אחד יהיה סדר גודל או אולי כמה סדר גודל מהיר יותר מהאחר. אך קחו בחשבון מה עובד בסביבה אחת, כמו בסביבת אחסון נתונים, ככל הנראה אינה בחירה טובה בסביבת OLTP.

לדוגמה, אם היית לוקח טבלת פעולות, ומניח אינדקסים של מפת סיביות על שולחן פעולות, זה יקר לחשב ולאתחל מפת סיביות, המיתרים הארוכים האלה, וכך בטבלת OLTP, אתה עלול להכות בטבלה בכבדות עד שמפת הסיביות אינדקס יכול להיפגם ולהאט את המערכת מכיוון שהם פשוט לא נועדו לעדכונים. הם נהדרים לגישה מהירה, אך אינם טובים לעדכונים. אני חושב שמדד לוקח ניסוי וטעייה. באמת שאין כלל כלל זהוב - יש יותר מדי משתנים שונים במשוואה הזו כדי לדעת - ובסופו של דבר תצטרכו לבדוק את הביצוע או להסביר תוכניות במסד הנתונים כדי לראות אם אתם מבצעים בחירות טובות או לא. ולפעמים, ניתוח התוכנית יכול להיות כמעט מדע בפני עצמו. אני לא מתכוון לסקר את זה היום - זה נושא אחר - אבל אל תיקח את עיצוב האינדקס כמובן מאליו. ישנן סיבות לגיטימיות לכך שיש את כל סוגי האינדקס המטורפים האלה שהראיתי לך, בתמונה הקודמת, ושהדובר הקודם דיבר עליהם. אלה לא נוצרו רק מכיוון שמדובר בתכונה מסודרת להעלות לרשימה רשימת איפשהו עבור ספק מסד נתונים; ישנם מקרי שימוש או תרחישים שבהם אינדקסים אלה חשובים וישפיעו משמעותית. כעת, אני אראה לכם כמה דוגמאות לסוגים שונים של אינדקסים באחד הכלים שלנו. תן לי רק להעלות את המסך שלי כדי שתוכל לראות אותו. אוקיי, אז הנה אני יושב בתוך - הרשו לי למזער את היישום הזה. אני יושב בתוך VMware ואני מנהל VM של Windows Server 2012.

ותוכלו לראות, יש לי כמעט כל כלי ידוע לאדם. כמנהל מוצר אני צריך להיות מודע לתחרות שלי, כך שלא רק אילו כלים יש לי, אלא מה עושים המתחרים שלי? ויש לנו כאן את הכלי הזה שנקרא DBwartan, שכבר ניהלתי אותו, אבל אני הולך - אז אני רק אעלה אותו. ומה שאתה יכול לראות זה כלי ממש נחמד, כי במקום שנצטרך להשתמש, נניח מנהל ארגוני עבור אורקל וסטודיו SQL לניהול עבור SQL Server, וספסל העבודה של MySQL עבור MySQL, ושנים עשר מאגרי מידע אחרים שאנחנו תומכים בהם, ובכן יש לי את כל מסדי הנתונים המובנים בכלי זה. יש DB2, יש MySQL, Oracle, Postgres, SQL Server ו- Sybase, וזה - יש לי רק שישה מסדי נתונים בדבר הספציפי הזה מכיוון שאיני יכול - הכלי תומך בשניים עשר מסדי נתונים, אך ה- VM המסכן שלי, מריץ שישה מסדי נתונים במקביל, ומנסה לעשות הדגמה, זה בערך כמו שהחומרה שלי תאפשר. אז הרשו לי לחזור לאורקל עכשיו, ואם שמתם לב, כל הדברים האלה זהים. אם אני רוצה למדוד את הביצועים שלי ב- DB2, זו אותן אפשרויות שהייתי עושה ב- Oracle. עכשיו תחת הכיסויים אנו מבצעים המון דברים שונים כך שלא תצטרכו לדעת מה קורה, אך אנו נותנים לכם ממשק עקבי כדי שתוכלו להיות מומחים עם פלטפורמות רבות של מסדי נתונים. וזה יכלול עבודה עם אינדקסים, נושא הדיון הזה.

תן לי להיכנס לכאן ותן לי קודם להתחיל להסתכל על כמה טבלאות, ויש לי מסד נתונים של סרטים שיש בו רק כמה טבלאות. ואם אני מסתכל על טבלה מסוימת, כמו טבלת הלקוחות, כשאני מעלה אותה לכאן, אני יכול לראות את עיצוב הטבלה שלי, הנה העמודות שלי בטבלה שלי, והנה מידע על כל עמודה. יש לי מאפיינים לטבלה, אך שימו לב שיש לי כאן כרטיסייה לאינדקסים ואני יכול לראות שהאינדקסים הם בטבלה. שימו לב שאחד האינדקסים האלה הוא אינדקס PK שלי, המפתח העיקרי שלי. אלה האחרים נראים רק אינדקסים לשיפור גישה לשאילתה, אולי אנו שואלים לפי שם פרטי, או שם משפחה, או אנו מסתכלים על טלפונים ומיקוד. ואם אני בוחר אינדקס מסוים, כמו המיקוד הזה כאן, ואני לוחץ עליו פעמיים, עכשיו אני יכול לראות את זה, היי, זה אינדקס לא ייחודי והנה כמה מהסוגים האחרים, מפת סיביות, לא ייחודיים, ייחודי, בין אם זה ממוין ובין אם לאו, בין אם זה רישום, בין אם זה סדר הפוך, בין אם זה בסיס פונקציות. אה, הנה כיף שלא כיסיתי. למעשה אתה יכול לקבל אינדקסים בלתי נראים. ותגיד, "ובכן, למה לעזאזל הייתי רוצה לעשות מדד בלתי נראה?" ובכן, אני אתן לך דוגמה טובה. אתה נמצא במערכת הייצור שלך ויש לך בעיית ביצועים ואתה לא בטוח שיצירת האינדקס תתקן את הבעיה, כך שאתה לא רוצה ליצור את האינדקס ולהאט את הייצור, אבל איכשהו או אחר אתה רוצה להיות מסוגל לבדוק את זה. אתה יכול ליצור את האינדקס בייצור כבלתי נראה, כלומר, לא הרבה קוד יישום, קוראים לכלי האופטימיזציה, ישתמשו באינדקס הזה. הוא נוצר, הוא תקף, אך לא ישמש אותו. אז אתה יכול לקחת שאילתה שאתה חושב שהאינדקס הזה יעזור לה, או סדרה של שאילתות, ותוכל לתלות רמז ולהגיד, "היי, מיטוב, יש אינדקס בלתי נראה בחוץ שאני רוצה שתשתמש ותניח אני יודע אם שיפרתי את הדברים. "ועכשיו בדקתי משהו בהפקה, אבל לא שברתי את היישומים בהפקה שהיו פועלים. זה השימוש במדד בלתי נראה. זה נשמע מטומטם כששומעים עליו לראשונה, אבל יש לזה שימוש.

אנחנו יכולים גם להגדיר באינדקסים אם הם מקבילים וגם כמה מקרים הם מקבילים לרוחב. כעת, בסביבת אשכול יישומים שאינם מקובצים או לא אמיתיים, כך שאינם מתלה, במקביל, פירושו כמה תהליכי משנה שאילתה יכולה להעלות על מנת לנסות ולעבד תהליכים כדי לנסות להשיג דבר מהיר יותר או מהיר יותר. . ומקרים מקבילים יהיו, אם אני נמצא באשכול יישומים אמיתי, נגיד שיש לי עשרה צמתים, כמה צמתים אני רשאי לפצל את העבודה לרוחב? אולי זה ארבעה מתוך העשרה, ועל כל אחד מהם, ארבעה תת-תהליכים. זו דוגמא. ואז יש לנו דחיסת מפתח. אתה באמת יכול לדחוס אינדקסים? כן או לא. ואז כמובן שיש לך את פרמטרי האחסון שלך שאתה יכול לציין באינדקסים. עכשיו, לא כיסיתי את אלה מכיוון שהם באמת יותר פרמטר אחסון מאשר נושא אינדקס. ולבסוף, יש לנו אם להפוך את המחולקים או לא מחולקים. תן לי להשאיר את זה כאן לרגע. אני הולך לסכימה אחרת. זו סכמת כוכבים וכדומה, טבלת תקופות זו היא טבלת ממדים. אם אי פעם עשית תכנון סכימת כוכבים, בדרך כלל יש לך ממד לזמן וכך במאגר זה ובסכמת הכוכבים הזו, תקופה היא ממד זמן. עכשיו, אני יודע שזה ייראה מצחיק, תגיד "בחיי, תראה את כל הטורים האלה - האם הבחור שמע על נורמליזציה?" ובכן, כשאתה במחסן נתונים או בעיצוב סכימת כוכבים, אתה בדרך כלל יש לא - יש לך טבלאות שאדם טיפוסי היה מסתכל עליהם ואומר, "בחיי, אלה לא מעוצבים במיוחד." אבל ככה אתה עושה את זה בסביבת אחסון נתונים.

עכשיו, צפו מה יקרה כי בסדר, יש את כל הטורים האלה, תראו את זה, יש לי אינדקס על כל טור בודד. עכשיו, בסביבת OLTP שתהיה לא-אין. זה היה מאט את כל הפעולות שלי. בסביבת אחסון נתונים, הייתי מוריד אותם במהלך מחזורי העומסים האצווים שלי. טען ללא התקורה או האינדקסים, והייתי משחזר את האינדקסים מחדש. ואם אני מחלק את השולחן שלי, אז במקום שאצטרך להוריד את האינדקס עבור כל דלי בטבלה, הייתי יכול פשוט להוריד את המדד על הדלי או הדליים שבהם נתונים עומדים להיכנס במהלך מחזור הטעינה של האצווה. ואז ליצור מחדש רק את חלק המדד עבור אותם דליים. וכך זה מאוד ניתן לניהול. ואם אני מסתכל - אז הנה טור בשם "דגל החג" ובעצם זה כן או לא. שימו לב שמדובר במדד מפת סיביות, ולרובכם תגידו, "ובכן, זה הגיוני." כן או לא, Y או N, יש רק שני ערכים הגיוניים. ומכיוון שכשאתה קורא את התיעוד עבור אינדקסים של מפת סיביות, הם תמיד אומרים לך לבחור משהו עם קרדינליות נמוכה.

עכשיו תן לי להיכנס לאחד מטבלאות העובדות שלי, אז הנה יש לנו את ההזמנות שלי. וזו ההזמנות שלי ליום. ואתה תראה עכשיו, ששוב יש לי לא מעט טורים, ושוב, יהיו לי יותר מכמה אינדקסים. וכאן, יש לנו משהו שנקרא קוד המחיר האוניברסלי. זה היה עבור חנות קמעונאית, אז אתה מכיר את הברקודים הקטנים האלה כשאתה קונה משהו בחנות, זה קוד המחיר האוניברסלי. כעת ישנם מיליוני קודי מחירים אוניברסליים. כעת, עבור החברה הספציפית הזו שמכרה דברים, היו לה כנראה 1.7 עד 2 מיליון קודי מחירים אוניברסליים, אז אתם תצפו שזה לא יהיה מדד מפת סיביות מכיוון ש 1.7 מיליון ערכים נבדלים נשמעים כמו קרדינליות גבוהה. אבל במציאות, בסביבת אחסון נתונים, אתה רוצה שזו תהיה מפת סיביות. עכשיו, הרשו לי להסביר מדוע. ובכן, יתכנו 1.7 מיליון ערכים ברורים לקוד המחיר האוניברסלי הזה, מספר השורות בטבלת ההזמנות הזו הוא במאות מיליונים עד מיליארדי שורות. האינדקס שלי הוא קרדינליות נמוכה בהשוואה לגודל או לקרדינליות של הטבלה. זה הופך אותו לקרדינליות נמוכה. זה הופך את מדד מפת הסיביות לשימושי, למרות שהוא אינטואיטיבי עם 1.7 מיליון ערכים ברורים שתבחר כאן מפת סיביות. עכשיו, אם הייתי יודע שאני רוצה להשתמש במדד הצטרפות של מפת סיביות, נכון לעכשיו המוצר לא תומך בזה, אני מוסיף את זה לקראת המהדורה הבאה, אבל זו תהיה אלטרנטיבה אחרת כאן. ובסכימת כוכבים, זכור, אינדקס מפת הסיביות היה על טבלת העובדות וכי מדד אחד בעץ B מצביע על השורה בטבלת העובדות ואז על כל שורה שנראתה בטבלת הממדים עבור אותה עובדה. . וכך, יש לך אפשרות אחרת שם. וכך, בוא נראה, אני רוצה לצאת מהטבלאות עכשיו ואני רק רוצה להראות לך במהירות שיש לי את אותו מידע, תחת אינדקסים, ואני מתכוון לעשות את אותו הדבר הבסיסי.

עכשיו, הסיבה שהעליתי את זה היא שתבחין בכך, היי אין כאן מפתחות ראשוניים. מקשים ראשוניים נעשים באילוץ מקשים, כך שהם למעשה מכוסים בהגדרות האילוץ. אלה יהיו אינדקסים שאינם חלק מאילוץ. עכשיו אתה יכול לומר, "נו, חכה רגע, זה עשוי להיראות כמו מפתח זר, ומפתח זר הוא אילוץ, " אך מפתחות זרים ורוב מסדי הנתונים לא יוצרים אוטומטית אינדקס בעמודת המפתח הזר, למרות שזה רצוי, והנה אתה הולך - יש לי שוב את אותן אפשרויות. ואם אני רוצה לשנות רק כדי להיות דחוס, אני יכול לעשות את זה.

כעת הדחיסה עובדת רק על אינדקס עץ B. מה שמאפשר זה, כשמסתכלים על הצמתים השונים בעץ B, זה מאפשר דחיסה של חלק מהערכים. זה באמת לא דחיסה כמו דחיסת טבלה, זה דחיסה של מה שנאגר בעץ B בצמתים שאינם עלים. זה לא חוסך המון מקום, אבל זה יכול לעשות את ההבדל. ועם זה שמתי לב לזה, אני מתקרב למדי בזמן, אז מה שאני רוצה לעשות זה שאני רוצה לחזור ולהפסיק את השיתוף שלי. בנוסף, יש לנו את המוצר בחוץ למשפט של ארבעה עשר יום באתר idera.com. זה מוצר די טוב, במיוחד אם אתה עובד עם פלטפורמות רבות של מסדי נתונים. אם אתה עובד עם שניים או שלושה מסדי נתונים שונים, הכלי הזה יקל על חייך. יש לנו כלים שיעזרו לך בתכנון ובחירת האינדקס, יש לנו כלי שנקרא DB Optimizer. פשוט לא יכולתי לכסות את זה היום, זה יהיה יותר מדי. ואם אתה רוצה ליצור איתי קשר, יש את כתובת הדוא"ל שלי, או שתוכל לתפוס אותי בדוא"ל הפרטי שלי, ויש לי בלוגים, יש לי אתר ובלוגים ופרופיל לינקדאין שם. אז אל תהסס לפנות אלי אל כל דבר, גם אם זה לא קשור למוצר, אם אתה רק רוצה לדבר מאגרי מידע, אני חנון בלב ואוהב לפטור על טכנו-גבל.

אריק קוואנה: בסדר, טוב דז, רובין, אני בטוח שלכל אחד יש לך כמה שאלות לפחות, נשארו לנו כמה דקות כאן. דז, מה אתה חושב?

דז בלנשפילד: יש לי שאלה אחת גדולה שיש לי לשאול אותך, זה ישב לי בראש. מה התרחיש הכי מטורף שראית? קראתי את הבלוג שלך, אני עוקב אחריך מקרוב, את - אתה, אתה כנראה אחד האנשים הבודדים שחיו כמעט בכל סבירות, ואני חושב שד"ר רובין בלור הוא השני שפגשתי בו חיי. אבל, אתה יודע, בטח ראית כל תרחיש מטורף, מהם התסריטים הכי מטורפים שראית, שנתקלת בהם, וכמו בני אדם שפשוט לא הצליחו להתמודד, הצלחת ללכת ולבצע טריקים של מחשבות ג'די עם כל ה- DBarusan הזה?

ברט סקלזו: היה לנו פעם לקוח שבעיצוב בסיס הנתונים שלהם הם חשבו מאוד כמו שהם יחשבו בעיצוב פריסת קבצים, וכך, זה - כשאתה מנרמל מסד נתונים, הדבר הראשון שאתה מנסה לעשות זה להיפטר של קבוצות חוזרות. ובכן, היה להם טור והם עשו את זה ארוך, או BLOB או CLOB, ובתוכו היו שמים ערך, מספר אחד, פסיק, ערך מספר שתיים, פסיק, מספר ערך, פסיק, ויהיו להם אלפי ערכים שם, אבל הם היו צריכים לחפש בעמודה הזו והם כאילו, "מדוע הדבר הזה פועל כל כך איטי?" ואני כמו "טוב, אתה לא יכול ליצור אינדקס על מה שעשית, זה פשוט למעשה, הראנו להם, בעזרת התוכניות, שמה שהם צריכים לעשות זה לנרמל את השולחן. לא מכיוון שנורמליזציה היא תרגיל אקדמי שמשפר את המצב, אלא בגלל שהם רצו שאילתה בתחום זה, מה שאומר שהם רצו להיות מסוגלים לאינדקס אותו, ולא ניתן היה להוסיף אותו לאינדקס בקבוצה חוזרת, או לפחות לא בקלות . וכך זה כנראה הדבר הגרוע ביותר שראיתי.

דז בלנשפילד: כן, מעניין באיזו תדירות אתה נתקל, אני חושב שהאתגר עם בסיסי נתונים, אנשים שוכחים שזה מדע. ויש אנשים שעושים תארים ותואר שלישי בכל המרחב הזה, כותבים עליו עבודות, וכתבת מדף שלם כולל ספרי היד של TOAD ודברים אחרים מהזיכרון. המגמה לעבר "נתונים גדולים" מציטוט אחר ציטוט - אני רואה הרבה אנשים שוכחים את היסודות של ארכיטקטורת מסדי נתונים וטכנולוגיית בסיסי נתונים, מדעי בסיס נתונים, אם תרצו. מה אתה רואה בשטח ככל שהתרחק מפלטפורמות בסיס נתונים מסורתיות ומחשבי מסדי נתונים מסורתיים שעשינו מסמרות ביעילות, וזה היה רק ​​מקרה של כוונון ביצועים וקנה מידה. האם אתה רואה הרבה אנשים לומדים מחדש וחווים חוויה בה הם פשוט יושבים שם ויש להם רגע "אה", כמו רגע של יוריקה, איפה שהם מבינים, הדברים הגדולים של נתונים גדולים הם למעשה סוג של מסדי נתונים גדולים באמת? זה דבר בחוץ ואנשים עונים לך בחזרה וסוג של "שכחנו, מה שידענו והאם אתה יכול להחזיר אותנו מהצד האפל?"

ברט סקלזו: ובכן, לא, וזה נורא צריך להודות, אבל ספקי מסדי הנתונים היחסים שתו גם את Kool-Aid. אם אתה זוכר, אני לא יודע, לפני כעשור התחלנו להכניס נתונים לא מובנים למאגרי מידע יחסיים, וזה היה דבר מוזר לעשות, ואז הנתונים, מסדי הנתונים ההתייחסותיים, מוסיפים כעת את סוג ה- NoSQL דברים. למעשה, ב- Oracle 12, CR2 - אני יודע שהיא עדיין לא יצאה - אבל אם אתה מסתכל על הבטא, אם אתה בתוכנית בטא, זה תומך בריסוס. וכך, עכשיו יש לך מסד נתונים יחסי שלא הוסיף את הרעיון מנגני NoSQL. וכך, נראה שרגע ה"ה-חה "יותר מתאים לאנשים בצד ההתייחסותי שעוברים" א-חה. "אף אחד לא יעשה זאת שוב נכון, אפילו לא מנהלי בסיסי הנתונים, אז יש לנו עלי לעבור ולהצטרף לצד האפל.

דז בלנשפילד: נכון, אז אתה אומר מעבר להרבה נתונים מבולגנים, אם אני מבין נכון, מכניסים אותם למה שאנחנו מכנים עכשיו פלטפורמות ביג-נתונים, וזה די מצחיק, כי הם לא כל כך ישן, אבל זה לא אומר אז שהם מתמקדים מחדש במה שהם עושים עם מסד הנתונים ההתייחסותי שלהם כדי לקבל יותר חיסכון בדולרים שלהם?

ברט סקלזו: לא, בדרך כלל, אם יש להם צורך בכך - זה היה מצטט "צורך מסוג גדול של נתונים", הם מגלים שבמקום שהם צריכים ללכת לפלטפורמת מסד הנתונים האחרת ולעשות משהו בלא באופן יחסי, ספקי בסיסי הנתונים נותנים להם את אותן טכניקות לא קשורות בתוך מסד הנתונים היחסי שלהם, כדי לעשות את הדברים האלה. כלומר, דוגמה טובה לכך היא שאם יש לך נתונים לא מובנים, כמו סוג נתונים של JSON או סוג נתונים מורכב אחר שיש לו משמעות מוטמעת בנתונים עצמם, ספקי בסיסי הנתונים לא רק תומכים בזה, אלא הם יתנו לך חומצה תאימות לנתונים לא מובנים. מאגרי המידע ההתייחסותיים אימצו את הטכניקות והטכנולוגיות החדשות החדשות יותר, וכך, שוב, נראה ש"האה "הוא לא יותר מכך, " היי אנחנו, מפתחי האפליקציות, ביטלנו משהו ואנחנו צריכים ללמוד את זה שוב, "זה" היי, אנחנו עושים את זה ככה עכשיו, איך אני יכול לעשות את זה ככה במסד הנתונים ההתייחסותי המסורתי שלך ולעשות את זה כמו שאני עושה בבסיס הנתונים הזה כאן? "וזה הופך להיות נפוץ יותר, וכפי שאמרתי, ספקי מסדי הנתונים עצמם מאפשרים זה.

דז בלנשפילד: נכון, מי הם החשודים המסורתיים בחלל הזה לכלי DBarusan וזה? עשיתי שיעורי בית על מה שכתבת לאחרונה, ומהזיכרון כתבת משהו, אני חושב שזה היה אחד הבלוגים שלך, על ביצועי מסד נתונים קיצוניים בעולם האורקל. אני לא זוכר מתי זה היה, אני חושב שזה היה מתישהו השנה מהזיכרון, או מסוף השנה שעברה, כתבת את הדבר הזה. ונראה היה לי שזה החשוד המסורתי והרגיל לסוג הנושא עליו אנו מדברים היום, שם אנשים ילכו לסביבת מסדי נתונים רחבת היקף ויחפשו את מה שאתה מכנה רווחים קיצוניים בזה. מיהו החשודים הרגילים שאתה רואה שם, המנצלים את DBbrevan ומעבירים אותה לשימוש טוב?

ברט סקלזו: ובכן, יש לנו הרבה לקוחות, למעשה, היום הייתי עם סוכנות ממשלתית גדולה מאוד, שיש להם קרוב ל -1, 000 עותקים של התוכנה שלנו, מכיוון שהיא מאפשרת לאנשים להתמקד במה שהם עושה מחדש, ולא איך לעשות את זה. וזה בסדר, זאת אומרת, כולם צריכים לדעת לעשות משהו, אבל הפרודוקטיביות גורמת ל"מה "לעשות. אם העסק מבקש ממני לבצע משימה, זה כל מה שהם מעוניינים בו. מתי קיבלתי סימן ביקורת כדי לומר מתי הסתיימה המשימה? לא באיזו טכניקה או באיזה טכני יכולתי להגיע לשם. וכך, הכלי שלנו מאפשר להם להתמקד במה, ומאפשר להם להיות הרבה יותר פרודוקטיביים, וזה באמת היתרון העצום, וכמו שאמרתי, מסדי נתונים מסוימים מציעים כלי רק לפלטפורמת בסיס הנתונים שלהם. אנו מציעים זאת לשנים עשר פלטפורמות מסד נתונים. יש לי אותה זרימת עבודה, אותו ממשק משתמש גרפי, אותם ניווטים. אם אתה יודע להעניק הרשאה למשתמש או כיצד ליצור טבלה או ליצור אינדקס במסד נתונים, אתה יכול לעשות זאת בכל שתים עשרה כיוון שזהו אותו מראה ותחושה ואותו זרימת עבודה. יש לזה ערך עצום ללקוחות שלנו.

דז בלנשפילד: כן, אני מניח שאנשים רוצים לקבל הרבה יותר מכות בגלל הכסף שלהם מהמשאבים האנושיים שלהם. והימים של קיום מומחה אינדיבידואלי באורקל, אינגר ו- DB2 נעלמו כולם. אנשים צפויים להיות הג'ק של כל המקצועות, כך שלדעתי הדבר הזה הציל לחלוטין את חייהם.

רק דבר אחד אחרון מהיר לפני שאני מוסר אותו לדוקטור רובין בלור. הזכרת שיש הורדה בחינם למשך ארבעה עשר יום, מה עושה - אם אני הולך להתקדם ואני הולך לעשות את זה, אגב, אני הולך להכניס את זה למעבדה הטכנולוגית של Bloor ולסובב את הדבר הזה לקום ולשים יד על זה בעצמי - לא היה לי סיכוי לעשות את זה לפני היום. הזכרת משפט בן ארבעה עשר יום, אמרת שאתה מפעיל אותו ב- VM במחשב שלך, אני מניח שזה מחשב נייד. מה הם, מהי ההגדרה ברמת הכניסה של מישהו להתמודד ולהשתמש במראה של משפט בן ארבעה עשר יום, רגע לפני שאני מחזיר לרובין את שאלותיו?

Bert Scalzo: כל סביבת Windows, כך Windows 7, מחשב וירטואלי עם מעבד אחד וארבע הופעות זיכרון. אנחנו לא כלי שמן או יקר באמת. עכשיו אם היית רוצה להריץ את שרת מסד הנתונים שלך באותו VM באותה Windows, כן, היית צריך להוסיף עוד, אבל אם אתה מפעיל את מסד הנתונים שלך בשרת מסד נתונים או ב- VM נפרד, ה- VM לטעינה ו הפעל את המוצר שלנו הוא קל מאוד: מעבד אחד, ארבע הופעות זיכרון, כמעט כל גרסה של Windows - ואנחנו תומכים בשתי התקנות של שלושים ושתיים ושישים וארבעה סיביות. אבל אתה צריך להתקין את הלקוח של ספק מסד הנתונים שלך. אז אם רצית להתחבר ל- Oracle, אתה צריך להתקין את לקוח ה- SQL net, כי זה מה ש- Oracle דורש כדי שתוכל לדבר עם מסד נתונים.

דז בלנשפילד: זה נשמע די פשוט. אני חושב שדבר אחד מזה יותר מכל דבר שאני מקווה שאנשים הולכים לקחת ממנו, חוץ מההכרה שהכלי הזה הולך להציל את חייהם, הוא שהם צריכים ללכת להוריד אותו ולשחק עם זה, בהתחשב בכך שאתה מציע תקופת ניסיון בחינם של ארבעה עשר יום. וזה יכול לפעול במחשב הנייד הנוכחי שלהם בלי להתקין שום דבר נוסף, כי אם הם כבר מנהלים מסד נתונים, הם כבר עובדים עם מסדי נתונים, יש להם את כל הכלים האלו במקום והאם זה פועל ב- VM מקומי או על שולחן העבודה המקומי, זה נשמע כאילו זה לא כאב להתקין ולשחק איתו. אז אני ממליץ לאנשים לעשות זאת.

רובין, אני בטוח שיש לך שאלות ואריק, בטח יש לך כמה מהקהל, אז רובין, מה איתך לעבור אליך ואז בחזרה לאריק?

רובין בלור: כן, בסדר, ובכן יש לי דברים לומר, זאת אומרת, תמיד מצאתי את האזור הזה מרתק כי הוא היה - חתכתי עליו שיניים. אבל האמת היא, קרוב לוודאי שמאז שנת 1998, 1999, התייחסתי למה שאורקל מסוגלת למעשה. וכן, הכרתי את Sybase ו- Microsoft SQL Server, שניהם פשוטים יחסית למה שאורקל יכולה לעשות. הצחקתם אותי כשאתה מתכוון - כיסיתי את פי, כשהתחלת לדבר על שרשור. אורקל עשתה זאת לפני כן. אורקל הציגה בנקודה מסוימת בזמן, הם נלחצו מהרעיון התייחסתי לאובייקט, ולכן הם הציגו את היכולת ליצור סוג של תיעוד אובייקטים ואחסון אובייקטים באורקל, ושוחחתי עם אחד המהנדסים שלהם, משהו כמו זוג שנים אחרי שהציגו את זה ושאלתי כמה אנשים השתמשו בו, והוא אמר שאני חושב ששני לקוחות ניסו את זה וזהו. ואני חושב שאותו דבר יקרה אם הם יתחילו לנסות ולעשות דברים NoSQL טרנדיים. אתה יודע, אני חושב שזו טעות, כלומר, אני מעוניין במה מחשבותיך. בהחלט, הם - שותים את Kool-Aid. הם מרגישים שהם צריכים להיות מסוגלים להעלות טענות הדומות למאגרי המידע הגדולים של NoSQL כמו קסנדרה, אבל אתה יודע, האם זה נראה לך הגיוני?

ברט סקלזו: לא, מכית את הציפורן על הראש. בעיניי הייתי עושה, אם אני מתכוון לעשות יחסיות, אני אבחר בספק יחסי כמו Oracle או SQL Server או DB2 או Postgres, אבל אם אני הולך לעשות משהו שאינו יחסי, במרחב הנתונים הגדול, או במרחב ה- NoSQL, אני הולך לבחור את הכלי המתאים למשימה הנכונה. ואני לא חושב שזה יהיה באופן טבעי קודם כל לספק למסד הנתונים היחסי שלי. ואז אתה מוסיף לזה את הקמט האחר, כלומר מה זמין בענן? כל כך הרבה אנשים שרוצים להוציא את בסיס הנתונים שלהם. אז אתה צריך להסתכל על ספק הענן שלך ולהגיד, "אוקיי, מה אתה מספק, אילו מאגרי מידע יש לך בשבילי שמתאימים לצרכים שלי וכמה הם ניתנים לשירות, ולמען האמת מה התעריף או החיוב עבור השימוש במאגר זה בענן לשעה, או ליום. ולפי ג'יגה-בייט או טרה-בייט? "ומה שתמצא זה אולי כמה ממאגרי המידע החדשים יחסית כמו מונגו או קסנדרה. אולי המחירים שלהם זולים יותר, כך שאם אתה מתכוון לעשות נתונים גדולים מסוג ריבוי פטיבה, אולי צריך - רק מבחינת העלות - לקחת בחשבון את מסדי הנתונים של NoSQL בענן מכיוון שהם אולי הדרך היעילה ביותר לעשות זאת.

רובין בלור: כן, נכון. כלומר, סוג שלי - העניין במאגרי מידע יחסים מניסיוני - שאורכו מספיק כדי שיהיו צלקות, זה בטוח - יש המון שכל ישר שאם תתחיל ליישם אותו ו - אתה מבין מהי יחסיות למעשה, אני מתכוון, אני זוכר שעברתי פעם ייעוץ עם לקוח אחד, והם הובילו אותי לחדר והם עשו סוג של תרשים ישויות ויצרו טופס רגיל שלישי, מודל לאיך נראות המערכות העיקריות של החברה. היו בו כמאתיים וארבעים שולחנות והם אמרו, "נו, מה אתה חושב על זה? אנחנו הולכים לבנות מסד נתונים בשביל זה, "ואמרתי" מה אתה חושב על זה? "אמרתי, " אני לא חושב שזה יעבוד. "וזה בדיוק נכון, אתה יודע, כי הם הסתיימו למעלה כדי ליצור מבנה מסוים בתוך חיבורי אחת-עשרה דרכים. וזה הדבר שצריך להבין לגבי יחסיות. אז אני די מעוניין במונחים של כמה עיצוב רע אתה נתקל. זאת אומרת, אין לי שום בעיה עם DBbrevan - זה עושה דברים מאוד הגיוניים והעובדה שאתה יכול להציג בפלטפורמות מרובות, אני חושב, זה נפלא - אבל כמה אתה נתקל שם איפה העיצוב נושא איפה אנשים היו יכולים לפתור את עצמם כל מיני כאב לב אם הם נופלים לסכימה של כוכב במקום לקבל פתית שלג על זה, אתה יודע?

ברט סקלזו: טוב, אני לא רוצה להישמע כמו יומרני או יהיר, אבל הייתי אומר לעיתים קרובות יותר מאשר לא. ברור שרוב בסיסי הנתונים שאני מסתבך איתם בחוץ, יש להם בעיות או בעיות. וזה טוב, מכיוון שהכלים שלנו, כמו כלי האופטימיזציה של מסדי הנתונים שלנו, יכולים לעזור להם לפתור את הבעיות האלה, אבל, אבל מה שמאוד מצחיק אותי זה שהרבה מהבעיות הן אותן בעיות פשוטות שוב ושוב. בדיוק עבדתי עם לקוח שלשום שהיה לו שאלת הצטרפות אחת-עשרה דרכים, ואני כמו "אוקיי, למה לא השתמשת בסעיף?" והם כמו "טוב, לא עשיתי "אני לא יודע מה זה." ואז אמרתי, "ותראה את תת-הנבחרים שלך כאן במתאם שלך ולא-מתואם שלך, " אמרתי, "בחלק מהמקרים יש לך את הסעיף שלך ברמה העמוקה ביותר, התייחסות טבלה מהטופס החיצוני. "אמרתי, " זהו, העבירו אותו לרמה הנכונה, אל תטמיעו אותו עמוק יותר מכפי שיהיה, תבלבלו את האופטימיזציה. ”ועם כמה כמה ציוצים אנחנו לקח משהו שרץ כשעתיים והורד אותו לעשר דקות וזה היה פשוט - במקרה כזה לא עשינו שום דבר מלבד שיפור ה- SQL שהם כתבו. אני חושב שהבעיה היא שהרבה אוניברסיטאות והרבה אנשים שלומדים תכנות בסביבה לא אקדמית, הם לומדים את זה כתהליכי זמן מוקלט או כתהליך מונחה שורות והתייחסות היא מערכת שמכוונת מטבעה, וכך אתה צריך לחשוב בסטים כדי לכתוב SQL טוב.

רובין בלור: כן, אני חושב שזה בדיוק נכון. ואתה צריך להבין, זה דברים כמו שאנשים צריכים לדעת את ה- ABC של דברים כאלה. זה לא משנה. אתם לא תוכלו לעשות דברים רציונליים אם לא תבינו שאפילו בסיס נתונים מעוצב ומעוצב היטב, הצטרפות ייקח זמן, ומינים ייקח זמן. הם עושים זאת מכיוון שהעולם מעולם לא מצא דרך לגרום לאלה ללכת מהר. הם מצאו דרכים לארגן את הנתונים כך שהם ילכו מהר יותר מהאחרים, והרבה מההתלהבות שיש לי לומר עבור מסדי הנתונים של NoSQL היא פשוט שהם נמנעים מלהצטרף. הם פשוט מתחילים לבנות את מסדי הנתונים באותה התפשטות נתונים, כי אם תצטרף לאחד ממסדי הנתונים של NoSQL הם יונקים בעוצמה. אתה לא חושב?

ברט סקלזו: אה בהחלט. ואני צריך לצחוק כי התחלתי לאחור לפני מאגרי מידע יחסיים ובחזרה כאשר אינגר היה RTI, מכון טכנולוגיה רציונאלית, ולא היה לנו SQL, היו לנו שפות יחסיות לפני SQL. אני חושב שבאינגר, אז זה נקרא קוול. אז קיבלתם את הפרדיגמות הישנות של מסד הנתונים כמו רשת וגרפיקה גבוהה יותר או היררכית ועוברים את הפרדיגמות ההתייחסותיות אחרי כמה עשורים ועכשיו לי זה מרגיש שאנחנו חוזרים לכמעט היררכי שוב. זה כמעט כמו שחזרנו.

רובין בלור: כן, נכון. עדיף למסור לך לאריק, אני לוקח יותר מדי זמן, אבל יש לנו שאלות מהקהל, אריק?

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

ברט סקלזו: זה טוב.

אריק קוונהאג: גם שאלה סקרנית, אז רק FYI.

ברט סקלזו: לא, אתה לא צריך את הכלים שלנו. זו תכונה של Oracle, מדד הבלתי נראה. בעיקרון במילון הנתונים, אורקל פשוט שומרת פיסת מטא נתונים שאומרת, "מיטוב, התעלם מהמדד הזה. זה כאן, אבל אלא אם כן אתה מקבל הוראות פיזית דרך רמז ב-, רמז למיטוב בפקודה SQL, אל תשתמש בזה. "וכך, לא, אתה לא צריך את הכלים שלנו, ומבחינה מכל זה הוא אינדקס ישן רגיל, אתה יכול לראות אותו בכל כלי, זה פשוט האופטימיזציה תאמר, "נתעלם ממנו בעיבוד שאילתה רגיל." אתה צריך לכוון אותו אם אתה רוצה שהוא יתרגל. זה ממש שימושי לתרחיש שתיארתי שהוא אם אתה רוצה לבנות אינדקס בייצור אבל לא להסתכן בשבירת הדוחות, או בדברים שכבר פועלים, אבל אתה רוצה לבדוק אותם, אתה יכול לעשות את זה. בשביל זה זה הכי שימושי.

אריק קוואנה: אלה דברים טובים ואז הייתה כאן שאלה טובה נוספת. "מה עם כמה ממאגרי המידע החדשים בזיכרון? כיצד טכנולוגיית מסד הנתונים בתוך הזיכרון משנה את המשחק ביחס לאינדקס? "

ברט סקלזו: ילד, ובכן אנחנו - עכשיו זה טוב, אני שמח שמישהו שאל את השאלה הזו, אנחנו נצטרך ללכת עוד חצי שעה. לא, הזיכרון, זה תלוי בספק הנתונים. עכשיו, בדרך כלל, אני לא מדבר אלא שבחים על כל דבר שאורקל עושה כי זה מדהים הטכנולוגיה שהם בנו, אבל כשאתה קורע לאחור מתחת לכיסויים ואתה מסתכל על מה שיש בזיכרון באורקל, באורקל מסד נתונים, מה שבאמת הוא שמירת חנות השורות בדיסק והיא תקבל זיכרון בחנות עמודות, ואם אין מספיק זיכרון בכדי להחזיק את כל הטבלה, היא תחזור לחלקים; זה לא יתאים בזיכרון, לעשות את זה בשורה בחנות, וכך למעשה תוכלו לבחור נגד השולחן ובמחצית השולחן, אתם משתמשים באינדקס שמכה בשורות מסורתיות בשולחן, ובמחצית השנייה של הבחירה היא בעצם יוצאת ופשוט תופסת הכל מחיפוש בתוך הזיכרון, וכך, זה שונה באופן ש- SQL Server, למשל, יישמה את זה בטכנולוגיית Hekaton שלהם, אתה יודע, ו- SQL 2014, והיא שופרה ב- SQL 2016, אך במובנים מסוימים, שלהם היא גרסה אמיתית יותר של זיכרון, ולכל יישום יש יתרונות וחסרונות, אבל צריך להסתכל במבט תחת הכיסויים ולהבין. מכיוון שהיה לי לקוח שאמר "הו הזיכרון של הטבלה הזו - אני פשוט אצור את כל האינדקסים", ואני כמו "השולחן גדול מהזיכרון שיש לך בשרת, כך שבשלב מסוים חלק מהשאילתות נאלצות לפגוע בדיסק. "

אריק קוואנה: זה תיאור טוב; זה דברים טובים. ובכן, חברים, אנחנו הולכים לעשות עוד כמה שידורי אינטרנט עם החבר'ה האלה בשאר השנה הזו, תחזור בכל פעם ששמעת שברט נמצא במצגת כי אנחנו יודעים שהוא יודע את הדברים שלו. תמיד כיף לדבר עם המומחים. אנו מבצעים ארכיון של כל שידורי האינטרנט הללו לצפייה מאוחרת יותר. להלן פרטי הקשר של ברט שוב, וננסה לחפור את הקישור להורדה ולשלוח אותו גם באמצעות הדוא"ל, אך אתה תמיד יכול לשלוח דוא"ל שלך באמת: יש לנו עוד כמה שידורי אתרים שמזמינים את זה בשנה ואנחנו עושים את הקורס עכשיו, אז אנשים, אם יש נושאים שאתה באמת רוצה לשמוע עליהם בשנה הבאה, אל תתביישו: תשמרו על עצמכם, חברים, נדבר אתכם בפעם הבאה. ביי ביי.

שותף תוכן Techopedia

צוות Techopedia מסונף לקבוצת Bloor וניתן ליצור איתו קשר באמצעות האפשרויות מימין. למידע על האופן בו אנו עובדים עם שותפים בתעשייה לחץ כאן.

• פרופיל
• אתר אינטרנט