עשרות אלפי טרנזקציות בשניה עם יכולת ה- In-Memory OLTP של SQL Server 2014

28 ביולי 2013

תגיות: , ,
3 תגובות

 

image_thumb13

 

 

 

 

  מאת: אורן בוני, מיקרוסופט ישראל

 

גרסת SQL Server 2014, החדשה, מציעה יכולת המאפשרת לבצע טרנזקציות in-memory ובכך לשפר באופן דרמטי את ה- throughput וה- latency של יכולות ה- Online transaction processing.

יכולת ה- In-Memory OLTP, הנקראת בשם הקוד "project Hekaton", אשר מובנית בתוך המוצר, נועדה לתת מענה לאפליקציות שצריכות לבצע טרנזקציות מהירות, בקצב של עשרות אלפי טרנזקציות בשניה. כאמור, היכולת הזאת הינה מובנית בתוך SQL Server ולא מצריכה שימוש בכלים חיצוניים לניהול נתונים ואף לא במודל תכנותי חדש.

במה זה שונה?

הגרסאות הקודמות של SQL Server כללו את מנוע ה- OLTP, אשר ביצע אופטימיזציה של האחסון בזכרון על ידי שמירה של ה"נתונים החמים" ב- buffer המרכזי של הזכרון על בסיס תדירות הגישה לנתונים. אך יכולות הגישה והשינוי של הנתונים הוגדרו עפ"י התפיסה שהנתונים יכנסו ויצאו מהזכרון בכל זמן נתון. עם In-Memory OLTP אנחנו נשים את הטבלאות, אשר ישמשו ל- extreme transaction processing של האפליקציה, לתוך מבנים בתוך הזכרון הראשי שהינם memory optimized. הטבלאות האחרות, כמו reference data או נתונים היסטוריים, ישמרו בתוך המבנים המוכרים שהינם storage-optimized. גישה זו מאפשרת לבצע אופטימיזציה של "נקודות חמות" לשימוש בזכרון ללא צורך בניהול של data engines מרובים. בנוסף, היכולת הזאת מונעת את התקורה של ה- storage optimized view, תוך שימור העקביות, המידור והשרידות המצופה מבסיס נתונים.

עשרות אלפי טרנזקציות בשניה עם יכולת ה- In-Memory OLTP של SQL Server 14

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

עיבוד מהיר של ה- Business logic

באמצעות In-Memory OLTP, שאילתות ולוגיקה פרוצדורלית של פרוצדורות השמורות ב-
T-SQL עוברים קומפילציה ישירות לשפת מכונה תוך אופטימיזציות, אשר מופעלות בזמן הקומפילציה. המשמעות היא שה- stored procedures מבוצעות במהירות של ה- native code.

יכולת scale-up ללא נעילת נתונים

In-Memory OLTP כוללת מנגנון concurrent control ומשתמשת במבני נתונים ללא נעילה המאפשרים להמנע משימוש ב- locks ו-latches, תוך שמירה על נכונות הסמנטית של הטרנזקציות והעקביות של הנתונים.

כיצד זה עובד?

למעשה אנו יכולים להכריז על טבלה כ- "memory-optimized", וכך SQL Server יעלה את כל הטבלה הזו לתוך הזכרון. בנוסף ניתן לקמפל stored procedures ל- native DLLs המאפשרים גישה מהירה.

 

CREATE TABLE  T1

(

       Fname                varchar(32) not null PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1024),

       Main_City            varchar(32) null,

       Last_Modifide datetime not null,

)      WITH (MEMORY_OPTIMIZED = ON,

       DURABILITY = SCHEMA_AND_DATA);

 

כאמור, בניגוד לעבר, ב- In-Memory OLTP אין שימוש ב- paging, אלא ההפניה ל- index הינה למעשה memory pointer אל הנתונים, המאפשרת גישה מהירה. כלומר, האינדקסים של טבלאות memory optimized אינם נשמרים כ- B-trees מסורתיים.

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

