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

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

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

ההגדרות של המארח

מערכת הפעלה והפצה

‫Looker פועל בצורה טובה בגרסאות הנפוצות ביותר של Linux: ‏ RedHat,‏ SUSE ו-Debian/Ubuntu. בדרך כלל אין בעיה עם נגזרות של ההפצות האלה שנועדו לפעול בסביבה מסוימת ועברו אופטימיזציה לפעולה בסביבה הזו. לדוגמה, הפצות Linux של Google Cloud או AWS תואמות ל-Looker. ‫Debian/Ubuntu היא הגרסה של Linux שהכי הרבה משתמשים בה בקהילת Looker, ואלה הגרסאות שצוות התמיכה של Looker מכיר הכי טוב. הכי קל להשתמש ב-Debian/Ubuntu או במערכת הפעלה של ספק שירותי ענן ספציפי שנגזרת מ-Debian/Ubuntu.

‫Looker פועל במכונה הווירטואלית של Java‏ (JVM). כשבוחרים הפצה, חשוב לבדוק אם הגרסאות של OpenJDK 11 עדכניות. יכול להיות שאפשר להריץ את Looker בהפצות ישנות יותר של Linux, אבל גרסת Java והספריות ש-Looker דורש לתכונות ספציפיות צריכות להיות עדכניות. אם ה-JVM לא מכיל את כל הספריות והגרסאות המומלצות של Looker, ‏ Looker לא יפעל כרגיל. כדי להשתמש ב-Looker, צריך Java HotSpot בגרסה 1.8 update 161 ואילך או Java OpenJDK בגרסה 11.0.12 ואילך.

מעבד (CPU) וזיכרון

צמתים בגודל ‎4x16 (4 CPUs ו-‎16 GB RAM) מספיקים למערכת פיתוח או למופע בסיסי של Looker לבדיקות שמשמש צוות קטן. עם זאת, בדרך כלל זה לא מספיק לשימוש בסביבת ייצור. לפי הניסיון שלנו, 16x64 צמתים (16 מעבדים ו-64GB של RAM) הם איזון טוב בין מחיר לביצועים. יותר מ-64GB של RAM יכולים להשפיע על הביצועים, כי אירועי מנגנון איסוף הם single threaded ועוצרים את כל השרשורים האחרים כדי לבצע אותם.

נפח אחסון בדיסק

בדרך כלל, 100GB של שטח בדיסק מספיקים למערכת ייצור.

שיקולים לגבי אשכולות

‫Looker פועל על Java JVM, ול-Java יכול להיות קשה לנהל זיכרון גדול מ-64GB. ככלל, אם נדרש יותר קיבולת, כדאי להוסיף עוד 16x64 צמתים לאשכול במקום להגדיל את גודל הצמתים מעבר ל-16x64. יכול להיות שנרצה גם להשתמש בארכיטקטורה מקובצת כדי להגדיל את הזמינות.

בצביר, צמתי Looker צריכים לשתף חלקים מסוימים במערכת הקבצים. הנתונים שמשותפים כוללים את הפרטים הבאים:

  • מודלים של LookML
  • מודלים של LookML למפתחים
  • קישוריות לשרת Git

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

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

הגדרת JVM

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

java \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
  -Xms$JAVAMEM -Xmx$JAVAMEM \
  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
  -Xloggc:/tmp/gc.log ${JAVAARGS} \
  -jar looker.jar start ${LOOKERARGS}

משאבים

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

JAVAMEM="2300m"
METAMEM="800m"

כשמקצים זיכרון ל-JVM, צריך לקחת בחשבון את התקורה של מערכת ההפעלה ש-Looker פועל עליה. הכלל הכללי הוא שאפשר להקצות ל-JVM עד 60% מהזיכרון הכולל, אבל יש לכך חריגים בהתאם לגודל המכונה. למחשבים עם 8GB זיכרון כולל, אנחנו ממליצים להקצות 4-5GB ל-Java ו-800MB ל-Meta. במכונות גדולות יותר, אפשר להקצות למערכת ההפעלה חלק קטן יותר מהזיכרון. לדוגמה, במכונות עם זיכרון כולל של 60GB, מומלץ להקצות 36GB ל-Java ו-1GB ל-Meta. חשוב לציין שהקצאת הזיכרון של Java אמורה בדרך כלל להשתנות בהתאם לזיכרון הכולל של המכונה, אבל 1GB אמור להספיק ל-Meta.

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

