SQL Server 2014 In-Memory OLTP - חלק א - ilDBA Portal

SQL Server 2014 In-Memory OLTP – חלק א

28/07/2013 | פורסם על ידי

אחת התכונות החדשות של SQL SERVER 2014 שגירסת CTP1 שלו שוחררה לאחרונה, הוא לא פחות ממהפכה. מדובר באפשרות לטעון טבלאות לזיכרון של SQL SERVER במבנה חדש לחלוטין שמאפשר ביצועים בין פי 10 עד פי 100 מטבלאות שוכנות דיסק!

In Memory OLTP (ידוע רשמית בתור שם קוד "Hekaton"), משולב במלואו לתוך SQL Server. הוא מותאם לעומסי עבודת OLTP בגישה לנתונים בזיכרון בלבד. In Memory OLTP מאפשר עומסי עבודה גבוהים ב-OLTP והפחתה לא פחות ממדהימה בזמני הביצוע של טרנזקציות. טבלאות בבסיס הנתונים ניתנות להכרזה כ- MEMORY OPTIMIZED כדי להשתמש ביכולות המנוע. כל הפעולות על טבלאות מסוג זה הן טרנזקטיביות לגמרי, וניתן לגשת אליהן ב-TSQL. כדי להשיג את מקסימום הביצועים מטבלאות שוכנות זיכרון יש לקמפל (Compile)  את הפרוצדורות  הניגשות אליהם לשפת מכונה.

למה עכשיו ?

השינויים בעולם החומרה מתרחשים לנגד עינינו בקצב מהיר מאוד, היום ניתן לרכוש שרת בעל 32  ליבות עם  1TB זיכרון בפחות מ- 50K$. למעשה את רוב בסיסי הנתונים בעולם ניתן ל"הכניס"  לגודל כזה של זיכרון. בגלל שינויים אלה בעולם החומרה בחר צוות הפיתוח של SQL SERVER  באפשרות של מנוע גישה לנתונים מבוסס זיכרון (IN MEMORY OLTP) או בשם אולי יותר מתאים- Extreme Transaction Processing .

תכונות

התכונות המובילות של טבלאות מותאמות זיכרון  (את רובם לא תמצאו אצל המתחרים):

  • אינטגרציה בין טבלאות מותאמות זיכרון לטבלאות רגילות, כך שהסבה של אפליקציה מהצורה הישנה לחדשה יכולה להתבצע באופן הדרגתי.
  • קומפילציה של STORED PROCEDURES לשפת מכונה לשיפור ביצועים בסדרי גודל.
  • HASH INDEXES מותאמים במיוחד לגישה לזיכרון.
  • אין שימוש בדפים (PAGES) אי לכך אין נעילות על דפים (PAGE  LATCHES).
  • שימוש באלגוריתם אופטימיסטי רב גרסתי ללא נעילות או LATCH (Multi-Version optimistic concurrency control with no locking or latching).

מגבלות

  • אין טריגרים.
  • אין FOREIGN KEYS ו CHECK CONSTRAINTS.
  • אין IDENTITY.
  • רק UNIQUE INDEX אחד והוא חייב להיות ה-PRINARY KEY.
  • מקסימום 8 אינדקסים, כולל האינדקס של ה-PRIMARY KEY.