אם טרנזקציה נכשלת (אינה עושה commit), השינויים לעולם לא יכתבו לתוך הדיסק. וכאשר טרנזקציה אכן מבצעת commit, היא נרשמת ב- transaction log ותהליך רקע מעתיק בחזרה אל סדרת הקבצים השנשמרים ב- In-Memory OLTP data. קבצים אלו נקראים כאשר בסיס הנתונים עולה, כאשר הם מועתקים לזכרון.

אמנם זה מובן מאיליו, אך יש לציין שהגודל של ה- RAM צריך להכיל את הנתונים. אם כמות הנתונים גדולה מדי, לא יוכנסו נתונים חדשים.

וכעת למספרים…

באופן טבעי המספרים שהוצגו עבור יכולת זו מרשימים במיוחד. במצגת שנערכה לפני מספר שבועות הוצגה היכולת עם שרת בעל 16 ליבות הכולל 256GB RAM ושני SSDים לצד דיסקים קשיחים. הסימולציה שהוצגה עם 80 משתמשים יצרה באופן רגיל 2400 טרנזקציות לשניה. כאשר השתמשו בטבלאות memory-optimized מספר זה קפץ ל- 17,000 טרנזקציות. השימוש ב- compiled store procedures הקפיץ את הביצועים ל- 65,000 טרנזקציות לשניה.

OLTP

 

 

 

 

 

 

 

 

 

 

 

 

 

לסיכום

יכולת ה- in-memory OLTP מאפשר ליצור ולעבוד עם טבלאות שהינם memory-optimized, המספקות ביצועים מעולים למשימות OLTP. היכולת הזאת הינה מובנית בתוך SQL Server 2014 ולא מצריכה שימוש בכלים חיצוניים לניהול נתונים ואף לא במודל תכנותי חדש.

להורדת גרסת הבטא של SQL Server 2014 – לחצו כאן

למידע נוסף אודות הגרסה החדשה – לחצו כאן

 

 אורן בוני הוא מהנדס בכיר בקבוצת המהנדסים של מיקרוסופט (PFE) המתמחה ב- SQL Server.לאורן ניסיון של 15 שנה בתחום, בהם ליווה את הטמעות ה- SQL הגדולות בארץ.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

3 תגובות

  1. אני29 ביולי 2013 ב 11:34

    עדיף כבר לכתוב את המאמר באנגלית. 🙂

    הגב
  2. התפוז הדיגיטלי18 באוגוסט 2013 ב 8:29

    מרתק… אבל נשמע כמו יתרון רק למסדי נתונים גדולים במיוחד, ו/או עם גישה של המון משתמשים בזמן נתון למידע.
    האם שימוש בשיטה הזו על שרת SQL "חלש" יחסית לזה שהוצג בהקדמה (נניח מחשב PC עם 4GB של RAM ומעבד מיד-ריינג') לצורך שמירת נתונים של, נניח אתר שכתוב בDOT.NET עם C# תשפר את ביצועי הגישה של קבצי C# או ASHX למסד הנתונים? נניח אתר שבו רק כמה מאות גולשים ביום…

    הגב
  3. אודי19 באוגוסט 2013 ב 10:45

    מספר הטרנזקציות שילכו לאיבוד מכיוון שלא הספיקו להרשם לדיסק הוא גדול?

    ובכלל, שיפור הביצועים הוא כתוצאה משימוש ב SSD וחומרה יותר מתקדמת או מגרסת הסיקוול החדשה?

    ובכלל, הלפני-ואחרי של אתר bwin מתייחס לחומרה זהה?

    בכל מקרה, כל הכבוד.
    השילוב של סיקוול סרבר, דוט נט, ו IIS 7 ומעלה הוא אולטימטיבי מכל הבחינות.

    כל מה שנשאר לעשות הוא לשפר ביצועים, ובכיוון הזה אתם הולכים….

    הגב