ניתוח דפוסי גישה

אתם יכולים לנתח באופן חזותי איך האפליקציות שלכם קוראות וכותבות נתונים ב-Bigtable באמצעות הדף Access patterns ב- Google Cloud console, או לקרוא באופן פרוגרמטי ל-Cloud Monitoring API כדי לשלוח שאילתות לגבי המדדים הבסיסיים של דפוסי הגישה.

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

סקירה כללית

ב-Cloud Monitoring, המערכת של Bigtable מסווגת באופן אוטומטי את בקשות הנתונים הנכנסות לפי סוגי שאילתות. דפוס הגישה לעומס העבודה הוא שילוב של סוגי שאילתות שונים. לדוגמה, דפוס הגישה של עומס העבודה יכול לכלול סוגי שאילתות של קריאת נקודה, סריקה קצרה וכתיבת נקודה. ב-Bigtable מוגדרים 10 סוגי שאילתות שונים.

בדף System insights מוצג ניצול המשאבים הכולל, וב-Key Visualizer מוצג איך Bigtable מחלק את התנועה בין טווחי מפתחות השורות. לעומת זאת, בדף Access patterns מוצג פירוט של עומס העבודה לפי שאילתות ברמות של האשכול, הטבלה ופרופיל האפליקציה. בדף Access patterns אתם יכולים לבצע את המשימות הבאות:

• הבנת עומס העבודה: הצגת הפרופורציה והקצב של סוגי השאילתות לקריאה, לכתיבה ולקריאה-כתיבה בכל אשכול, וקיבוץ המדדים לפי טבלה או פרופיל אפליקציה.
• זיהוי מבני שאילתות לא יעילים ופתרון בעיות של זמן אחזור:
  • זיהוי קריאות דלילות שבהן Bigtable סורק הרבה יותר שורות או תאים מאשר אלה שהוא מחזיר, בגלל מסננים סלקטיביים או תאים שלא נאספו וממתינים לאיסוף אשפה
  • מעקב אחרי סריקות הפוכות, שהן פחות יעילות מסריקות קדימה
  • השוואה בין אחוזוני זמן האחזור בצד השרת לבין השורות שנסרקו, השורות שהוחזרו והתאים שנצפו, כדי לזהות אילו דפוסי גישה תורמים לעליות חדות בזמן האחזור.
• זיהוי עומסי עבודה להטמעת תכונות:
  • זיהוי טבלאות או פרופילי אפליקציות עם נפחים גדולים של קריאות נקודתיות שיכולות להפיק תועלת משכבת הזיכרון במהדורת Enterprise Plus
  • מזהים עומסי עבודה גדולים של סריקה או קריאה באצווה שאפשר לבודד מתנועת הגולשים באמצעות מחשוב בלי שרת (serverless computing) של Data Boost.

מגבלות

‫Bigtable לא מסווג שאילתות GoogleSQL ל-Bigtable כתבניות גישה, ולא כולל את השאילתות האלה במדדים של תבניות הגישה לשורות, לתאים או לבייטים. בתרשימים QPS distribution,‏ QPS ו-Latency, שאילתות SQL ובקשות אחרות שלא סווגו מופיעות בתור QUERY_TYPE_UNKNOWN.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לצפייה בדף Access patterns במסוף Google Cloud , בקשו מהאדמין לתת לכם את התפקידים הבאים ב-IAM ברמת הפרויקט:

• משאבים בנושא Bigtable:
  • צפייה ב-Bigtable (roles/bigtable.viewer)
  • Bigtable Reader (roles/bigtable.reader)
• צפייה בנתוני סדרות הזמן של Monitoring:‏ צפייה ב-Monitoring‏ (roles/monitoring.viewer)

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

התפקידים המוגדרים מראש האלה כוללים את ההרשאות שנדרשות כדי לצפות בדף Access patterns במסוף Google Cloud . כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:

ההרשאות הנדרשות

כדי לצפות בדף Access patterns במסוף Google Cloud , צריך את ההרשאות הבאות:

• הצגת פרטי המכונה: bigtable.instances.get
• הצגת רשימה של אשכולות, פרופילי אפליקציות וטבלאות: bigtable.clusters.list, bigtable.appProfiles.list, bigtable.tables.list
• מדדי מעקב אחרי שאילתות: monitoring.timeSeries.list

יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

דפוסי גישה

כשהאפליקציה משתמשת בספריית לקוח של Bigtable, ספריית הלקוח מתרגמת את הקריאות ל-method לבקשות API של Bigtable Data API:

• קריאות: כל השיטות לקריאה של ספריית הלקוח – כולל קריאות של שורה אחת כמו readRow, קריאות של כמה שורות כמו readRows או bulkReadRows עם כמה מפתחות שורה, וסריקות של טווח שורות או קידומת כמו readRows עם טווח או קידומת – שולחות בקשת ReadRows Data API.
• כתיבה: שיטות הכתיבה של ספריית הלקוח שולחות בקשת MutateRow לכתיבה פשוטה ולעדכונים מצטברים, בקשת MutateRows לכתיבה באצווה, בקשת CheckAndMutateRow לכתיבה מותנית או בקשת ReadModifyWriteRow להוספות והגדלות.

‫Bigtable מסווג כל בקשת API נכנסת ל-Data API בשרת אחרי שהיא מסתיימת, על סמך הגורמים הבאים ולא רק על סמך השם של ה-method בספריית הלקוח:

• פרמטרים של בקשות: אם הבקשה מטרגטת מפתח שורה אחד, כמה מפתחות שורה או טווח שורות, אם הבקשה מגדירה את reversed ואילו מסננים היא מחילה
• נתונים סטטיסטיים של ביצוע: מספר השורות והתאים שנסרקו והוחזרו, ומטען הנתונים (payload) בבייטים

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

סדר קריאת ההערכה

בקשה אחת של ReadRows Data API יכולה להתאים למאפיינים של יותר מקטגוריה אחת, ולכן Bigtable מעריך את בקשות הקריאה בסדר הבא ומקצה את דפוס הגישה התואם הראשון:

1. קריאה נקודתית
2. סריקה קצרה (לסריקות קדימה) או סריקה קצרה הפוכה (כאשר reversed מוגדר לערך true)
3. סריקה הפוכה (לכל בקשת קריאה שנותרה שבה reversed מוגדר לערך true)
4. קריאה דלילה (מוערכת לפני קריאה בכמות גדולה, כך ש-Bigtable מסמן קריאות של כמה מפתחות או סריקות קדימה גדולות יותר עם ביטול מסננים כבדים כדלילות)
5. קריאה בכמות גדולה
6. קריאה אחרת (לכל בקשת ReadRows שנותרה)

ההגדרות של סוגי השאילתות

בטבלה הבאה מתוארת כל קטגוריה של דפוס גישה, התווית התואמת של query_type ב-Monitoring, הפעולות האופייניות של ספריית הלקוח וה-method הבסיסית של Data API (תווית המדד method) שעליהן היא חלה, ואיך Bigtable מסווג בקשות לקטגוריה הזו. מכיוון ששמות ה-methods משתנים בהתאם לשפת התכנות, בטבלה מפורטים שמות מייצגים של methods בספריית הלקוח. לדוגמאות קוד בשפות ספציפיות, ראו דוגמאות לקריאה ודוגמאות לכתיבה. מידע על מסננים פשוטים ומורכבים מופיע בקטע מסננים פשוטים לעומת מסננים מורכבים במסמך הזה.

