שימוש ב-Cloud Firestore עם מסד נתונים בזמן אמת ב-Firebase

אתם יכולים להשתמש גם ב-Firebase Realtime Database וגם ב-Cloud Firestore באפליקציה, ולנצל את היתרונות של כל פתרון מסדי נתונים בהתאם לצרכים שלכם. לדוגמה, תוכלו להשתמש בתמיכה של Realtime Database בסטטוס 'באינטרנט', כפי שמתואר במאמר יצירת סטטוס 'באינטרנט' ב-Cloud Firestore.

מידע נוסף על ההבדלים בין מסדי הנתונים

העברת נתונים אל Cloud Firestore

אם החלטתם להעביר חלק מהנתונים מ-Realtime Database אל Cloud Firestore, כדאי להשתמש בתהליך הבא. מכיוון שלכל מסד נתונים יש צרכים ייחודיים ושיקולים מבניים, אין נתיב אוטומטי להעברה. במקום זאת, אפשר לפעול לפי התהליך הכללי הבא:

1. ממפים את מבנה הנתונים וכללי האבטחה מ-Realtime Database ל-Cloud Firestore. גם Realtime Database וגם Cloud Firestore מסתמכים על אימות Firebase, כך שאין צורך לשנות את אימות המשתמשים באפליקציה. עם זאת, כללי האבטחה ומודל הנתונים שונים, וצריך להביא בחשבון את ההבדלים האלה לפני שמתחילים להעביר נתונים ל-Cloud Firestore.

2. העברת נתונים היסטוריים כשמגדירים את מבנה הנתונים החדש ב-Cloud Firestore, אפשר למפות ולהעביר נתונים קיימים מ-Realtime Database למכונה החדשה של Cloud Firestore. עם זאת, אם אתם משתמשים בשני מסדי הנתונים באפליקציה, אין צורך להעביר את הנתונים ההיסטוריים מ-Realtime Database.

3. העתקת נתונים חדשים ל-Firestore בזמן אמת משתמשים ב-Cloud Functions כדי לכתוב נתונים חדשים למסד הנתונים החדש Cloud Firestore כשהם מתווספים ל-Realtime Database.

4. מגדירים את Cloud Firestore כמסד הנתונים הראשי של הנתונים שהועברו. אחרי שתעבירו חלק מהנתונים, תוכלו להשתמש ב-Cloud Firestore כמסד הנתונים הראשי ולצמצם את השימוש ב-Realtime Database לנתונים שהועברו. כדאי לבדוק אילו גרסאות של האפליקציה עדיין קשורות ל-Realtime Database לצורך קבלת הנתונים האלה, ואיך אתם מתכננים להמשיך לתמוך בהן.

חשוב להביא בחשבון את העלויות לחיוב גם ב-Realtime Database וגם ב-Cloud Firestore.

מיפוי הנתונים

הנתונים ב-Realtime Database מובְנים כעץ יחיד, בעוד ש-Cloud Firestore תומך בהיררכיות נתונים מפורשות יותר באמצעות מסמכים, אוספים ואוספים משניים. אם מעבירים חלק מהנתונים מ-Realtime Database אל Cloud Firestore, כדאי לשקול ארכיטקטורה אחרת לנתונים.

הבדלים עיקריים שכדאי להביא בחשבון

אם מעבירים נתונים מעץ Realtime Database הקיים למסמכים ולאוספים ב-Cloud Firestore, חשוב לזכור את ההבדלים העיקריים הבאים בין מסדי הנתונים, שעשויים להשפיע על מבנה הנתונים ב-Cloud Firestore:

• שאילתות שטוחות מספקות גמישות רבה יותר במבנים היררכיים של נתונים.
• שאילתות מורכבות מספקות רמת פירוט גבוהה יותר ומפחיתות את הצורך בנתונים כפולים.
• הסמן של השאילתה מאפשר חלוקה לדפים יעילה יותר.
• עסקאות כבר לא דורשות שורש משותף לכל הנתונים, והן יעילות יותר.
• עלויות החיוב שונות בין Realtime Database לבין Cloud Firestore. במקרים רבים, Cloud Firestore עשוי להיות יקר יותר מ-Realtime Database, במיוחד אם אתם מסתמכים על פעולות קטנות רבות. כדאי לצמצם את מספר הפעולות במסד הנתונים ולהימנע מכתיבת מידע מיותר. מידע נוסף על ההבדלים בחיוב בין Realtime Database לבין Cloud Firestore

