אמזון לאדום: מחיר נמוך יותר, ביצועים גבוהים יותר | שירותי האינטרנט של אמזון

אמזון לאדום: מחיר נמוך יותר, ביצועים גבוהים יותר | שירותי האינטרנט של אמזון

חותמת זמן: 26 באוקטובר 2023 6:10
צומת המקור: 2959258

כמו כמעט כל הלקוחות, אתה רוצה להוציא כמה שפחות, תוך כדי השגת הביצועים הטובים ביותר. זה אומר שאתה צריך לשים לב למחיר-ביצועים. עם האדום של אמזון, אתה יכול לקבל את העוגה שלך וגם לאכול אותה! Amazon Redshift מספקת עד פי 4.9 עלות נמוכה יותר למשתמש ועד פי 7.9 ביצועי מחיר טובים יותר ממחסני נתונים אחרים בענן על עומסי עבודה בעולם האמיתי תוך שימוש בטכניקות מתקדמות כמו קנה מידה במקביל לתמיכה במאות משתמשים במקביל, קידוד מחרוזת משופר לביצועי שאילתות מהירים יותר. , ו אמזון ללא שרתים לאדום שיפורי ביצועים. המשך לקרוא כדי להבין מדוע המחיר-ביצועים חשובים וכיצד ביצועי המחיר של Amazon Redshift הם מדד לכמה עולה להשיג רמה מסוימת של ביצועי עומס עבודה, כלומר החזר ROI על ביצועים (החזר על השקעה).

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

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

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

מחיר-ביצועים לעומסי עבודה בעולם האמיתי

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

כמה דוגמאות עדכניות למיטובי ביצועים המונעים על ידי טלמטריית צי כוללות:

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

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

כדי לדמות סוג זה של עומס עבודה, השתמשנו ב-benchmark שנגזר מ-TPC-DS עם מערך נתונים של 100 GB. TPC-DS הוא אמת מידה סטנדרטית בתעשייה הכוללת מגוון שאילתות אופייניות למחסני נתונים. בקנה מידה קטן יחסית זה של 100 ג'יגה-בייט, שאילתות ב-benchmark זה פועלות ב-Redshift Serverless תוך מספר שניות בממוצע, מה שמייצג את מה שמשתמשים הטוענים לוח מחוונים אינטראקטיבי של BI מצפים. הרצנו בין 1-200 בדיקות בו-זמנית של רף זה, המדמים בין 1-200 משתמשים המנסים לטעון לוח מחוונים בו-זמנית. חזרנו גם על הבדיקה מול כמה מחסני נתונים חלופיים פופולריים בענן שתומכים גם בקנה מידה אוטומטי (אם אתה מכיר את הפוסט אמזון Redshift ממשיכה בהובלת המחיר-ביצועים שלה, לא כללנו מתחרה A מכיוון שהוא לא תומך בהגדלה אוטומטית). מדדנו זמן תגובה ממוצע לשאילתות, כלומר כמה זמן ימתין משתמש לסיום השאילתות שלו (או לטעינת לוח המחוונים שלו). התוצאות מוצגות בתרשים הבא.

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

כאן, Redshift Serverless מסוגל לשמור על זמן התגובה לשאילתה עקבי יחסית בסביבות 5 שניות גם כאשר מאות משתמשים מריצים שאילתות בו-זמנית. זמני התגובה הממוצעים לשאילתות עבור מתחרים B ו-C גדלים בהתמדה ככל שהעומס על המחסנים גדל, מה שגורם למשתמשים להמתין זמן רב יותר (עד 16 שניות) עד שהשאילתות שלהם יחזרו כאשר מחסן הנתונים תפוס. המשמעות היא שאם משתמש מנסה לרענן לוח מחוונים (שעשוי אפילו לשלוח כמה שאילתות במקביל בעת טעינה מחדש), אמזון Redshift תוכל לשמור על זמני הטעינה של לוח המחוונים עקביים הרבה יותר גם אם לוח המחוונים נטען בעשרות או מאות אחרים. משתמשים בו זמנית.

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

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

התוצאות הקודמות הן פשוטות לשכפול. כל השאילתות המשמשות ב-benchmark זמינות אצלנו מאגר GitHub והביצועים נמדדים על ידי השקת מחסן נתונים, הפעלת קנה מידה במקביל ב- Amazon Redshift (או תכונת השינוי האוטומטי המקביל במחסנים אחרים), טעינת הנתונים מהקופסה (ללא כוונון ידני או הגדרה ספציפית למסד נתונים), ולאחר מכן הפעלת זרם בו-זמני של שאילתות בזמנים בין 1-200 בשלבים של 32 בכל מחסן נתונים. אותו ריפו של GitHub מפנה לנתוני TPC-DS שנוצרו מראש (ולא השתנו). שירות אחסון פשוט של אמזון (Amazon S3) בהיקפים שונים באמצעות ערכת יצירת הנתונים הרשמית TPC-DS.

