עיצוב המודל הפיסי

1. Data Warehouses עיצוב המודל הפיסי ODS Star Schema Fact Tables ROLAP Snowflake Schema Datamart MPP מחבר: רז הייפרמן מציג : אבי שמיר

2. טכניקות לשיפור ביצועיםPerformance Enhancements

3. שיפור אופטימזציה בסביבתStar Schema Join סכימת כוכב מחייבת בדרך כלל מספר רב של פעולות זמן מכירות תאריך רבעון שבוע בשנה Select Prod_Name, Cust_Name, Q_Name From Sales, Products, Customers, Periods Where Prod_Name = “Widget” and Cust_Name = “Tadiran” and Q_Name = “Q197” and Sales.Prod_Id = Products.Prod_Id and Sales.Cust_Id = Customer.Cust_Id and Sales.Time_Id = Period.Time_Id קוד מוצר תאריך קוד לקוח סכום מכירות לקוחות קוד לקוח שם לקוח מוצר קוד מוצר תאור מוצר בהנחה שקיים אינדקס על המפתחות של טבלאות המימד, רכיב האופטמיזציה יכול לבחור לבצע צירוף עם טבלת העובדות בשלב מוקדם מדי ולכן תוצאות הביניים יהיו גדולות מאד

4. שיפור אופטימזציה בסביבתStar Schema חברות הכניסו שיפורים מיוחדים לרכיב האופטימיזציה על מנת לזהות מצבי כוכב בדרך כלל עדיף לבחור את טבלת העובדות בסוף זיהוי מצב כוכב ע”י האופטימייזר של אורקל לפחות שלוש טבלאות מעורבות בשאילתא אינדקס משורשר על שלוש עמודות לפחות בטבלת העובדות אינדקסים על עמודות תאור בטבלאות המימדים Hint ניתן לתת רמז לאופטימייזר ע”י משפט זיהוי מצב כוכב יכול להביא לשיפור משמעותי בביצועי השאילתא לא יעיל אם טבלאות המימדים גדולות מאד ואין אילוץ על שורות

5. שיפור אופטימזציה בסביבתStar Schema אם קיים אינדקס על עמודות התאור, האופטימייזר יבצע מכפלה קרטזית בזיכרון של השורות מטבלאות המימדים שמקיימים את התנאי ולטבלה התוצאתית יבוצע צירוף לטבלת העובדות טבלה זמנית Prod_Id Cust_Id Time_Id Prod_Name Cust Name Period_Name Concatenated Key Join with Fact Table Outside-In Queries מתאים לשאילתות

6. שיפור אופטימזציה בסביבתStar Schema בגלל התנאי על טבלת העובדות יתכן שבחירה מוקדמת של טבלה זו הינה החלטה טובה - אם יש אינדקס על סכום מכירה Select Prod_Name, Cust_Name, Q_Name From Sales, Products, Customers, Periods Where Prod_Name = “Widget” and Cust_Name = “Tadiran” and Q_Name = “Q197” and Sales_Ammount > 1000 and Sales.Prod_Id = Products.Prod_Id and Sales.Cust_Id = Customer.Cust_Id and Sales.Time_Id = Period.Time_Id Inside-in Queries מתאים לשאילתות

7. אינדקסים מסוגJoin Indexes אינדקס רגיל מצביע על שורה בטבלה אחת בלבד אינדקס צירוף מצביע על מספר טבלאות בו זמנית Read Only מתאימים במיוחד במצבי Store Key RowId 001 002 003 PLD4387 AR43A6 PO12B3 Sales Fact Table RowId Store Key Prod Key Period Key Prod Key RowId 001 002 003 AR43A6 AR43A6 PO12B3 880112 880114 880112 011796 011796 011796 880112 880114 880176 345 346 347 Join Index Period Key RowId RowId Store RowId Prod RowId Period RowId 1009 1010 1011 011796 011896 011996 001 002 003 002 002 003 345 346 345 1009 1009 1009

8. אינדקסים מסוגBit Maps Sybase IQ לחברת סייביס יש מוצר מיוחד למחסני נתונים המוצר משתמש בטכנולוגיה של מפות בינאריות במקום אינדקסים רגילים טוב במיוחד במצבים בו יש עמודות עם קרדינליות נמוכה. למשל עמודה מין יכולה להכיל רק שני ערכים אינו מאפשר עדכון מקוון אלא רק באצווה

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

10. דוגמא לחלוקת בסיס הנתוניםDatabase Partitioning חלוקה לפי זמן רבעון ראשון חלוקה נוספת שנה שוטפת רבעון שני שנה קודמת רבעון שלישי לפני שנתיים רבעון רביעי טבלת תנועות חלוקה לפי זמן וחנויות חלוקה נוספת שנה שוטפת חנות 1 חנות 1 שנה שוטפת חנות 2 חנות 2 שנה שוטפת חנות 3 חנות 3 שנה קודמת חנות 1

