כשמקצים מכונה של Cloud Firestore, צריך לבחור מיקום למכונה. כדי לצמצם את זמן האחזור ולהגביר את הזמינות, כדאי לאחסן את הנתונים קרוב למשתמשים ולשירותים שצריכים אותם.
אם הפרויקט שלכם נמצא בתוכנית התמחור "Blaze בתשלום לפי שימוש", אתם יכולים ליצור כמה מסדי נתונים בפרויקט, ולכל אחד מהם תהיה הגדרת מיקום משלו.
חשוב לדעת שאחרי שמקצים מכונה של מסד נתונים, אי אפשר לשנות את הגדרת המיקום שלה.
סוגי מיקומים
אתם יכולים לאחסן את הנתונים של Cloud Firestore במיקום במספר אזורים או במיקום אזורי.
מיקומים במספר אזורים
כדי למקסם את הזמינות והעמידות של מסד הנתונים, בחרו מיקום במספר אזורים.
מיקום במספר אזורים מורכב מקבוצה מוגדרת של אזורים שבהם מאוחסנים כמה עותקים של מסד הנתונים. כל רפליקה היא רפליקה לקריאה ולכתיבה שמכילה את כל הנתונים במסד הנתונים, או רפליקת עדות שלא מכילה קבוצה מלאה של נתונים אבל משתתפת ברפליקציה.
כך, גם אם אזור שלם לא יהיה זמין, הנתונים ימשיכו להיות זמינים. בתוך אזור מסוים, נוצרת רפליקה של הנתונים בין אזורים, כדי שאפשר יהיה להמשיך להציג את הנתונים באותו אזור גם אם אחד מהאזורים אבד.
Cloud Firestore תומך במיקומים הבאים במספר אזורים:
| השם של המיקום "במספר אזורים" | תיאור של המיקום "במספר אזורים" | אזורי קריאה-כתיבה | אזור העד |
|---|---|---|---|
eur3 |
אירופה | europe-west1 (בלגיה), europe-west4 (הולנד) |
europe-north1 (פינלנד) |
nam5 |
ארצות הברית (מרכז) | us-central1 (איווה), us-central2 (אוקלהומה – אזור GCP פרטי) |
us-east1 (קרוליינה הדרומית) |
nam7 |
ארצות הברית (מרכז ומזרח) | us-central1 (איווה), us-east4 (צפון וירג'יניה) |
us-central2 (אוקלהומה – אזור פרטי Google Cloud) |
מיקומים אזוריים
מיקום אזורי הוא מקום גיאוגרפי ספציפי, כמו דרום קרוליינה. נתונים במיקום אזורי משוכפלים במספר אזורים בתוך אזור.
כדאי לבחור מיקום אזורי כדי להוזיל את העלויות, כדי להפחית את זמן האחזור של הכתיבה אם האפליקציה רגישה לזמן אחזור, או כדי למקם את הנתונים באותו מיקום עם משאבים אחרים של Google Cloud.
Cloud Firestore תומך במיקומי המשאבים האזוריים הבאים:
| שם האזור | תיאור האזור | |
|---|---|---|
| צפון אמריקה | ||
us-west1 | אורגון | |
us-west2 | לוס-אנג׳לס | |
us-west3 | סולט לייק סיטי | |
us-west4 | לאס וגאס | |
|
|
איווה | |
northamerica-northeast1 | מונטריאול | |
|
|
טורונטו | |
|
|
קרטרו | |
us-east1 | דרום קרוליינה | |
us-east4 | צפון וירג'יניה | |
|
|
קולומבוס | |
|
|
דאלאס | |
| דרום אמריקה | ||
|
|
סנטיאגו | |
southamerica-east1 | סאו פאולו | |
| אירופה | ||
europe-west2 | לונדון | |
|
|
בלגיה | |
|
|
הולנד | |
|
|
מילאנו | |
|
|
מדריד | |
|
|
פריז | |
|
|
טורינו | |
|
|
ברלין | |
europe-west3 | פרנקפורט | |
|
|
פינלנד | |
|
|
שטוקהולם | |
europe-central2 | ורשה | |
europe-west6 | ציריך | |
| המזרח התיכון | ||
|
|
דוחה | |
|
|
דמאם | |
|
|
תל אביב | |
| אסיה | ||
asia-south1 | מומבאי | |
|
|
דלהי | |
asia-southeast1 | סינגפור | |
asia-southeast2 | ג'קארטה | |
asia-southeast3 | בנגקוק | |
asia-east2 | הונג קונג | |
asia-east1 | טאיוואן | |
asia-northeast1 | טוקיו | |
asia-northeast2 | אוסקה | |
asia-northeast3 | סיאול | |
| אוסטרליה | ||
australia-southeast1 | סידני | |
|
|
מלבורן | |
| אפריקה | ||
|
|
יוהנסבורג | |
הסכם רמת השירות (SLA) של המיקום
סוג המיקום של Cloud Firestore קובע את אחוז זמן הפעולה התקינה של הסכם רמת השירות (SLA):
| שירות נכלל | אחוז זמן הפעולה התקינה בחודש |
|---|---|
| מספר אזורים ב-Cloud Firestore | >= 99.999% |
| Cloud Firestore Regional | 99.99% ומעלה |
תמחור לפי מיקום
המיקום של Cloud Firestore קובע את העלות של פעולות במסד הנתונים.
הסבר מקיף על התמחור לפי אזור ולפי סוג אזור מופיע במאמר הסבר על החיוב ב-Cloud Firestore.
הצגת המיקום של מסדי הנתונים
אפשר לראות את רשימת המופעים של מסד הנתונים והמיקומים שלהם במסוף Firebase, בקטע Databases & Storage > Firestore > הכרטיסייה Data.
יחסי תלות אפשריים במיקום בגלל "מיקום למשאבי Google Cloud שמוגדרים כברירת מחדל"
"המיקום של משאבי ברירת המחדל של Google Cloud" הוא הגדרת המיקום של כל משאבי הפרויקט שמשויכים ל-Google App Engine, כולל:
- מכונה של מסד נתונים Cloud Firestore שמוגדרת כברירת מחדל
- קטגוריית ברירת המחדל של Cloud Storage ל-Firebase, בפורמט השם
*.appspot.com - Google Cloud Scheduler משמשת במיוחד לפונקציות מתוזמנות מהדור הראשון
ההגדרה "מיקום ברירת המחדל של משאבי Google Cloud" לא ניתנת לשינוי. בנוסף, כשמגדירים את המיקום של אחד מהמשאבים המשויכים, מגדירים באופן עקיף את המיקום של כולם בגלל השיוך המשותף שלהם ל-App Engine.
עם זאת, בעקבות שינויים רבים בסביבה העסקית של Firebase ו-Google Cloud לאורך השנים, השיוך של המשאבים ל-App Engine השתנה. השינוי הבולט ביותר הוא שהחל מ-*.firebasestorage.app
אלה הפרטים של השינויים שבוצעו בתלויות המיקום האפשריות:
החל מ-
30 באוקטובר 2024 , אם מכסת ברירת המחדל של מכונות Cloud Firestore ושל קטגוריות Cloud Storage ל-Firebase עדיין לא הוקצתה:הקצאת מכונת ברירת המחדל של Cloud Firestore מגדירה את המיקום של כל אפליקציית App Engine עתידית שמוקצית בפרויקט. עם זאת, הוא לא קובע את המיקום של קטגוריית ברירת המחדל העתידית של Cloud Storage.
הקצאת קטגוריית ברירת המחדל של Cloud Storage לא מקצה יותר אפליקציית App Engine. לכן, המיקום של קטגוריית ברירת המחדל של Cloud Storage לא קובע את המיקום של מכונת ברירת המחדל העתידית של Cloud Firestore.
החל מ-
30 באוקטובר 2024 , אם כבר הוקצה מכונה של Cloud Firestore כברירת מחדל, אבל לא הוקצה קטגוריה של Cloud Storage ל-Firebase כברירת מחדל:- מכונת ברירת המחדל הקיימת של Cloud Firestore לא קובעת את המיקום של קטגוריית ברירת המחדל העתידית של Cloud Storage (
*.firebasestorage.app
- מכונת ברירת המחדל הקיימת של Cloud Firestore לא קובעת את המיקום של קטגוריית ברירת המחדל העתידית של Cloud Storage (
החל מ-
30 באוקטובר 2024 , אם הקצאתם כבר את קטגוריית ברירת המחדל של Cloud Storage ל-Firebase (ספציפית, הקטגוריה*.appspot.com- כשהוקצה קטגוריית ברירת המחדל של Cloud Storage (
*.appspot.com*.appspot.com
- כשהוקצה קטגוריית ברירת המחדל של Cloud Storage (
אם השתמשתם בפונקציות מתוזמנות של דור ראשון, המיקום שלהן מוגדר למיקום של משאבי ברירת המחדל של Google Cloud. הסיבה לכך היא שבעבר היה שיוך בין Cloud Scheduler לבין App Engine. בנוסף, אם הגדרתם פונקציות מתוזמנות מהדור הראשון לפני הקצאת משאבים אחרים שחלקו את הגדרת המיקום הזו, הגדרתם גם את המיקום שלהם.
שימו לב: אם יש לכם אפליקציית App Engine במיקום us-central או europe-west, המיקום של משאבי ברירת המחדל של Google Cloud נחשב במספר אזורים.
השלבים הבאים
- כדי ליצור מסד נתונים של Cloud Firestore במיקום ספציפי, קראו את המאמר תחילת העבודה עם Cloud Firestore.
- במאמר מיקום גיאוגרפי ואזורים מוסבר איך לבנות אפליקציות שעומדות בדרישות שלכם לגבי זמן אחזור, זמינות ועמידות.