אל העתיד: רמפה למחשבי זיכרון

על ידי צוות Techopedia, 25 בינואר 2017

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

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

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

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

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

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

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

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

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

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

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

ואז יש לנו את הופעתם של 3D XPoint ו- PCM של IBM. וזה כמעט מהירויות זיכרון RAM, זה בעצם מה ששני הספקים הללו מתהדרים בו. מקרי השימוש הם ככל הנראה שונים. הניסוי המוקדם עם זה טרם הושלם. איננו יודעים כיצד זה ישפיע על השימוש ב- RAM וטכנולוגיה של מסד הנתונים בתוך הזיכרון לצורך העניין. יש לך זיכרון RAM לעומת SSD. נכון לעכשיו ה- RAM מהיר פי 300 בערך, אך כמובן שמכפיל זה הולך ופוחת. ו- SSD לעומת דיסק שהוא מהיר פי 10, אם אני מבין אותו. אז זהו סוג הסיטואציה שיש לכם. זו חנות היררכית. התבוננות בזה בדרך אחרת, הזיכרון, כמובן, שונה לחלוטין. אז, התרשים העליון מראה שני יישומים, שניהם אולי ניגשים למסד נתונים, אך בהחלט ניגשים לנתונים על חלודה מסתובבת. והדרך בה אתה באמת גורם לדברים לזרום דרך הרשת, תלוי באילו תלות יש, האם יש לך ETL. אז המשמעות היא שידוע לכם שהנתונים עוברים חלודה מסתובבת ואז יורדים מסתובבים חלודה על מנת ללכת לשום מקום, וכדי להגיע לכל מקום הם חוזרים לחלודה מסתובבת, שהיא שלוש תנועות. וקחו בחשבון שהזיכרון יכול להיות מהיר פי מאה מהדיסק המסתובב, ואתם בהחלט מבינים שלקחת נתונים ולהכניס אותם לזיכרון הופכת את כל הדבר הזה למשהו אחר לגמרי.

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

אז זהו סוג ענק של השפעה. אז הזיכרון משבש, נכון? ועלינו לקבל את זה ממה שאמרתי. עיבוד בזיכרון כרגע מאיץ אך הוא יהפוך לנורמה. זה ישמש, מיושם לפי ערך היישום, ולכן מאוד מאוד מעניין, ש- SAP תצא עם גירסת תוכנת ה- ERP שלהם בזיכרון. ושיפורי חביון עד שלושה סדרי גודל אפשריים לחלוטין, ולמעשה אפילו יותר מזה אפשרי, תלוי איך תעשה זאת. אז, אתה מקבל שיפורים אדירים במהירות על ידי כניסה לזיכרון. והתוצאה, S / 4 של SAP HANA - שהם הוציאו, אני חושב, ובכן, אנשים אומרים שזה עדיין יוצא, אבל הוא בהחלט שוחרר בשנה שעברה - זה מחליף משחק בהתחשב בבסיס הלקוחות של SAP. זאת אומרת, יש 10, 000 חברות בחוץ המשתמשות ב- ERP של SAP ודי כמעט כולן חברות גדולות, אתה יודע. אז הרעיון שלכולם יש תמריץ להכנס לזיכרון ולהשתמש ביסודות שלהם, מכיוון ש- ERP כמעט תמיד הם יישומים בסיסיים שעסקים מפעילים, זה פשוט מחליף משחק ענק וזה יהיה מאוד מעניין. אבל כמובן, הכל נשמע טוב מאוד, אבל זה צריך להיות מוגדר בצורה מושכלת ויש צורך לפקח עליו היטב. זה לא פשוט כמו שזה נשמע.

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

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

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

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

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

אבל רק בקצרה כיצד הגענו לכאן. כלומר, טכנולוגיית החומרה השתפרה והשתפרה באופן דרמטי. עברנו מלהיות מעבדים והרעיון של ליבה היה מושג מודרני למדי. אנו לוקחים את זה כמובן מאליו ברגע שיש לטלפונים שלנו שתיים או ארבע ליבות ובמחשבים שלנו יש שתיים או ארבע, או אפילו שמונה ליבות בשולחן העבודה ושמונה ו -12 ועוד, אתה יודע, ה- 16 ו -32 אפילו בפלטפורמת השרת . אבל זה למעשה דבר די מודרני שהליבות הפכו ליכולת בתוך מעבדים ושאנחנו עברנו מ 32 סיביות ל 64 סיביות. אירעו שם כמה דברים גדולים: קיבלנו מהירויות שעון גבוהות יותר על מספר ליבות כדי שנוכל לעשות דברים במקביל וכל אחת מהליבות הללו תוכל להריץ חוטים מרובים. פתאום יכולנו להריץ המון דברים באותו נתונים בו זמנית. מרווח כתובות של שישים וארבעה סיביות העניק לנו שני טרה-בייט של זיכרון RAM, שזה מושג פנומנלי, אבל זה דבר עכשיו. ארכיטקטורות המישור האחורי של ריבוי הדרך, אתם יודעים, לוחות אם, פעם יכולתם לעשות דברים רק בכיוון אחד: אחורה וקדימה. וכמו בימים עם מחשוב Cray וכמה מעיצבי מחשב העל של אותה תקופה, ועכשיו במחשבים שולחניים ומחשבים נפוצים מחוץ למדף, מעין מחשבים שולחניים המותאמים למחשבים שולחניים, כי באמת, רוב המודרני מחשבים אישיים עברו עידן זה של שולחנות עבודה של מיינפריים, בינוני, מיקרו והפכנו אותם שוב לשרתים.

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