אופטימיזציה של עומסי עבודה עתירי מחרוזת

כפי שהוזכר קודם לכן, צוות אמזון Redshift מחפש ללא הרף הזדמנויות חדשות לספק ביצועי מחיר טובים עוד יותר ללקוחותינו. שיפור אחד שהשקנו לאחרונה ששיפור משמעותי בביצועים הוא אופטימיזציה שמאיצה את הביצועים של שאילתות על פני נתוני מחרוזת. לדוגמה, ייתכן שתרצה למצוא את סך ההכנסות שנוצרו מחנויות קמעונאיות הממוקמות בעיר ניו יורק באמצעות שאילתה כמו SELECT sum(price) FROM sales WHERE city = ‘New York’. שאילתה זו מיישמת פרידיקט על נתוני מחרוזת (city = ‘New York’). כפי שאתה יכול לדמיין, עיבוד נתוני מחרוזת נמצא בכל מקום ביישומי מחסני נתונים.

כדי לכמת באיזו תדירות גישה למחרוזות עומסי העבודה של לקוחות, ביצענו ניתוח מפורט של השימוש בסוג נתוני מחרוזת באמצעות טלמטריית צי של עשרות אלפי אשכולות לקוחות המנוהלים על ידי Amazon Redshift. הניתוח שלנו מצביע על כך שב-90% מהאשכולות, עמודות מחרוזות מהוות לפחות 30% מכלל העמודות, וב-50% מהאשכולות, עמודות מחרוזות מהוות לפחות 50% מכלל העמודות. יתרה מכך, רוב כל השאילתות המופעלות על פלטפורמת מחסני הנתונים בענן של Amazon Redshift גישה לפחות עמודת מחרוזת אחת. גורם חשוב נוסף הוא שנתוני המחרוזת הם לעתים קרובות מאוד קרדינליות נמוכה, כלומר העמודות מכילות קבוצה קטנה יחסית של ערכים ייחודיים. לדוגמה, למרות ש-an orders טבלה המייצגת נתוני מכירות עשויה להכיל מיליארדי שורות, א order_status העמודה בתוך טבלה זו עשויה להכיל רק כמה ערכים ייחודיים על פני מיליארדי שורות אלה, כגון pending, in process, ו completed.

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

כדי לשפר עוד יותר את ביצועי המחיר עבור עומסי עבודה כבדי מחרוזת, אמזון Redshift מציגה כעת שיפורי ביצועים נוספים שמאיצים סריקות והערכות פרדיקט, על פני עמודות מחרוזות עם קרדינליות נמוכה המקודדות כ-BYTEDICT, מהר יותר פי 5-63 (ראה תוצאות ב- הסעיף הבא) לעומת קידודי דחיסה חלופיים כגון LZO או ZSTD. אמזון Redshift משיגה שיפור ביצועים זה על ידי העברת סריקות וקטוריות על פני עמודות מחרוזות קלות משקל, חסכוניות במעבד, מקודדות BYTEDICT, עם קרדינליות נמוכה. אופטימיזציות אלה של עיבוד מחרוזות עושות שימוש יעיל ברוחב הפס של הזיכרון שמעניקה החומרה המודרנית, ומאפשרות ניתוח בזמן אמת על נתוני מחרוזת. יכולות ביצועים אלה שהוצגו לאחרונה הן אופטימליות עבור עמודות מחרוזות עם קרדינליות נמוכה (עד כמה מאות ערכי מחרוזת ייחודיים).

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

תוצאות ביצועים

כדי למדוד את השפעת הביצועים של שיפורי המחרוזת שלנו, יצרנו מערך נתונים של 10TB (Tera Byte) שהורכב מנתוני מחרוזות בעלי קרדינליות נמוכה. יצרנו שלוש גרסאות של הנתונים באמצעות מחרוזות קצרות, בינוניות וארוכות, התואמות לאחוזון ה-25, ה-50 וה-75 של אורכי המחרוזות מטלמטריית הצי של אמזון Redshift. טענו את הנתונים האלה לאמזון Redshift פעמיים, קידוד אותם במקרה אחד באמצעות דחיסת LZO ובמקרה אחר באמצעות דחיסת BYTEDICT. לבסוף, מדדנו את הביצועים של שאילתות כבדות סריקה שמחזירות שורות רבות (90% מהטבלה), מספר שורות בינוני (50% מהטבלה), וכמה שורות (1% מהטבלה) מעל הנמוכים הללו. מערכי נתונים של מחרוזת קרדינליות. תוצאות הביצועים מסוכמות בתרשים הבא.

