ערב טוב
אז זהו הגיע זמן הפוסט על "SQL Azure Elastic Pools", ניסינו - התנסינו - למדנו ועכשיו יודעים על זה דבר או שניים.
ראשית זהו כלי בעל פוטנציאל מדהים שכאשר יעבוד חלק ויושלמו כל המרכיבים שלו זה שינוי מהותי.
שנית הוא בשל חלקית - אבל ככה היום עושות כל חברות הווב - מובייל - ענן... מוציאות משהו שלם לחצאין ונתנים לקהל להיות ה QA. אני מקבל את זה וזורם עם זה.
את הפוסט הזה אחלק ל 4 חלקים:
אם עד היום בסיס נתונים אחד מהדרגה S0 היה יכול להיות עד 250 GB, היום אם מכניסים אותו ועוד בסיס נתונים אחד לפול ואפשר במקסימום עד 1200 GB שזה שיםור עצום - אולם אם נכניס 15 בסיס נתונים תהיה לנו הרעה בהקצאת הסטורג'.
ואותו הדבר לביצועים - עם הזמן נלמד היכן האיזון.
זו ההגדרה של הפול באופן כללי מאד.
הלינקים הרלוונטים של איך יוצרים ומשתמשים מצא פה:
ומכאן לנקודה השניה מה רואים בפורטל ואיך זה בעצם עובד:
זו תמונה מעמוד הביית של הפורטל
אנו רואים פה קיצורי דרך לרכיבים הקריטיים של ה Pool. אני הולך משמאל לימין:
אלו קיצורי הדרך והסימנים החשובים עכשיו נלחץ על ה - Pool עצמו ונראה מה רואים - אני פתחתי פה שני Blaeds - זוכרים את המושג הזה? אם היינו בשנות ה 80 היינו אומרים זה כמו ה windows - היום בעידן המובייל אלו מסכי הזזה....
מה רואים פה? ובכן ב etoro אני עובדים במקום מסויים באפליקציה על Shards DB's, הם חייבים להיות זהים מבחינת הסכמה ומאוזנים בביצועים. האפליקציה כותבת לכל Shard לפי טבלת מיפויים ובכך מאוזנת גם בקריאה וגם בכתיבה. פה אדגים מה רואים ב Elastic Pool על 4 בסיסי נתונים שיש ב Pool:
ועכשיו אחרי שברור איך מקנפגים ומה רואים נעבור לעולם התוכן השני שזה הג'ובים: כשמו - לא - כן הוא זהו תהליך הרצה שניתן להריץ שוב ושוב של T-SQL אולם כרגע אי אפשר לקבוע לו לוח זמנים.
למה זה טוב?
זה מעולה הוא מריץ על כל בסיסי הנתונים שב Pool את אותו ה Query אם זה עידכון סטטיסטיקות - ואם זה Deploy חד פעמי. במקום לעבור בסיס נתונים אחד אחד זה רץ על הכל..
גונב לאוזניי שממש בקרוב יהיה ניתן לעבוד בבסיס נתונים אחד עם כמה
external data source
שזה אומר שתוכל לעבוד מול בסיס נתונים אחרים או משהו כזה אבל זה לא כרגע...
בקיצור לוחצים על הלינק של יצירת ג'וב
נוצרים מספר רכיבים ב Azure שמנהלים את הג'ובים - בעיקרון רכיבים אלו שקופים מבחינתינו מלבד התשלום החודשי - אבל באמת זהו סכום אפסי. יש פה אפליקציה, סטורג, ובסיס נתונים.
זהו ה
Resource Group that holds the components related to Jobs
שהזכרתי למעלה.
אז זהו הגיע זמן הפוסט על "SQL Azure Elastic Pools", ניסינו - התנסינו - למדנו ועכשיו יודעים על זה דבר או שניים.
ראשית זהו כלי בעל פוטנציאל מדהים שכאשר יעבוד חלק ויושלמו כל המרכיבים שלו זה שינוי מהותי.
שנית הוא בשל חלקית - אבל ככה היום עושות כל חברות הווב - מובייל - ענן... מוציאות משהו שלם לחצאין ונתנים לקהל להיות ה QA. אני מקבל את זה וזורם עם זה.
את הפוסט הזה אחלק ל 4 חלקים:
- הסבר קצר ולינקים להסברים על המוצר ועל חלקיו השונים.
- הסבר ודוגמאות על מה רואים בפורטל בחלקים השונים
- מהם ג'ובים? כיצד הם פועלים ומה האפשרויות מהם.
- מה הלאה...
אם עד היום בסיס נתונים אחד מהדרגה S0 היה יכול להיות עד 250 GB, היום אם מכניסים אותו ועוד בסיס נתונים אחד לפול ואפשר במקסימום עד 1200 GB שזה שיםור עצום - אולם אם נכניס 15 בסיס נתונים תהיה לנו הרעה בהקצאת הסטורג'.
ואותו הדבר לביצועים - עם הזמן נלמד היכן האיזון.
זו ההגדרה של הפול באופן כללי מאד.
הלינקים הרלוונטים של איך יוצרים ומשתמשים מצא פה:
ומכאן לנקודה השניה מה רואים בפורטל ואיך זה בעצם עובד:
זו תמונה מעמוד הביית של הפורטל
אנו רואים פה קיצורי דרך לרכיבים הקריטיים של ה Pool. אני הולך משמאל לימין:
Resource Group (I know I need to explain abut that too) - of all my components in the pool
Sql Server V12 that hold few DB's that exists in the Pool
Elastic Pool itself
Resource Group that holds the components related to Jobs
מה רואים פה? ובכן ב etoro אני עובדים במקום מסויים באפליקציה על Shards DB's, הם חייבים להיות זהים מבחינת הסכמה ומאוזנים בביצועים. האפליקציה כותבת לכל Shard לפי טבלת מיפויים ובכך מאוזנת גם בקריאה וגם בכתיבה. פה אדגים מה רואים ב Elastic Pool על 4 בסיסי נתונים שיש ב Pool:
- גרף קטן שמראה תנודות של DTU וסטורג' ברמת ה Pool
- הגדרת ה Pool
- מה המקסימום DTU שיש ברמת בסיס הנתונים שנמצא ב Pool וכך אפשר לראות מי צרכן כבד או על חוסר איזון
- גרף קטן שמראה את מה שהטבלה מראה...
- קונפיגורציה של ה Pool: גרף קטן שמראה כמה אנו מנצלים מהגדרת ה storage של ה Pool וה DTU של ה Pool. וכפתורי לחיצה כאשר ההגדרה היא פה מה המקסימום שה Pool יוכל להגיע הן ברמת DTU והן ברמת Storage - רק היום הודיעו שהמינימום ירד ל 100 - דבר שמוריד הרבה עליות למי שרק בודק את המערכת.
- קונפיגורציה של ה Pool: גרף קטן שמראה כמה אנו מנצלים מהגדרת ה DTU של ה Pool ברמת בסיס נתונים אחד. וכפתורי לחיצה כאשר ניתן להגדיר מינימום ומקסימום לכל DB
ועכשיו אחרי שברור איך מקנפגים ומה רואים נעבור לעולם התוכן השני שזה הג'ובים: כשמו - לא - כן הוא זהו תהליך הרצה שניתן להריץ שוב ושוב של T-SQL אולם כרגע אי אפשר לקבוע לו לוח זמנים.
למה זה טוב?
זה מעולה הוא מריץ על כל בסיסי הנתונים שב Pool את אותו ה Query אם זה עידכון סטטיסטיקות - ואם זה Deploy חד פעמי. במקום לעבור בסיס נתונים אחד אחד זה רץ על הכל..
גונב לאוזניי שממש בקרוב יהיה ניתן לעבוד בבסיס נתונים אחד עם כמה
external data source
שזה אומר שתוכל לעבוד מול בסיס נתונים אחרים או משהו כזה אבל זה לא כרגע...
בקיצור לוחצים על הלינק של יצירת ג'וב
נוצרים מספר רכיבים ב Azure שמנהלים את הג'ובים - בעיקרון רכיבים אלו שקופים מבחינתינו מלבד התשלום החודשי - אבל באמת זהו סכום אפסי. יש פה אפליקציה, סטורג, ובסיס נתונים.
זהו ה
Resource Group that holds the components related to Jobs
שהזכרתי למעלה.
מכיוון שאני אוהב בסיס נתונים וזהו בסיס הנתונים הרלוונטי שהוא כמו MSDB:
נחזור לג'ובים - אחרי שיצרנו את כל הרכיבים ניתן לייצר כמה ג'ובים שרוצים פשוט ממלאים יוזר וססמא שהם אחידים בכל בסיסי הנתונים. הנה דוגמא לרשימה של ג'ובים כאשר לכל אחד ניתם להיכנס ולהריץ מחדש - כאמור עדיין אין אפשרות לקבוע לוז ריצה קבוע.
ניתן לראות לוגים של הצלחות של הג'ובים ברמה כללית וברמה של כל DB לעצמו:
וניתן לראות לוגים של כשלונות של הג'ובים ברמה כללית וברמה של כל DB לעצמו:
עד כאן.
לסיכום:
בצורה קלה ומהירה אפשר לייצר ישות חדשה בעולם ה SQL Azure DB, יישות שנקראת POOL והיא יישות ברמת תשלומים וברמת ניהול.
היא מתאימה לצרכים מסויימים כמו שירותים SAASים או Shards - אבל אם נחשוב מחוץ לקופסא יש פה פוטנציאל למשהו הרבה יותר רחב.
נסו ותהנו
פיני