התוכנה גם השתפרה, בעיקר ניהול זיכרון וחלוקת נתונים. אני לא אכנס הרבה פרטים על זה, אבל אם אתה מסתכל על השינוי הגדול ב -15 השנים האחרונות, או אפילו פחות מכך, כיצד מנוהל הזיכרון, במיוחד נתונים ב- RAM ואיך הנתונים מחולקים ב- RAM, כך שכפי שד"ר רובין בלור ציין קודם או הרמז אליו, אתה יודע, דברים יכולים לקרוא ולכתוב בו זמנית מבלי להשפיע זה על זה, במקום שיהיו להם זמני המתנה. הרבה תכונות מאוד עוצמתיות כמו דחיסה והצפנה בשבב. ההצפנה הופכת לדבר חשוב יותר ואנחנו לא חייבים לעשות זאת בהכרח בתוכנה, ב- RAM, במרחב מעבד, עכשיו זה קורה בפועל על השבב באופן טבעי. זה מזרז את הדברים בצורה דרמטית. וחילקנו אחסון ועיבוד נתונים, שוב, דברים שהנחנו פעם שהם מחשבי-על ועיבוד מקביל, אנו לוקחים זאת כמובן מאליו במרחב של אנשים כמו SAP HANA ו- Hadoop and Spark, וכן הלאה.

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

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

בעיניי זו אנלוגיה נהדרת לאיך לבנות את הפלטפורמות המאוד מורכבות האלה, כי הכל טוב ויפה לבנות אותה ובסופו של דבר עם סביבה שיש לך נתבים ומתגים ושרתים ומתלים. ויש לך מעבדים ו- RAM ומערכת הפעלה מקובצים זה לזה. ואתה שם משהו כמו HANA לעיבוד בזיכרון המופץ ואחסון נתונים וניהול נתונים. אתה בונה את ערימת ה- SAP על גבי זה, אתה מקבל את יכולות בסיס הנתונים ואז אתה טוען את הנתונים שלך ואת ההיגיון העסקי שלך ומתחיל ליישם עליו כמה קריאות וכתובות ושאלות וכן הלאה. עליכם להמשיך ולהקפיד על קלט / פלט ועליכם לתזמן דברים ולנהל עומסי עבודה ורב-גומלין וכדומה. ערימה זו הופכת למורכבת מאוד, מהר מאוד. זו ערימה מורכבת בפני עצמה אם היא רק על מכונה אחת. הכפל את זה ב 16 או 32 מכונות, זה נהיה מאוד מאוד לא טריוויאלי. כשאתה מכפיל עד מאות ובסופו של דבר אלפי מכונות, לעבור מ- 100 טרה-בייט לסולם פטה-בייט, זה מושג מפחיד, ואלה המציאויות שאנו עוסקים בהן כעת.

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

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

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

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

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

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

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

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

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

ועם זה בראש אני הולך למסור לחברנו מ- IDERA ולשמוע איך הם ניגשו לאתגר הזה.

ביל אליס: תודה רבה. אני משתף את המסך שלי והנה. אז, זה באמת משפיל פשוט לקחת בחשבון את כל הטכנולוגיה, ואת כל האנשים שבאו לפנינו, כדי להפוך את החומר הזה שזמין בשנת 2017, לזמין. אנו מדברים על ניתוח עומסי עבודה עבור SAP HANA - בעיקרון, פיתרון לניטור בסיסי נתונים: מקיף, חסר סוכן, מספק זמן אמת והוא בונה היסטוריה, וכך תוכלו לראות מה קרה בעבר. SAP S / 4 HANA מציע את הפוטנציאל של טוב יותר, מהיר יותר וזול יותר. אני לא אומר שזה לא יקר, אני רק אומר שזה פחות יקר. מה שבאופן מסורתי מה שקרה היה שיהיה לך מופע ייצור ראשי - כנראה שרץ ב- Oracle בחנות גדולה יותר, פוטנציאלית SQL Server - ואז היית משתמש בתהליך ETL ההוא והיו לך מספר גרסאות של סוג האמת. . וזה יקר מאוד מכיוון ששילמת עבור חומרה, מערכת הפעלה, רישיון אורקל עבור כל אחת מהסביבות הבודדות הללו. ואז נוסף על כך, תצטרך שאנשים יתפייסו גרסה אחת של האמת לגירסה הבאה של האמת. וכך, עיבוד ה- ETL בעל מספר הגרסאות היה פשוט איטי ומאוד מסורבל.