איסוף אשפה

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

-XX:MaxGCPauseMillis=2000

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

יומנים

כברירת מחדל, יומני מנגנון איסוף הזבל של Looker מאוחסנים ב-/tmp/gc.log. אפשר לשנות את ההגדרה הזו על ידי עריכת האפשרות הבאה בהגדרת ההפעלה: 

-Xloggc:/tmp/gc.log

JMX

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

אפשרויות ההפעלה של Looker

אפשרויות ההפעלה מאוחסנות בקובץ בשם lookerstart.cfg. הקובץ הזה מקורו בסקריפט מעטפת שמתחיל את Looker.

מאגרים של פרוטוקולי Thread

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

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

בכל הצמתים שאינם צמתים של מתזמן, מוסיפים --scheduler-threads=0 למשתנה הסביבה LOOKERARGS ב-lookerstart.cfg. ללא שרשורים של מתזמן, לא יפעלו עבודות מתוזמנות בצמתים האלה.

בכל הצמתים הייעודיים של מתזמן הפגישות, מוסיפים את --scheduler-threads=<n> למשתנה הסביבה LOOKERARGS ב-lookerstart.cfg. כברירת מחדל, ל-Looker יש 10 שרשורים של מתזמן, אבל אפשר להגדיל את המספר הזה ל-<n>. עם <n> שרשורים של מתזמן, כל צומת יוכל להריץ <n> משימות מתוזמנות בו-זמנית. בדרך כלל מומלץ להגדיר את <n> כך שיהיה קטן מפי 2 ממספר המעבדים. המארח הגדול ביותר המומלץ הוא מארח עם 16 מעבדים וזיכרון בנפח 64GB, ולכן הגבול העליון של השרשורים של מתזמן המשימות צריך להיות קטן מ-32.

אפשרויות של תפוקת עיבוד גבוהה

בכל הצמתים שאינם צמתי רינדור, מוסיפים --concurrent-render-jobs=0 למשתנה הסביבה LOOKERARGS ב-lookerstart.cfg. ללא צמתי עיבוד, לא יופעלו משימות עיבוד בצמתים האלה.

לכל צומתי הרינדור הייעודיים, מוסיפים --concurrent-render-jobs=<n> למשתנה הסביבה LOOKERARGS ב-lookerstart.cfg. כברירת מחדל, Looker מתחיל עם שני שרשורים של עיבוד, אבל אפשר להגדיל את המספר הזה ל-<n>. עם <n> שרשורים של עיבוד, כל צומת יוכל להריץ <n> משימות עיבוד בו-זמנית.

כל עבודת רינדור יכולה להשתמש בכמות משמעותית של זיכרון. מומלץ להקצות כ-2GB לכל עבודת רינדור. לדוגמה, אם לתהליך הליבה של Looker ‏ (Java) מוקצים 60% מהזיכרון הכולל, ו-20% מהזיכרון שנותר שמורים למערכת ההפעלה, נשארים 20% אחרונים לעבודות רינדור. במכונה עם 64GB, נשארים 12GB, שזה מספיק ל-6 עבודות רינדור בו-זמניות. אם צומת מוקדש לרינדור ולא נכלל במאגר של מאזן העומסים שמטפל בעבודות אינטראקטיביות, אפשר לצמצם את הזיכרון של תהליך הליבה של Looker כדי לאפשר יותר עבודות רינדור. במכונה עם 64GB, אפשר להקצות בערך 30% (20GB) לתהליך הליבה של Looker. אם נשמור 20% לשימוש כללי במערכת ההפעלה, יישארו 50% (32GB) לרינדור, וזה מספיק ל-16 עבודות רינדור בו-זמניות.

מסד נתונים פנימי (בקצה העורפי)

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

