ריבוי דיירים

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

היתרונות של ריבוי דיירים

‫Firestore במצב Datastore מאפשר לאפליקציה עם מספר דיירים להשתמש במאגרי נתונים נפרדים לכל דייר, ועדיין להשתמש ב:

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

מצב Datastore מאפשר ריבוי דיירים באמצעות מרחבי שמות.

ריבוי דיירים ונתונים שחולקו למחיצות

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

ציון מרחב שמות לישות

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

שימוש במרחבי שמות עם ישויות אב

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

תרחיש לדוגמה

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

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

Partition ID: project:"my_project_id"/namespace:"Joe"
Partition ID: project:"my_project_id"/namespace:"Alice"
Partition ID: project:"my_project_id"/namespace:"Charlie"

האפליקציה יכולה להגדיר מבנה לוגי מסוג Task באופן הבא, לשימוש בכל מרחבי השמות:

kind: Task
properties:
 - "done", Boolean
 - "created", DateTime
 - "description", String, excluded from index

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

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

  • ‫Task entities in the Joe namespace exclude the description property from the index
  • Task ישויות במרחב השמות Alice כוללות את המאפיין description מהאינדקס

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

הצגת מרחבי שמות במסוף

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

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

המאמרים הבאים