בדף הזה מוסבר על הממשקים השונים שזמינים לגישה לנתונים במסד נתונים במצב 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, ופעולות של תאימות ל-MongoDB ב-Firestore. |
| דרישות להוספה לאינדקס | כל השאילתות דורשות אינדקסים. | לא צריך אינדקסים כדי להריץ שאילתות. |
| יצירת אינדקס | אינדקסים אוטומטיים נוצרים לשדות בודדים. אפשר ליצור אינדקסים מורכבים באופן ידני. | לא נוצרים אינדקסים אוטומטיים. צריך לנהל את האינדקסים באופן ידני. |
| שדות באינדקס | אם השדה __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$למיליון יחידות קריאה. |