חיבור Looker למסד הנתונים באמצעות תהליך העבודה מדור קודם

אחרי שמאבטחים ומגדירים את מסד הנתונים, אפשר לחבר אותו ל-Looker.

יוצרים חיבור למסד נתונים ב-Looker בדף חיבור מסד הנתונים ל-Looker. יש שתי אפשרויות לפתיחת הדף חיבור מסד הנתונים ל-Looker:

  • בקטע Database (מסד נתונים) בחלונית Admin (ניהול), לוחצים על Connections (קישורים). בדף Connections (חיבורים), לוחצים על הלחצן Add Connection (הוספת חיבור).
  • לוחצים על הלחצן יצירה בחלונית הניווט הימנית ואז בוחרים באפשרות חיבור בתפריט.

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

בדף הזה מתוארים שדות נפוצים שמוצגים ב-Looker בדף Connect your database to Looker (חיבור מסד הנתונים ל-Looker). השדות שיוצגו בדף תלויים בהגדרת הדיאלקט שלכם.

אחרי שמזינים את הגדרות החיבור למסד הנתונים, אפשר ללחוץ על הלחצן בדיקה בדף חיבור מסד הנתונים ל-Looker כדי לבדוק את החיבור ולוודא שהוא מוגדר בצורה נכונה. לוחצים על בדיקה כדי לוודא שהחיבור הצליח. מידע לפתרון בעיות זמין בדף בנושא בדיקת הקישוריות למסד הנתונים. אם ב-Looker מוצגת האפשרות Can Connect (אפשר להתחבר), לוחצים על Connect (התחברות) כדי ליצור את החיבור. החיבור למסד הנתונים יתווסף לרשימה בדף הניהול Connections ב-Looker.

הגדרות כלליות

שם

השם של החיבור שרוצים להתייחס אליו. השם הזה של חיבור מסד הנתונים נדרש לשימוש בפרמטר connection של מודל LookML. שם החיבור למסד הנתונים הוא גם השם שבו החיבור מזוהה בדף חיבורים ניהול ב-Looker. אסור להשתמש בשם של תיקיות בהגדרה הזו. הערך הזה לא צריך להיות זהה לערך כלשהו במסד הנתונים שלכם. Name היא תווית שמזהה את החיבור הזה בממשק המשתמש של Looker.

היקף החיבור

בוחרים אם אפשר להשתמש בחיבור עם כל הפרויקטים או רק עם פרויקט אחד:

  • ‫All Projects: לכל פרויקט LookML במכונה יכולה להיות גישה לחיבור, ולכן אפשר לציין את שם החיבור בפרמטר connection של קובצי מודלים בפרויקט הזה.
  • ‫Selected Project: רק לפרויקט של LookML אחד במופע יכולה להיות גישה לחיבור. כשבוחרים באפשרות הזו, בתפריט הנפתח במסך 'חיבור' מוצגים הפרויקטים במופע. בוחרים את הפרויקט שיוכל לגשת לחיבור הזה.

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

דיאלקט

ניב ה-SQL שתואם לחיבור. חשוב לבחור את הערך הנכון כדי שיוצגו לכם אפשרויות החיבור המתאימות, וכדי שמערכת Looker תוכל לתרגם את LookML ל-SQL בצורה נכונה.

מזהה פרויקט לחיוב

בחיבורים ל-Google BigQuery בלבד, מזהה פרויקט החיוב הוא Google Cloud מזהה הפרויקט.

מארח

שם המארח של מסד הנתונים ש-Looker צריך להשתמש בו כדי להתחבר למארח של מסד הנתונים.

אם עבדתם עם אנליסט של Looker כדי להגדיר מנהרת SSH למסד הנתונים שלכם, בשדה Host (מארח), מזינים "localhost".

יציאה

יציאת מסד הנתונים ש-Looker צריך להשתמש בה כדי להתחבר למארח מסד הנתונים.

אם עבדתם עם אנליסט Looker כדי להגדיר מנהרת SSH למסד הנתונים שלכם, בשדה Port (יציאה), מזינים את מספר היציאה שמפנה מחדש למסד הנתונים. האנליסט של Looker אמור לספק את המספר הזה.

מסד נתונים

השם של מסד הנתונים במארח. לדוגמה, יכול להיות שיש לכם שם מארח my-instance.us-east-1.redshift.amazonaws.com שבו יש מסד נתונים בשם sales_info. בשדה הזה צריך להזין sales_info. אם יש לכם כמה מסדי נתונים באותו מארח, יכול להיות שתצטרכו ליצור כמה חיבורים כדי להשתמש בהם (למעט MySQL, שבה המילה database משמעותה קצת שונה מאשר ברוב הניבים של SQL).

