סקירה כללית של Firestore במצב Native

‫Firestore במצב Native מורכב משתי קבוצות של פעולות – פעולות ליבה של Firestore ופעולות פייפליין של Firestore.

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

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

תכונות של פעולות הליבה של Firestore

הפעולות הבסיסיות מאפשרות פעולות CRUD רגילות ושאילתות האזנה בזמן אמת. עם זאת, כשמשתמשים בפעולות האלה במהדורת Enterprise, ההתנהגות הבסיסית בנוגע להוספה לאינדקס ולחיוב משתנה באופן משמעותי בהשוואה למהדורת Standard.

פונקציונליות והמשכיות

בפעולות הליבה נשמר התחביר המוכר של שרשור השיטות (לדוגמה, .where(), .orderBy()) שמשמש במהדורת Standard. הפעולות האלה תומכות בשאילתות האזנה בזמן אמת ובשמירת נתונים אופליין ללקוחות בנייד ובאינטרנט. מומלץ להשתמש בפעולות האלה לעומסי עבודה רגילים של טרנזקציות, לחיפושים פשוטים ולהעברת קוד אפליקציה קיים.

הוספה לאינדקס בהתאמה אישית

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

מודל חיוב (מבוסס-יחידות)

יחידות הקריאה מחויבות במנות של 4KB ולא לפי מספר המסמכים. שאילתה ללא אינדקס שסורקת אוסף גדול תצרוך יחידות קריאה על סמך סך כל הבייטים שנסרקו בכל המסמכים. יחידות כתיבה מחויבות במנות של 1KB. כתיבת מסמך צורכת יחידות עבור הנתונים, וגם יחידות נוספות לכל רשומה באינדקס שמתעדכנת. בניגוד למהדורת Standard, שבה מתבצעת אכיפה של הוספה אוטומטית של שדה יחיד לאינדקס, עכשיו אתם יכולים לבחור שדות ספציפיים להוספה לאינדקס כדי לשפר את עלויות הכתיבה והביצועים.

תכונות של פעולות ב-Firestore Pipeline

מהדורת Firestore Enterprise עם פעולות Pipeline משתמשת במנוע שאילתות מתקדם שמסיר הרבה מהמגבלות הקיימות של מהדורת Firestore Standard. פעולות בצינור עיבוד נתונים מספקות מאות תכונות נוספות של שאילתות. הפעולות ב-Pipeline כוללות את היכולות הבאות:

תחביר של רכיב קומפוזבילי מבוסס-שלב

שאילתות צינור עיבוד נתונים נוצרות על ידי הגדרת סדרה של שלבים עוקבים שמבוצעים לפי הסדר. כך אפשר לבצע פעולות מורכבות, כמו סינון לפי תוצאה של צבירה, שלא היה אפשרי בעבר.

בדוגמה הבאה מוצגת שאילתת צינור עיבוד נתונים שמוצאת את מספר מזהי המוצרים הייחודיים שנצפו בחודש האחרון:

guard let cutoffDate = Calendar.current.date(byAdding: .month, value: -1, to: Date()) else {
  return
}
let snapshot = try await db.pipeline()
  .collection("productViews")
  .where(Field("viewedAt").greaterThan(cutoffDate.timeIntervalSince1970))
  .aggregate([Field("productId").countDistinct().as("uniqueProductViews")])
  .execute()

יכולות מורחבות

השאילתה Pipeline כוללת מספר עצום של יכולות חדשות, כולל:

  • צבירות: תמיכה בפונקציות צבירה חדשות (כמו sum(...), min(...) ו-count_distinct(...)) בשילוב עם שדות קיבוץ שרירותיים.
  • איחודים יחסיים: ביצוע איחודים בצד השרת בין אוספים ואוספי משנה באמצעות שאילתות משנה מתואמות.
  • סינון מורכב: תמיכה במאות פונקציות נוספות לביטוי הצהרות where(...) מורכבות באופן שרירותי, כולל regex_match(...),‏ add(...) ו-str_contains(...), והכול בלי דרישות אינדקס קשיחות.
  • קריאות חלקיות / השלכות: אחזור קבוצות משנה דינמיות של מסמכים באמצעות select(...),‏ remove_fields(...) ושלבים רבים אחרים של שינוי מסמכים.

במאמר שאילתות נתונים באמצעות פעולות בצינור עיבוד נתונים תוכלו לקרוא בהרחבה על היכולות האלה.

תמיכה בזמן אמת ובמצב אופליין

כדי להשתמש בתכונות "בזמן אמת" ו"אופליין", המפתחים יכולים להשתמש בפעולות של Firestore Core במהדורת Firestore Enterprise.

שילוב של לקוחות וכלים

