שימוש ב-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 Authentication, כך שלא צריך לשנות את אימות המשתמשים באפליקציה. עם זאת, כללי האבטחה ומודל הנתונים שונים, ולכן חשוב להביא בחשבון את ההבדלים האלה לפני שמתחילים להעביר נתונים ל-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 או אינטרנט, או ב-Identity Access Management (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. בכרטיסייה נתונים, בוחרים את הצומת ברמת הבסיס של מסד הנתונים ובתפריט בוחרים באפשרות ייצוא JSON.

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

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

   • לכתוב סקריפט בהתאמה אישית שמייצא את הנתונים בשבילכם. אנחנו לא יכולים לספק תבנית לסקריפט הזה, כי לכל מסד נתונים יש צרכים ייחודיים.Cloud Firestore עם זאת, מומחים בערוץ Slack שלנו או ב-Stack Overflow יכולים לבדוק את הסקריפט שלכם או להציע לכם ייעוץ בהתאם למצב הספציפי שלכם.
   • אפשר להשתמש ב-SDKs של השרת (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.Cloud Firestore Security Rules

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

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