סוגי נתונים נתמכים 

  • Bit
  • int, bigint, smallint, and tinyint
  • money,Smallmoney
  • varchar(n),char(n),nchar(n),nvarchar(n),sysname
  • uniqueidentifier
  • float,real
  • (varbinary(n),binary(n
  • datetime,smalldatetime,datetime2,date,time
  • numeric,decimal

ארכיטקטורה

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

הדבר החשוב ביותר שיש לדעת לגבי טבלאות מותאמות זיכרון שבשונה מטבלאות רגילות אין צורך לקרוא מהדיסק ל-BUFFER CACHE כאשר שאילתות ניגשות לטבלאות. כל הנתונים מאוחסנים בזיכרון כל הזמן, קבצי CHECKPOINT נכתבים כל הזמן לצרכי RECOVERY ,קבצים אלה נוצרים בקובץ FILESTREAM שיצרנו במיוחד לטבלאות מותאמות זיכרון. כמובן שגם נעשה שימוש ב- TRANSACTION LOG, כך שבמקרה של נפילת השרת, הטבלאות נוצרות מחדש (נטענות לזיכרון) מתוך קבצי ה-CHECKPOINT וה-TRANSACTION LOG.

עוד תכונה מרכזית של טבלאות מותאמות זיכרון היא שאנו יכולים לבחור ליצור טבלה שאין לה כלל שרידות, או DURABILTY כפי שמיקרוסופט מכנה את זה. כלומר אם ניצור טבלה שוכנת זיכרון עם האופציה SCHEMA_ONLY, לא תהיינה כלל פעולות I/O לדיסק לא יהיו קבצי CHECKPOINT ולא רשומות ב-TRANSACTION LOG, מה שאומר ביצועים גבוהים, אבל ברגע שהשרת ירד/נפל או שהיה FAILOVER הסכימה תשאר אך הנתונים אבדו, סוג זה יכול להיות מאוד שימושי כטבלאות STAGING או אחסון SESSION STATE ביישומי WEB. אבל עדיין גם בטבלאות מסוג זה טרנזקציות וכל כללי ה-ACID תקפים לחלוטין.

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

clientapppic

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

אינדקסים

אינדקסים על טבלאות מותאמות זיכרון אינם מאוחסנים במבנה BTREE. טבלאות מותאמות זיכרון תומכות באינדקסים מסוג HASH ו–RANGE. טבלאות מאוחסנות כרשימות משורשרות (LINKED LISTS). גם טבלאות מותאמות זיכרון מחייבות אינדקס אחד לפחות כי זאת הדרך היחידה לזהות שורות השייכות לטבלה מסויימת. אינדקסים לעולם אינם מאוחסנים בדיסק או יוצרים פעולת דיסק כלשהי, הם מתוחזקים בזיכרון כל זמן שהשרת למעלה, במקרה של נפילה כל האינדקסים נבנים מחדש בזמן הטעינה לזיכרון.

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

4 תגובות ל- “SQL Server 2014 In-Memory OLTP – חלק א”

commenter

נשמע פצצה.

itai binyamin | 29/07/2013 בשעה 15:15
commenter

מאמר מצויין !!

השאר תגובה:

שם (חובה):
אימייל (לא יפורסם) (חובה):
תגובה (חובה):

*



מאמרים קשורים

קהילת

קהילת ה- BI וה- BIG DATA מתכנסת ב- 28-10 !

שלום רב, למי שלא ידע 🙂 קהילת ה- BI וה- BIG DATA בעולמות Microsoft מתכנסת מידי חודש על מנת להפגש, להכיר ולשמוע הרצאות במגוון נושאים טכנולוגיים מרתקים בתחום. במפגש הקרוב (מספר 63) שיתקיים ב- 28-10-2015, יום רביעי [...]
הזמנה

הזמנה ל-SQL Saturday #481 – Israel 2016

שלום רב, בקרוב יתקיים בישראל כנס טכנולוגי מרכזי קהילת ה-DB וה-BI בתחום ה-SQL Server – ה-SQL Saturday! הכנס אשר מאורגן בהתנדבות על ידי אנשי הקהילה יכלול במהלכו מספר מסלולי לימוד בתחומים טכנולוגיים שונים. [...]

איך לבצע Sizing DB ב-Datacenter בארגונך בקלות (חלק א')

כחלק מהטמעות מוצרי IT תשתיתיים (כגון FWDB, מוצרי גיבוי, חוות Storage, מוצרי שו"ב ועוד…) בארגוני, אנו נדרשים המון פעמים לענות על שאלות לספקים כגון : מה גודל הכולל של ה –  Datacenter  ? מה חלוקת גודל ה [...]

תיעוד בסיס הנתונים – למה זה טוב?

ישנם מספר נושאים חשובים שיש לתת עליהם את הדעת בפיתוח ותכנון בסיס נתונים. כמובן שצריך לשים לב לנירמול נכון של הטבלאות, וכמובן שצריך להגדיר סטנדרט לכתיבה נכונה של הקוד, וכמובן שאי אפשר בלי [...]
Copyright 2019 ilDBA Portal. Brought to you by Brillix - Israel Leading DBA company. Sponsored by: DBSnaps - Database Video Tutorialss
Website Security Test
%d בלוגרים אהבו את זה: