Rapid Cache

בדף הזה מתואר Rapid Cache, תכונה שמספקת מטמון קריאה אזורי שמגובה על ידי SSD לקטגוריות של Cloud Storage, ומאפשרת לכם לקבל תפוקה גבוהה יותר וזמן אחזור נמוך יותר של הנתונים המאוחסנים. ‫Rapid Cache מספק קיבולת אחסון ורוחב פס שמתרחבים או מצטמצמים באופן אוטומטי בהתאם לצרכים שלכם.

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

במאמר יצירה וניהול של מטמונים מוסבר איך ליצור ולנהל מטמונים ב-Rapid Cache.

איך זה עובד?

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

Rapid Cache הוא שירות שמנוהל במלואו שתמיד מחזיר נתונים עקביים.

יתרונות

כששומרים את הנתונים במטמון באמצעות Rapid Cache, נהנים מהיתרונות הבאים:

  • גישה מהירה יותר לנתונים: Rapid Cache ממקם את הנתונים באותו אזור שבו נמצאים משאבי המחשוב, והוא מגובה באופן מלא על ידי SSD. כך עומסי העבודה יכולים להשיג קצב העברה של עד 2.5TB/s, וזמן האחזור קצר יותר כך שהקריאות מהירות יותר.

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

  • צמצום עמלות האחזור: עמלות האחזור של באקטים ב-Nearline Storage,‏ Coldline Storage ו-Archive Storage לא חלות על קריאות נתונים מהמטמון.

  • עלויות נמוכות יותר על פעולות קריאה: פעולות קריאה שמוגשות מ-Rapid Cache עולות פחות מפעולות Class B שמוגשות מקטגוריית אחסון ב-Standard Storage.

  • שינוי אוטומטי של גודל המטמון: המטמון הדינמי של Rapid Cache ב-SSD משתנה אוטומטית בהתאם לשימוש, בלי שתצטרכו לציין את גודל המטמון.

  • שימוש יעיל במטמון: אפשר להפעיל את Rapid Cache בדליים קיימים בלי לבצע שינויים באפליקציות או בממשקי ה-API הקיימים. הנתונים שמאוחסנים ב-Rapid Cache הם עקביים מאוד.

פרטים על התמחור מופיעים במאמר תמחור של Rapid Cache. מידע על מכסות זמין במאמר מכסות של Rapid Cache.

מתי כדאי להשתמש ב-Rapid Cache?

כדי להאיץ את קריאת הנתונים עבור עומסי עבודה של ניתוח, אימון וטעינה של מודלים של AI/ML, אפשר להשתמש ב-Rapid Cache לנתונים שמשתנים לעיתים רחוקות ונקראים לעיתים קרובות.

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

התאמה אוטומטית של גודל המטמון ומגבלת רוחב הפס

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

ההגבלה על רוחב הפס של המטמון מתחילה ב-‎100 Gbps וגדלה בקצב של ‎20 Gbps לכל ‎1 TiB של נתונים מאוחסנים. כדי להגדיל את רוחב הפס ההתחלתי או את המגבלה הכוללת של רוחב הפס, אפשר להגדיל את כמות הנתונים שמאוחסנים במטמון, ליצור עוד מטמונים באזור או לפנות למנהל החשבון הטכני או לנציג Google.

מידע נוסף על מגבלות הגודל ורוחב הפס של Rapid Cache

שמירת נתונים במטמון באזורים

כשיוצרים מטמון לקטגוריה, המטמון צריך להיווצר באזור בתוך המיקום של הקטגוריה. לדוגמה, אם הקטגוריה שלכם נמצאת באזור us-east1, אתם יכולים ליצור מטמון באזור us-east1-b אבל לא באזור us-central1-c. אם הקטגוריה נמצאת בשני אזורים ASIA, אפשר ליצור מטמון בכל האזורים שמרכיבים את האזורים asia-east1 ו-asia-southeast1.

