הטמעה של ריבוי דיירים ב-Spanner

בדף הזה מתוארות כמה דרכים להטמעת ריבוי דיירים ב-Spanner. בנוסף, מוסבר על דפוסי ניהול נתונים ועל ניהול מחזור החיים של הדייר. המאמר מיועד לארכיטקטים של מסדי נתונים, לארכיטקטים של נתונים ולמהנדסים שמטמיעים אפליקציות מרובות דיירים ב-Spanner כמסד הנתונים הרלציוני שלהם. בהתאם להקשר הזה, הוא מציג גישות שונות לאחסון נתונים של דיירים מרובים. המונחים 'דייר', 'לקוח' ו'ארגון' משמשים לסירוגין לאורך המאמר כדי לציין את הישות שיש לה גישה לאפליקציה מרובת דיירים. הדוגמאות שמופיעות בדף הזה מבוססות על הטמעה של אפליקציה מרובת דיירים של ספק SaaS של משאבי אנוש (HR) ב- Google Cloud. אחת הדרישות היא שלכמה לקוחות של ספק ה-HR SaaS תהיה גישה לאפליקציה מרובת הדיירים. הלקוחות האלה נקראים דיירים.

ריבוי דיירים

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

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

‫Spanner הוא מסד נתונים מנוהל באופן מלא, ברמה שמתאימה לארגונים, מבוזר ועקבי, שמשלב את היתרונות של מודל מסד הנתונים הרלציוני עם יכולת הרחבה אופקית לא יחסית. Google Cloud ל-Spanner יש סמנטיקה יחסית עם סכימות, סוגי נתונים נאכפים, מודל עקביות חזק, טרנזקציות ACID מרובות הצהרות ושפת שאילתות SQL שמיישמת ANSI 2011 SQL. ‫ הוא מספק אפס זמן השבתה לתחזוקה מתוכננת או לכשלים באזור, עם הסכם רמת שירות (SLA) לזמינות של 99.999%. בנוסף, Spanner תומך באפליקציות מודרניות עם ריבוי דיירים, ומספק זמינות גבוהה ומדרגיות.

קריטריונים למיפוי נתונים של דיירים

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

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

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

• בידוד נתונים: רמת הבידוד של הנתונים בין דיירים שונים היא שיקול חשוב מאוד בשימוש בגישה מרובת דיירים. לדוגמה, האם צריך להפריד את הנתונים באופן פיזי או לוגי, והאם יש רשימות בקרת גישה (ACL) עצמאיות שאפשר להגדיר לנתונים של כל דייר. הבידוד נובע מהבחירות שנעשו לגבי הקריטריונים בקטגוריות אחרות. לדוגמה, דרישות רגולטוריות ותאימות מסוימות עשויות להצריך רמת בידוד גבוהה יותר.
• גמישות: קלות ההצטרפות והיציאה של פעילויות לדייר בהקשר של יצירת מופע, מסד נתונים, טבלה או שורה.
• פעולות: הזמינות או המורכבות של יישום פעולות אופייניות, ספציפיות לדייר, של מסד נתונים ופעולות ניהול. לדוגמה, תחזוקה שוטפת, רישום ביומן, גיבויים או פעולות של תוכנית התאוששות מאסון (DR).
• התאמה להיקף: היכולת להרחיב את הפתרון בצורה חלקה כדי לאפשר צמיחה עתידית. התיאור של כל תבנית מכיל את מספר הדיירים שהתבנית יכולה לתמוך בהם.
• ביצועים:
  • בידוד משאבים: היכולת להקצות משאבים בלעדיים לכל דייר, לטפל בתופעת השכן הרועש ולאפשר ביצועי קריאה וכתיבה צפויים לכל דייר.
  • משאבים מינימליים לכל דייר: הכמות המינימלית הממוצעת של משאבים לכל דייר. זה לא בהכרח אומר שאתם צריכים לשלם לפחות את הסכום הזה עבור כל דייר בנפרד, אלא שאתם צריכים לשלם לפחות N כפול הסכום הזה עבור כל N הדיירים יחד.
  • יעילות המשאבים: היכולת להשתמש במשאבים לא פעילים של דיירים אחרים כדי לחסוך בעלויות הכוללות.
  • בחירת מיקום לאופטימיזציה של זמן האחזור: אפשר לבחור טופולוגיית שכפול ספציפית לכל דייר, כך שהנתונים של כל דייר יוצבו במיקום שבו זמן האחזור הכי טוב עבור הדייר.
