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

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

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

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

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

יש נקודה שלך באמת, היכה אותי, @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 ישר-up - הוא למעשה יתפוס את עסקת משתמש הקצה מקליק לדיסק, כל הדרך עד להצהרת 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. התמקד באתר זה לקבלת מידע רב ומעניין, כולל רשימה של כל הארכיונים שלנו של שידורי האינטרנט בעבר. אבל חברים, תודה גדולה לכולכם שם, לחברים שלנו באי.די.ארה, לרובין וכמובן לדז. ואנחנו נתייחס אליכם בשבוע הבא, אנשים. שוב תודה על הזמן ותשומת הלב. שמור על עצמך. ביי ביי.