11. איחוד טבלאות מחולקות Union הבעיה המרכזית בחלוקה היא כיצד בסיס הנתונים מטפל ב ניתן לבנות מבט לוגי עליו עובד המשתמש ולא על החלוקות Create View Sales95 as Select * from Sales95Q1 Union Select * from Sales95Q2 Union Select * from Sales 95Q3 Union Select * from Sales 95Q4 טבלת תנועות רבעון ראשון רבעון שני רבעון שלישי רבעון רביעי

12. בעית האופטימיזציה שלאיחוד הטבלאות Select * from Sales95 Where ProdId = AR123A1 and StoreId = 123 Insert into Temp Select * from Sales95Q1 Where ..... Insert into Temp Select * from Sales95Q2 Where ..... Insert into Temp Select * from Sales95Q1 Insert into Temp Select * from Sales95Q2 Select * from Temp Where ......

13. מאפייני ם ייחודייםלבסיסי נתוניםבסביבת מחסן נתונים

14. טעינת נתונים Data Loading מחסני המידע מתעדכנים ע”י תהליכי טעינה תקופתיים של כמויות גדולות של נתונים - עשרות עד מאות גיגהבייט כמויות הנתונים גדלות עם הזמן כתוצאה מיישומי מחסן מידע חדשים אולם חלון הזמן לטעינת הנתונים נשאר קבוע תוכניות הטעינה חייבות לנצל את ריבוי המעבדים למקביליות הטעינה Parallel Loader

15. טעינת נתונים Data Loading תוכניות השרות לטעינה קריטיות להצלחת מחסני המידע ומבצעות קליטת נתונים ממגוון אמצעים כמו דיסקים, ערוצי תקשורת ועוד המרת הנתונים מפורמטים שונים לפורמט של בסיס הנתונים סינון נתונים שגויים כמו ערכים כפולים, ערכים חסרים Data and Referential Integrity בדיקות אמינות ושלמות הנתונים בנית ועדכון האינדקסים Meta Data עדכון ה

16. התאוששות מתקלותData Recovery מנגנוני ההתאוששות צריכים לאפשר התאוששות מהירה מתקלות בזמן טעינת הנתונים על מנת לא לאבד את חלון הזמן מאחר ועדכון מחסן המידע מתבצע ע”י טעינה ולא טרנזקציות יש לבנות מנגנוני התאוששות מתוחכמים שאינם מבוססים על יומן הארועים Check Point אלא על נקודות מבדק

17. ביצועים משופרים לשאילתותEnhanced Query Performance מחסן המידע מאופיין ע”י ריבוי שאילתות מורכבות ומזדמנות השאילתות מטפלות בכמויות גדולות של נתונים, לעיתים מיליוני שורות בטבלאות זמני התגובה הנדרשים ע”י המשתמשים הם קצרים מאד מאחר וכל Drill Down and Up תשובה מביאה לשאלה נוספת טכניקות האופטימיזציה צריכות להתבסס על איפיוני מחסן המידע Bit Map Index התבססות על טכניקות אינדקסים מיוחדות כמו Predefined Joins ביצוע צירופי טבלאות מראש

18. כושר גידול מחסן המידעSScalability מחסני המידע מכילים כיום מספר עשרות עד מאות גיגהבייט כמות הנתונים במחסן נוטה לגדול במהירות רבה ויכולה להגיע למספר טרהבייט הגידול המהיר בנתונים נובע מ כמויות גדולות של נתונים המיוצרים במערכות התפעוליות צבירת נתונים לאורך זמן רב ניהול אינטגרטיבי של נושאים שונים על בסיס הנתונים לאפשר גידול חלק עד לנפחי נתונים גדולים מאד בסיס הנתונים צריך לתמוך בהיררכיה של אמצעי איחסון Hierarachical Storage Management

19. ניהול מחסן המידעData Warehouse Administration סביבת מחסן המידע דורשת כלי ניהול יחודיים נדרשים כלים לנושאים כגון בחינת עומסי שאילתות וניתוח ההשפעות כלים להקצאת עדיפויות למשתמשים שונים סטיסטיקות מפורטות על השאילתות כולל ניתוח מסלולי גישה כלי כיוונון של בסיס הנתונים להשגת ביצועים ותפוקה מקסימליים Resource Limits Warnings אפשרויות לקביעת מגבלות ניהול התחשבנות עם לקוחות מחסן המידע כלי ניהול על קטעי טבלאות Time Cyclic Administration כלים לביצוע פעולות ניהול מחזוריות ניהול קבוצות גדולות של משתמשים מבחינת הרשאות, עדיפויות ועוד

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

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

22. שילוב ניתוח רב מימדיMulti Dimensional Integration חלק ניכר מדרישות המשתמשים הן לניתוח מידע רב מימדי בעקרון קיימות שתי גישות Multi Dimensional Database בסיס נתונים רב מימדי כלי ניתוח העובדים ישירות על בסיס הנתונים הטבלאי כלי ניתוח רב מימדיים מכילים בדרך כלל מידע סיכומי במבנה יעיל וייחודי. חלקם תומכים בבניה אוטומטית של שאילתות מול מחסן המידע Drill Down לצורך תמיכה ישירה של בסיס הנתונים בניתוח רב מימדי הינו אתגר משמעותי ומחייב בניה אוטומטית של סיכומים והגדרות בסכימה