במקרים של מופע עצמאי של Looker בגודל בינוני, הנתונים האלה מאוחסנים במסד נתונים של HyperSQL בזיכרון שמוטמע בתהליך Looker עצמו. הנתונים של מסד הנתונים הזה מאוחסנים בקובץ <looker install directory>/.db/looker.script. המסד נתונים הזה נוח וקל משקל, אבל יש בו בעיות בביצועים כשיש עומס שימוש. לכן מומלץ להתחיל עם מסד נתונים מרוחק של MySQL. אם זה לא אפשרי, מומלץ לבצע העברה למסד נתונים מרוחק של MySQL אחרי שהקובץ ~/looker/.db/looker.script יגיע לגודל של 600MB. חובה להשתמש במסד נתונים של MySQL באשכולות.

שרת Looker מבצע הרבה פעולות קטנות של קריאה וכתיבה במסד הנתונים של MySQL. בכל פעם שמשתמש מריץ Look או Explore,‏ Looker בודק במסד הנתונים כדי לוודא שהמשתמש עדיין מחובר, שיש לו הרשאות גישה לנתונים, שיש לו הרשאות להריץ את ה-Look או את ה-Explore וכו'. ‫Looker גם יכתוב נתונים למסד הנתונים של MySQL, כמו ה-SQL בפועל שהופעל והזמן שבו הבקשה התחילה והסתיימה. אינטראקציה אחת בין משתמש לבין אפליקציית Looker יכולה להוביל ל-15 או 20 פעולות קטנות של קריאה וכתיבה במסד הנתונים של MySQL.

MySQL

שרת MySQL צריך להיות בגרסה 8.0.x, וצריך להגדיר אותו לשימוש בקידוד utf8mb4. חובה להשתמש במנוע האחסון InnoDB. הוראות ההגדרה של MySQL, וגם הוראות להעברת נתונים ממסד נתונים קיים של HyperSQL אל MySQL, זמינות בדף התיעוד העברת מסד הנתונים של הבק-אנד של Looker אל MySQL.

כשמגדירים את Looker לשימוש ב-MySQL, צריך ליצור קובץ YAML שמכיל את פרטי החיבור. נותנים לקובץ ה-YAML את השם looker-db.yml ומוסיפים את ההגדרה -d looker-db.yml בקטע LOOKERARGS של הקובץ lookerstart.cfg.

MariaDB

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

גרסאות Cloud

אם אתם מארחים את Looker בתשתית הענן שלכם, הגיוני לארח את מסד הנתונים של MySQL באותה תשתית ענן. שלושת ספקי הענן הגדולים – Amazon AWS,‏ Microsoft Azure ו- Google Cloud. ספקי הענן מנהלים חלק גדול מהתחזוקה וההגדרה של מסד הנתונים MySQL, ומציעים שירותים כמו עזרה בניהול גיבויים ומתן שחזור מהיר. ידוע שהמוצרים האלה פועלים היטב עם Looker.

שאילתות של פעילות המערכת

מסד הנתונים של MySQL משמש לאחסון מידע על אופן השימוש של המשתמשים ב-Looker. לכל משתמש ב-Looker שיש לו הרשאה לצפייה במודל System Activity יש גישה למספר לוחות בקרה מוכנים מראש ב-Looker לניתוח הנתונים האלה. המשתמשים יכולים גם לגשת לניתוחים של מטא-נתונים של Looker כדי ליצור ניתוחים נוספים. מסד הנתונים של MySQL משמש בעיקר לשאילתות קטנות, מהירות ו"תפעוליות". שאילתות גדולות, איטיות ו'אנליטיות' שנוצרות על ידי מודל פעילות המערכת יכולות להתחרות בשאילתות התפעוליות האלה ולהאט את Looker. בנוסף, שאילתות אוטומטיות לתחזוקה ברקע (ניקויים אינטנסיביים) שמכוונות לטבלאות גדולות של מטא-נתונים שמכילות היסטוריה של שנים יכולות לצרוך כמות משמעותית של פעולות קלט/פלט במסד הנתונים ולהשפיע על הביצועים הכוללים. בקטע תחזוקה של מסד הנתונים בעורף ושמירה של מטא-נתונים מפורטות שיטות מומלצות לניהול טבלאות של מטא-נתונים.

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

