שלשום ניהלתי ויכוח בנוגע ל אופן שיש לבנות distinct count measures ,
האם לבנות את המדד ב measure group נפרד ואיזה נפח אגרגציות יש להקנות לו.
מהויכוח נזכרתי שכבר ראיתי התייחסות טובה לנושא ב performance guide אך שכחתי את ההסברים למסכנות שהוסקו מהמאמר ולכן החלטתי ללמוד שוב את הנושא ולכתוב עליו.
פונקצית distinct count ( מרגע זה אני אכתוב DC במקום distinct count)
הינה פונקציה שסופרת מופעים ייחודיים של אלמנט בטבלה. לצערנו למרות שהשימוש בפונקציה נרחב מאוד במיוחד במערכות BI ההשפעה שלו הינה שלילית בכול הנוגע לגודל אגרגציות וזמן process.
לדוגמה:
נגיד שיש לי טבלת measure group של מכירות מוצרים שיש לו אגרגציות ( ב profiler ניתן לראות
מתי תשובות לשאילתות MDX נלקחות מהאגרגציות) הכוללות סיכום של המכירות של קבוצות מוצרים בכול שנה (בקובייה עצמה המידע מפורט הרבה יותר האגרגציות מכילות מידע מסוכם).
נניח כי שיש לנו 10 קטגוריות מוצר ו 10 שנים , זה אומר שאם כל מוצר נמכר כל שנה אז
האגרגציות יהיו מורכבות מ 100 ערכים.
אם נחליט כי אנו מוסיפים ל measure group שלנו חישוב distinct count של לקוחות, זה יגרום
להוספת קוד לקוח לכול קבוצת מוצרים בכול שנה. אם יש לנו 1000 לקוחות אזי במקרה הכי גרוע בו לקוחות קונים את כול קבוצות המוצר שלי כל שנה כמות האגרגציות תקפוץ ל 100,000
במציאות המספר יהיה נמוך יותר אך התקורה ברוב הפעמים תהיה גבוהה מאוד.
אם תחשבו על מתי אתם משתמשים ב DC ולאיזה חישוב תראו כי הוספתו לאגרגציות של ה measure group לא משתלמת ולכן מומלץ ליצור measure group חדש לכול חישוב DC,דבר
שמבוצע אוטומטית כאשר בוחרים באפשרות הוספת DC ( אפשר באופן ידני לעקוף את זה).
ביצוע DC לטבלאות גדולות הינו תהליך שיכול להכביד על המחשב ולקחת הרבה זמן.
מומלץ במידה והטבלה גדולה לחלק את הביצוע למספר partitions ע"פ קיבוץ של השדה לו מבוצע ה DC ( לדוגמה: חלוקה ע"פ מספרי לקוח 0-100 ו 100-200) ואם זה לא מספיק אפשר לחשוב להוסיף חלוקה נוספת המתאימה למודל ( לדוגמה: נחלק ע"פ תחום זמן הזהה לשאר המודל) .
שלוש הערות לסיום:
א. יצירת partition רבים מידי יכולים לגרום להשפעה שלילית על ביצועי השאילתות בשל ריבוי
תהליכי סריקה המתבצעים במספר רב של מקומות.
ב. בהרצת measure המוגדר כ DC מתבצעת שאילתת SQL הכוללת group by דבר שמאריך
את זמן הריצה.
ג. העלות של האגרגציות ל measure group הכולל DC גבוהה ( משאבים וזמן) ולכן מומלץ
לשקול את יצירתם בזהירות. לשם כך אפשר להשתמש ב "Usage-Based Optimization Wizard" וב " Aggregation Utility"