שאילתות עם פרדיקטים התואמים לאחוז גבוה של שורות ראו שיפורים של פי 5-30 עם הקידוד החדש של BYTEDICT הווקטורי בהשוואה ל-LZO, בעוד שאילתות עם פרדיקטים התואמות לאחוז נמוך של שורות ראו שיפורים של פי 10-63 במדד פנימי זה.

הסחה לאדום שרת ללא ביצועים במחיר

בנוסף לתוצאות הביצועים בו-זמנית גבוהה המוצגות בפוסט זה, השתמשנו גם במבחן ה-Cloud Data Warehouse שמקורו ב-TPC-DS כדי להשוות את ביצועי המחיר של Redshift Serverless למחסני נתונים אחרים המשתמשים במערך נתונים גדול יותר של 3TB. בחרנו במחסני נתונים שתומחרו באופן דומה, במקרה זה בטווח של 10% מ-$32 לשעה תוך שימוש בתמחור זמין לפי דרישה. תוצאות אלו מראות שכמו מופעי Amazon Redshift RA3, Redshift Serverless מספקת ביצועי מחיר טובים יותר בהשוואה למחסני נתונים מובילים אחרים בענן. כמו תמיד, ניתן לשכפל את התוצאות הללו על ידי שימוש בסקריפטים של SQL שלנו מאגר GitHub.

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

מצא את המחיר-ביצועים הטובים ביותר לעומסי העבודה שלך

אמות המידה המשמשות בפוסט זה נגזרים ממבחן TPC-DS הסטנדרטי בתעשייה, ויש להם את המאפיינים הבאים:

  • הסכימה והנתונים משמשים ללא שינוי מ-TPC-DS.
  • השאילתות נוצרות באמצעות ערכת TPC-DS הרשמית עם פרמטרי שאילתה שנוצרו באמצעות ברירת המחדל הזרע האקראי של ערכת TPC-DS. גרסאות שאילתות מאושרות TPC משמשות עבור מחסן אם המחסן אינו תומך בניב SQL של ​​שאילתת ברירת המחדל של TPC-DS.
  • הבדיקה כוללת את 99 שאילתות ה-TPC-DS SELECT. זה לא כולל שלבי תחזוקה ותפוקה.
  • עבור מבחן ה-3TB הבודד במקביל, בוצעו שלוש ריצות כוח, והריצה הטובה ביותר נלקחת עבור כל מחסן נתונים.
  • מחיר-ביצועים עבור שאילתות TPC-DS מחושבים כעלות לשעה (USD) כפול זמן הריצה של המדד בשעות, השווה לעלות להפעלת ה-benchmark. התמחור האחרון שפורסם לפי דרישה משמש עבור כל מחסני הנתונים ולא בתמחור של מופע שמור כפי שצוין קודם לכן.

אנו קוראים לזה מדד Cloud Data Warehouse, ותוכל לשחזר בקלות את תוצאות המדד הקודמות באמצעות הסקריפטים, השאילתות והנתונים הזמינים שלנו מאגר GitHub. הוא נגזר ממדדי ה-TPC-DS כמתואר בפוסט זה, וככזה אינו בר השוואה לתוצאות TPC-DS שפורסמו, מכיוון שתוצאות הבדיקות שלנו אינן תואמות למפרט הרשמי.

סיכום

Amazon Redshift מחויבת לספק את ביצועי המחיר הטובים ביותר בתעשייה עבור המגוון הרחב ביותר של עומסי עבודה. Redshift Serverless מוגדל באופן ליניארי עם ביצועי המחיר הטובים (הנמוכים ביותר), תמיכה במאות משתמשים במקביל תוך שמירה על זמני תגובה עקביים לשאילתות. בהתבסס על תוצאות הבדיקה שנדונו בפוסט זה, לאמזון Redshift יש עד פי 2.6 ביצועי מחיר טובים יותר באותה רמת במקביל בהשוואה למתחרה הקרוב ביותר (מתחרה B). כפי שהוזכר קודם לכן, שימוש במופעים שמורים עם אפשרות 3 שנים הכל מראש נותן לך את העלות הנמוכה ביותר להפעלת אמזון Redshift, וכתוצאה מכך ביצועי מחיר יחסי טובים אפילו יותר בהשוואה לתמחור מופע לפי דרישה שהשתמשנו בו בפוסט זה. הגישה שלנו לשיפור ביצועים מתמשך כוללת שילוב ייחודי של אובססיה של לקוחות להבנת מקרי שימוש בלקוחות וצווארי הבקבוק הקשורים להרחבה בשילוב עם ניתוח נתוני צי מתמשך כדי לזהות הזדמנויות לבצע אופטימיזציות משמעותיות של ביצועים.

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

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

על המחברים

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

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

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

Sanket Hase הוא מנהל פיתוח תוכנה בצוות שירות אמזון Redshift.

Orestis Polychroniou הוא מהנדס ראשי בצוות שירות ההיסט האדום של אמזון.

בול זמן:

עוד מ AWS Big Data