סיכום תהליך בחינת MSSQL לעומת Snowflake. השוואת ביצועים של תהליכי עיבוד, שאילתות אנליטיות, עלויות ועוד.
ה-POC רלוונטי לכל מי שעובד עם MSSQL על שרתי On-Prem. אין להתייחס לנתונים כהשוואה בין שתי הטכנולוגיות באופן גורף. מדובר על בחינה של מקרה פרטני. עם זאת חשוב לציין שאלו התוצאות שאנחנו רואים ברוב המקרים.
תאור ה-Use Case
הלקוח רץ על שרתי MSSQL בענן פרטי עם כ-200 מליון רשומות בחודש. נדרש לעשות תהליכי טעינה שוטפים ולהגיע לעדכניות נתונים הקרובה ביותר לזמן אמת. הבעיה, מחזור טעינה כיום לוקח כ-4 שעות.
בנוסף, אחת לשנה / שנה וחצי השרתים מגיעים לעומס גבוה שדורש לשדרג. ישנו חשש להכניס מודלים חדשים שיעמיסו עוד יותר על המערכת. ההצעה לפתרון, מעבר לטכנולוגיית SAAS סקיילבילית - Snowflake על תשתית גוגל.
הנתונים
נטענו לסנופלייק כ-4 טבלאות עם 200 מליון רשומות המייצגות חודש נתונים. ועוד כ-40 טבלאות אחרות. להלן דוגמא:
השלבים ב-POC
שלב א׳ - יצירת הטבלאות
יצרנו את כל טבלאות היעד. כל עמודות ה varchar הוחלפו אוטומטית ל String, ההתאמות ב-DDL ליצירת הטבלאות היו מינוריות.
שלב ב׳ - טעינת הנתונים
טענו את הנתונים לסנופלייק. העלנו את קבצי ה-CSV ל-GCS, יצרנו Stage בסנופלייק הממופה ל-storage בגוגל. טעינת קבצים הקבצים מה-stage נעשתה בקלות באמצעות פקודת insert או Copy) שהציגה ביצועים טובים יותר אבל, בגלל מבנה הקבצים, לא התאפשר להריץ אותה על כל הטבלאות)משך הטעינה המצורף כאן אינו מייצג את השוטף, שכן הוא כולל טעינת חודש נתונים ולרוב הטעינה שעתית, אך בכל זאת ראינו לנכון לצרף את זמן טעינה כדי לקבל מושג. שימו לב שזה לא כולל את זמן ההעלאה של הקובץ ל-GCS.
שלב ג', הסבת הסקריפטים
הסבת הפרוצדורות (Stored procedures) לשאילתות סנופלייק. יצרנו מעטפת פשוטה בפייתון שמריצה קבצי SQL והתחלנו להמיר את השאילתות והתהליכים לסנופלייק. 90% מהסקריפטים היו פשוטים מאד ותאמו לסנופלייק, המקומות בהם נדרשנו לעשות התאמות היו:
סינטקס בסיסי - isnull, insert into temp tables - וכד׳
המרת Cursor-ים לשאילתות. ברוב המקרים היה ניתן להמיר ל-Join
שינוי Cross Apply ל-Left join עם Case
פונקציות משתמש
שלב ד, הרצת תהליכים והשוואת ביצועים
כאמור שרת ה-MSSQL הינו שרת 16 קורים עם 190 ג'יגה זכרון, לא שרת קטן. בסנופלייק ניתן לבחור דינמית על איזה גודל משאבים להריץ (ניתן אפילו לשנות תוך כדי התהליך אם רק חלק מהתהליכים דורשים יותר משאבים). אך במקרה שלנו השתמשמנו ב-Warehouse (יחידת עיבוד וירטואילית בסנופלייק) בגודל X-Small, הקטן ביותר שיש.
תוצאות תהליכי העיבוד (Job)
תוצאות של שאילתות נבחרות
Snowflake can Scale
כדי להמחיש את ה- Scale לקחנו את השאילתא הימנית שלא מסתיימת ב-MSSQL והרצנו אותה על מספר גדלים של Warehouses כדי להראות את הגמישות שניתן לקבל במעבר לסנופלייק
הערכת עלויות
השתמשנו במחשבון שיצרנו ב-Snowly כדי להעריך את מספר ה-Credits ביום לאחר ההסבה. עלות Credit אחת מתשנה לפי הגרסה, ה-Resion, הענן והפיצ׳רים בשימוש. בגדול המחיר נע בין 2 ל-4 דולר לקרדיט.
נתחיל ב-SQL Server. כיום הלקוח רץ על ענן פרטי, עם שרת 16 Cores, 191 Gb RAM יחד עם עלות הרישוי של MSSQL התשלום החודשי עומד כיום על כ-2500$ לחודש.
כדי להשוות עלויות נתחיל במעבר As Is, כמה יעלה לקבל את מה שיש ללקוח כיום. כלומר, עדכניות נתונים של כל 4 שעות (משך ריצת ה-ETL). במצב זה סנופלייק ירוץ כל 4 שעות, יעבד את הנתונים (במהירות של 90% פחות) תוך חצי שעה (עיגלנו למעלה), כולל טעינת הטאבלו.
במקרה כזה כמות ה-Credits הנדרשים והעלות הם:
הסיבה לעלות הנמוכה יחסית היא- א׳ ה-Wh פעיל רק 13% מהזמן. ב׳ - המשתמשים עובדים מעל טאבלו, כך שהם לא מעלים את הצריכה.
אבל! כל מטרת בהמעבר היא להעלות את תדירות הטעינה ל-Near real time. לכן לקחנו שני מצבים, האחד תדירות טעינה של כל חצי שעה, ואחת אחרת שה-ETL רץ מיד בסיום התהליך, כך שה-Warehouse תמיד פעיל.
אפשרות א׳ - ריצה כל 30 דקות במשך 6 דקות
אפשרות ב׳ - ריצה תמידית
עלויות אחסון
לעלות הנ״ל יש להוסיף את ה-Storage
ללקוח יש 5Tb, הוספנו על כך גיבויים ו-DR שמנוהלים אוטומטית בסנופלייק. עלות Storage היא $20 ל-Tb.
כך שאם ניקח 15Tb יש להוסיף $300 לעלות החודשית.
סיכום
התוצאות שרואים כאן ללא ספק מרשימות, כפי שציינתי בהתחלה, אלו לא תוצאות שונות במיוחד ממה שאנחנו רואים ברוב ה-POCs, עשינו עד כיום מעל 20 תהליכים כאלו ובכל פעם שמשווים טכנולוגיית On-Prem מגיעים לתוצאה דומה.
המעבר לסנופלייק במקרה הזה יאפשר:
יחתוך כ 90% במשך תהליכי הטעינה.
ישפר את זמני השאילתות פי 50 אם לא יותר.
יאפשר לשפר אף יותר עם הגדלת כח העיבוד.
לא יצריך תחזוקת בסיס נתונים - אין צורך ב-DBA, אין אינדקסים, פרטישנים וכו׳
יספק DR אוטומטי, כולל Time travel ופונקציות אחרות
יאפשר גידול אין סופי לעשורים הקרובים, אין צורך להחליף תשתית
יאפשר מעבר בין עננים ובין פלטפורמות ללא שינוי
לא יוסיף עלות לעלויות התשתית הנוכחית ובוודאי יחסוך עלויות תחזוקה
יאפשר לממש דרישות עסקיות שלא ניתנות כיום למימוש (השאילתא שלא מסתיימת למשל)
מוזמנים לפנות אלינו בכל נושא לשאלות והרחבות. למייל info@vision.bi או להרשם לבלוג לקבל עדכונים על פוסטים חדשים.
Comentários