הסבר על הביצועים

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

ביצועים של עומסי עבודה אופייניים

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

רמת האחסון קריאות   כתיבה   סריקות
שכבת In-memory (תצוגה מקדימה) עד 120,000 שורות בשנייה1 או עד 10,000 שורות לשנייה2 לא רלוונטי
SSD עד 17,000 שורות בשנייה או עד 14,000 שורות לשנייה או עד 220 MBps
HDD עד 500 שורות בשנייה או עד 10,000 שורות בשנייה או עד 180MB לשנייה
אחסון עם גישה לא תכופה עד 100 שורות בשנייה או עד 10,000 שורות בשנייה או עד 36 MBps

ההערכות האלה מבוססות על ההנחה שכל שורה מכילה 1KB.

‫1 צומת של Enterprise Plus כולל 40,000 שורות לשנייה, ואפשר להגדיל אותו אנכית ל-120,000 שורות לשנייה לכל צומת, במרווחים של 40,000. למידע נוסף, קראו את המאמר In-memory tier.

‫2 קצב כתיבה גבוה של שורות לשנייה בנתונים בשכבת הזיכרון יכול להשפיע על קצב העברת הנתונים בכתיבה.

באופן כללי, הביצועים של אשכול משתנים באופן לינארי כשמוסיפים צמתים לאשכול. לדוגמה, אם יוצרים אשכול SSD עם 10 צמתים, האשכול יכול לתמוך בעד 140,000 שורות לשנייה לעומס עבודה אופייני לקריאה בלבד או לכתיבה בלבד, בלי להפעיל את שכבת הזיכרון. כשהשכבה בזיכרון מופעלת, האשכול יכול לתמוך בקצב קריאה של עד 1.2 מיליון שורות בשנייה.

תכנון הקיבולת של Bigtable

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

רמת הזיכרון

כשהשכבה בזיכרון מופעלת, כל צומת כולל 40,000 שורות לשנייה. הוספת צמתים באופן אופקי מגדילה את הקיבולת הכוללת של האשכול. בנוסף, כל צומת יכול לגדול אנכית עד למקסימום של 120,000 שורות לשנייה לכל צומת, כדי לתמוך בקצב הקריאה בזיכרון. כשהמגבלה של ההתאמה לעומס (scaling) האנכית מגיעה לסף, ההתאמה האוטומטית לעומס של Bigtable מוסיפה עוד צמתים כדי לבצע התאמה לעומס אופקית. אשכול עם התאמה ידנית לעומס תומך בהתאמה אנכית לעומס בזיכרון עד שמגיעים לקיבולת התפוקה. החיוב על התאמה אנכית לעומס מעבר ל-40,000 שורות לשנייה מתבצע באמצעות הכפלת העלות השעתית של הצומת. למידע נוסף על תמחור

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

ניצול יחידת העיבוד המרכזית (CPU)

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

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

יעד האופטימיזציה ניצול מקסימלי של המעבד (CPU)
תפוקה 90%
זמן אחזור 60%

מידע נוסף על מעקב

ניצול נפח האחסון

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

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

כדי לקבוע את נפח האחסון שנוצל בכל צומת, מחלקים את נפח האחסון שנוצל (בבייטים) באשכול במספר הצמתים באשכול. לדוגמה, נניח שיש אשכול עם שלושה צומתי HDD ו-9TB של נתונים. כל צומת מאחסן כ-3TB, שהם 18.75% מהמגבלה של 16TB לאחסון HDD לכל צומת.

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

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

יעד האופטימיזציה ניצול מקסימלי של נפח האחסון
תפוקה 70%
זמן אחזור 60%

מידע נוסף זמין במאמר אחסון לכל צומת.

הרצת עומסי העבודה ב-Bigtable

כשאתם מתכננים את הקיבולת, תמיד כדאי להריץ את עומסי העבודה מול אשכול Bigtable כדי לקבוע את הקצאת המשאבים הטובה ביותר לאפליקציות שלכם.

‫PerfKit Benchmarker של Google משתמש ב-YCSB כדי לבצע השוואת ביצועים של שירותי ענן. אתם יכולים לפעול לפי המדריך של PerfKitBenchmarker ל-Bigtable כדי ליצור בדיקות לעומסי העבודה שלכם. כשעושים את זה, צריך לשנות את הפרמטרים בקובצי ה-YAML של הגדרות ההשוואה כדי לוודא שההשוואה שנוצרת משקפת את מאפייני הייצור הבאים:

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

גורמים לביצועים איטיים יותר

