הטמעה של ריבוי דיירים ב-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, עם מסד נתונים אחד בדיוק לאותו דייר.
• מסד נתונים: דייר נמצא במסד נתונים במופע יחיד של Spanner שמכיל כמה מסדי נתונים.
• טבלה: דייר נמצא בטבלאות בלעדיות במסד נתונים, ויכולים להיות כמה דיירים באותו מסד נתונים.
• שורה: נתוני הדייר הם שורות בטבלאות של מסד הנתונים. הטבלאות האלה משותפות עם דיירים אחרים.

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

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

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

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

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

Instance

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

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

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

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

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

קריטריונים	מופע – דפוס ניהול נתונים של דייר אחד לכל מופע
בידוד נתונים	רמת הבידוד הגבוהה ביותר של הנתונים אחסון הנתונים מופרד פיזית הרשאות ACL ניתנות בנפרד לכל מופע
Agility	הוספה והסרה של משתמשים דורשות הגדרה או ביטול של: מכונת Spanner אבטחה ספציפית למופע קישוריות ספציפית למכונה אפשר להפוך את תהליכי ההצטרפות והעזיבה לאוטומטיים באמצעות תשתית כקוד (IaC)
תפעול	גיבויים נפרדים לכל דייר תזמוני גיבוי נפרדים וגמישים תקורה תפעולית גבוהה יותר מספר גדול של מופעים לניהול ולתחזוקה (שינוי קנה מידה, מעקב, רישום ביומן וכוונון ביצועים)
להתכונן להתרחבות	מסד נתונים עם יכולת התאמה רחבה צמיחה בלתי מוגבלת על ידי הוספת צמתים מספר בלתי מוגבל של דיירים מכונת Spanner זמינה לכל דייר
ביצועים	בידוד משאבים: אין תחרות על משאבים משאבים מינימליים לכל דייר: משאב מינימלי לכל דייר הוא צומת אחד אם משתמשים במופע גדול יותר, ו-100 יחידות PU (1/10 צמתים) אם משתמשים במופע גרנולרי יעילות המשאבים: אי אפשר להשתמש במשאבים לא פעילים של דיירים אחרים בחירת מיקום לאופטימיזציה של זמן האחזור: צריך להציב כל דייר במופע נפרד ולהתאים אישית את טופולוגיית השכפול לכל דייר
דרישות רגולטוריות ודרישות תאימות	אחסון נתונים באזור ספציפי הטמעה של תהליכי אבטחה, גיבוי או ביקורת ספציפיים לפי הדרישות של עסקים או ממשלות

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

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

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

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

מסד נתונים

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

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

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

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

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

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

קריטריונים	מסד נתונים – דייר אחד לכל תבנית של ניהול נתונים במסד נתונים
בידוד נתונים	בידוד לוגי מלא ברמת מסד הנתונים אחסון הנתונים מופרד פיזית אפשר להעניק ACL לכל מסדי הנתונים במופע, או להעניק אותם בנפרד לכל מסד נתונים.
Agility	נדרש מאמץ כדי ליצור או למחוק את מסד הנתונים ואמצעי בקרה ספציפיים לאבטחה אוטומציה להוספה ולהסרה של משתמשים מתבצעת באמצעות תשתית כקוד (IaC)
תפעול	גיבויים נפרדים לכל דייר תזמוני גיבוי נפרדים וגמישים תקורה תפעולית נמוכה יותר בהשוואה לדפוס המופע מופע אחד למעקב אחרי עד 100 מסדי נתונים
להתכונן להתרחבות	מסד נתונים עם יכולת התאמה רחבה מגבלה של 100 מסדי נתונים לכל מופע. לכל 100 דיירים, יוצרים מכונה חדשה של Spanner. מספר בלתי מוגבל של מופעים מספר בלתי מוגבל של צמתים לכל מופע
ביצועים	בידוד משאבים: התנגשות בין כמה מסדי נתונים מסדי נתונים שמתפרסים על צמתים של מכונות Spanner מסדי נתונים חולקים תשתית שכנים רועשים משפיעים על הביצועים משאבים מינימליים לכל דייר: יש מגבלה של 100 מסדי נתונים לכל מופע, ולכן קיבולת החישוב המינימלית ל-100 מסדי נתונים (או 100 דיירים) היא צומת אחד. גם במקרים של מופעים גרנולריים, קיבולת החישוב המינימלית לכל 100 דיירים היא עדיין צומת אחד. למרות שכל מופע גרנולרי יכול להשתמש ב-100 יחידות עיבוד בלבד, Spanner מאפשר רק מגבלה של 10 מסדי נתונים לכל 100 יחידות עיבוד. יעילות המשאבים: דיירים חולקים את המשאבים של מופע אחד. דיירים יכולים להשתמש במשאבים לא פעילים של דיירים אחרים. בחירת מיקום לאופטימיזציה של זמן האחזור: אם אתם לא משתמשים בתכונת החלוקה הגיאוגרפית, המיקום של מסד הנתונים זהה להגדרת המופע. אי אפשר להתאים אישית את המיקום של מסד הנתונים לכל דייר. עם זאת, אם אתם משתמשים בתכונה של חלוקה גיאוגרפית, אתם יכולים ליצור מחיצות של מופעים במיקומים שונים, ולמקם נתונים במיקומים שונים באמצעות מפתח למיקום שורה. שימוש בחלוקה גיאוגרפית משפר את זמן האחזור לכל דייר.
דרישות רגולטוריות ודרישות תאימות	אם אתם לא משתמשים בתכונה של חלוקה גיאוגרפית, המיקום של מסדי הנתונים זהה להגדרת המופע, כדי לעמוד בדרישות הרגולטוריות בנוגע למיקום הנתונים. עם זאת, אם אתם משתמשים בתכונה של חלוקה גיאוגרפית, אתם יכולים ליצור מחיצות של מופעים במיקומים שונים, ולמקם נתונים במיקומים שונים באמצעות מפתח מיקום לכל שורה. כל מסד נתונים יכול להשתמש במפתח CMEK משלו להצפנת נתונים.

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

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

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

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