שיטות מומלצות בפעולה

הדוגמה הבאה משקפת חלק מהשיקולים שצריך להביא בחשבון כשעוברים את הנתונים בין מסדי נתונים. תוכלו להשתמש בקריאות שטוחות וביכולות שיפור של שאילתות כדי ליצור מבני נתונים טבעיים יותר מאשר השתמשתם בהם ב-Realtime Database.

כדאי לחשוב על אפליקציית מדריך עיר שעוזרת למשתמשים למצוא ציוני דרך בולטים בערים ברחבי העולם. מכיוון ש-Realtime Database חסר קריאות שטחיות, יכול להיות שתצטרכו לבנות את הנתונים בשני צמתים ברמה העליונה, באופן הבא:

// /cities/$CITY_KEY
{
  name: "New York",
  population: 8000000,
  capital: False
}

// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
  name: "Empire State Building",
  category: "Architecture"
}

ל-Cloud Firestore יש קריאות שטוחות, כך ששאילתות למסמכים באוסף לא גוררות נתונים מאוספי משנה. לכן, אפשר לאחסן מידע על ציוני דרך באוסף משנה:

// /cities/$CITY_ID
{
  name: "New York",
  population: 8000000,
  capital: False,
  landmarks: [... subcollection ...]
}

הגודל המקסימלי של מסמכים הוא 1MB, וזו סיבה נוספת לאחסן את האתרים החשובים כאוסף משנה, כדי שכל מסמך של עיר יהיה קטן, במקום להגדיל את המסמכים באמצעות רשימות בתצוגת עץ.

יכולות השאילתות המתקדמות של Cloud Firestore מפחיתות את הצורך לשכפל נתונים לדפוסי גישה נפוצים. לדוגמה, נניח שרוצים להציג במסך באפליקציית מדריך הערים את כל הבירות לפי סדר האוכלוסייה. ב-Realtime Database, הדרך היעילה ביותר לעשות זאת היא לשמור רשימה נפרדת של ערי בירה עם נתונים כפולים מהרשימה cities, באופן הבא:

{
   cities: {
    // ...
   },

   capital-cities: {
     // ...
   }
}

ב-Cloud Firestore, אפשר להציג רשימה של ערי בירה לפי סדר האוכלוסייה כשאילתה אחת:

db.collection('cities')
    .where('capital', '==', true)
    .orderBy('population')

מידע נוסף על מודל הנתונים של Cloud Firestore ורעיונות נוספים לגבי תכנון מבנה מסד הנתונים של Cloud Firestore זמינים בפתרונות שלנו.

אבטחת הנתונים

בין שאתם משתמשים ב-Cloud Firestore Security Rules ללקוחות Android,‏ Apple או אינטרנט, ובין שאתם משתמשים ב-ניהול זהויות והרשאות גישה (IAM) לשרתים, חשוב לוודא שאתם מאבטחים את הנתונים ב-Cloud Firestore וגם ב-Realtime Database. אימות המשתמשים מתבצע על ידי Authentication בשני מסדי הנתונים, כך שאין צורך לשנות את ההטמעה של Authentication כשמתחילים להשתמש ב-Cloud Firestore.

הבדלים עיקריים שכדאי להביא בחשבון

• ערכות ה-SDK לנייד ולאינטרנט משתמשות ב-Cloud Firestore Security Rules, ואילו ערכות ה-SDK לשרתים משתמשות בניהול זהויות והרשאות גישה (IAM) כדי לאבטח את הנתונים.
• Cloud Firestore Security Rules לא מתבצעת שרשור אלא אם משתמשים בתווים כלליים לחיפוש. מסמכים ואוספים לא יורשים כללים בדרך אחרת.
• לא צריך יותר לאמת את הנתונים בנפרד (כמו שעשיתם ב-Realtime Database).
• Cloud Firestore בודק את הכללים לפני ביצוע השאילתה כדי לוודא שלמשתמש יש את הרשאת הגישה המתאימה לכל הנתונים שמוחזרים על ידי השאילתה.

העברת נתונים היסטוריים אל Cloud Firestore

אחרי שממפים את המבנים של הנתונים והאבטחה למודלים של הנתונים והאבטחה של Cloud Firestore, אפשר להתחיל להוסיף את הנתונים. אם אתם מתכננים לשלוח שאילתות על נתונים היסטוריים אחרי שתעבירו את האפליקציה מ-Realtime Database ל-Cloud Firestore, עליכם להוסיף ייצוא של הנתונים הישנים למסד הנתונים החדש של Cloud Firestore. אם אתם מתכננים להשתמש גם ב-Realtime Database וגם ב-Cloud Firestore באפליקציה, אתם יכולים לדלג על השלב הזה.

