להבין קריאה וכתיבה בקנה מידה

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

Cloud Firestore הוא מסד נתונים גמיש וניתן להרחבה לפיתוח מכשירים ניידים, אינטרנט ושרתים מ-Firebase ו-Google Cloud. קל מאוד להתחיל עם Cloud Firestore ולכתוב אפליקציות עשירות ועוצמתיות.

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

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

הבן את הרכיבים ברמה גבוהה

התרשים הבא מציג את הרכיבים ברמה גבוהה המעורבים בבקשת Cloud Firestore API.

Cloud Firestore SDK וספריות לקוח

Cloud Firestore תומך ב-SDK וספריות לקוחות עבור פלטפורמות שונות. בעוד שאפליקציה יכולה לבצע קריאות HTTP ו-RPC ישירות ל-Cloud Firestore API, ספריות הלקוח מספקות שכבה של הפשטה כדי לפשט את השימוש ב-API וליישם שיטות עבודה מומלצות. הם עשויים גם לספק תכונות נוספות כגון גישה לא מקוונת, מטמונים וכן הלאה.

Google Front End (GFE)

זהו שירות תשתית המשותף לכל שירותי הענן של גוגל. ה-GFE מקבל בקשות נכנסות ומעביר אותן לשירות Google הרלוונטי (שירות Firestore בהקשר זה). הוא מספק גם פונקציות חשובות אחרות, כולל הגנה מפני התקפות מניעת שירות.

שירות Cloud Firestore

שירות Cloud Firestore מבצע בדיקות לבקשת ה-API, הכוללת אימות, הרשאה, בדיקות מכסות וכללי אבטחה, וכן מנהל עסקאות. שירות Cloud Firestore זה כולל לקוח אחסון המקיים אינטראקציה עם שכבת האחסון עבור הקריאה והכתיבה של הנתונים.

שכבת אחסון Cloud Firestore

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

טווחי מפתח ופיצולים

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

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

שכפול סינכרוני

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

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

פריסת נתונים

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

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

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

אזור בודד לעומת רב ​​אזור

כאשר אתה יוצר מסד נתונים, עליך לבחור אזור או אזור מרובה .

מיקום אזורי יחיד הוא מיקום גיאוגרפי ספציפי, כמו us-west1 . לפיצולים של נתונים של מסד נתונים של Cloud Firestore יש העתקים באזורים שונים באזור שנבחר, כפי שהוסבר קודם לכן.

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

למידע נוסף על המיקומים של אזור, ראה מיקומי Cloud Firestore .

הבן את החיים של כתיבה ב-Cloud Firestore

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

עבור כל מיני כתיבה, Cloud Firestore מספקת את מאפייני ה-ACID (אטומיות, עקביות, בידוד ועמידות) של מסדי נתונים יחסיים. Cloud Firestore מספקת גם יכולת לסידרה , כלומר כל העסקאות נראות כאילו בוצעו בהזמנה סדרתית.

שלבים ברמה גבוהה בעסקת כתיבה

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

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

זה כולל גם ביצוע עדכונים נחוצים בטבלת האינדקסים כדלקמן:

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

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

ברגע שהמוטציות מחושבות, Cloud Firestore אוספת אותן בתוך עסקה ואז מבצעת אותה.

הבן עסקת כתיבה בשכבת האחסון

כפי שנדון קודם לכן, כתיבה ב-Cloud Firestore כוללת עסקת קריאה-כתיבה בשכבת האחסון. בהתאם לפריסת הנתונים, כתיבה עשויה לכלול פיצול אחד או יותר כפי שניתן לראות בפריסת הנתונים .

בתרשים הבא, למסד הנתונים של Cloud Firestore יש שמונה פיצולים (מסומנים 1-8) המתארחים בשלושה שרתי אחסון שונים באזור אחד, וכל פיצול משוכפל ב-3 (או יותר) אזורים שונים. לכל פיצול יש מנהיג Paxos, שעשוי להיות באזור אחר עבור פיצולים שונים.

שקול מסד נתונים של Cloud Firestore הכולל את אוסף Restaurants כדלקמן:

לקוח Cloud Firestore מבקש את השינוי הבא במסמך באוסף Restaurant על ידי עדכון הערך של השדה priceCategory .

השלבים הבאים ברמה הגבוהה מתארים מה קורה כחלק מהכתיבה:

1. צור עסקת קריאה-כתיבה.
2. קרא את מסמך restaurant1 באוסף Restaurants מטבלת המסמכים משכבת ​​האחסון.
3. קרא את האינדקסים של המסמך מטבלת האינדקסים .
4. חשב את המוטציות שיש לבצע בנתונים. במקרה זה, ישנן חמש מוטציות:
   • M1: עדכן את השורה עבור restaurant1 בטבלת המסמכים כדי לשקף את השינוי בערך של השדה priceCategory .
   • M2 ו-M3: מחק את השורות עבור הערך הישן של priceCategory בטבלת האינדקסים עבור אינדקסים יורדים ועולים.
   • M4 ו-M5: הכנס את השורות עבור הערך החדש של priceCategory בטבלת האינדקסים עבור אינדקסים יורדים ועולים.
5. לבצע את המוטציות האלה.

לקוח האחסון בשירות Cloud Firestore מחפש את הפיצולים שבבעלותם מפתחות השורות שיש לשנות. הבה נבחן מקרה שבו ספליט 3 משרת את M1, וספליט 6 משרת את M2-M5. יש עסקה מבוזרת, הכוללת את כל הפיצולים האלה כמשתתפים . פיצולי המשתתפים עשויים לכלול גם כל פיצול אחר שממנו נקראו נתונים קודם לכן כחלק מעסקת הקריאה-כתיבה.

