Rapid Cache

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

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

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

איך פועל Rapid Cache?

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

הנתונים מקטגוריה נקלטים במטמון כשהם נקראים על ידי מכונה וירטואלית שנמצאת באותו אזור כמו המטמון. אם מגדירים את ההתנהגות ingest-on-write, הנתונים נקלטים במטמון גם כשהם נכתבים בקטגוריה.

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

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

יתרונות

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

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

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

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

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

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

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

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

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

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

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

התאמה לעומס (autoscaling) של גודל המטמון ומגבלת רוחב הפס

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

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

מידע נוסף על מגבלות הגודל ורוחב הפס של Rapid Cache זמין במאמר המכסות והמגבלות של Cloud Storage.

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

כשיוצרים מטמון לקטגוריה, צריך ליצור את המטמון באזור בתוך המיקום של הקטגוריה. לדוגמה, אם הקטגוריה נמצאת באזור 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-west3-a
europe-west3-b
europe-west3-c
europe-west4-a
europe-west4-b
europe-west4-c
europe-west4-ai1a (AI zone)
europe-west6-a
europe-west6-b

ארצות הברית

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

שם האזור אזור שני אזורים במספר אזורים צמד מותאם אישית של שני אזורים
us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-central1-ai1a (AI zone)
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 zone)
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. כשהמערכת מעבירה את הנתונים שאוחזרו למשתמש, היא גם מטמיעה אותם במטמון.

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

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

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

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

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

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

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

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

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

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

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

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

לדוגמה, נניח שאתם מפעילים מטמון כדי לבצע הטמעה בזמן כתיבה ברמת הקידומת לאובייקטים בקטגוריה my-bucket, שהשם שלהם כולל את הקידומת red/. לאחר מכן אתם מעלים שלושה אובייקטים אל my-bucket: האובייקטים red/my-dog.png, blue/my-cat.png ו-red/my-goldfish.png. כתוצאה מכך, רק האובייקטים red/my-dog.png ו-red/my-goldfish.png נקלטים במטמון כשהם מועלים אל my-bucket.

כשמגדירים הטמעה בכתיבה ברמת הקידומת באמצעות כלים מסוימים (כמו מסוףGoogle Cloud ), נוצרת באופן אוטומטי תיקייה מנוהלת חדשה אם מציינים קידומת שהיא לא שם של תיקייה מנוהלת קיימת. עם זאת, כשמשתמשים ב-API בפורמט JSON, צריך ליצור באופן ידני את התיקייה המנוהלת ולהחיל את ההגדרות של ingestOnWrite על כל אזור מטמון. במאמר שימוש ב-Rapid Cache מוסבר איך להפעיל או להשבית את ההטמעה בזמן הכתיבה בכל אחד מהכלים.

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

איך מפעילים את התכונה "הטמעה בזמן הכתיבה"

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

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

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

    {
"zone": "us-east1-a",
"ttl": "24h",
"ingestOnWrite": true
}
    • אם הערך הוא true, המערכת תפעיל את האפשרות "הטמעה בזמן כתיבה" לכל האובייקטים שנכתבים בקטגוריה. הפעולה הזו מבטלת את כל ההגדרות ברמת התיקייה המנוהלת שמאפשרות הטמעה בזמן הכתיבה לאובייקטים נבחרים לפי קידומת.
    • אם הערך הוא false, האפשרות "הטמעה בזמן הכתיבה" מושבתת באובייקטים ברמת הקטגוריה. ההגדרה הזו מאפשרת להפעיל את התכונה "הטמעה בזמן הכתיבה" לאובייקטים נבחרים לפי קידומת, דרך ההגדרות של התיקיות המנוהלות.

  • כדי להפעיל את התכונה "הטמעה בזמן כתיבה" ברמת הקידומת, משתמשים בתיקיות מנוהלות שמייצגות נתיבי קידומת שמסתיימים בלוכסן (לדוגמה: my-prefix/). כשהתכונה "הטמעה בזמן כתיבה" מופעלת ברמת הקידומת, המטמון מטמיע אובייקטים באופן סלקטיבי בזמן כתיבה רק אם השם של האובייקט כולל את הקידומת.

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

    המיפוי של rapidCacheConfig.policies בתיקייה מנוהלת נראה כך:

    "rapidCacheConfig": {
  "policies": {
    "us-east1-a": {
      "rapidCacheId": "us-east1-a",
      "ingestOnWrite": "unspecified"
    }
    "us-east1-b": {
      ...,
      ...
    }
  }
}
    • כדי שההטמעה בזמן הכתיבה ברמת הקידומת תפעל, מופעי המטמון שצוינו במיפוי של policies כבר צריכים להיות קיימים. לדוגמה, כדי לציין את rapidCacheId: "us-east1-a" במיפוי של policies, צריך קודם ליצור מטמון לאזור us-east1-a.
    • אפשר לעדכן כמה מופעי מטמון שצוינו במיפוי policies בקריאה אחת ל-API.
    • אם הערך של ingestOnWrite הוא enabled, ההגדרה ingest-on-write מופעלת לכל האובייקטים שנכתבים בקטגוריה עם הקידומת הזו של התיקייה המנוהלת. אפשר להפעיל את האפשרות "הטמעה בזמן כתיבה" ברמת הקידומת רק אם השדה ingestOnWrite של משאב המטמון הוא false.
    • אם הערך הוא unspecified (ברירת המחדל), ההפעלה של הטמעה בזמן כתיבה עוברת בירושה ממשאב ההורה הישיר, שיכול להיות תיקייה מנוהלת ברמה גבוהה יותר או הקטגוריה שמכילה את התיקייה המנוהלת עצמה.
    • כל מטמון שלא צוין במיפוי המדיניות מטופל כאילו ההגדרה ingestOnWrite שלו מוגדרת לערך unspecified.

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

  • הפעלת הטמעה בזמן הכתיבה ברמת הקטגוריה (אבל לא ברמת הקידומת)

    • הגדרה: מגדירים את השדה ingestOnWrite של משאב המטמון לערך true.

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

  • הפעלת הטמעה בזמן כתיבה ברמת הקידומת (אבל לא ברמת הקטגוריה)

    • הגדרה:

      1. מגדירים את השדה ingestOnWrite של משאב המטמון לערך false.
      2. צריך להגדיר מיפוי policies תקין (לא null) במשאב התיקייה המנוהלת.
      3. מגדירים את השדה ingestOnWrite של התיקייה המנוהלת לערך enabled (או לערך unspecified אם זו תיקיית צאצא שיורשת את הערך enabled מתיקיית הורה מנוהלת שמופעלת).

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

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

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

  • השבתת הטמעה בזמן כתיבה גם לקטגוריה וגם לקידומת

    • הגדרה:

      1. מגדירים את השדה ingestOnWrite של משאב המטמון לערך false.

      2. מגדירים את כל השדות ingestOnWrite של התיקיות המנוהלות לערך unspecified, ומוודאים שאף שדה ingestOnWrite של תיקיות מנוהלות ראשיות לא מוגדר לערך enabled.

        לחלופין, אפשר לא להגדיר כללי מדיניות על ידי השארת המפה policies null או השמטת ההגדרה rapidCacheConfig לגמרי.

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

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