כדי למנוע החלפה של נתונים חדשים בנתונים ישנים, מומלץ להוסיף קודם את הנתונים ההיסטוריים. אם מוסיפים נתונים חדשים לשני מסדי הנתונים בו-זמנית, כפי שמתואר בשלב הבא, חשוב לתת עדיפות לנתונים החדשים שנוספו ל-Cloud Firestore על ידי Cloud Functions.

כדי להעביר נתונים היסטוריים אל Cloud Firestore:

1. לייצא את הנתונים מ-Realtime Database או להשתמש בגיבוי עדכני.
   1. עוברים לקטע Realtime Database במסוף Firebase.
   2. בכרטיסייה Data, בוחרים את הצומת ברמת הבסיס של מסד הנתונים ובוחרים באפשרות Export JSON בתפריט.

2. יוצרים את מסד הנתונים החדש ב-Cloud Firestore ומוסיפים את הנתונים.

   כשאתם מעבירים חלק מהנתונים אל Cloud Firestore, כדאי לשקול את האסטרטגיות הבאות:

   • כותבים סקריפט מותאם אישית שיעביר את הנתונים בשבילכם. אנחנו לא יכולים להציע תבנית לסקריפט הזה, כי לכל מסד נתונים יש צרכים ייחודיים, אבל Cloud Firestore מומחים בערוץ Slack שלנו או ב-Stack Overflow יכולים לבדוק את הסקריפט או להציע עצות למקרה הספציפי שלכם.
   • משתמשים ב-SDK של השרת (Node.js,‏ Java,‏ Python או Go) כדי לכתוב נתונים ישירות ל-Cloud Firestore. הוראות להגדרת ערכות ה-SDK של השרת מפורטות במאמר תחילת העבודה.
   • כדי לזרז העברות של כמויות גדולות של נתונים, כדאי להשתמש בכתיבה באשכולות ולשלוח עד 500 פעולות בבקשת רשת אחת.
   • כדי לא לחרוג ממגבלות הקצב של Cloud Firestore, כדאי להגביל את הפעולות ל-500 שינויי כתיבה לשנייה לכל קולקציה.

הוספת נתונים חדשים אל Cloud Firestore

כדי לשמור על תאימות בין מסדי הנתונים, מוסיפים נתונים חדשים לשני מסדי הנתונים בזמן אמת. משתמשים ב-Cloud Functions כדי להפעיל כתיבה ב-Cloud Firestore בכל פעם שלקוח כותב ב-Realtime Database. חשוב לוודא ש-Cloud Firestore נותן עדיפות לנתונים חדשים שמגיעים מ-Cloud Functions על פני כל פעולות הכתיבה שאתם מבצעים מהעברת הנתונים ההיסטוריים.

יוצרים פונקציה שכותבת נתונים חדשים או משתנים ל-Cloud Firestore בכל פעם שלקוח כותב נתונים ל-Realtime Database. מידע נוסף על טריגרים של Realtime Database ב-Cloud Functions

הופכים את Cloud Firestore למסד הנתונים הראשי של הנתונים שהועברו

אם החלטתם להשתמש ב-Cloud Firestore כמסד הנתונים הראשי לחלק מהנתונים שלכם, חשוב להביא בחשבון את כל הפונקציות של שיקוף הנתונים שהגדרתם ולאמת את Cloud Firestore Security Rules.

1. אם השתמשתם ב-Cloud Functions כדי לשמור על תאימות בין מסדי הנתונים, חשוב לוודא שאתם לא מכפילים פעולות כתיבה בשני מסדי הנתונים בלולאה. צריך להעביר את הפונקציה לכתיבה במסד נתונים יחיד, או להסיר את הפונקציה לגמרי ולהתחיל להוציא משימוש את הפונקציונליות של הכתיבה לנתונים שהועברו באפליקציות שעדיין קשורות ל-Realtime Database. האופן שבו תפעלו את זה באפליקציה שלכם תלוי בצרכים הספציפיים שלכם ובמשתמשים שלכם.

2. מוודאים שהנתונים מאובטחים כראוי. מאמתים את ההגדרה של Cloud Firestore Security Rules או IAM.