סכימה

סכימת ברירת המחדל ש-Looker משתמש בה כשלא מצוינת סכימה. ההגדרה הזו רלוונטית כשמשתמשים ב-SQL Runner, במהלך יצירת פרויקט של LookML וכשמבצעים שאילתות בטבלאות.

אימות

בחיבורים ל-Google BigQuery,‏ Snowflake,‏ Trino ו-Databricks, בוחרים את סוג האימות שרוצים ש-Looker ישתמש בו כדי לגשת למסד הנתונים:

  • בחיבורים ל-Google BigQuery, יש לכם אפשרות להגדיר OAuth או חשבון שירות ש-Looker ישתמש בו כדי לבצע אימות למסד הנתונים.
  • בחיבורים ל-Snowflake,‏ Trino ו-Databricks, יש לכם אפשרות להגדיר OAuth או חשבון מסד נתונים ש-Looker ישתמש בו כדי לבצע אימות למסד הנתונים.

כשמשתמשים ב-OAuth, המשתמשים צריכים להיכנס למסד הנתונים כדי להריץ שאילתות מ-Looker. מידע נוסף על הגדרת OAuth בחיבור ל-Looker זמין בהוראות לחיבור אל Google BigQuery,‏ Snowflake,‏ Trino או Databricks.

שם משתמש

שם המשתמש מחשבון משתמש במסד הנתונים, ש-Looker יכול להשתמש בו כדי להתחבר למסד הנתונים.

סיסמה

הסיסמה מחשבון משתמש במסד הנתונים, ש-Looker יכול להשתמש בה כדי להתחבר למסד הנתונים.

הגדרות אופציונליות

שרת SSH

האפשרות SSH Server זמינה רק אם המופע נפרס בתשתית Kubernetes, ורק אם הופעלה האפשרות להוסיף מידע על הגדרת שרת SSH למופע Looker. אם האפשרות הזו לא מופעלת במכונה של Looker ואתם רוצים להפעיל אותה, צרו קשר עם Google Cloud מומחה מכירות או פתחו בקשת תמיכה.

שרת ה-SSH בוחר באופן אוטומטי את יציאת ה-localhost בשבילכם, ואי אפשר לציין את יציאת ה-localhost. אם אתם צריכים ליצור חיבור SSH שבו צריך לציין יציאת localhost, אתם יכולים לפתוח בקשת תמיכה.

כדי להתחבר למסד הנתונים באמצעות מנהרת SSH, מפעילים את המתג ובוחרים הגדרת שרת SSH מהרשימה הנפתחת.

יציאה מקומית

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

טבלאות נגזרות מתמידות (PDT)

הפעלת PDT

מעבירים את המתג הפעלה של PDT למצב מופעל כדי להפעיל טבלאות נגזרות קבועות. כשמפעילים PDT, בחלון Connection מופיעים שדות PDT נוספים והקטע PDT Overrides. המתג Enable PDTs (הפעלת PDT) מוצג ב-Looker רק אם ניב מסד הנתונים תומך בשימוש ב-PDT.

חשוב לדעת את הפרטים הבאים על PDT:

  • אין תמיכה ב-PDT בחיבורים ל-Snowflake שמשתמשים ב-OAuth.
  • השבתה של PDTs בחיבור לא משביתה את קבוצות הנתונים שמשויכות ל-PDTs. גם אם משביתים את ה-PDT, קבוצות נתונים קיימות עדיין יפעילו את השאילתות sql_trigger שלהן מול מסד הנתונים. אם רוצים להפסיק את ההפעלה של שאילתת sql_trigger של קבוצת נתונים מול מסד הנתונים, צריך למחוק את הפרמטר datagroup מפרויקט LookML או להוסיף לו הערה, או לעדכן את ההגדרה Datagroup and PDT Maintenance Schedule של החיבור כך שמערכת Looker תבדוק את PDT ואת קבוצות הנתונים בתדירות נמוכה מאוד או אף פעם לא.
  • בחיבורים ל-Snowflake, ‏ Looker מגדיר את הערך של הפרמטר AUTOCOMMIT ל-TRUE (ערך ברירת המחדל של Snowflake). ‫AUTOCOMMIT נדרש לפקודות SQL שמערכת Looker מריצה כדי לתחזק את מערכת הרישום של PDT.