השלבים הבאים מתארים מה קורה כחלק מההתחייבות:

1. לקוח האחסון מוציא commit. ה-commit מכיל את המוטציות M1-M5.
2. פיצולים 3 ו-6 הם המשתתפים בעסקה זו. אחד המשתתפים נבחר כמתאם , כגון פיצול 3. תפקידו של הרכז הוא לוודא שהעסקה מתחייבת או תבוטל מבחינה אטומית על פני כל המשתתפים.
   • העתקים של המנהיגים של הפיצולים הללו אחראים לעבודה שנעשתה על ידי המשתתפים והרכזים.
3. כל משתתף ורכז מפעיל אלגוריתם Paxos עם ההעתקים שלהם.
   • המנהיג מריץ אלגוריתם Paxos עם ההעתקים. המניין מושג אם רוב ההעתקים עונים עם ok to commit לתגובה למנהיג.
   • לאחר מכן כל משתתף מודיע לרכז כאשר הם מוכנים (שלב ראשון של התחייבות דו-שלבית). אם משתתף כלשהו אינו יכול לבצע את העסקה, העסקה כולה aborts .
4. ברגע שהרכז יודע שכל המשתתפים, כולל עצמו, מוכנים, הוא מעביר לכל המשתתפים את תוצאת accept (שלב שני של התחייבות דו-שלבית). בשלב זה, כל משתתף רושם את החלטת ההתחייבות לאחסון יציב והעסקה מתבצעת.
5. הרכז משיב ללקוח האחסון ב-Cloud Firestore שהעסקה בוצעה. במקביל, הרכז וכל המשתתפים מיישמים את המוטציות על הנתונים.

כאשר מסד הנתונים של Cloud Firestore קטן, עלול לקרות שפיצול יחיד מחזיק בכל המפתחות במוטציות M1-M5. במקרה כזה, יש רק משתתף אחד בעסקה ולא נדרשת ההתחייבות הדו-פאזית שהוזכרה קודם לכן, ובכך הופכת הכתיבה למהירה יותר.

כותב בריבוי אזורים

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

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

כל כתיבה ב-Cloud Firestore כרוכה גם באינטראקציה מסוימת עם המנוע בזמן אמת ב-Cloud Firestore. למידע נוסף על שאילתות בזמן אמת, ראה הבנת שאילתות בזמן אמת בקנה מידה .

הבן את החיים של קריאה ב-Cloud Firestore

חלק זה מתעמק בקריאה עצמאית שאינה בזמן אמת ב-Cloud Firestore. באופן פנימי, שרת Cloud Firestore מטפל ברוב השאילתות הללו בשני שלבים עיקריים:

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

עשויות להיות שאילתות מסוימות הדורשות פחות עיבוד או יותר עיבוד (לדוגמה, שאילתות IN) ב-Cloud Firestore.

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

הבן עסקת קריאה בשכבת האחסון

סעיף זה מתאר את סוגי הקריאה וכיצד הם מעובדים בשכבת האחסון ב-Cloud Firestore.

קריאה חזקה

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

קריאה של פיצול יחיד

לקוח האחסון ב-Cloud Firestore מחפש את הפיצולים שבבעלותם המפתחות של השורות שיש לקרוא. הבה נניח שהוא צריך לבצע קריאה מפיצול 3 מהסעיף הקודם . הלקוח שולח את בקשת הקריאה לעותק הקרוב ביותר כדי להפחית את זמן האחזור הלוך ושוב.

בשלב זה, המקרים הבאים עשויים להתרחש בהתאם לעתק הנבחר:

• בקשת הקריאה עוברת לעתק מוביל (אזור A).
  • מכיוון שהמנהיג תמיד מעודכן, הקריאה יכולה להמשיך ישירות.
• בקשת הקריאה עוברת לעתק שאינו מוביל (כגון, אזור B)
  • פיצול 3 עשוי לדעת לפי המצב הפנימי שלו שיש לו מספיק מידע כדי לשרת את הקריאה והפיצול עושה זאת.
  • פיצול 3 לא בטוח אם הוא ראה את הנתונים העדכניים ביותר. הוא שולח הודעה למנהיג כדי לבקש את חותמת הזמן של העסקה האחרונה שעליו להחיל כדי להגיש את הקריאה. לאחר החלת העסקה הזו, הקריאה יכולה להמשיך.

Cloud Firestore מחזירה את התגובה ללקוח שלה.

קריאה מרובה פיצולים

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

מעופש קורא

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

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

הימנע מנקודות חמות

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

פיצול אחסון ועומס לוקח זמן, והגברת התעבורה מהירה מדי עלולה לגרום לשגיאות זמן אחזור גבוה או חריגה מהמועד האחרון, המכונה בדרך כלל נקודות חמות , בזמן שהשירות מתכוונן. השיטה הטובה ביותר היא להפיץ פעולות על פני טווח המפתח, תוך הגברת התעבורה על אוסף במסד נתונים עם 500 פעולות בשנייה. לאחר העלייה הדרגתית זו, הגדל את התנועה בעד 50% כל חמש דקות. תהליך זה נקרא כלל 500/50/5 וממקם את מסד הנתונים לקנה מידה מיטבי כדי לעמוד בעומס העבודה שלך.

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

שגיאות מחלוקת קורות כאשר מספר פעולות מנסות לקרוא ו/או לכתוב את אותו מסמך בו-זמנית.

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

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

פתרון תקלות

Firestore מספקת את Key Visualizer ככלי אבחון שתוכנן במיוחד לניתוח דפוסי שימוש ופתרון בעיות של נקודות חמות.

מה הלאה

• קרא על שיטות עבודה מומלצות נוספות
• למד על שאילתות בזמן אמת בקנה מידה