כדי להשתמש בעותק המשוכפל בשאילתות של פעילות המערכת, צריך ליצור עותק של הקובץ looker-db.yml, למשל בשם looker-usage-db.yml, לשנות אותו כך שיצביע על העותק המשוכפל ולהוסיף את ההגדרה --internal-analytics-connection-file looker-usage-db.yml לקטע LOOKERARGS בקובץ lookerstart.cfg.

אפשר להריץ את השאילתות של פעילות המערכת מול מופע MySQL או מול מסד נתונים של Google BigQuery. הם לא נבדקים מול מסדי נתונים אחרים.

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

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

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

  1. צמצום תקופת השמירה של מטא-נתונים: כדי להגביל את הגודל של הטבלאות האלה, צריך להגדיר את הפרמטר Extract History Retention Days (מספר הימים לשמירת היסטוריית החילוץ) בלוח **הניהול** של Looker ל-90 ימים או פחות.
  2. ביצוע תחזוקה פיזית: מבצעים ניקוי ידני של הרשומות בטבלאות הגדולות ביותר (כמו טבלת היסטוריית השאילתות), ואחריו מריצים פקודת MySQL OPTIMIZE TABLE כדי לפנות מקום פיזי בדיסק ולבנות מחדש את אינדקסים של הטבלאות.
  3. אימות הגדרות הזיכרון: מוודאים שהגדרות הזיכרון של מסד הנתונים (כמו InnoDB Buffer Pool) מספיקות לטיפול בשאילתות אינטנסיביות. יכול להיות שיהיה צורך לבצע אופטימיזציה של innodb_buffer_pool_size באשכולות פעילים מאוד (ראו את הקטע הגדרת ביצועים של MySQL בהמשך הדף).

הגדרת הביצועים של MySQL

בנוסף להגדרות שנדרשות כדי להעביר את מסד הנתונים של העורף של Looker ל-MySQL, יכול להיות שיהיה כדאי לבצע כוונון והגדרה נוספים באשכולות פעילים מאוד. אפשר להגדיר את ההגדרות האלה בקובץ /etc/my.cnf או דרך מסוף Google Cloud עבור מופעים שמנוהלים בענן.

קובץ ההגדרה my.cnf מחולק לכמה חלקים. השינויים הבאים בהגדרות שמוזכרים בקטע הזה מתבצעים בחלק [mysqld].

הגדרת גודל מאגר הנתונים הזמני של InnoDB

גודל מאגר הנתונים הזמני של InnoDB הוא נפח ה-RAM הכולל שמשמש לאחסון המצב של קובצי הנתונים של InnoDB בזיכרון. אם השרת מוקדש להרצת MySQL, צריך להגדיר את innodb_buffer_pool_size ל-50% עד 70% מזיכרון המערכת הכולל.

אם הגודל הכולל של מסד הנתונים קטן, אפשר להגדיר את מאגר הנתונים של InnoDB לגודל של מסד הנתונים ולא ל-50% או יותר מהזיכרון.

בדוגמה הזו, לשרת יש זיכרון של 64GB, ולכן מאגר הנתונים הזמני של InnoDB צריך להיות בין 32GB ל-45GB. בדרך כלל ככל שהמסך גדול יותר, כך טוב יותר. 

[mysqld]
...
innodb_buffer_pool_size=45G

הגדרת מופעים של מאגר הנתונים הזמני של InnoDB

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

[mysqld]
...
innodb_buffer_pool_instances=32

אופטימיזציה של קובץ היומן של InnoDB

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

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

בדרך כלל יש שני קובצי יומן של InnoDB. הם צריכים להיות בערך 25% ממאגר הנתונים הזמני של InnoDB. לדוגמה, במסד נתונים עם מאגר של 32GB, קובצי היומן של InnoDB צריכים להיות בגודל כולל של 8GB, או 4GB לכל קובץ. 