סוג השאילתה	תווית המדד query_type	פעולת לקוח ו-method של Google Data API	קריטריונים לסיווג
קריאה נקודתית	QUERY_TYPE_POINT_READ	קריאה של שורה אחת, כמו readRow או readRows עם מפתח אחד Google Data API: ReadRows	קריאה קדימה של מפתח שורה יחיד שלא משתמשת בבלי פילטר או משתמשת במסנן פשוט, שבה מספר התאים שנסרקו והוחזרו וגודל התגובה הכולל נשארים בתוך מגבלות קטנות של שורה אחת.
סריקה קצרה	QUERY_TYPE_SHORT_SCAN	סריקה של טווח שורות או קידומת, כמו readRows עם טווח או קידומת בודדים Google Data API: ReadRows	סריקה קדימה של טווח שורות רציף אחד שלא משתמשת בבלי פילטר או משתמשת במסנן פשוט, שבה מספר השורות והתאים שנסרקו והוחזרו וגודל התגובה הכולל נשארים בתוך גבולות קטנים.
סריקה קצרה הפוכה	QUERY_TYPE_REVERSE_SHORT_SCAN	סריקה הפוכה, כמו readRows עם טווח או קידומת יחידים בסדר הפוך Google Data API: ReadRows	סריקה הפוכה של טווח שורות רציף אחד, שלא משתמשת במסנן או משתמשת במסנן פשוט, ונשארת באותן מגבלות של שורות, תאים ובייטים כמו סריקה קצרה.
סריקה הפוכה	QUERY_TYPE_REVERSE_SCAN	סריקה הפוכה, כמו readRows בסדר הפוך Google Data API: ReadRows	כל קריאה הפוכה שלא עומדת בתנאים של סריקה קצרה הפוכה. לדוגמה, סריקה הפוכה שחורגת מהמגבלות של סריקה קצרה על שורות, תאים או בייטים, מציינת מפתחות שורה ספציפיים, סורקת כמה טווחי שורות או משתמשת במסנן מורכב.
קריאה דלילה (sparse)	QUERY_TYPE_SPARSE_READ	קריאה מסוננת או סריקה של תאים שלא נאספו, באמצעות readRow או readRows Google Data API: ReadRows	כל בקשת קריאה קדימה (שנבדקת אחרי קריאת נקודה, סריקה קצרה וסריקה הפוכה) שבה Bigtable סורק הרבה יותר שורות או תאים מאשר אלה שהוא מחזיר, בגלל ביטול סינון או תאים שלא נאספו וממתינים לאיסוף אשפה.
קריאה בכמות גדולה	QUERY_TYPE_BULK_READ	קריאה של כמה שורות, כמו readRows או bulkReadRows עם כמה מפתחות, או קריאה של שורה אחת גדולה באמצעות readRow Google Data API: ReadRows	קריאה קדימה שמציינת מפתח שורה אחד או יותר בלי פילטר או עם מסנן פשוט, חורגת ממגבלות הקריאה הנקודתית (לדוגמה, מבקשת כמה מפתחות שורה או קוראת שורה אחת גדולה) ולא עומדת בדרישות של קריאה חסכונית.
קריאה אחרת	QUERY_TYPE_OTHER_READ	סריקה של טווח גדול, סריקה של כמה טווחים או קריאה מסוננת באמצעות readRow או readRows Google Data API: ReadRows	כל בקשת ReadRows שלא תואמת לקטגוריות הקריאה הקודמות, למשל סריקות של טווחים גדולים קדימה, סריקות של טווחים מרובים, בקשות שמשלבות מפתחות שורות וטווחי שורות, או קריאות עם מסננים מורכבים שלא נחשבים כחסכוניים (sparse).
כתיבת נקודות	QUERY_TYPE_POINT_WRITE	כתיבה פשוטה, עדכון מצטבר או כתיבה באצווה קטנה, כמו mutateRow או bulkMutateRows ‫Google Data API: MutateRow, MutateRows	בקשת MutateRow בשורה אחת או בקשת Batch קטנה של MutateRows שמשנה מספר קטן של שורות ותאים עם מטען ייעודי (payload) קטן של בייטים.
כתיבה אחרת	QUERY_TYPE_OTHER_WRITE	כתיבה באצווה גדולה או כתיבה פשוטה גדולה, כמו bulkMutateRows או mutateRow ‫Google Data API: MutateRow, MutateRows	כל בקשת MutateRow או MutateRows שחורגת ממגבלות הכתיבה של נקודות, כמו כתיבה של אצוות גדולות יותר או כתיבה עם מספר גדול של מוטציות או מטען ייעודי (payload) של בייטים.
קריאה וכתיבה	QUERY_TYPE_READ_WRITE	כתיבה מותנית או פעולת append, כמו checkAndMutateRow או readModifyWriteRow Google Data API: CheckAndMutateRow, ReadModifyWriteRow	כל בקשה לכתיבה מותנית (CheckAndMutateRow) או להוספה או הוספה אטומית (ReadModifyWriteRow), ללא קשר לגודל המטען הייעודי (payload).

במדדים של מספר הבקשות וזמן האחזור, Bigtable מתייג בקשות לא מסווגות, כמו שאילתות GoogleSQL ל-Bigtable, בתור QUERY_TYPE_UNKNOWN.

מסננים פשוטים לעומת מסננים מורכבים

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

‫Bigtable מסווג מסנן כמסנן פשוט אם הוא משתמש רק בסוגי המסננים הבאים, לבד או בשילוב במסנן chain מוגבל. מידע נוסף זמין במאמר בנושא רשת.

• בלי פילטר (FILTER_NOT_SET)
• pass_all_filter או block_all_filter
• ‫column_range_filter, column_qualifier_regex_filter או family_name_regex_filter
• ‫cells_per_column_limit_filter, cells_per_row_limit_filter או cells_per_row_offset_filter
• timestamp_range_filter

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

• value_regex_filter
• value_range_filter
• row_key_regex_filter
• row_sample_filter
• interleave
• condition
• sink
• strip_value_transformer
• apply_label_transformer