• תקנות ותאימות: היכולת לעמוד בדרישות של תעשיות ומדינות מפוקחות מאוד, שבהן נדרשת הפרדה מוחלטת של משאבים ופעולות תחזוקה. לדוגמה, דרישות לגבי מיקום הנתונים בצרפת מחייבות שפרטים אישיים מזהים יאוחסנו פיזית רק בצרפת. בדרך כלל, בתעשיות הפיננסיות נדרשים מפתחות הצפנה בניהול הלקוח (CMEK), וכל דייר עשוי לרצות להשתמש במפתח הצפנה משלו.

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

דפוסי ניהול נתונים ב-Multi-tenancy

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

Instance

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

כפי שניתן לראות בדיאגרמה הבאה, בדפוס ניהול הנתונים יש דייר (tenant) אחד לכל מכונה.

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

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

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

לסיכום, המסקנות העיקריות הן:

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

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

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

מסד נתונים

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

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

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

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

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

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

לסיכום, המסקנות העיקריות הן:

• יתרון: רמה בינונית של בידוד נתונים ובידוד משאבים; רמה בינונית של יעילות משאבים; לכל דייר יכולה להיות גיבוי משלו ו-CMEK משלו.
• חיסרון: מספר מוגבל של דיירים לכל מופע; גמישות מוגבלת במיקום אם לא משתמשים בתכונת החלוקה הגיאוגרפית.

דפוס ניהול נתוני מסד הנתונים מתאים במיוחד לתרחישים הבאים:

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

טבלה

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

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

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

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

במקרה של אפליקציית משאבי אנוש, ספק ה-SaaS יכול ליצור קבוצה של טבלאות לכל לקוח עם tenant ID כקידומת בשמות הטבלאות. לדוגמה, customer1_employee, customer1_payroll ו-customer1_department. לחלופין, הם יכולים להשתמש במזהה הדייר כסכימה עם שם ולתת לטבלה את השם customer1.employee, customer1.payroll ו-customer1.department.

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

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

לסיכום, המסקנות העיקריות הן:

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

הדפוס של ניהול נתונים בטבלה מתאים במיוחד לתרחישים הבאים:

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

Row

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

במקרה של אפליקציית משאבי אנוש, המפתח הראשי של טבלת השכר יכול להיות שילוב של customerID ושל payrollID.

כפי שאפשר לראות בדיאגרמה הבאה, בדפוס ניהול נתוני השורות יש טבלה אחת לכמה דיירים (tenants).

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

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

לסיכום, המסקנות העיקריות הן:

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

הדפוס הזה מתאים במיוחד לתרחישים הבאים:

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

דפוסי ניהול נתונים וניהול מחזור החיים של הדייר

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

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

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

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

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

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

• תוכנית בחינם:

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

• רמה רגילה:

  • מתאים ללקוחות משלמים שאין להם דרישות חזקות במיוחד לגבי הרחבת היקף הפעילות או בידוד.
  • הדפוס של ניהול נתוני הטבלה או הדפוס של ניהול נתוני מסד הנתונים הם מועמדים טובים לרמה רגילה:
    • הטבלאות והאינדקסים הם בלעדיים לדייר.
    • הגיבוי פשוט בתבנית של ניהול נתונים במסד נתונים
    • אין תמיכה בגיבוי של נתונים בטבלה.
      • גיבוי של דייר (tenant) צריך להיות מיושם ככלי מחוץ ל-Spanner.

• מסלול Enterprise:

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

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

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

ניהול מחזור החיים של הדייר

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

• ייצוא נתוני הדייר:

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

• גיבוי נתונים של דיירים:

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