וכך, HANA, בעצם מופע HANA אחד, יכול להחליף את כל אותם מקרים אחרים. אז זה פחות יקר מכיוון שמדובר בפלטפורמת חומרה אחת, מערכת הפעלה אחת, במקום מכפילים. וכך ה- S / 4 HANA, באמת, זה משנה הכל ואתה בעצם בוחן את ההתפתחות של SAP מ- R / 2 ל- R / 3, חבילות השיפור השונות. עכשיו, מערכת מורשת זמינה עד 2025, כך שיש לך שמונה שנים עד שאתה באמת נאלץ לעבור. למרות שאנו רואים אנשים, אתם יודעים, מכניסים את בהונותיהם לנוכח זה כי הם יודעים שזה בא ובסופו של דבר, אתם יודעים, ECC יתמודד על HANA וכך באמת הייתם צריכים להיות מוכנים לזה ולהבין את הטכנולוגיה.

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

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

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

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

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

אתה יכול לקבל מספר משתמשים להתחבר למופע מסוים. אתה יכול לפקח על מקרים מקומיים של SAP HANA. ואנחנו מנהלים היסטוריה של ארבעה שבועות במאגר שלנו וזה מנוהל על ידי עצמנו. לפרוס את זה, זה די פשוט. אתה צריך שרת Windows. אתה צריך להוריד אותו. לרוב שרתי Windows תהיה מסגרת מובנית .NET והיא כוללת רישיון. וכך תעבור לאשף ההתקנה המונע על ידי Setup.exe והוא למעשה יפתח מסך, הסכם רישיון, ופשוט תעבוד על המתווה הזה על ידי לחיצה על "הבא". וכך, איפה היית רוצה ש- HANA להתקין? הבא הוא מאפייני מסד נתונים, וזה הולך להיות החיבור שלך ל- SAP HANA, כך שמדובר בפיקוח ללא סוכן אחר מופע HANA. ואז בעצם ניתן תצוגה מקדימה, זה היציאה שאנו מתקשרים עליה כברירת מחדל. לחץ על "התקן" וזה בעצם מפעיל את HANA ותתחיל לבנות את ההיסטוריה. אז, רק קצת ממידע על תרשים הגודל. אנו יכולים לפקח על עד 45 מופעי HANA, ואתה תרצה להשתמש בסוג כזה בסולם הזזה כדי לקבוע את מספר הליבות, הזיכרון, שטח הדיסק הדרוש לך. וזה מניח שיש לך היסטוריה מלאה של ארבעה שבועות שמתגלגלת.

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

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

עכשיו, אני מראה לך רק מסך סיכום אחד. יש כמה טעימות שאני רוצה שיהיו לך ממסך הסיכום הזה. זה זמן התגובה של ציר ה- Y, ​​זמן ציר ה- X בתוספת היום, ובתצוגת עסקה זו נראה לך זמן לקוח, זמן תור, זמן קוד ABAP, זמן מסד נתונים. אנו יכולים ללכוד מזהי משתמש קצה, קודי T ותוכלו למעשה לסנן ולהראות שרתים באמצעות עסקה מסוימת שנחוצה. וכך, חנויות רבות מנהלות את הקצה הקדמי של הנוף תחת VMware, כך שתוכלו באמת למדוד את המתרחש בכל אחד מהשרתים ולהיכנס לניתוח מאוד מפורט. אז, תצוגת עסקאות זו מיועדת לעסקת משתמש הקצה דרך כל נוף SAP. ותוכלו למצוא שבאתר שלנו תחת מוצרים APM Tools וזה יהיה פיתרון SAP שיש לנו. ההתקנה לכך מורכבת מעט יותר, כך שהיא לא רק להוריד ולנסות אותה, כמו שיש לנו HANA. זה משהו בו נעבוד יחד כדי לבצע, לתכנן וליישם את העסקה הכוללת עבורך.

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

אז עם זה, אני אעביר את הזמן לאריק, דז וד"ר בלור.

אריק קוואנה: כן, אולי רובין, יש לך שאלות, ואז דז 'אחרי רובין?

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

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

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

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

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

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

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

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

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

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

דז בלנשפילד: תודה. לא, הכל טוב. שניים מהירים מאוד, רק כדי לנסות להגדיר את הנושא. SAP HANA כבר בחוץ כבר כמה שנים ולאנשים יש סיכוי לשקול זאת. אם היית נותן לנו הערכה גסה לאחוז האנשים המנהלים את זה - מכיוון שיש הרבה אנשים שמנהלים את הדברים האלה - מה אתה חושב שאחוז השוק שאתה מודע אליו הוא כרגע שהלך רק מהטמעות SAP מסורתיות ועד SAP ב- HANA? האם אנו מסתכלים על 50/50, 30/70? מה, אחוז מהשוק, אתה רואה לאנשים שעברו ועברו את המהלך עכשיו לעומת אנשים שרק מתאפקים ומחכים שהדברים ישתפרו או ישתפרו או ישתנו או מה שלא יהיה?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ביל אליס: כן.

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

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

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

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

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

ביל אליס: בהחלט.

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