אתם יכולים להשתמש גם ב-Firebase Realtime Database וגם ב-Cloud Firestore באפליקציה שלכם, וליהנות מהיתרונות של כל פתרון מסד נתונים כדי להתאים אותו לצרכים שלכם. לדוגמה, יכול להיות שתרצו להשתמש בתמיכה של Realtime Database בנוכחות, כמו שמתואר במאמר Build Presence in Cloud Firestore.
מידע נוסף על ההבדלים בין מסדי הנתונים
העברת נתונים אל Cloud Firestore
אם החלטתם להעביר חלק מהנתונים מ-Realtime Database אל Cloud Firestore, כדאי לעיין בתהליך הבא. לכל מסד נתונים יש צרכים ייחודיים ושיקולים מבניים, ולכן אין דרך אוטומטית להעביר אותו. במקום זאת, אפשר לפעול לפי סדר הפעולות הכללי הבא:
מיפוי של מבנה הנתונים וכללי האבטחה מ-Realtime Database אל Cloud Firestore. גם Realtime Database וגם Cloud Firestore מסתמכים על אימות ב-Firebase, כך שלא צריך לשנות את אימות המשתמשים באפליקציה. עם זאת, כללי האבטחה ומודל הנתונים שונים, ולכן חשוב להביא בחשבון את ההבדלים האלה לפני שמתחילים להעביר נתונים ל-Cloud Firestore.
העברת נתונים היסטוריים במהלך ההגדרה של מבנה הנתונים החדש ב-Cloud Firestore, אפשר למפות ולהעביר נתונים קיימים מ-Realtime Database למופע החדש של Cloud Firestore. עם זאת, אם אתם משתמשים בשני מסדי הנתונים באפליקציה, אתם לא צריכים להעביר נתונים היסטוריים מ-Realtime Database.
שיקוף נתונים חדשים ב-Firestore בזמן אמת. משתמשים ב-Cloud Functions כדי לכתוב נתונים חדשים למסד הנתונים החדש Cloud Firestore כשהם מתווספים ל-Realtime Database.
הופכים את 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, פועלים לפי השלבים הבאים:
- מייצאים את הנתונים מ-Realtime Database או משתמשים בגיבוי מהזמן האחרון.
- במסוף Firebase, עוברים אל Databases & Storage (מסדי נתונים ואחסון) > Realtime Database (מסד נתונים בזמן אמת).
- בכרטיסייה נתונים, בוחרים את הצומת ברמת הבסיס של מסד הנתונים ובתפריט בוחרים באפשרות ייצוא JSON.
יוצרים את מסד הנתונים החדש ב-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 Security Rules.
אם השתמשתם ב-Cloud Functions כדי לשמור על שוויון בין מסדי הנתונים, ודאו שאתם לא משכפלים פעולות כתיבה בשני מסדי הנתונים בלולאה. צריך לשנות את הפונקציה כך שתכתוב למסד נתונים יחיד, או להסיר את הפונקציה לחלוטין ולהתחיל להפסיק את פונקציונליות הכתיבה לנתונים שהועברו באפליקציות שעדיין מקושרות ל-Realtime Database. האופן שבו מטפלים בזה באפליקציה תלוי בצרכים הספציפיים שלכם ושל המשתמשים.
מוודאים שהנתונים מאובטחים כמו שצריך. מאמתים את ההגדרה של Cloud Firestore Security Rules או של IAM.