כשמפעילים מופע של 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 | מונטריאול | |
|
|
טורונטו | |
|
|
Queretaro | |
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 | סידני | |
|
|
מלבורן | |
| אפריקה | ||
|
|
יוהנסבורג | |
הסכם רמת שירות (SLA) למיקום
Cloud Firestore סוג המיקום קובע את אחוז הזמינות של הסכם רמת השירות (SLA):
| שירות מכוסה | אחוז חודשי של זמן פעולה תקינה |
|---|---|
| Cloud Firestore מספר אזורים | >= 99.999% |
| Cloud Firestore אזורי | >= 99.99% |
תמחור לפי מיקום
המיקום שלכם Cloud Firestore קובע את העלות של פעולות במסד הנתונים.
הסבר מקיף על התמחור לפי אזור ולפי סוג אזור זמין במאמר הסבר על החיוב ב-Cloud Firestore.
הצגת המיקום של מסדי הנתונים
במסוף Firebase, עוברים אל הכרטיסייה Cloud Firestore Data (נתונים) כדי לראות את רשימת המופעים של מסד הנתונים והמיקומים שלהם.
יחסי תלות אפשריים במיקום בגלל 'מיקום למשאבי Google Cloud שמוגדרים כברירת מחדל'
ההגדרה 'מיקום למשאבי ברירת מחדל של Google Cloud' היא הגדרת המיקום של כל משאבי הפרויקט שמשויכים ל-Google Google Cloud, כולל המשאבים הבאים:App Engine
- מופע ברירת מחדל של מסד נתונים Cloud Firestore
- ברירת המחדל Cloud Storage לקטגוריית Firebase עם פורמט השם
*.appspot.com - Google Cloud Scheduler בשימוש ספציפי עם פונקציות מתוזמנות מהדור הראשון
ההגדרה הזו של "מיקום למשאבי ברירת מחדל Google Cloud" היא קבועה. בנוסף, כשמגדירים את המיקום של אחד מהמשאבים המשויכים, המיקום מוגדר באופן עקיף לכולם, כי כולם משויכים לאותו App Engine.
עם זאת, במהלך השנים חלו שינויים רבים במערכת האקולוגית של Firebase ו-Google Cloud, ולכן השיוכים של משאבים ל-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.
- מידע נוסף על פיתוח אפליקציות שיעמדו בדרישות שלכם לגבי זמן אחזור, זמינות ועמידות זמין במאמר מיקום גיאוגרפי ואזורים.