מהדורת Enterprise כוללת תכונות מיוחדות לאינטראקציה עם שאילתות Pipeline ולניהול שלהן:

  • הסבר ופרופיילינג של שאילתות: אתם יכולים להשתמש בתוצאות של Query Explain כדי להבין כמה יחידות קריאה או כתיבה שאילתה צורכת, ולנתח את הביצוע שלה.
  • תובנות לגבי שאילתות: מהדורת Enterprise תומכת בתובנות לגבי שאילתות, שעוזרות לכם להבין איפה אפשר ליצור אינדקסים כדי לשפר את הביצועים והעלות. התובנות האלה מספקות תצוגה של השאילתות המובילות שמופעלות במסד הנתונים שלכם ומאפייני הביצועים שלהן.
  • סוגי אינדקסים חדשים: אתם יכולים ליצור אינדקסים ייעודיים למהדורת Enterprise, כולל סוגי אינדקסים כמו אינדקסים דלילים, לא דלילים וייחודיים. הוא גם תומך ביצירה ובעריכה של אינדקס החיפוש הווקטורי למסדי נתונים של Enterprise.

ההבדלים בין מהדורת Firestore Standard לבין מהדורת Firestore Enterprise

ההבדל התפעולי העיקרי בין פעולות ליבה לפעולות בצינור עיבוד נתונים הוא ניהול ההוספה לאינדקס, שמשפיע ישירות על הביצועים ועל העלות.

מהדורת Standard – פעולות ליבה מהדורת Enterprise – פעולות ליבה ופעולות בצינור עיבוד נתונים
דרישות להוספה לאינדקס אינדקסים נדרשים לשאילתות.

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

לא חובה להשתמש באינדקסים, ולכן הם אופציונליים לשאילתות.

אתם מגדירים אינדקסים לפי הצורך. במהדורת Enterprise יש גם תמיכה במגוון רחב יותר של סוגי אינדקסים, כולל אינדקסים ייחודיים ואינדקסים דלילים או לא דלילים.

שדות שנוספו לאינדקס אם השדה ‎__name__‎ לא קיים, הוא מתווסף אוטומטית לשדות שנוספו לאינדקס. השדה __name__ לא מתווסף באופן אוטומטי לשדות שנוספו לאינדקס. אם זה חשוב לאפליקציה, צריך לציין במפורש את __name__ בשדות שנוספו לאינדקס.
נרמול של סדר המיון סעיף order by של השאילתה עובר נרמול על ידי הוספת שדות אי-שוויון והשדה __name__‎ בסוף (אם הם עדיין לא קיימים). כך מובטח סדר ייחודי ודטרמיניסטי של התוצאות, בלי קשר לשדות האחרים שמופיעים בסעיף order by. אין נרמול של סדר המיון. סדר מיון כמו sort a ASC מבטיח רק שהתוצאות ימוינו לפי שדה a. ‫Cloud Firestore ישתמש באינדקסים הקיימים כדי להחזיר תוצאות בסדר היעיל ביותר. לכן, אם a לא ייחודי בקבוצת התוצאות, סדר התוצאות עשוי להשתנות משאילתה לשאילתה בהתאם להגדרת האינדקס, לאסטרטגיות הביצוע וכו'. כדי להבטיח סדר תוצאות ייחודי ודטרמיניסטי, צריך להוסיף שדה ייחודי כמו __name__‎ לסדר המיון.
ביצועים שאילתות שנוספו לאינדקס: הביצועים והעלות משתנים בהתאם לגודל של קבוצת התוצאות.

שאילתות ללא אינדקס: הביצועים והעלות משתנים בהתאם לגודל של מערך הנתונים.

שאילתות שנוספו לאינדקס: הביצועים והעלות משתנים בהתאם לגודל של קבוצת התוצאות.

מומלץ להשתמש בכלים Query Explain ו-Query Insights כדי ליצור אינדקסים ולשפר את הביצועים והעלות של השאילתות.

ההשלכות של עלות האחסון אתם צוברים תקורה של אחסון מאינדקסים אוטומטיים ומאינדקסים מורכבים. אתם חוסכים בעלויות האחסון כי לא נוצרים אינדקסים באופן אוטומטי לכל שדה.
בסיס עלות החיוב הוא על כל פעולת קריאה, כתיבה ומחיקה של מסמך. החיוב מתבצע לכל יחידת קריאה (מנות של 4KB) ויחידת כתיבה (מנות של 1KB). כתיבת רשומות באינדקס צורכת יחידות כתיבה.

מידע ולמידה על התמחור החדש עם כמה דוגמאות.

כללי אבטחה כללי אבטחה מגנים על אוספים על ידי אימות הרשאות קריאה/כתיבה. כללי אבטחה מגנים על אוספים על ידי אימות הרשאות קריאה/כתיבה. במדריך Data Model מוסבר איך ליצור מודל של הנתונים כדי לתמוך בשאילתות Pipeline.