התוכניות שהוצבו בצורה הטובה ביותר: חסכון בזמן, כסף ובעיות בתחזיות מיטביות

על ידי צוות Techopedia, 19 באפריל 2017

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

עליך להירשם לאירוע זה כדי לצפות בסרטון הווידאו. הירשמו לצפייה בסרטון.

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

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

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

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

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

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

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

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

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

לאחר שאמרתי את זה, אני חושב שאנחנו יכולים להעביר לריק.

אריק קוונהאג: בסדר, ריק, תן לי לתת לך את המפתחות לרכב ה- WebEx. קח את זה מפה.

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

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

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

כעת, יש לנו את הביקוש, יש לנו כמויות אדירות של נתונים. ואני לא ממש מדבר רק על נתונים גדולים, אני מדבר על שימוש בנתונים בכל מיני ארגונים. אבל מלווה את זה מצד אספקה, עבור אנשים שיכולים לנהל את המשאבים האלה, יש לנו ראשית, יש לנו סוג של מחסור ב- DBA. לפי נתוני הלשכה לסטטיסטיקה של העבודה, בין השנים 2014-2020 משרות ה- DBA רק הולכות וגדלות ב -11 אחוזים - עכשיו מדובר באנשים שיש להם תארים בתפקיד של DBA, אבל נדבר על זה בעוד שנייה - לעומת 40- עם אחוז שטח צמיחה נתונים שנתי. ויש לנו הרבה DBAs; בממוצע שאותו מחקר דיבר על הגיל הממוצע הוא די גבוה בהשוואה למקצועות IT אחרים. ואז יש לנו הרבה אנשים שעוזבים את התחום, לא בהכרח פורשים, אלא עוברים לאספקטים אחרים, נכנסים לניהול, או כל דבר אחר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אריק קוונהאג: יש לי את זה עכשיו, כן.

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

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

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

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

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

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

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

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

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

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

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

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

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

עכשיו, בנוסף לכל זה - ואחד הדברים שברור שאנחנו נתקלים בהם לא מעט בזמן האחרון הוא - ראשית, זה היה הכל, כולם מדליקים או עוברים ל- VMs. ועכשיו יש לנו הרבה אנשים שעוברים לענן. ויש המון שאלות שעולות סביב סוגים אלה של דברים. האם נראה לי הגיוני לעבור לענן? האם אני הולך לחסוך כסף על ידי מעבר לענן? אם הייתי שם את הדברים האלה ב- VM, על מחשב עם משאבים משותפים, כמה כסף אוכל לחסוך? אלה סוגים של שאלות, ברור שגם הם יגיעו. אז, הרבה דברים שכדאי לזכור, בעזרת Diagnostic Manager, אנו יכולים להוסיף ולמשוך מהסביבות הווירטואליות של VMware וגם Hyper-V. אנו יכולים גם להוסיף מקרים שנמצאים בענן, כך שהסביבות שלך כמו Azure DB למשל, או אפילו RDS, נוכל לשלוף מדדים גם מסביבות אלה.

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

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

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

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

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

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

ריק שרמן: אוקיי, נהדר. ואז מה העומס על המופעים עצמם עם כל הניטור הזה?

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

אז, זה יחסית יחסית למה שההגדרות שלך, באופן כללי, מחוץ לתיבה. זה בכל מקום בין 1-3 אחוזים תקורה, אך ישנם תנאים אחרים שיחולו. זה גם תלוי בכמה שאילתות נמל פועלות בסביבה שלך, נכון? זה תלוי גם בשיטת איסוף השאלות האלו ובאילו גרסאות SQL מדובר. כך, למשל, SQL Server 2005, אנו לא נוכל למשוך מאירועים מורחבים, ואילו אנו נמשכים ממעקב כדי לעשות זאת. אז זה יהיה קצת שונה מבחינת הדרך בה נלך לאיסוף נתונים אלה, אבל זה אמר, כמו שאמרתי, אנו משערים שכבר משנת 2004 עם המוצר הזה. זה היה הרבה זמן, יש לנו אלפי לקוחות, ולכן הדבר האחרון שאנחנו רוצים לעשות זה להיות כלי לניטור ביצועים שגורם לבעיות ביצועים (צוחק). וכך אנו מנסים להימנע מכך ככל האפשר, אך באופן כללי, כך שכ- 1-3 אחוזים הם כלל אצבע טוב.

ריק שרמן: אוקיי, וזה די נמוך, אז זה נהדר.

אריק קוואנה: טוב. רובין, יש לך שאלות?

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

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

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

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

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

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

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

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

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

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

רובין בלור: אוקיי, אריק, אני מניח שלקהל יש שאלה או שתיים?

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

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

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

קולט מנאלה: אל תאמין להייפ .

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

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

ועם זה, ניפרד מכם, אנשים. שוב תודה, נדבר איתך בפעם הבאה. שמור על עצמך. ביי ביי.