Rapid Cache

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

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

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

איך פועל Rapid Cache

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

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

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

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

מגבלת רוחב הפס של המטמון מתחילה ב-100Gbps וגדלה בקצב של 20Gbps לכל 1TiB של נתונים מאוחסנים. כדי להגדיל את רוחב הפס ההתחלתי או את המגבלה הכוללת של רוחב הפס, אפשר להגדיל את כמות הנתונים שמאוחסנים במטמון, ליצור עוד מטמונים באזור או לפנות למנהל החשבונות הטכני או לנציג 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	check		check	check
asia-east1-b	check		check	check
asia-east1-c	check		check	check
asia-northeast1-a	check	check
asia-northeast1-b	check	check
asia-northeast1-c	check	check
asia-south1-a	check
asia-south1-b	check
asia-south1-c	check
asia-southeast1-a	check		check	check
asia-southeast1-b	check		check	check
asia-southeast1-c	check		check	check

אירופה

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

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

ארצות הברית

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

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

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

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

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

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

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

הסבר על הפעלת הטמעה בזמן כתיבה

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

ה-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.

מגבלות

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

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

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

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

• יצירה וניהול של מטמונים.