מסד נתונים זמני

למרות שהתווית היא Temp Database, צריך להזין את שם מסד הנתונים או את שם הסכימה – בהתאם לדיאלקט ה-SQL – ש-Looker צריך להשתמש בו כדי ליצור טבלאות נגזרות קבועות. צריך להגדיר את מסד הנתונים או הסכימה מראש, עם הרשאות הכתיבה המתאימות. בדף התיעוד הוראות להגדרת מסד נתונים, בוחרים את הדיאלקט של מסד הנתונים כדי לראות את ההוראות לדיאלקט הזה.

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

מספר החיבורים המקסימלי של כלי ה-PDT

ההגדרה Max number of PDT builder connections מאפשרת לציין כמה בנייות מקבילות של טבלאות יכולה התכונה Looker regenerator ליזום בחיבור למסד הנתונים. ההגדרה Max number of PDT builder connections (מספר החיבורים המקסימלי ליצירת PDT) חלה רק על סוגי הטבלאות שבהן הכלי ליצירת PDT ב-Looker יוזם בנייה מחדש:

  • טבלאות שנגזרות מטריגר מתמיד (טבלאות נגזרות מתמידות וטבלאות מסכמות שמשתמשות באסטרטגיית ההתמדה datagroup_trigger או sql_trigger_value).
  • טבלאות קבועות שמשתמשות באסטרטגיית persist_for, אבל רק אם טבלת persist_for היא חלק מסדרה של טבלאות נגזרות שבהן היא תלויה בטבלה שמשתמשת באסטרטגיית השמירה datagroup_trigger או sql_trigger_value. במקרה כזה, הכלי ליצירה מחדש של Looker יבנה מחדש את הטבלה persist_for, כי הטבלה נדרשת כדי לבנות מחדש טבלה אחרת בשרשור. אחרת, הגנרטור לא יתחיל לבנות טבלאות של persist_for.

ההגדרה מספר החיבורים המקסימלי של כלי ה-PDT מוגדרת כברירת מחדל ל-1, אבל אפשר להגדיר אותה עד 10. עם זאת, הערך לא יכול להיות גבוה מהערך שמוגדר בשדה Max connections per node או ב-per-user-query-limit שמוגדר באפשרויות ההפעלה של Looker.

חשוב להגדיר את הערך הזה בקפידה. אם הערך גבוה מדי, יכול להיות שתעמיסו על מסד הנתונים. אם הערך נמוך, יכול להיות ש-PDT שפועלים לאורך זמן או טבלאות מצטברות יעכבו את היצירה של טבלאות קבועות אחרות או יאטו את השאילתות האחרות בחיבור. מסדי נתונים שתומכים בשימוש של כמה דיירים – כמו BigQuery,‏ Snowflake ו-Redshift – עשויים להיות יעילים יותר בטיפול בבנייה מקבילה של שאילתות.

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

הערות לגבי ההגדרה מספר החיבורים המקסימלי של כלי ה-PDT Builder:

  • ההגדרה Max number of PDT builder connections חלה רק על חיבורים שנדרשים לבנייה מחדש של טבלאות, ולא על חיבורים שנדרשים לבדיקות של טריגרים. בדיקת טריגר היא שאילתה שבודקת אם מופעלת אסטרטגיית השמירה של הטבלה. מכיוון שהשאילתות האלה של בדיקת הטריגר מופעלות תמיד ברצף, ההגדרה מספר החיבורים המקסימלי של כלי ה-PDT לא חלה.
  • במופע Looker מקובץ, הגנרטור מחדש פועל רק בצומת הראשי. ההגדרה מספר מקסימלי של חיבורים לכלי ליצירת PDT חלה רק על הצומת הראשי, ולכן היא מגדירה את המגבלה לכל האשכול.
  • ההגדרה מספר מקסימלי של חיבורים לכלי ליצירת PDT לא חלה על סוגי הטבלאות הבאים. הטבלאות האלה נוצרות ברצף:
    • טבלאות שנשמרות באמצעות הפרמטר persist_for (אלא אם טבלאות אחרות מסתמכות על הטבלה הזו באמצעות האסטרטגיות datagroup_trigger או sql_trigger_value).
    • טבלאות במצב פיתוח.
    • טבלאות שנבנו מחדש באמצעות האפשרות Rebuild Derived Tables & Run.
    • טבלאות שבהן אחת תלויה באחרת בקסקדה של תלות. אי אפשר ליצור טבלה במקביל לטבלה שהיא תלויה בה. לדוגמה, אם table_B תלוי ב-table_A, אז table_A צריך לסיים את הבנייה מחדש לפני ש-table_B יכול להתחיל את הבנייה מחדש.

