כשמקצים מכונה של 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 נחשב במספר אזורים.