טבלה

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

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

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

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

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

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

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

קריטריונים	טבלה – קבוצה אחת של טבלאות לכל דפוס של ניהול נתונים של דייר
בידוד נתונים	רמה בינונית של בידוד נתונים. הנתונים מופרדים באופן לוגי, אבל יכולים להיות מאוחסנים פיזית באותו קובץ באחסון מתמיד. רשימות ACL משותפות כברירת מחדל, אבל אפשר להעניק אותן בנפרד באמצעות בקרת גישה פרטנית (FGAC).
Agility	נדרש מאמץ כדי ליצור או למחוק את הטבלאות החדשות, את האינדקסים המשויכים ואת אמצעי הבקרה של האבטחה שנוצרו באמצעות FGAC הסרת לקוח מהמערכת פירושה מחיקת טבלאות יכולה להיות השפעה זמנית שלילית על הביצועים של דיירים אחרים במסד הנתונים
תפעול	אין פעולות נפרדות לדיירים גיבוי, מעקב ורישום ביומן צריכים להיות מוטמעים כפונקציות נפרדות של האפליקציה או כסקריפטים של כלי עזר
להתכונן להתרחבות	בכל מסד נתונים יכולות להיות עד 5,000 טבלאות רק 5,000/<number tables for tenant> מספר דיירים בכל מסד נתונים אם במסד הנתונים יש יותר מ-5,000 טבלאות, צריך להוסיף מסד נתונים חדש לדיירים הנוספים.
ביצועים	בידוד משאבים: משאבי תשתית בסיסיים משותפים. יכול להיות שיהיה מאבק על משאבים. שכנים רועשים משפיעים על הביצועים. משאבים מינימליים לכל דייר: יש מגבלה של 100 מסדי נתונים לכל מופע ו-5,000 טבלאות לכל מסד נתונים, ולכן קיבולת המחשוב המינימלית שנדרשת ל-500,000 דיירים היא צומת אחד. יעילות המשאבים: דיירים חולקים את המשאבים של מופע אחד. כל דייר יכול להשתמש במשאב לא פעיל מדיירים אחרים. בחירת מיקום לאופטימיזציה של זמן האחזור: אם אתם לא משתמשים בתכונת החלוקה הגיאוגרפית, המיקום של מסד הנתונים זהה להגדרת המופע. אי אפשר להתאים אישית את המיקום של מסד הנתונים לכל דייר. עם זאת, אם אתם משתמשים בתכונה של חלוקה גיאוגרפית, אתם יכולים ליצור מחיצות של מופעים במיקומים שונים, ולמקם נתונים במיקומים שונים באמצעות מפתח למיקום שורה. שימוש בחלוקה גיאוגרפית משפר את זמן האחזור לכל דייר.
דרישות רגולטוריות ודרישות תאימות	אם אתם לא משתמשים בתכונה של חלוקה גיאוגרפית, המיקום של מסדי הנתונים זהה להגדרת המופע, כדי לעמוד בדרישות הרגולטוריות בנוגע למיקום הנתונים. עם זאת, אם אתם משתמשים בתכונה של חלוקה גיאוגרפית, אתם יכולים ליצור מחיצות של מופעים במיקומים שונים, ולמקם נתונים במיקומים שונים באמצעות מפתח מיקום לכל שורה. בכל אזור, טבלאות שונות באותו מסד נתונים צריכות להשתמש באותו CMEK להצפנת נתונים.

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

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

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

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

Row

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

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

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

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

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

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

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

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

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

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

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

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

	Instance	מסד נתונים	טבלה	Row
בידוד נתונים	הושלמה	גבוהה	בינוני	נמוכה
גמישות	נמוכה	בינוני	בינוני	הכי גבוה
קלות התפעול	גבוהה	גבוהה	נמוכה	נמוכה
קנה מידה	גבוהה	מוגבל (אלא אם משתמשים במופעים נוספים כשמגיעים למגבלה)	מוגבלת (אלא אם משתמשים במסדי נתונים נוספים כשמגיעים למגבלה)	הכי גבוה
ביצועים^1 – בידוד משאבים	גבוהה	נמוכה	נמוכה	נמוכה
ביצועים^1 – משאבים מינימליים לכל דייר	גבוהה	בינוני גבוה	בינוני	אין מינימום לכל דייר
ביצועים^1 – יעילות המשאבים	נמוכה	גבוהה	גבוהה	גבוהה
‫Performance^1 – בחירת מיקום לאופטימיזציה של זמן האחזור	גבוהה	בינוני	בינוני	בינוני
תקנות ותאימות	הכי גבוה	גבוהה	בינוני	נמוכה

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

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

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

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

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

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

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

• רמה רגילה:

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

• מסלול Enterprise:

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

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

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

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

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

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

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

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

  • כשמשתמשים בתבנית לניהול נתונים של מופע או מסד נתונים ומגבים נתונים של דיירים ספציפיים, צריך להשתמש בפונקציות הייצוא או הגיבוי של מסד הנתונים.
  • כשמשתמשים בתבנית לניהול נתונים של טבלה או שורה ומגבים נתונים של דיירים ספציפיים, האפליקציה מרובת הדיירים צריכה להטמיע את הפעולה הזו. מסד הנתונים של 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%. הוא גם תומך באפליקציות מודרניות עם דיירים מרובים, ומספק זמינות גבוהה ויכולת הרחבה.