לוח זמנים לתחזוקה של קבוצות נתונים ו-PDT

הכלי Looker regenerator בודק קבוצות נתונים וטבלאות קבועות (גם טבלאות מצטברות וגם טבלאות נגזרות קבועות) שמבוססות על sql_trigger_value. על סמך הבדיקות האלה, כלי היצירה מחדש של Looker בונה מחדש טבלאות שנשמרו או מסיר אותן מסכימת הבסיס של מסד הנתונים.

הערך Datagroup and PDT Maintenance Schedule מגדיר את המרווח cron של מחולל ה-LookML. הכלי Looker regenerator מתחיל מחזור של regenerator כדי לבדוק קבוצות נתונים וטבלאות שנשמרו במרווח cron. אם מחזור של Looker regenerator עדיין מתבצע במרווח הזמן הבא cron, הוא יסיים את המחזור הנוכחי ואז ימתין עד למרווח הזמן הבא cron כדי להתחיל את המחזור הבא.

ההגדרה Datagroup and PDT Maintenance Schedule מקבלת ביטוי cron. ערך ברירת המחדל הוא */5 * * * *, כלומר מחזור החידוש של Looker יתחיל מחזור במרווח של חמש דקות, אם המחזור הקודם הסתיים. אם מחזור הרגנרטור הקודם לא הסתיים, הרגנרטור של Looker יופעל במרווח הבא של חמש דקות אחרי שהמחזור שלו יסתיים.

ברירת המחדל של חמש דקות היא גם המרווח הכי קצר שנתמך בDatagroup and PDT Maintenance Schedule. ‫Looker לא אוכף מרווח מקסימלי עבור Datagroup and PDT Maintenance Schedule, כלומר אפשר להאריך את המרווח בין מחזורי יצירה מחדש של Looker לכל משך זמן שאפשר לציין באמצעות ביטוי cron. חשוב לזכור שמחזורי יצירה מחדש ארוכים יותר ב-Looker עלולים להשפיע לרעה על עדכניות הנתונים במטמון ובטבלאות המתמידות.

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

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

cron ביטוי הגדרה
*/5 8-17 * * MON-FRI בדיקת קבוצות נתונים ו-PDT כל 5 דקות במהלך שעות הפעילות, בימים שני עד שישי
*/5 8-17 * * * בדיקת קבוצות נתונים ו-PDT כל 5 דקות במהלך שעות הפעילות, בכל יום
0 8-17 * * MON-FRI בדיקת קבוצות נתונים ו-PDT בכל שעה במהלך שעות הפעילות, בימים שני עד שישי
1 3 * * * בדיקת קבוצות נתונים ו-PDT כל יום בשעה 3:01

כמה דברים שחשוב לזכור כשיוצרים ביטוי cron:

  • ‫Looker משתמש ב-parse-cron v0.1.3, שלא תומך ב-? בביטויי cron.
  • הביטוי cron משתמש באזור הזמן של האפליקציה ב-Looker כדי לקבוע מתי מתבצעות הבדיקות.
  • אם לא נוצרים PDT, מאפסים את מחרוזת ה-cron בחזרה לברירת המחדל */5 * * * *.

ריכזנו כאן כמה מקורות מידע שיעזרו לכם ליצור מחרוזות cron:

ניסיון חוזר של בניית כללי PDT שנכשלו

המתג Retry failed PDT builds מגדיר איך Looker regenerator מנסה לבנות מחדש trigger-persisted tables שנכשלו במחזור הקודם של regenerator. התהליך של יצירה מחדש ב-Looker הוא התהליך שבו נבנות מחדש טבלאות PDT וטבלאות מסכמות שנשמרות על ידי טריגר, בהתאם למרווח הזמן שמוגדר בהגדרת החיבור Datagroup and PDT Maintenance Schedule. כשהמתג Retry Failed PDT Builds (ניסיון חוזר לבניית PDT שנכשלו) מופעל, הגנרטור מחדש של Looker ינסה לבנות מחדש PDT שנכשל במחזור הקודם של הגנרטור מחדש, גם אם תנאי הטריגר של ה-PDT לא מתקיימים. כשההגדרה הזו מושבתת, הגנרטור מחדש של Looker ינסה לבנות מחדש PDT שנבנה בעבר ונכשל רק כשמתקיים תנאי הטריגר של ה-PDT. האפשרות Retry Failed PDT Builds (ניסיון חוזר של בניית PDT שנכשלה) מושבתת כברירת מחדל.