לכל קטגוריה, אפשר ליצור עד מטמון אחד לכל אזור. לדוגמה, אם קטגוריה נמצאת באזור us-east1, אפשר ליצור מטמון ב-us-east1-b ומטמון נוסף ב-us-east1-c. אם קטגוריה נמצאת במספר אזורים שכוללים את us-central1 ואת us-east1, אפשר ליצור מטמון ב-us-central1-a ומטמון נוסף ב-us-east1-b.

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

אפשר להשתמש ב-Rapid Cache באזורים הבאים. אפשר להשתמש באזורים האלה בהתאם לסוג המיקום של הקטגוריה.

אסיה

בטבלה הבאה מוצגים האזורים וסוגי המיקומים שזמינים ל-Rapid Cache באזור הגיאוגרפי של אסיה.

שם האזור אזור שני אזורים במספר אזורים שני אזורים מותאמים אישית
asia-east1-a
asia-east1-b
asia-east1-c
asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-south1-a
asia-south1-b
asia-south1-c
asia-southeast1-a
asia-southeast1-b
asia-southeast1-c

אירופה

בטבלה הבאה מוצגים האזורים וסוגי המיקומים שזמינים ל-Rapid Cache באזור הגיאוגרפי של אירופה.

שם האזור אזור שני אזורים במספר אזורים שני אזורים מותאמים אישית
europe-north1-a
europe-north1-b
europe-north1-c
europe-west1-b
europe-west1-c
europe-west1-d
europe-west4-a
europe-west4-b
europe-west4-c
europe-west4-ai1a (אזור AI)
europe-west6-a
europe-west6-b

ארצות הברית

בטבלה הבאה מוצגים האזורים וסוגי המיקומים שזמינים ל-Rapid Cache באזור הגיאוגרפי של ארצות הברית.

שם האזור אזור שני אזורים במספר אזורים שני אזורים מותאמים אישית
us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-central1-ai1a (אזור AI)
us-east1-b
us-east1-c
us-east1-d
us-east4-a
us-east4-b
us-east4-c
us-east5-a
us-east5-b
us-east5-c
us-south1-a
us-south1-b
us-south1-c
us-south1-ai1b (אזור AI)
us-west1-a
us-west1-b
us-west1-c
us-west2-a
us-west3-a
us-west3-b
us-west3-c
us-west4-a
us-west4-b
us-west4-c

הטמעת נתונים

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

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

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

מקטע הוא בלוק נתונים בגודל 2MB. כשמתקבלת בקשה לאובייקט, Rapid Cache מזהה אילו נתחים של 2MB מכסים את טווח הבייטים המבוקש ומנהל את הנתחים האלה בנפרד.

ההתנהגות של הכנסת הנתונים שונה בהתאם לגודל האובייקט שמוכנס למטמון:

  • בבקשות קריאה לאובייקטים שגדולים מ-2MB, רק נתחי המידע שמכילים את טווח הבייטים המבוקש נקלטים. לדוגמה, אם קוראים את ה-1MB הראשון של קובץ בגודל 100MB, רק הנתח הראשון בגודל 2MB ייטען.

  • בבקשות קריאה לאובייקטים קטנים מ-2MB (לדוגמה, תמונה בגודל 500KB), המערכת מטמיעה את האובייקט כולו במטמון.

הגדרת מטמון

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

אורך חיים (TTL)

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

הטמעה בכתיבה

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

פעולות במטמון

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

יצירת מטמון

כשיוצרים מטמון, הוא עובר למצב CREATING (יצירה) בזמן היצירה, ולמצב RUNNING (פועל) כשהוא מתחיל לפעול באופן פעיל. יצירת מטמון יכולה להימשך עד 48 שעות, ולאחר מכן הפעולה מסתיימת בטיימאאוט.

ה-API ליצירת AnywhereCaches הוא אסינכרוני. פעולת יצירה גורמת להחזרת פעולה ממושכת. הפעולה הממושכת מספקת סטטוס של פעולת היצירה ומאפשרת לבטל את הפעולה לפני שהיא מסתיימת.

עדכון מטמון

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

אי אפשר לעדכן מטמון במצב CREATING או DISABLED.

ה-API לעדכון AnywhereCaches הוא אסינכרוני ומחזיר פעולה ממושכת.