הגורמים הבאים יכולים לגרום ל-Bigtable לפעול לאט יותר מההערכה:

  • אתם קוראים מספר גדול של מפתחות שורות או טווחי שורות לא רציפים בבקשת קריאה אחת. ‫Bigtable סורק את הטבלה וקורא את השורות המבוקשות ברצף. היעדר המקביליות משפיע על זמן האחזור הכולל, ופעולות קריאה שמגיעות לצומת חם יכולות להגדיל את זמן האחזור בזנב. פרטים נוספים זמינים במאמר קריאות וביצועים.
  • הסכימה של הטבלה לא מוגדרת נכון. כדי לקבל ביצועים טובים מ-Bigtable, חשוב לתכנן סכימה שמאפשרת להפיץ את פעולות הקריאה והכתיבה באופן שווה בכל טבלה. בנוסף, נקודות חמות בטבלה אחת יכולות להשפיע על הביצועים של טבלאות אחרות באותו מכונה. מידע נוסף זמין במאמר שיטות מומלצות לעיצוב סכימה.
  • השורות בטבלה ב-Bigtable מכילות כמויות גדולות של נתונים. ההערכות של הביצועים מבוססות על ההנחה שכל שורה מכילה 1KB של נתונים. אפשר לקרוא ולכתוב כמויות גדולות יותר של נתונים בכל שורה, אבל הגדלת כמות הנתונים בכל שורה גם תפחית את מספר השורות לשנייה.
  • השורות בטבלת Bigtable מכילות מספר גדול מאוד של תאים. ל-Bigtable לוקח זמן לעבד כל תא בשורה. בנוסף, כל תא מוסיף קצת תקורה לכמות הנתונים שמאוחסנים בטבלה ונשלחים ברשת. לדוגמה, אם אתם מאחסנים נתונים בנפח של 1KB‏ (1,024 בייטים), הרבה יותר יעיל לאחסן את הנתונים האלה בתא אחד, במקום לפזר אותם על פני 1,024 תאים שכל אחד מהם מכיל בייט אחד. אם תפצלו את הנתונים ליותר תאים מהנדרש, יכול להיות שלא תקבלו את הביצועים הטובים ביותר. אם השורות מכילות מספר גדול של תאים כי העמודות מכילות כמה גרסאות של נתונים עם חותמות זמן, כדאי לשמור רק את הערך האחרון. אפשרות נוספת לטבלה קיימת היא לשלוח בקשת מחיקה לכל הגרסאות הקודמות בכל כתיבה מחדש.

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

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

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

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

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

  • יש בעיות בחיבור לרשת. בעיות ברשת יכולות להפחית את קצב העברת הנתונים ולגרום לפעולות קריאה וכתיבה להימשך יותר זמן מהרגיל. יכול להיות שתיתקלו בבעיות אם הלקוחות לא פועלים באותו אזור כמו אשכול Bigtable, או אם הלקוחות פועלים מחוץ ל- Google Cloud.

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

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

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

הפעלות במצב התחלתי (cold start) ומספר נמוך של שאילתות לשנייה (QPS)

הפעלות במצב התחלתי (cold start) ומספר נמוך של שאילתות לשנייה (QPS) יכולים להגדיל את זמן האחזור. ‫Bigtable פועל בצורה הטובה ביותר עם טבלאות גדולות שניגשים אליהן לעיתים קרובות. לכן, אם תתחילו לשלוח בקשות אחרי תקופה שבה לא השתמשתם ב-Bigtable (הפעלה במצב התחלתי), יכול להיות שתבחינו בזמן אחזור ארוך בזמן ש-Bigtable יוצר מחדש את החיבורים. זמן האחזור גם גבוה יותר כשמספר השאילתות לשנייה נמוך.

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

בתקופות של QPS נמוך, מספר השגיאות שמוחזרות על ידי Bigtable רלוונטי יותר מאחוז הפעולות שמחזירות שגיאה.

הפעלה במצב התחלתי (cold start) בזמן האתחול של הלקוח. אם אתם משתמשים בגרסה של לקוח Cloud Bigtable ל-Java שקודמת לגרסה 2.17.1, אתם יכולים להפעיל את רענון הערוץ. בגרסאות מאוחרות יותר, רענון הערוץ מופעל כברירת מחדל. רענון הערוץ מבצע שתי פעולות:

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

עם זאת, זה לא שומר על הערוץ פעיל כשיש תקופות של חוסר פעילות.

איך Bigtable מבצע אופטימיזציה של הנתונים לאורך זמן

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

  1. ב-Bigtable מאוחסנת כמות נתונים דומה בכל צומת של Bigtable.
  2. ‫Bigtable מחלק את פעולות הקריאה והכתיבה באופן שווה בין כל הצמתים של Bigtable.

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

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

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

חלוקת כמות הנתונים בין הצמתים

כשכותבים נתונים בטבלה ב-Bigtable, המערכת מחלקת את נתוני הטבלה לטאבלטים. כל טאבלט מכיל טווח רציף של שורות בטבלה.

אם כתבתם פחות מכמה GB של נתונים בטבלה, Bigtable מאחסן את כל הטאבלטים בצומת אחד בתוך האשכול:

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

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

טבלאות נוספות מופצות בין כמה צמתים.

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

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

לדוגמה, נניח ש-25% מהקריאות מגיעות למספר קטן של טבלאות באשכול, והקריאות מפוזרות באופן שווה בין כל שאר הטבלאות:

מתוך 48 טבלאות, 25% מהקריאות מגיעות ל-3 טבלאות.

‫Bigtable יפזר מחדש את הטאבלטים הקיימים כדי שהקריאות יתפרסו באופן שווה ככל האפשר על פני כל האשכול:

