אחת הדרכים הכי טובות לאפשר למשתמשים לעיין בנתונים היא ליצור לוחות בקרה יעילים ב-Looker. כדי ליצור חוויית ביצועים מעולה למשתמשים, כדאי לעיין בטיפים שבדף הזה כשמעצבים את לוחות הבקרה.
לוחות בקרה של Looker נטענים בדפדפן. כדי להשיג ביצועים אופטימליים, חשוב לזכור את העובדות הבאות.
הגורם הכי חשוב בביצועים של לוח הבקרה הוא הביצועים של שאילתת ה-SQL הבסיסית. כל רכיב בלוח הבקרה, אם הוא לא מוחזר מהמטמון, מריץ שאילתת SQL שלוקח זמן להריץ אותה במסד הנתונים הבסיסי. בקטע אופטימיזציה של ביצועי שאילתות בדף השיטות המומלצות בנושא אופטימיזציה של הביצועים ב-Looker יש פרטים נוספים על יצירת שאילתות יעילות.
חלק מהרכיבים צורכים יותר זיכרון מאשר רכיבים שקשורים ל-SQL – הם עלולים לגרום לביצועים איטיים בלוחות בקרה:
-
נפח הנתונים משפיע הכי הרבה על הביצועים. ככל שיותר נתונים מוחזרים באלמנט בודד, כך ייצרכו יותר משאבי זיכרון. מראה ורכיבים של לוח בקרה שמוחזרים עם אלפי נקודות נתונים ינצלו יותר זיכרון.
-
הגבלת מספר הרכיבים במרכז הבקרה. אין כלל ברור לגבי המספר, כי העיצוב של רכיב יחיד משפיע על צריכת הזיכרון שלו על סמך כמה גורמים (שמפורטים בהמשך הדף). עם זאת, מומלץ להימנע מיצירת מרכזי בקרה עם 25 שאילתות או יותר. כדי לשמור על ביצועים חלקים של מרכז הבקרה, אפשר ליצור קישורי ניווט בין מרכזי בקרה או ליצור קישורים לכתובות URL מותאמות אישית כדי ליצור ניווט מותאם אישית ממרכז בקרה אחד למשנהו. אפשר גם לנסות לשרשר מדדים דומים לתצוגה חזותית של ערך יחיד כדי להימנע מתצוגות חזותיות רבות של משבצת יחידה.
-
שימוש אסטרטגי בהגדרות של לוח הבקרה. אם נעשה שימוש ברענון אוטומטי בלוח הבקרה, צריך לוודא שהרענון לא מהיר יותר מתהליך ה-ETL. באופן כללי, מומלץ להימנע מהגדרת רענון אוטומטי מהיר יותר מ-15 דקות. אם רוצים לסנן את לוח הבקרה, לא משתמשים באפשרות run on load. כדי למנוע ממשתמשים להפעיל לוחות בקרה בלי המסננים הנדרשים, אפשר להשתמש במסננים נדרשים.
-
שימוש במטמון. השיטה המומלצת היא להשתמש ב קבוצות נתונים כדי לסנכרן את כל התוכן ב-Looker (לוחות בקרה, תצוגות, לוחות זמנים) עם תהליך ה-ETL. כך אפשר להימנע משאילתות מיותרות כשהנתונים לא עדכניים.
-
תכונות של עיבוד אחרי שליחת השאילתה, כמו מיזוג תוצאות, שדות מותאמים אישית וחישובים בטבלה, צורכות זיכרון. ככל שמשתמשים ביותר תכונות של עיבוד אחרי שאילתה, כך נצרך יותר זיכרון. אם אתם משתמשים באותם חישובים בטבלה, בתוצאות הממוזגות או בשדות בהתאמה אישית בכמה טבלאות Look ולוחות בקרה, כדאי לשקול להגדיר אותם בתוך הקוד של מודל LookML בכל מקום שאפשר. באופן כללי, לא מומלץ להוסיף ללוח בקרה יותר מארבעה אריחים של תוצאות ממוזגות.
-
מאפייני ציר צורכים זיכרון. ככל שיש יותר מאפיינים שמוצגים בטבלת ציר ב-Look או במשבצת של לוח בקרה, כך נצרך יותר זיכרון כשלוח הבקרה נטען. כפי שצוין בנקודת התבליט הראשונה, הסיבה לכך היא שנעשה שימוש ביותר נתונים ככל שמוחזרים יותר נתונים. אם למאפיין שמבצעים עליו Pivot יש עוצמה גבוהה (הרבה ערכים ייחודיים), תהיה עמודה לכל ערך. כדי לא להציג את כל הנתונים בבת אחת, אפשר להשתמש במסנן ברמת מרכז הבקרה או ברמת ה-Look כדי לאפשר למשתמש לבחור את ערכי המאפיינים שהכי מעניינים אותו להשוואה.
-
שימוש בהרבה עמודות ושורות צורך יותר זיכרון. כדי לשפר את הביצועים בדפדפן, מומלץ להשתמש ב-50 עמודות או פחות. כמו שצוין בנקודת התבליט הראשונה, אם מחזירים ב-Looks נפח גדול של שורות והרבה עמודות, הביצועים עלולים להיות איטיים. כדי לצמצם את מספר התוצאות ברכיב מסוים, אפשר לסנן ברמת לוח הבקרה או ברמת ה-Look.
-
אפשר להשתמש במסננים משותפים עם שאילתה אחת כדי להציג תוצאה של שאילתה אחת בכמה משבצות. הפעולה הזו אמורה להקטין את המספר הכולל של השאילתות שמופעלות מלוח הבקרה, כי שאילתה אחת תפעיל כמה רכיבים בלוח הבקרה.
-
מסנני AND/OR. אין הגבלה על מספר הקבוצות שאפשר ליצור, אבל יותר מדי קבוצות סינון עלולות להשפיע על ביצועי הדפדפן.
-
מומלץ להשתמש באפשרות כל התוצאות כדי להוריד או לשלוח שאילתות רק לעיתים רחוקות, כי חלק מהשאילתות יכולות להיות גדולות מאוד ולגרום לעומס יתר על שרת Looker בזמן העיבוד.
חשוב לבדוק את ביצועי לוח הבקרה אחרי שמוסיפים אליו רכיבים. במהלך הפיתוח, כדאי להמשיך לנווט אל לוח הבקרה ולרענן את הדף כדי לראות איך הביצועים מושפעים כשמוסיפים עוד תצוגות Look.
אחרי שיוצרים לוח בקרה חדש ב-Looker, חשוב להשתמש בהרשאות לתיקיות כדי לוודא שלא ניתן יהיה לשנות את לוח הבקרה בטעות. כדאי להשתמש בקבוצות משתמשים כדי לנהל את הגישה לתוכן ואת ההרשאות בכמות גדולה, במקום לנהל אותן עבור כל משתמש בנפרד.
אם נתקלתם בבעיות בביצועים, אתם יכולים לפנות ישירות אל התמיכה של Looker. הצוות שלנו תמיד מוכן לבדוק ולעזור!