איך פועלת קבלת הרשאות בירושה בהטמעה בזמן הכתיבה

אם בתיקייה המנוהלת לא מופעלת באופן מפורש האפשרות "הטמעה בזמן כתיבה" (כשהשדה ingestOnWrite של התיקייה המנוהלת מוגדר לערך unspecified), ההתנהגות של המטמון לגבי "הטמעה בזמן כתיבה" עוברת בירושה מהמשאב הראשי של התיקייה המנוהלת, בין אם הוא מהקטגוריה או מתיקייה מנוהלת ראשית.

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

לדוגמה, נבחן את התרחיש הבא:

  • יש לכם תיקייה מנוהלת a/ שמשאב ההורה שלה הוא הקטגוריה my-bucket.
  • יש לכם תיקייה מנוהלת a/b/ שמשאב ההורה שלה הוא התיקייה המנוהלת a/ בתוך my-bucket.

כשנכתב אובייקט בשם a/b/info.txt, ‏Rapid Cache מעריך את היררכיית ההגדרות מלמעלה למטה:

  1. בודקים את התיקייה המנוהלת המיידית: אם a/b/ מוגדר ל-enabled, אז ingest-on-write ברמת הקידומת מופעל לאובייקטים שנכתבו ב-a/b/. אם הערך של a/b/ הוא unspecified, המערכת של Rapid Cache בודקת את המשאב ההורה המיידי, שהוא התיקייה המנוהלת a/.
  2. בודקים את התיקייה הראשית המנוהלת: אם a/ מוגדר ל-enabled, אז ingest-on-write ברמת הקידומת מופעל בשביל a/ ו-a/b/. אם הערך של a/ הוא unspecified, ‏Rapid Cache בודק את הקטגוריה הראשית.
  3. בודקים את ההגדרה ingestOnWrite ברמת המטמון של הקטגוריה: אם השדה ingestOnWrite של המטמון מוגדר לערך true, ההגדרה ingest-on-write ברמת הקטגוריה מופעלת ומבטלת כל תיקייה מנוהלת שמוגדרת בה ingest-on-write ברמת הקידומת. אם השדה ingestOnWrite של המטמון הוא false והשדה ingestOnWrite של התיקיות המנוהלות הראשית והמשנית הוא unspecified, אז ingest-on-write מושבת לאובייקטים בקטגוריה שנמצאים בתיקיות המנוהלות הראשית והמשנית. בתרחיש הזה, אם אין בקטגוריה תיקיות מנוהלות אחרות שמוגדרת בהן הטמעה בזמן כתיבה, ההטמעה בזמן כתיבה מושבתת לכל האובייקטים בקטגוריה.

אורך חיים (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 החדש חל באופן מיידי על הנתונים הקיימים והחדשים במטמון.

‫AnywhereCaches Update API הוא אסינכרוני ומחזיר פעולה ממושכת.

קבלת מטמון

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

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

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

השבתת מטמון

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

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

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

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

המשך מטמון

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

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

המלצות לגבי Rapid Cache

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

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

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

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

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

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

מגבלות והגבלות

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

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

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

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

  • אי אפשר לקרוא באמצעות BigQuery את ההמלצות והתובנות שנוצרו על ידי שירות ההמלצות של Rapid Cache.

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

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

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

תמחור

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

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

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

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

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

בחירת אזור

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

הגדרת TTL

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

השבתת המטמון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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