Skip to main content

SQL Azure Elastic Pools - Review

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

את הפוסט הזה אחלק ל 4 חלקים:
  1. הסבר קצר ולינקים להסברים על המוצר ועל חלקיו השונים.
  2. הסבר ודוגמאות על מה רואים בפורטל בחלקים השונים
  3. מהם ג'ובים? כיצד הם פועלים ומה האפשרויות מהם.
  4. מה הלאה...
נתחיל בהסבר קצר ובלינקים: המוצר הזה נועד להכניס לפול אחד מספר בסיס נתונים באותו שרת (נקווה שבעתיד הפול יוכל להכיל מספר שרתים), וכשהם בפול אחד ישנה דינמיות בהקצאת המשאבים בין בסיס הנתונים - אם עד היום כל בסיס נתונים היה יישות עצמאית בעלת יכולת עבודה וביצועים משלה ה DTU היה רק שלה, פה מכניסים לפול אחד מספר בסיסי נתונים וההגדרה של הסטורג' ושל ה DTU היא לא ברמת בסיס נתונים אלא ברמת הפול.
אם עד היום בסיס נתונים אחד מהדרגה 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
 


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

מה רואים פה? ובכן ב etoro אני עובדים במקום מסויים באפליקציה על Shards DB's, הם חייבים להיות זהים מבחינת הסכמה ומאוזנים בביצועים. האפליקציה כותבת לכל Shard לפי טבלת מיפויים ובכך מאוזנת גם בקריאה וגם בכתיבה. פה אדגים מה רואים ב Elastic Pool על 4 בסיסי נתונים שיש ב Pool:
  1. גרף קטן שמראה תנודות של DTU וסטורג' ברמת ה Pool
  2. הגדרת ה Pool
  3. מה המקסימום DTU שיש ברמת בסיס הנתונים שנמצא ב Pool וכך אפשר לראות מי צרכן כבד או על חוסר איזון
  4. גרף קטן שמראה את מה שהטבלה מראה...
  5. קונפיגורציה של ה Pool: גרף קטן שמראה כמה אנו מנצלים מהגדרת ה storage של ה Pool וה DTU של ה Pool. וכפתורי לחיצה כאשר ההגדרה היא פה מה המקסימום שה Pool יוכל להגיע הן ברמת DTU והן ברמת Storage - רק היום הודיעו שהמינימום ירד ל 100 - דבר שמוריד הרבה עליות למי שרק בודק את המערכת.
  6. קונפיגורציה של ה 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 - אבל אם נחשוב מחוץ לקופסא יש פה פוטנציאל למשהו הרבה יותר רחב.
 
נסו ותהנו
פיני


Comments

  1. Once you’ve decided on a method, merely choose it and follow the instructions. Of course, you’ll need to have some data prepared depending on the strategy you’re using. For instance, card payments would require your card number, expiration date, and CVC code. The 파라오카지노 excellent news is virtually all|that the majority} casino deposit strategies are instant, so find a way to|you presumably can} play immediately.

    ReplyDelete

Post a Comment

Popular posts from this blog

ועוד קצת על ניהול פיתוח לענן

היום עקב תקלה קטנה מול מיקרוסופט בוצע disable לחשבון. הדבר גרם לאתר לא לעבוד וכמובן 3 רולים נוטרלו. כשחזרו לחיים נדרשנו לעשות מחדש deploy ל 3 הרולים. (רוצים הסבר קטן לעבודה על הענן? ובכן תמצית הדבר הוא שכשאנו עוקפים נהלים שאנו יצרנו בשרתים שלנו מיקרוסופט - לא מרשים לעקוף וכך הכל חייב להתנהל לפי הספר... מה שתעלה לענן זה מה שירוץ ואם תשנה - השינויים יימחקו...) הבעיה החלה כאשר הסתבר שלא כל קבצי ה deploy נשמרו על מכונת הגירסה וכי אחד הקבצים שודרג לגירסא חדשה שטרם עלתה לענן.... הדבר גזל 4 שעות בנסיון להחזיר את הגירסה... מסקנתי היא כי חייב להיות נוהל שמירת קבצי deploy מיד אחרי העלתם לענן - ובכך לשמור גיבוי לעת צרה - נכון - אל תצעקו עליי - בוצע לייבל ב TFS - ואפשר למשוך ולקמפל - אבל תראו לי עובד אחד שעשה את זה תוך חמש דקות....? יש לציין לטובה את ה SQL Azure - שלו - לא קרה כלום כל העת... כל הכבוד ל SQL... ובנימה יותצר רצינית - אל תשכחו לגבות כל מה שעולה ... - במיוחד אצלך . אגב בענן עצמו - זה כבר יגובה אל דאגה... ערב טוב

על בעיות של ניהול פיתוח לענן

על ניהול סביבת פיתוח מול הענן:   הבעיה המרכזית בניהול פיתוח לענן שייכת לתחום הבדיקות  - שום ענן מקומי ושם אימולטור אינו מדמה במאה אחוזים את מה שקורה בענן עצמו. בכל רכיבי הבדיקות, על בעיה זו ניתן להתגבר בשיטת עבודה טובה והקמת מערכת בדיקות בענן עצמו. על ניהול גרסאות מול הענן:    במידה ואתם עובדים מול לקוחות רגילים ומול לקוחות הרוצים מוצרים בענן  - מהי הדרך הטובה ביותר לנהל את הפיתוח כך שאפשר יהיה לתחזק את שתי המערכות ואת שתי סביבות הבדיקות? אפשר לומר כי מטרת מנהל הפיתוח היא להקים סביבת פיתוח אחת - אם הדבר לא אפשרי צריך למצוא את הפתרון לסינכרון 2 הסביבות. Check List -   למנהל המבולבל - מה הצוות צריך לבצע לפני העלאה לענן: על הפרוייקט להיות מקומפל בסביבת VS2010 - רצוי 64 Bits ולא 32. יש להריץ בענן מקומי (אימולטור) ולראות שהכול עובד כהלכה במידה ואתה משתמש ב Registery או ב Event Log עליך ליצור קובץ StartUp command שבעצם ירוץ בעליית ה Role וייצור את מה שצריך במחשב המיועד לך בענן. יש ליצור חבילה להעלאה - רצוי לשמור חבילה זו עם מספר ותיאור כללי. יש להעלות את החבילה ולבדוק שהכול רץ ועו

Azure SQL DB tiers comparison

Hi All In the last few month Brent Ozar gae us 2 masterpiece blogs related to Azure SQL DB:   How fast can a $21,468/mo Azure SQL DB load data?     In this blog Brent compared the abilities of Azure SQL DBs to load Data - he compared all combinations of vCors tiers. (When I asked him about comparing the Standard\Premium tiers, he told me to do it.... :-) )   There’s a bottleneck in Azure SQL DB storage throughput.   In this blog Brent showed us that in the vCors world the storage throughput has limit and there is not need to pay so much money when you need to upload lots of data.   So I took have taken up his challenge and done a comparison in Azure SQL DB in Standard\Premium tiers. I have created a new DB with 1 Table. I have generated 7 GB of DATA, and created the file in my local on premise drive (Yes, do not kill me, I did not had the time to put it on azure), and uploaded it via BCP command.   bcp "TableName" in "T:\MyTable.bcp"