שלושת הטאבלטים החמים מבודדים בצומת משלהם.

בדיקת הביצועים באמצעות Bigtable

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

  • בודקים עם מספיק נתונים.
    • אם הטבלאות במכונה בסביבת הייצור מכילות סך של 100GB נתונים או פחות לכל צומת, בצעו בדיקה עם טבלה שמכילה את אותה כמות נתונים.
    • אם הטבלאות מכילות יותר מ-100GB של נתונים לכל צומת, בודקים באמצעות טבלה שמכילה לפחות 100GB של נתונים לכל צומת. לדוגמה, אם למכונה בסביבת הייצור יש אשכול אחד עם ארבעה צמתים, והטבלאות במכונה מכילות בסך הכול 1TB של נתונים, צריך להריץ את הבדיקה באמצעות טבלה של 400GB לפחות.
  • בדיקה עם טבלה אחת.
  • לא לחרוג מההמלצה לניצול האחסון בכל צומת. לפרטים, ראו ניצול האחסון לכל צומת.
  • לפני הבדיקה, מריצים בדיקה מקדימה כבדה במשך כמה דקות. בשלב הזה, Bigtable יכול לאזן את הנתונים בין הצמתים על סמך דפוסי הגישה שהוא מזהה.
  • מריצים את הבדיקה במשך 10 דקות לפחות. השלב הזה מאפשר ל-Bigtable לבצע אופטימיזציה נוספת של הנתונים, ועוזר לוודא שתבדקו קריאות מהדיסק וגם קריאות שנשמרו במטמון מהזיכרון.
  • לבדיקת שכבת הזיכרון (גרסת טרום-השקה (Preview)), ודאו שמשך הבדיקה מספיק כדי לאכלס את שכבת הזיכרון בקריאות.

פתרון בעיות בביצועים

אם אתם חושבים ש-Bigtable יוצר צוואר בקבוק בביצועים של האפליקציה, חשוב לבדוק את כל הדברים הבאים:

  • בודקים את הסריקות של Key Visualizer בטבלה. הכלי Key Visualizer ל-Bigtable יוצר נתוני סריקה חדשים כל 15 דקות, שמציגים את דפוסי השימוש בכל טבלה באשכול. בעזרת Key Visualizer תוכלו לבדוק אם דפוסי השימוש שלכם גורמים לתוצאות לא רצויות, כמו נקודות חמות בשורות ספציפיות או ניצול יתר של המעבד (CPU). מידע נוסף זמין במאמר שימוש ב-Key Visualizer.
  • מסמנים כהערה את הקוד שמבצע קריאות וכתיבות ב-Bigtable. אם הבעיה בביצועים נעלמת, כנראה אתם משתמשים ב-Bigtable באופן שגורם לביצועים לא אופטימליים. אם הבעיה בביצועים נמשכת, כנראה שהיא לא קשורה ל-Bigtable.

  • חשוב ליצור כמה שפחות לקוחות. יצירת לקוח ל-Bigtable היא פעולה יקרה יחסית. לכן, כדאי ליצור כמה שפחות לקוחות:

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

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

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

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

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

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

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

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

    אם אתם משתמשים בספריית הלקוח של Bigtable ל-Java, אתם יכולים לראות את המדד read_rows_first_row_latency ב-Google Cloud Metrics Explorer במסוף אחרי שהפעלתם את המדדים בצד הלקוח.

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

  • מפעילים את המדדים בצד הלקוח. אתם יכולים להגדיר מדדים בצד הלקוח כדי לבצע אופטימיזציה ולפתור בעיות בביצועים. לדוגמה, Bigtable פועל בצורה הכי טובה עם מספר גבוה של שאילתות לשנייה (QPS) שמתפלגות באופן שווה, ולכן עלייה בזמן האחזור של P100 (מקסימום) באחוז קטן מהבקשות לא בהכרח מעידה על בעיה בביצועים גדולה יותר ב-Bigtable. מדדים בצד הלקוח יכולים לתת לכם תובנות לגבי החלק במחזור החיים של הבקשה שעלול לגרום לעיכוב.

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

קישוריות ישירה

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

  • פועל במכונה וירטואלית של Compute Engine או של Google Kubernetes Engine‏ (GKE) ברשת של ענן וירטואלי פרטי (VPC)
  • שימוש בספריית לקוח נתמכת של Bigtable
  • שימוש בפרופיל אפליקציה רגיל (לא Data Boost)
  • ברשת שמוגדרת עם מסלולים וכללי חומת אש שמאפשרים לתעבורת נתונים יוצאת להגיע אל 34.126.0.0/18 ואל 2001:4860:8040::/42

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

  • ‫Java מגרסה 2.76.0 ואילך
  • מתאם HBase מגרסה 2.17.0 ואילך
  • ‫Go בגרסה 1.50.1 ואילך

יש תמיכה גם ב-IPv4 וגם ב-IPv6. מידע נוסף זמין במאמר קישוריות ישירה לממשקי API ולשירותים במסמכי התיעוד של VPC.

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