Rapid Cache

בדף הזה מתואר Rapid Cache, תכונה שמספקת מטמון קריאה אזורי שמגובה על ידי SSD לקטגוריות של Cloud Storage. המטמון הזה יכול להגדיל את קצב העברת הנתונים ולהקטין את זמן האחזור של הנתונים המאוחסנים. ‫Rapid Cache מספק קיבולת אחסון ורוחב פס שמתרחבים או מצטמצמים באופן אוטומטי בהתאם לצרכים שלכם. ‫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. מידע על מכסות זמין במאמר מכסות של 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-west3-a
europe-west3-b
europe-west3-c
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), המערכת מטמיעה את האובייקט כולו במטמון.

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

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

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

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

לדוגמה, נניח שהפעלתם מטמון כדי לבצע הטמעה ברמת הקידומת לאובייקטים בקטגוריה 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, האפשרות 'הוספה בזמן כתיבה' מופעלת לכל האובייקטים שנכתבים לקטגוריה תחת הקידומת הזו של התיקייה המנוהלת. אפשר להפעיל את האפשרות 'הוספה בזמן כתיבה' ברמת הקידומת רק אם השדה ingestOnWrite במשאב המטמון הוא false.
    • אם הערך הוא unspecified (ברירת מחדל), ההגדרה של האפשרות ingest-on-write עוברת בירושה ממשאב ההורה המיידי, שיכול להיות תיקייה מנוהלת או הבאקט שמכיל את התיקייה המנוהלת עצמה.
    • מטמון שלא צוין במיפוי המדיניות יטופל כאילו ההגדרה 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, ההטמעה ברמת הקידומת מופעלת לאובייקטים שנכתבים ב-a/b/. אם הערך של a/b/ הוא unspecified, Rapid Cache בודק את משאב ההורה המיידי, שהוא התיקייה המנוהלת a/.
  2. בודקים את התיקייה שמנוהלת על ידי ההורה: אם a/ מוגדר כ-enabled, ההטמעה ברמת הקידומת מופעלת עבור a/ ו-a/b/. אם a/ מוגדר ל-unspecified, ‏ Rapid Cache בודק את דלי האב.
  3. בודקים את הגדרת רמת המטמון של הדלי ingestOnWrite: אם השדה ingestOnWrite של המטמון מוגדר ל-true, ההגדרה של הטמעה בזמן כתיבה ברמת הדלי מופעלת ומבטלת את ההגדרה של הטמעה בזמן כתיבה ברמת הקידומת בכל תיקייה מנוהלת. אם השדה ingestOnWrite במטמון הוא false והשדה ingestOnWrite בשתי התיקיות המנוהלות (הורה וצאצא) הוא unspecified, ההטמעה בכתיבה מושבתת לאובייקטים בדלי שנמצאים בתיקיות המנוהלות (הורה וצאצא). בתרחיש הזה, אם אין בקטגוריה תיקיות מנוהלות אחרות עם הגדרה של הטמעה בכתיבה, ההטמעה בכתיבה מושבתת לכל האובייקטים בקטגוריה.

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

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

קבלת מטמון

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

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

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

השבתת מטמון

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

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

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

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

המשך של מטמון

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

‫AnywhereCaches Resume API הוא סינכרוני ומחזיר משאב 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 הוא לא אחסון עמיד, ויכול להיות שהנתונים יוסרו מהמטמון בתרחישים שונים. תרחיש אחד הוא שינוי הגודל של המטמון באופן אוטומטי כדי לוודא שיש מספיק משאבים לעומסי העבודה. בתרחיש הזה, יכול להיות שחלק מהנתונים יימחקו בהתאם לאלגוריתם של פריטים שהשימוש בהם היה הכי פחות לאחרונה (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.

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

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

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

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

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