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

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

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

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

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

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

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

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

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

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

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

רמת הזיכרון

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

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

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

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

כדאי להשתמש בהנחיות הבאות כשמגדירים את יעדי ההתאמה האוטומטית לעומס, או כשבוחרים בהקצאה ידנית של צמתים. ההנחיות האלה רלוונטיות בלי קשר למספר האשכולות במכונה. באשכול עם הקצאת צמתים ידנית, צריך לעקוב אחרי ניצול המעבד (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 יש תמיכה בקישוריות ישירה לתנועה באפליקציה שעומדת בקריטריונים מסוימים, תוך עקיפת ממשק ה-frontend של Google ואופטימיזציה של הביצועים. כדי לשפר את התפוקה ואת זמן האחזור, כדאי לשדרג לגרסה העדכנית של ספריית הלקוח כדי לנצל את היתרונות של הקישוריות הישירה. קישוריות ישירה ניתנת לאפליקציות עם המאפיינים הבאים:

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

קישוריות ישירה זמינה רק ללקוחות שפועלים ב-Compute Engine או ב-Google Kubernetes Engine ‏(GKE). בקישוריות ישירה נעשה שימוש באבטחת שכבת התעבורה של אפליקציה (ALTS), שמאמתת כל חיבור באמצעות פרטי כניסה ש-Google מספקת. למכונות מחוץ ל- Google Cloud, כולל סביבות מקומיות שמחוברות באמצעות Cloud Interconnect או Cloud VPN, אין את פרטי הכניסה האלה ש-Google מספקת. כתוצאה מכך, לקוחות שפועלים במכונות כאלה משתמשים בחיבור רגיל במקום בקישוריות ישירה.

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

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

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

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