מידע נוסף על מחולל הטבלאות הנגזרות ב-Looker זמין בדף טבלאות נגזרות ב-Looker.

בקרת PDT API

המתג PDT API Control קובע אם אפשר להשתמש בקריאות ל-API של start_pdt_build,‏ check_pdt_build ו-stop_pdt_build עבור החיבור הזה. אם המתג PDT API Control מושבת, קריאות ה-API האלה ייכשלו אם הן מפנות ל-PDT בחיבור הזה. המתג PDT API Control מושבת כברירת מחדל.

שינויים מברירת המחדל של PDT

אם מסד הנתונים שלכם תומך בטבלאות נגזרות קבועות, והפעלתם את המתג Enable PDTs (הפעלת טבלאות נגזרות קבועות) בהגדרות החיבור, Looker יציג את הקטע PDT Overrides (שינויים בטבלאות נגזרות קבועות). בקטע PDT Overrides (שינויים ב-PDT), אפשר להזין פרמטרים נפרדים של JDBC (מארח, יציאה, מסד נתונים, שם משתמש, סיסמה, סכימה, פרמטרים נוספים ומשפטים אחרי ההתחברות) שספציפיים לתהליכי PDT. יש לכך כמה יתרונות:

  • אם יוצרים משתמש נפרד במסד הנתונים לתהליכי PDT, אפשר להשתמש ב-PDT בפרויקט Looker גם אם מקצים מאפייני משתמש לפרטי הכניסה למסד הנתונים או משתמשים ב-OAuth לחיבור למסד הנתונים.
  • תהליכי PDT יכולים לבצע אימות דרך משתמש מסד נתונים נפרד עם עדיפות גבוהה יותר. כך מסד הנתונים יכול לתת עדיפות לעבודות PDT על פני שאילתות משתמשים שהן פחות קריטיות.
  • אפשר לבטל את גישת הכתיבה לחיבור הרגיל של מסד הנתונים ב-Looker, ולהעניק אותה רק למשתמש מיוחד שהתהליכים של PDT ישתמשו בו לאימות. זו אסטרטגיית אבטחה טובה יותר לרוב הארגונים.
  • במסדי נתונים כמו Snowflake, אפשר להפנות תהליכי PDT לחומרה חזקה יותר שלא משותפת עם שאר משתמשי Looker. כך אפשר ליצור PDT במהירות בלי לשלם על הפעלת חומרה יקרה במשרה מלאה.

לדוגמה, בהגדרה הבאה מוצג חיבור שבו השדות של שם המשתמש והסיסמה מוגדרים כמאפייני משתמש. כך כל משתמש יכול לגשת למסד הנתונים באמצעות פרטי הכניסה האישיים שלו. בקטע PDT Overrides (שינויים ב-PDT) נוצר משתמש נפרד (pdt_user) עם סיסמה משלו. חשבון pdt_user ישמש לכל התהליכים של PDT, עם רמות גישה שמתאימות ליצירה ולעדכון של PDT.

בקטע PDT Overrides (שינויים ב-PDT) בדף Connect your database to Looker (חיבור מסד הנתונים ל-Looker).

אזור זמן

אזור הזמן של מסד הנתונים

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

אזור הזמן של השאילתות

האפשרות אזור זמן של השאילתה מוצגת רק אם השבתתם את אזורי זמן ספציפיים למשתמש.

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

מידע נוסף מופיע בדף התיעוד בנושא שימוש בהגדרות אזור הזמן.

הגדרות נוספות

פרמטרים נוספים של JDBC

במידת הצורך, אפשר לכלול כאן פרמטרים נוספים של Java Database Connectivity ‏ (JDBC) לשאילתות.

כדי להפנות אל מאפיין משתמש בפרמטר JDBC, משתמשים בתחביר של תבניות Liquid: _user_attributes['name_of_attribute']. לדוגמה:

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

מספר החיבורים המקסימלי לכל צומת

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

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

ערך ברירת המחדל (שמשתנה בהתאם לניב ה-SQL) הוא בדרך כלל נקודת התחלה סבירה. לרוב מסדי הנתונים יש גם הגדרות משלהם לגבי המספר המקסימלי של חיבורים שהם יקבלו. אם הגדרת מסד הנתונים מגבילה את החיבורים, צריך לוודא שהערך של Max Connections per node (מספר החיבורים המקסימלי לכל צומת) שווה למגבלה של מסד הנתונים או נמוך ממנה.