קבלת מטמון

כשמקבלים מטמון, Rapid Cache מחזיר את המצב וההגדרה של מופע המטמון. ה-API של AnywhereCaches Get הוא סינכרוני ומחזיר משאב AnywhereCache.

הצגת רשימה של מטמונים

אפשר להחזיר רשימה של מטמונים משויכים לדלי נתון. ‫AnywhereCaches List API הוא סינכרוני ותומך בעימוד.

השבתת מטמון

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

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

במהלך השעה שלפני מחיקת המטמון, אפשר להחזיר את המצב DISABLED על ידי הפעלה מחדש של המטמון. בשלב הזה המטמון יחזור למצב RUNNING.

ה-API להשבתת AnywhereCaches הוא סינכרוני ומחזיר משאב AnywhereCache.

המשך של מטמון

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

ממשק ה-API של AnywhereCaches Resume הוא סינכרוני ומחזיר משאב AnywhereCache.

Rapid Cache recommender

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

שימוש ב-Rapid Cache כדי להאיץ קריאות ב-BigQuery

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

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

הצפנה של נתונים שנשמרו במטמון

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

מגבלות

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

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

  • Rapid Cache הוא לא אחסון עמיד, ויכול להיות שהנתונים יוסרו מהמטמון בתרחישים שונים. תרחיש אחד הוא שהמטמון משנה את הגודל שלו באופן אוטומטי כדי לוודא שיש מספיק משאבים לעומסי העבודה. בתרחיש הזה, יכול להיות שחלק מהנתונים יימחקו בהתאם לאלגוריתם של least-recently-used (LRU) עד ששירות Rapid Cache יסיים להגדיל את גודל המטמון.

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

  • אי אפשר לקרוא המלצות ותובנות שנוצרו על ידי הכלי להמלצות בנושא מטמון מהיר באמצעות BigQuery.

שיקולי ביצועים

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

  • אורך חיים (TTL) ופינוי: גם מדיניות הפינוי של אורך החיים (TTL) ושל Least Recently Used (LRU) פועלת על נתחים. יכול להיות שחלקים בשימוש תדיר בקובץ גדול יישארו במטמון, וחלקים בשימוש לא תדיר יוסרו ממנו.

תמחור

למידע על התמחור של השימוש ב-Rapid Cache, אפשר לעיין בתמחור של Rapid Cache.

אמצעי בקרה על עלויות

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

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

מומלץ ליצור מטמון רק לקטגוריות שמכילות נתונים שרוצים לשמור במטמון.

בחירת אזור

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

הגדרת TTL

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

השבתת המטמון

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

פתרון בעיות של מחסור זמני במשאבים

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

היצירה של מטמון חדש נכשלה

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

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

הגדלת גודל המטמון נכשלה

Rapid Cache יכול להיות שלא יצליח להגדיל את הגודל של המטמון אם כמות הקיבולת הנדרשת של ה-SSD לא זמינה בתחום (zone) של המטמון.

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

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

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

מידע על העמלות האלה מופיע במאמר בנושא תמחור של Rapid Cache.

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

הגדלת מגבלת רוחב הפס של מטמון נכשלה

מחסור במגבלת רוחב פס של מטמון יכול להתרחש באופן זמני במהלך הגדלת גודל המטמון, אם משאבי העברת הנתונים באזור מסוים לא מספיקים כדי להגדיל את מגבלת רוחב הפס של מטמונים קיימים ב-20‎ Gbps לכל ‎TiB. במהלך מחסור ברוחב פס של מטמון, Rapid Cache לא מאפשר להגדיל את מגבלת רוחב הפס של המטמון ל-20Gbps לכל TiB של נתונים, אבל המטמון ממשיך לשרת בקשות קריאה. כדי לבקש רוחב פס גדול יותר של מטמון, אפשר לפנות למנהל החשבונות הטכני או לנציג Google. במקרה של מחסור ברוחב פס זמין של מטמון, יכול להיות שתהיה עלייה בשימוש ברוחב הפס של תעבורת נתונים יוצאת (egress) מהקטגוריה.

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

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