• העברת נתונים של דייר:

  • כדי להעביר דייר מדפוס אחד של ניהול נתונים לדפוס אחר (או להעביר דייר באותו דפוס של ניהול נתונים בין מופעים או מסדי נתונים), צריך לחלץ את הנתונים מדפוס אחד של ניהול נתונים ולהוסיף אותם לדפוס החדש של ניהול נתונים.

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

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

עיצוב אפליקציות

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

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

הגדרה של שאילתות וחיבורים דינמיים לדיירים

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

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

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

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

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

tenant id -> (data management pattern,
              database connection string)

נדרש עיצוב נוסף לדפוסי ניהול הנתונים של הטבלה והשורה.

דפוס לניהול נתונים בטבלה

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

אחת הגישות היא למקם את הטבלה של כל דייר במרחב שמות שנקרא על שם הדייר, ולציין את שם הטבלה באופן מלא באמצעות namespace.name. לדוגמה, אם אתם מציבים טבלה EMPLOYEE במרחב השמות T356 לדייר עם המזהה 356, האפליקציה שלכם יכולה להשתמש ב-T356.EMPLOYEE כדי להפנות את הבקשות לטבלה.

גישה נוספת היא להוסיף את מזהה הדייר לשמות הטבלאות. לדוגמה, הטבלה EMPLOYEE נקראת T356_EMPLOYEE בדייר עם המזהה 356. האפליקציה צריכה להוסיף לכל טבלה את הקידומת tenant ID לפני שליחת השאילתה למסד הנתונים שהמיפוי החזיר.

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

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

דפוס לניהול נתוני שורות

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

אחת הדרכים למצוא את הדייר המתאים היא להוסיף עמודה בשם TENANT לכל טבלה. כדי לשפר את הבידוד של הנתונים, ערך העמודה צריך להיות חלק מהמפתח הראשי. הערך בעמודה הוא tenant ID. לכל שאילתה צריך לצרף פרדיקט AND TENANT = tenant ID למשפט WHERE קיים או להוסיף משפט WHERE עם הפרדיקט AND TENANT = tenant ID.

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

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

יצירה ושיוך (Attribution) של שאילתות

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

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

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

בדפוס ניהול הנתונים במסד הנתונים או בדפוס ניהול הנתונים במופע, טקסט השאילתה לא מכיל פרטי דייר. כדי לקבל מידע על הדייר עבור הדפוסים האלה, צריך לשלוח שאילתה לטבלת המיפוי tenant-to-data-management-pattern.

יהיה קל יותר לנתח יומנים ושאילתות אם תהיה אפשרות לקבוע את הדייר עבור שאילתה מסוימת בלי לנתח את הטקסט של השאילתה. דרך אחת לזהות באופן אחיד דייר בשאילתה בכל דפוסי ניהול הנתונים היא להוסיף הערה לטקסט השאילתה עם tenant ID, ו (אופציונלית) עם label.

השאילתה הבאה בוחרת את כל נתוני העובדים עבור הדייר שמזוהה על ידי TENANT 356. כדי להימנע מניתוח תחביר ה-SQL וחילוץ מזהה הדייר מהפרדיקט, מזהה הדייר מתווסף כהערה. אפשר לחלץ תגובה בלי לנתח את תחביר ה-SQL.

SELECT * FROM EMPLOYEE
  -- TENANT 356
  WHERE TENANT = 'T356';

או

SELECT * FROM T356_EMPLOYEE;
  -- TENANT 356

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

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

SELECT * FROM T356_EMPLOYEE;
  -- {"TENANT": 356}

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

פעולות במחזור החיים של גישה לדייר

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

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

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

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

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

בידוד אפליקציות

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

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

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

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

ריבוי דיירים הוא דפוס חשוב של ניהול נתונים בעיצוב אפליקציות, במיוחד כששימוש יעיל במשאבים הוא חיוני. ‫Spanner תומך בכמה דפוסי ניהול נתונים – אפשר להשתמש בו להטמעה של אפליקציות מרובות דיירים. ‫ הוא מספק אפס זמן השבתה לתחזוקה מתוכננת או לכשלים באזור, עם הסכם רמת שירות (SLA) לזמינות של 99.999%. הוא תומך גם באפליקציות מודרניות עם מספר דיירים, ומספק זמינות גבוהה ויכולת הרחבה.