‫Bigtable מסווג בקשות כאלה כסריקה הפוכה אם הערך של reversed הוא true, אחרת כקריאה חסכונית (אם הוא סורק הרבה יותר שורות או תאים ממה שהוא מחזיר) או כקריאה אחרת.

הצגת דפוסי הגישה

אפשר לפתוח את הדף Access patterns במסוף Google Cloud ברמת המכונה או ברמת האשכול.

הצגת דפוסי הגישה של מכונה

1. במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.

   פתיחת רשימת המכונות

2. לוחצים על המכונה שרוצים לראות את המדדים שלה.

3. בחלונית הניווט, בקטע Observability, לוחצים על Access patterns.

4. ברשימה Cluster, בוחרים את האשכול שאת דפוסי הגישה שלו רוצים לבדוק. כברירת מחדל, במסוף Google Cloud נבחר האשכול הראשון במכונה.

5. ברשימה קיבוץ לפי, בוחרים איך לפצל את התרשימים:

   • None: אפשרות ברירת המחדל שמפרטת את כל התרשימים לפי דפוס גישה, כמו QUERY_TYPE_POINT_READ
   • פרופיל אפליקציה: פירוט של כל התרשימים לפי מזהה פרופיל האפליקציה ולפי דפוס הגישה
   • טבלה: פירוט של כל התרשימים לפי מזהה הטבלה ודפוס הגישה

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

הצגת דפוסי גישה לאשכול

1. במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.

   פתיחת רשימת המכונות

2. לוחצים על המכונה שרוצים לראות את המדדים שלה.

   דף הסקירה הכללית של המכונה נפתח.

3. בטבלת האשכולות, לוחצים על מזהה האשכול.

4. בחלונית הניווט, לוחצים על Access patterns. בדף מוצגים מדדים של האשכול שנבחר.

5. ברשימה קיבוץ לפי, בוחרים איך לפצל את התרשימים:

   • None: אפשרות ברירת המחדל שמפרטת את כל התרשימים לפי דפוס גישה, כמו QUERY_TYPE_POINT_READ
   • פרופיל אפליקציה: פירוט של כל התרשימים לפי מזהה פרופיל האפליקציה ולפי דפוס הגישה
   • טבלה: פירוט של כל התרשימים לפי מזהה הטבלה ודפוס הגישה

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

תרשימים ומדדים בדף דפוסי הגישה

בדף Access patterns מוצגים תרשימים של המדדים הבאים:

מדד	זמין עבור	תיאור
התפלגות QPS	אשכולות טבלאות פרופילים של אפליקציות	היחס והשיעור הממוצע של בקשות לשנייה (QPS) שנצברו בכל טווח התאריכים שנבחר לאשכול, בחלוקה לפי query_type והאפשרות שנבחרה ב-Group by.
זמן אחזור	אשכולות טבלאות פרופילים של אפליקציות	זמן האחזור של הבקשות בצד השרת לאורך זמן, בחלוקה לפי query_type והאפשרות שנבחרה ב-Group by. בתפריט האחוזונים שבתרשים, אפשר לעבור בין האחוזון ה-99 (ברירת המחדל), האחוזון ה-95 והאחוזון ה-50.
QPS	אשכולות טבלאות פרופילים של אפליקציות	קצב הבקשות לשנייה לאורך זמן, בחלוקה לפי query_type והאפשרות שנבחרה ב-Group by.
שורות שהוחזרו	אשכולות טבלאות פרופילים של אפליקציות	מספר השורות ש-Bigtable מחזיר ללקוח בשנייה לבקשות קריאה וקריאה-כתיבה אחרי החלת מסננים.
שורות שנסרקו	אשכולות טבלאות פרופילים של אפליקציות	מספר השורות ש-Bigtable קורא בשנייה בזמן עיבוד בקשות קריאה וכתיבה, לפני החלת מסננים. השוואה בין שורות שנסרקו לבין שורות שהוחזרו עוזרת לזהות מסנני קריאה לא יעילים.
שורות ששונו	אשכולות טבלאות פרופילים של אפליקציות	מספר השורות ששונו בשנייה על ידי בקשות כתיבה ובקשות קריאה-כתיבה.
תאים שנצפו	אשכולות טבלאות פרופילים של אפליקציות	מספר התאים ש-Bigtable בודק בשנייה במהלך בקשות קריאה ובקשות קריאה-כתיבה לפני החלת מסננים, כולל תאים שהוא מסנן או שממתינים לאיסוף אשפה.
תאים שנשלחו	אשכולות טבלאות פרופילים של אפליקציות	מספר התאים ש-Bigtable מחזיר ללקוח בשנייה אחרי החלת המסננים. השוואה בין Cells seen לבין Sent cells עוזרת לזהות בקשות קריאה שבודקות הרבה תאים לכל תא שמוחזר.
בייטים שנשלחו	אשכולות טבלאות פרופילים של אפליקציות	מספר הבייטים של נתוני שורות מקודדים שמוחזרים בשנייה.