[mysqld]
...
innodb_log_file_size=8GB

הגדרת קיבולת קלט/פלט של InnoDB

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

במערכת שמארחת בענן, ספק הענן אמור להיות מסוגל לדווח על הביצועים של הדיסקים שמשמשים לאחסון נתונים. בשרת MySQL באירוח עצמי, מודדים את מהירות הכתיבה האקראית לדיסק הנתונים בפעולות קלט/פלט לשנייה (IOPS). אחת הדרכים למדוד את זה היא באמצעות כלי השירות sysbench של Linux. משתמשים בערך הזה במאפיין innodb_io_capacity_max, ובערך ששווה למחצית עד שלושת-רבעי מהערך הזה במאפיין innodb_io_capacity. לכן, בדוגמה הבאה, נראה את הערכים אם נמדוד 800 פעולות קלט/פלט בשנייה. 

[mysqld]
...
innodb_io_capacity=500
innodb_io_capacity_max=800

הגדרת שרשורי InnoDB

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

כדאי לבצע השוואה לשוק כדי לקבוע את מספר השרשורים האידיאלי. כדי לבדוק, מגדירים את מספר השרשורים בין מספר המעבדים (או ליבות המעבד) במערכת לבין פי 4 ממספר המעבדים. במערכת עם 16 ליבות, הערך הזה יהיה כנראה בין 16 ל-64. 

[mysqld]
...
innodb_thread_concurrency=32

עמידות העסקה

ערך עסקה של 1 מאלץ את MySQL לכתוב לדיסק לכל עסקה. אם השרת קורס, העסקה לא תאבד, אבל הביצועים של מסד הנתונים יושפעו. הגדרת הערך הזה ל-0 או ל-2 יכולה לשפר את הביצועים, אבל היא כרוכה בסיכון לאובדן של נתונים של כמה שניות. 

[mysqld]
...
innodb_flush_log_at_trx_commit=1

הגדרת שיטת ה-flush

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

[mysqld]
...
innodb_flush_method=O_DIRECT

הפעלת קובץ אחד לכל טבלה

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

[mysqld]
...
innodb_file_per_table=ON

השבתת נתונים סטטיסטיים במטא-נתונים

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

[mysqld]
...
innodb_stats_on_metadata=OFF

השבתת המטמון של השאילתות

הוצא משימוש מטמון השאילתות, ולכן הגדרת הערכים query_cache_size ו-query_cache_type ל-0 משביתה אותו. 

[mysqld]
...
query_cache_size=0
query_cache_type=0

הגדלת מאגר ההצטרפות

הפעולה join_buffer משמשת לביצוע פעולות join בזיכרון. הגדלת הערך הזה יכולה לשפר פעולות מסוימות. 

[mysqld]
...
join_buffer_size=512KB

הגדלת הגודל של הטבלה הזמנית ושל הערימה המקסימלית

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