הזמן הקצוב לתפוגה של מאגר החיבורים

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

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

מספר מקסימלי של שאילתות בו-זמניות לחיבור הזה

הערך האופציונלי הזה מגביל את מספר השאילתות המקבילות ש-Looker ישלח לחיבור הזה למסד הנתונים בכל פעם. אם יגיעו עוד בקשות בו-זמניות שדורשות את אותו חיבור, Looker יכניס אותן לתור פנימי ויעבד אותן לפי הסדר. הגדרת הערך הזה תחליף ערך קיים של Max connections per node.

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

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

SSL

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

אימות SSL

בוחרים אם רוצים לדרוש אימות של אישור ה-SSL שמשמש לחיבור. אם נדרש אימות, רשות אישורי ה-SSL שחתמה על אישור ה-SSL צריכה להיות ברשימת המקורות המהימנים של הלקוח. אם רשות האישורים לא מהימנה, החיבור למסד הנתונים לא יתבצע.

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

SQL Runner Precache

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

אם אתם מעדיפים ש-SQL Runner יטען את פרטי הטבלה רק כשבוחרים טבלה, אתם יכולים לבטל את הסימון של האפשרות SQL Runner Precache כדי להשבית את הטעינה מראש של SQL Runner עבור החיבור.

אחזור סכימת מידע לכתיבת SQL

כדי לבצע אופטימיזציה של כתיבת SQL, Looker משתמש בסכימת המידע של מסד הנתונים עבור תכונות מסוימות של כתיבת SQL, כמו הכרת נתוני צבירה. אם סכימת המידע לא נשמרת במטמון, יכול להיות ש-Looker יצטרך מדי פעם לחסום כתיבת SQL למסד הנתונים כדי לאחזר את סכימת המידע. בניבים שמשתמשים ב-Hadoop Distributed File System (HDFS), יכול להיות שייקח זמן רב מדי לאחזור סכימת המידע, וזה ישפיע באופן משמעותי על הביצועים של השאילתות ב-Looker. אם אתם יודעים שסכימת המידע שלכם איטית, אתם יכולים להשבית את האפשרות Fetch Information Schema For SQL Writing (אחזור סכימת מידע לכתיבת SQL) בחיבור. השבתת התכונה הזו תמנע אופטימיזציה של SQL ב-Looker עבור תכונות מסוימות, ולכן כדאי להפעיל את האפשרות Fetch Information Schema For SQL Writing, אלא אם אתם יודעים שסכימת המידע של החיבור שלכם איטית במיוחד.

עלות משוערת

המתג הערכת עלויות רלוונטי רק לחיבורי מסדי הנתונים הבאים:

המתג הערכת עלויות מאפשר להשתמש בתכונות הבאות בחיבור:

מידע נוסף זמין בדף התיעוד בנושא בדיקת נתונים ב-Looker.

איגום חיבורים למסד נתונים

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

בדיקת הגדרות החיבור

אפשר לבדוק את הגדרות החיבור מכמה מקומות בממשק המשתמש של Looker:

  • בתחתית הדף הגדרות חיבורים, לוחצים על הלחצן בדיקה.
  • לוחצים על הלחצן בדיקה ברשימת החיבורים בדף האדמין חיבורים, כמו שמתואר בדף התיעוד בנושא חיבורים.

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

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

  • נסו כמה מהשלבים לפתרון בעיות שמופיעים בדף התיעוד בנושא בדיקת הקישוריות למסד הנתונים.
  • אם אתם מריצים את Mongo בגרסה 3.6 או בגרסה מוקדמת יותר ב-Atlas ומתקבלת שגיאה לגבי כשל בקישור תקשורת, כדאי לעיין בדף התיעוד של Mongo Connector.
  • כדי לקבל הודעות על חיבור מוצלח לגבי סכימת הטמפ' ו-PDT, צריך לאפשר את הפונקציונליות הזו כשמגדירים את מסד הנתונים של Looker. הוראות לביצוע הפעולה מופיעות בדף התיעוד הוראות להגדרת מסד נתונים.

אם הבעיה נמשכת, אפשר לפתוח בקשת תמיכה.

בדיקה כמשתמש

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

השלבים הבאים

אחרי שמקשרים את מסד הנתונים ל-Looker, אפשר להגדיר את אפשרויות הכניסה למשתמשים.