אפשר גם לשלוח שאילתות לגבי המדדים האלה באופן פרוגרמטי באמצעות Cloud Monitoring API, להציג אותם ב-Metrics Explorer או להוסיף אותם למרכזי בקרה בהתאמה אישית. כל מדד של bigtable.googleapis.com/query_type/* במשאב במעקב bigtable_table כולל את התוויות הבאות:

• תוויות של משאבים: project_id,‏ instance,‏ cluster ו-table
• תוויות מדדים: query_type, app_profile ו-method

למידע נוסף על שאילתות של מדדי Bigtable ב-Monitoring, קראו את המאמרים מעקב באמצעות Monitoring ומדדים.

אופטימיזציה של עומסי עבודה על סמך דפוסי גישה

אתם יכולים להשתמש במדדים שבדף Access patterns כדי לקבל את ההחלטות הבאות:

• הפעלת שכבת הזיכרון הפנימי לקריאות נקודתיות עם זמן אחזור קצר: אם בתרשימים QPS distribution,‏ QPS ו-Latency מוצג נפח גבוה של בקשות QUERY_TYPE_POINT_READ בטבלאות או בפרופילים של אפליקציות עם יעדים מחמירים של זמן אחזור לקריאה, כדאי להפעיל את שכבת הזיכרון הפנימי שזמינה במהדורת Enterprise Plus. כדי לזהות אילו טבלאות ועומסי עבודה יפיקו את התועלת הרבה ביותר, מקבצים את התרשימים לפי Table או App profile.
• בידוד של סריקות גדולות וקריאות באצווה באמצעות Data Boost: אם אתם מבחינים בנפחים גבוהים או בעליות חדות תקופתיות בבקשות QUERY_TYPE_BULK_READ או QUERY_TYPE_OTHER_READ שחולקות אשכול עם תנועת הצגת מודעות שרגישה לזמן אחזור, קבצו לפי פרופיל אפליקציה כדי לזהות את מקור הסריקות. כדי שסריקות גדולות לא יתחרו עם צומתי שירות על משאבי מעבד (CPU), אתם יכולים לנתב קריאות של אצווה, דיווח או ניתוח נתונים דרך פרופיל אפליקציה ייעודי שמוגדר להשתמש במחשוב בלי שרת (serverless computing) של Data Boost.
• הפחתת התקורה של המסננים וכוונון איסוף האשפה: אם אתם רואים שיעור גבוה של בקשות QUERY_TYPE_SPARSE_READ, אם הערך של Scanned rows גבוה בהרבה מהערך של Returned rows, או אם הערך של Cells seen גבוה בהרבה מהערך של Sent cells, סימן שבקשות הקריאה סורקות נתונים ש-Bigtable לא מחזיר ללקוח. כדי לשפר את יעילות הקריאה:
  • צמצמו את הטווחים או את הקידומות של מפתחות השורות בבקשת הקריאה, במקום להסתמך על מסננים של ערכים או של ביטויים רגולריים כדי למחוק שורות.
  • כדי שהאפליקציה תצטרך רק את הגרסאות האחרונות של התאים, צריך לכלול מסנן להגבלת תאים, כמו cells_per_column_limit_filter. מידע נוסף מופיע במאמר מגבלת התאים לכל עמודה.
  • כדאי לבדוק את כללי המדיניות של איסוף האשפה כדי שגרסאות תאים שפג תוקפן או שהן מיושנות לא יצטברו ויאטו את הסריקות. למידע נוסף, ראו סקירה כללית על איסוף אשפה.
• החלפת סריקות הפוכות בסריקות קדימה: אם אתם מבחינים בבקשות QUERY_TYPE_REVERSE_SCAN או QUERY_TYPE_REVERSE_SHORT_SCAN תכופות עם זמן אחזור גבוה, כדאי לשקול לתכנן את מפתחות השורות כך שהאפליקציה תוכל להנפיק סריקות קדימה. מידע נוסף זמין במאמר שיטות מומלצות לעיצוב סכימה.

המאמרים הבאים

• מעקב אחרי ביצועי המכונה באמצעות System insights
• ניתוח דפוסי השימוש במפתחות של שורות באמצעות Key Visualizer
• פתרון בעיות שקשורות לזמן האחזור