Rapid Cache

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

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

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

איך פועל Rapid Cache?

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

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

המטא-נתונים לא נשמרים במטמון. בקשות למטא-נתונים של אובייקטים תמיד מעובדות על ידי הקטגוריה ולא על ידי המטמון.

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

יתרונות

כששומרים את הנתונים במטמון באמצעות 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.

מתי כדאי להשתמש בזיכרון מטמון מהיר?

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

שם האזור אזור שני אזורים במספר אזורים שני אזורים מותאמים אישית
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

הטמעת נתונים במטמון

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

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

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

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

הטמעת נתונים כמקטעים

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

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

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

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

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

הטמעת נתונים בזמן כתיבה

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

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

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

אורך חיים (TTL)

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

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

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

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

יצירת מטמון

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

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

עדכון מטמון

אפשר להגדיר את ה-TTL או את אופן ההטמעה של נתונים במטמון כשמעדכנים את המטמון. אפשר לעדכן רק מטמון שנמצא במצב RUNNING. אי אפשר לעדכן מטמון במצב CREATING או DISABLED.

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

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

קבלת מטמון

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

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

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

השבתת מטמון

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

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

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

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

המשך של מטמון

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

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

Rapid Cache recommender

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

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

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

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

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

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

מגבלות

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

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

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

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

  • אי אפשר לקרוא המלצות ותובנות שנוצרו על ידי הכלי להמלצות בנושא מטמון מהיר באמצעות 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 שעות, הבקשה ליצירת מטמון תיכשל.

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

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

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

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

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

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

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

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

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

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

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

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