[mysqld
...
tmp_table_size=32MB
max_heap_table_size=32MB

שינוי המטמון הפתוח של הטבלה

ההגדרה table_open_cache קובעת את גודל המטמון שמכיל את מתארי הקבצים של טבלאות פתוחות. ההגדרה table_open_cache_instances מחלקת את המטמון למספר חלקים קטנים יותר. יש פוטנציאל לתחרות על ה-Thread ב-table_open_cache, ולכן חלוקה לחלקים קטנים יותר עוזרת להגדיל את הבו-זמניות (concurrency). 

[mysqld]
...
table_open_cache=2048
table_open_cache_instances=16

שירות Git

‫Looker מיועד לעבודה עם שירות Git כדי לספק ניהול גרסאות של קובצי LookML. יש תמיכה בשירותי אירוח Git עיקריים, כולל GitHub,‏ GitLab ו-Bitbucket. ספקי שירותי Git מציעים תוספות בעלות ערך, כמו ממשק משתמש גרפי לצפייה בשינויים בקוד ותמיכה בתהליכי עבודה כמו בקשות משיכה ואישורי שינויים. אם נדרש, אפשר להריץ את Git בשרת Linux רגיל.

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

בקטעים הבאים מפורטים ניואנסים של ספקי השירות הנפוצים ביותר.

‫GitHub/GitHub Enterprise

בדף התיעוד הגדרה ובדיקה של חיבור Git נעשה שימוש ב-GitHub כדוגמה.

‫GitLab/gitlab.com

שלבי ההגדרה המפורטים של GitLab מופיעים בפוסט בקהילת Looker בנושא שימוש ב-GitLab לניהול גרסאות ב-Looker. אם המאגר שלכם נמצא בתוך קבוצות משנה, אפשר להוסיף אותן לכתובת ה-URL של המאגר באמצעות הפורמט של HTTPS או SSH: 

https://gitlab.com/accountname/subgroup/reponame


git@gitlab.com:accountname/subgroup/reponame.git

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

Google Cloud מקור

במאמר ב-Community Using Cloud Source Repositories for version control in Looker מוסבר איך להגדיר Git באמצעות Cloud Source Repositories.

Bitbucket Cloud

במאמר שימוש ב-Bitbucket לניהול גרסאות ב-Looker בקהילה מוסבר איך להגדיר את Git באמצעות Bitbucket Cloud. החל מאוגוסט 2021, ב-Bitbucket Cloud אין תמיכה בסודות ב-webhooks של פריסה.

Bitbucket Server

כדי להשתמש בבקשות משיכה ב-Bitbucket Server, יכול להיות שתצטרכו לבצע את השלבים הבאים:

  1. כשפותחים בקשת משיכה, Looker משתמש באופן אוטומטי במספר היציאה שמוגדר כברירת מחדל (7999) בכתובת ה-URL. אם אתם משתמשים במספר יציאה מותאם אישית, תצטרכו להחליף את מספר היציאה בכתובת ה-URL באופן ידני.
  2. כדי לסנכרן את ענף הייצור ב-Looker עם הענף הראשי במאגר, צריך להפעיל את ה-webhook של פריסת הפרויקט.

Phabricator diffusion

בפוסט לקהילה הגדרה של Phabricator ו-Looker לניהול גרסאות מפורטים השלבים להגדרה של Git באמצעות Phabricator.

רשת

חיבורים נכנסים

אפליקציית האינטרנט של Looker

כברירת מחדל, Looker מאזין לבקשות HTTPS ביציאה 9999. ‫Looker משתמש באישור עם חתימה עצמית עם CN של self-signed.looker.com. אפשר גם להגדיר את שרת Looker כך שיבצע את הפעולות הבאות:

  1. קבלת חיבורי HTTP ממאזן עומסים או משרת proxy עם סיום SSL, באמצעות --ssl-provided-externally-by=<s> startup flag. הערך צריך להיות כתובת ה-IP של ה-Proxy או שם מארח שאפשר לפתור באופן מקומי לכתובת ה-IP של ה-Proxy. ‫Looker יקבל חיבורי HTTP רק מכתובת ה-IP הזו.
  2. משתמשים באישור SSL שסופק על ידי הלקוח, עם דגל ההפעלה --ssl-keystore=<s>.

Looker API

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

מאזני עומסים

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

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

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

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

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

חיבורים יוצאים

לשרתי Looker יכולה להיות גישה בלתי מוגבלת לכל המשאבים, כולל האינטרנט הציבורי. זה מפשט הרבה משימות, כמו התקנת Chromium, שדורשת גישה למאגרי החבילות של הפצת Linux.

אלה חיבורים יוצאים ש-Looker עשוי להזדקק להם.

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

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

שירותים חיצוניים

שרתי הטלמטריה והרישיון של Looker זמינים באמצעות HTTPS באינטרנט הציבורי. יכול להיות שיהיה צורך להוסיף לרשימת ההיתרים את התנועה מצומת Looker אל ping.looker.com:443 ואל license.looker.com:443.

חיבורים למחסני נתונים

יכול להיות שיהיה צורך בחיבור לאינטרנט הציבורי כדי לגשת למסדי נתונים שמתארחים בענן. לדוגמה, אם אתם משתמשים ב-BigQuery, יכול להיות שתצטרכו להוסיף את accounts.google.com:443 ו-www.googleapis.com:443 לרשימת ההיתרים. אם מסד הנתונים נמצא מחוץ לתשתית שלכם, צריך להתייעץ עם מארח מסד הנתונים כדי לקבל פרטים על הרשת.

שירותי SMTP

כברירת מחדל, Looker שולח אימיילים יוצאים באמצעות SendGrid. יכול להיות שתצטרכו להוסיף את smtp.sendgrid.net:587 לרשימת ההיתרים. אפשר גם לשנות את הגדרות ה-SMTP בהגדרות כדי להשתמש בטיפול אחר באימייל.

מרכזי פעולות, שרתי פעולות ו-webhooks

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

  • במקרה של וווב-הוקים, המשתמשים מציינים את היעדים האלה בזמן הריצה, והם עשויים לסתור את המטרה של חומת אש לחיבורים יוצאים.
  • במרכז הפעולות, הבקשות האלה נשלחות אל actions.looker.com. פרטים נוספים זמינים במסמכי התיעוד בנושא הגדרת Looker Action Hub.
  • בשרתי פעולות אחרים, הבקשות האלה נשלחות לדומיינים שצוינו בהגדרות של שרת הפעולות על ידי אדמינים בחלונית Admin ב-Looker.

שרת Proxy

אם אי אפשר להגיע לאינטרנט הציבורי ישירות, אפשר להגדיר את Looker כך שישתמש בשרת proxy לבקשות HTTP(S). כדי לעשות את זה, מוסיפים שורה כמו זו שבהמשך לקובץ lookerstart.cfg: 

JAVAARGS="-Dhttp.proxyHost=myproxy.example.com
  -Dhttp.proxyPort=8080
  -Dhttp.nonProxyHosts=127.0.0.1|localhost
  -Dhttps.proxyHost=myproxy.example.com
  -Dhttps.proxyPort=8080"

שימו לב שהתקשורת בין הצמתים מתבצעת באמצעות HTTPS, ולכן אם אתם משתמשים בשרת proxy והמופע שלכם הוא מקובץ, בדרך כלל כדאי להוסיף את כתובות ה-IP או שמות המארחים של כל הצמתים בארגומנט Dhttp.nonProxyHosts.

Internode communications

מזהה מארח פנימי

בתוך אשכול, כל צומת חייב להיות מסוגל לתקשר עם הצמתים האחרים. כדי לאפשר זאת, מציינים את שם המארח או את כתובת ה-IP של כל צומת בהגדרת ההפעלה. כשהצומת יופעל, הערך הזה ייכתב במאגר MySQL. חברים אחרים באשכול יכולים להשתמש בערכים האלה כדי לתקשר עם הצומת הזה. כדי לציין את שם המארח או כתובת ה-IP בהגדרת ההפעלה, מוסיפים את -H node1.looker.example.com למשתנה הסביבה LOOKERARGS ב-lookerstart.cfg.

מכיוון ששם המארח צריך להיות ייחודי לכל צומת, הקובץ lookerstart.cfg צריך להיות ייחודי בכל מופע. במקום להגדיר את שם המארח או כתובת ה-IP בהגדרות הקוד, אפשר להשתמש בפקודה hostname -I או hostname --fqdn כדי למצוא אותם בזמן הריצה. כדי להטמיע את זה, מוסיפים את -H $(hostname -I) או -H $(hostname --fqdn) למשתנה הסביבה LOOKERARGS ב-lookerstart.cfg.

יציאות פנימיות

בנוסף ליציאות 9999 ו-19999, שמשמשות לשרתי האינטרנט ולשרתי ה-API בהתאמה, הצמתים של האשכול יתקשרו ביניהם באמצעות שירות של ברוקר הודעות, שמשתמש ביציאות 1551 ו-61616. היציאות 9999 ו-19999 צריכות להיות פתוחות לתנועת נתונים של משתמשי קצה, אבל היציאות 1551 ו-61616 צריכות להיות פתוחות בין צמתי האשכול.