כשאתם מקצים מכונה של Cloud Firestore, אתם צריכים לבחור מיקום למכונה. כדי לצמצם את זמן האחזור ולהגדיל את הזמינות, כדאי לאחסן את הנתונים קרוב למשתמשים ולשירותים שזקוקים להם.
אם הפרויקט שלכם מוגדר לתוכנית התמחור של Blaze בתשלום לפי שימוש, תוכלו ליצור כמה מסדי נתונים בפרויקט, לכל אחד מהם הגדרת מיקום משלו.
חשוב לזכור שאחרי שמקצים מכונה של מסד נתונים, אי אפשר לשנות את הגדרת המיקום שלה.
סוגי המיקומים
אפשר לשמור את נתוני Cloud Firestore במיקום במספר אזורים או במיקום אזורי.
מיקומים במספר אזורים
כדאי לבחור מיקום במספר אזורים כדי למקסם את הזמינות והעמידות של מסד הנתונים.
מיקום במספר אזורים מורכב מקבוצה מוגדרת של אזורים שבהם מאוחסנות כמה רפליקות של מסד הנתונים. כל עותק הוא עותק לקריאה וכתיבה שמכיל את כל הנתונים במסד הנתונים, או עותק עד (witness) שלא שומר קבוצה מלאה של נתונים אבל משתתף ברפליקה.
יצירת רפליקות של הנתונים במספר אזורים מאפשרת להמשיך להציג את הנתונים גם אם אזור שלם מושבת. בתוך אזור מסוים, הנתונים עוברים רפליקה בתחומים כדי שאפשר יהיה להמשיך להציג את הנתונים באותו אזור גם אם תחום מסוים יוצא משימוש.
Cloud Firestore תומך במיקומים הבאים במספר אזורים:
| השם של המיקום 'במספר אזורים' | תיאור של המיקום 'במספר אזורים' | אזורים לקריאה וכתיבה | אזור העד |
|---|---|---|---|
eur3 |
אירופה | europe-west1 (בלגיה), europe-west4 (הולנד) |
europe-north1 (פינלנד) |
nam5 |
ארצות הברית | us-central1 (איווה), us-central2 (אוקלהומה – אזור GCP פרטי) |
us-east1 (קרוליינה הדרומית) |
שימו לב: אם בפרויקט שלכם כבר יש אפליקציית App Engine עם המיקום us-central או europe-west, מסד הנתונים Cloud Firestore שמוגדר כברירת מחדל ייחשב כמספר אזורים.
מיקומים אזוריים
מיקום אזורי הוא מקום גיאוגרפי ספציפי, כמו דרום קרולינה. נתונים במיקום אזורי עוברים רפליקה בכמה תחומים בתוך אזור. כל המיקומים האזוריים מופרדים ממיקומים אזוריים אחרים במרחק של לפחות 160 ק"מ.
בוחרים מיקום אזורי כדי להוזיל את העלויות, כדי לקצר את זמן האחזור לכתיבה אם האפליקציה שלכם רגישת לזמן אחזור, או כדי למקם את המשאבים לצד משאבי 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-east2 | הונג קונג | |
asia-east1 | טאיוואן | |
asia-northeast1 | טוקיו | |
asia-northeast2 | אוסקה | |
asia-northeast3 | סיאול | |
| אוסטרליה | ||
australia-southeast1 | סידני | |
|
|
מלבורן | |
| אפריקה | ||
|
|
יוהנסבורג | |
הסכם רמת שירות למיקום
סוג המיקום Cloud Firestore קובע את אחוז זמן הפעולה לפי הסכם רמת השירות (SLA):
| שירות מכוסה | אחוז זמן פעולה תקינה חודשי |
|---|---|
| Cloud Firestore מספר אזורים | >= 99.999% |
| Cloud Firestore אזורית | >= 99.99% |
תמחור לפי מיקום
המיקום של Cloud Firestore קובע את העלות של פעולות במסד נתונים.
הסבר מקיף על התמחור לפי אזור וסוג אזור זמין במאמר הסבר על החיוב ב-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 Storage שתוגדר כברירת מחדל בעתיד (
*.firebasestorage.app
- המיקום של קטגוריית 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.
- למידע נוסף על פיתוח אפליקציות בהתאם לדרישות שלכם לגבי זמן אחזור, זמינות ועמידות, תוכלו לעיין במאמר מיקום גיאוגרפי ואזורים.