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