בדף הזה מוסבר על הממשקים השונים שזמינים לגישה לנתונים במסד נתונים במצב Native.
ממשקי הפעלה
במצב מקורי יש שני ממשקים לגישה לנתונים:
פעולות בצינור עיבוד הנתונים
ממשק השאילתות החדש יותר של Cloud Firestore. פעולות של פייפליינים תומכות בתחביר קומפוזבילי שמבוסס על שלבים. אתם יוצרים פעולה על ידי הגדרה של סדרה של שלבים עוקבים שמבוצעים לפי הסדר. כך אפשר לבצע פעולות מורכבות, כמו סינון לפי תוצאה של צבירה, שלא היה אפשר לבצע קודם בממשק המקורי (פעולות ליבה).
פעולות של פייפליין זמינות רק במהדורת Enterprise של Firestore, והן בשלב ההשקה של גרסת טרום-השקה (Preview).
פעילויות מרכזיות
פעילויות מרכזיות הן הממשק המקורי של Cloud Firestore.
פעולות ליבה משתמשות בתחביר של שרשור שיטות (.where(), .orderBy(), .get()) בהפניות למסמכים או לאוספים כדי לאחזר מסמכים.
סדר השלבים בשאילתה מרומז, והתמיכה בצבירה מוגבלת.
פעולות הליבה זמינות במהדורות Enterprise ו-Standard, אבל הגדרות ברירת המחדל של האינדקס שונות מאוד בין המהדורות. פרטים נוספים מופיעים בקטע הבא.
הבדלים בממשק בין המהדורות
עם השקת התמיכה במצב Native במהדורת Enterprise, אפשר להשתמש גם ב-Firestore Core וגם בפעולות Pipeline. כשמשתמשים בפעולות ליבה במהדורת Enterprise, ההתנהגות החדשה של האינדקס ומודל התמחור החדש מסירים הרבה מההגבלות של מהדורת Standard.
| Feature | מהדורת Standard | מהדורת Enterprise |
| פעולות נתמכות | הגישה מוגבלת לפעולות ליבה ב-Firestore. | תמיכה בפעולות של Firestore Core ו-Pipeline, ופעולות של תאימות Firestore ל-MongoDB. |
| דרישות להוספה לאינדקס | כל השאילתות דורשות אינדקסים. | לא צריך אינדקסים כדי להריץ שאילתות. |
| יצירת אינדקס | אינדקסים אוטומטיים נוצרים לשדות בודדים. אפשר ליצור אינדקסים מורכבים באופן ידני. | לא נוצרים אינדקסים אוטומטיים. צריך לנהל את האינדקסים באופן ידני. |
| שדות באינדקס | אם השדה __name__ לא קיים, הוא יצורף אוטומטית לשדות המאונדקסים. | הפרמטר __name__ לא מצורף אוטומטית לשדות שנוספו לאינדקס. אם חשוב לכם שהשם __name__ יופיע בשדות המאונדקסים, אתם צריכים לציין אותו במפורש. |
| נרמול של סדר המיון | סעיף ה-order by של השאילתה עובר נרמול על ידי הוספת שדות אי-שוויון ושדה __name__ בסוף (אם הם לא כבר קיימים). כך מובטח סדר ייחודי ודטרמיניסטי של התוצאות, ללא קשר לשדות אחרים שנכללים בסעיף order by. | אין נירמול של סדר המיון. סדר מיון כמו sort a ASC מבטיח רק שהתוצאות ימוינו לפי השדה a. Cloud Firestore ישתמש באינדקסים הקיימים כדי להחזיר תוצאות בסדר היעיל ביותר האפשרי. לכן, אם הערך a לא ייחודי בקרב קבוצת התוצאות, סדר התוצאות עשוי להשתנות משאילתה לשאילתה בהתאם להגדרת האינדקס, לאסטרטגיות הביצוע וכו'. כדי להבטיח סדר ייחודי ודטרמיניסטי של התוצאות, צריך להוסיף לשדה המיון שדה ייחודי כמו __name__. |
| ביצועי שאילתות ועלות | השאילתות בדרך כלל יעילות בגלל דרישות האינדקס. | כדי לשפר את ביצועי השאילתות ולהוזיל את העלויות, כדאי ליצור אינדקסים. אפשר לזהות אינדקסים חסרים באמצעות Query Explain ו-Query Insights.
שאילתות ללא אינדקסים עלולות להיות לא יעילות ויקרות ככל שמערך הנתונים גדל, ולכן נדרשים מעקב וכוונון. |
| עלות תקורה של יצירת אינדקס | אין חיוב על כתיבה לאינדקסים, כי האינדקסים הם אוטומטיים. | כתיבת רשומות באינדקס צורכת יחידות כתיבה כשמסמך משויך נכתב (יחידת כתיבה אחת לכל 1KiB של גודל רשומה באינדקס). כדי לחסוך בעלויות האחסון, לא צריך ליצור רשומות אינדקס לכל שדה. |
| מודל חיוב (קריאות/כתיבות/מחיקות) | החיוב הוא על כל קריאה, כתיבה ומחיקה של מסמך. | החיוב הוא על כל קריאה וכתיבה (חלוקה). החיוב על קריאות מתבצע ביחידות קריאה (מנות של 4KiB). פעולות כתיבה ומחיקה מאוחדות ליחידות כתיבה (במנות של 1KiB). |
| תמחור בסיסי (למיליון)
המחירים שמוצגים הם לאזור us-central1 |
קריאות: 0.03$ לכל 100,000 מסמכים (או 0.30 $ למיליון).
כתיבה: 0.09$ לכל 100,000 מסמכים (או 0.90 $ לכל מיליון). מחיקות: 0.01$ לכל 100,000 מסמכים (או 0.10 $ לכל מיליון) |
קריאת יחידות: $0.05 למיליון יחידות קריאה.
יחידות כתיבה: $0.26 למיליון יחידות כתיבה. המחירים בדרך כלל נמוכים יותר אם המסמכים קטנים מ-4KiB בהשוואה לעלות הקריאה הרגילה. |
| עדכונים בזמן אמת
המחירים שמוצגים הם לאזור us-central1 |
עדכונים בזמן אמת נכללים בחיוב כקריאות במחיר של 0.03 $ל-100,000 מסמכים. | לעדכונים בזמן אמת יש מק"ט חדש ונפרד (יחידות של עדכונים בזמן אמת), והחיוב הוא על כל 4KiB. העלות של עדכונים בזמן אמת היא 0.30$למיליון יחידות קריאה. |