במסמך הזה מתוארות ארכיטקטורות פריסה, תרחישים לדוגמה ושיטות מומלצות לניהול מסדי נתונים מרובי-ענן. הוא מיועד לארכיטקטים ולמהנדסים שתפקידם לתכנן וליישם אפליקציות עם שמירת מצב בענן אחד או בכמה עננים.
ארכיטקטורות של אפליקציות מרובות עננים עם גישה למסדי נתונים תלויות בתרחיש השימוש. אין ארכיטקטורה של אפליקציה עם שמירת מצב שיכולה לתמוך בכל תרחישי השימוש של multicloud. לדוגמה, פתרון מסד הנתונים הטוב ביותר לתרחיש לדוגמה של cloud bursting שונה מפתרון מסד הנתונים הטוב ביותר לאפליקציה שפועלת בו-זמנית בסביבות ענן מרובות.
בעננים ציבוריים כמו Google Cloud, יש טכנולוגיות שונות של מסדי נתונים שמתאימות לתרחישי שימוש ספציפיים של ריבוי עננים. כדי לפרוס אפליקציה בכמה אזורים בענן ציבורי יחיד, אפשר להשתמש במסד נתונים ציבורי שמנוהל על ידי ספק הענן וממוקם במספר אזורים, כמו Spanner. כדי לפרוס אפליקציה שניתן להעביר בין עננים ציבוריים, יכול להיות שעדיף לבחור במסד נתונים בלתי תלוי בפלטפורמה, כמו AlloyDB Omni או PostgreSQL.
במסמך הזה מוגדרת אפליקציית מסד נתונים עם שמירת מצב, ובהמשך מופיע ניתוח של תרחיש שימוש במסד נתונים מרובה עננים. לאחר מכן, המערכת מציגה סיווג מפורט של מערכות מסדי נתונים לארכיטקטורות של פריסות בענן מרובה, על סמך תרחישי השימוש.
במסמך מוצג גם עץ החלטות לבחירת מסדי נתונים, שבו מפורטות נקודות ההחלטה העיקריות לבחירת טכנולוגיה מתאימה של מסד נתונים. בסיום הקורס יש דיון על שיטות מומלצות לניהול מסדי נתונים בסביבת מרובה עננים.
מונחים והגדרות חשובים
בקטע הזה מוסבר על המינוח ומוגדרת אפליקציית מסד הנתונים הגנרית עם שמירת מצב שמשמשת במסמך הזה.
הסברים על המונחים
- ענן ציבורי. ענן ציבורי מספק תשתית (בדרך כלל גלובלית) ושירותים שמשותפים לכמה לקוחות, והלקוחות יכולים להשתמש בהם כדי להריץ את עומסי העבודה של הייצור שלהם. Google Cloud הוא ענן ציבורי שמספק הרבה שירותים מנוהלים, כולל GKE ומסדי נתונים מנוהלים.
- ענן היברידי. ענן היברידי הוא שילוב של ענן ציבורי עם מרכז נתונים אחד או יותר בארגון. לקוחות של ענן היברידי יכולים לשלב בין השירותים המקומיים שלהם לבין שירותים נוספים שמסופקים על ידי ענן ציבורי.
- Multicloud. סביבה מרובת-עננים היא שילוב של כמה עננים ציבוריים ומרכזי נתונים מקומיים. ענן היברידי הוא תת-קבוצה של מרובה עננים.
- מיקום הפריסה. מיקום תשתית הוא מיקום פיזי שבו אפשר לפרוס ולהפעיל עומסי עבודה, כולל אפליקציות ומסדי נתונים. לדוגמה, ב- Google Cloud, מיקומי הפריסה הם אזורים ותחומים. ברמה המופשטת, אזור או תחום בענן ציבורי ומרכז נתונים מקומי הם מיקומי פריסה.
אפליקציות של מסדי נתונים עם שמירת מצב
כדי להגדיר תרחישי שימוש במרובה עננים (multi-cloud), במסמך הזה נעשה שימוש בארכיטקטורה כללית של אפליקציית מסד נתונים עם שמירת מצב, כמו שמוצג בתרשים הבא.
בתרשים מוצגים הרכיבים הבאים:
- מסד נתונים. מסד נתונים יכול להיות מופע יחיד, מופע מרובה או מסד נתונים מבוזר, שנפרס בצמתים של מחשוב או זמין כשירות מנוהל בענן.
- שירותי אפליקציות. השירותים האלה משולבים כאפליקציה שמיישמת את הלוגיקה העסקית. שירותי האפליקציה יכולים להיות כל אחת מהאפשרויות הבאות:
- מיקרו-שירותים ב-Kubernetes.
- תהליכים גסים שפועלים במכונה וירטואלית אחת או יותר.
- אפליקציה מונוליתית במכונה וירטואלית גדולה אחת.
- קוד Serverless ב-פונקציות Cloud Run או ב-Cloud Run. חלק משירותי האפליקציות יכולים לגשת למסד הנתונים. אפשר לפרוס כל שירות אפליקציה כמה פעמים. כל פריסה של שירות אפליקציה היא מופע של שירות האפליקציה הזה.
- אפליקציות לקוח. לקוחות של אפליקציות ניגשים לפונקציונליות שמסופקת על ידי שירותי האפליקציה. לקוחות אפליקציות יכולים להיות אחד מהסוגים הבאים:
- לקוחות שפריסתם בוצעה, שבהם הקוד פועל במחשב, במחשב נייד או בטלפון נייד.
- לקוחות שלא נפרסו, שבהם קוד הלקוח פועל בדפדפן. מופעים של לקוחות אפליקציות תמיד ניגשים למופע אחד או יותר של שירותי אפליקציות.
בדיון על מסד נתונים מרובה עננים, ההפשטה הארכיטקטונית של אפליקציה עם מצב כוללת מסד נתונים, שירותי אפליקציה ולקוחות אפליקציה. בהטמעה של אפליקציה, יכולים להיות הבדלים בין גורמים כמו מערכות ההפעלה או שפות התכנות שבהן נעשה שימוש. עם זאת, הפרטים האלה לא משפיעים על ניהול מסדי נתונים מרובי עננים.
תורים וקבצים כשירותי אחסון נתונים
יש הרבה משאבי אחסון נתונים שזמינים לשירותי אפליקציות. המשאבים האלה כוללים מסדי נתונים, תורים וקבצים. כל משאב של אחסון נתונים מספק מודלים של אחסון נתונים ודפוסי גישה שמותאמים במיוחד למודלים האלה. אף על פי שאפליקציות משתמשות בתורים, במערכות העברת הודעות ובמערכות קבצים, בחלק הבא נתמקד במסדי נתונים.
למרות שאותם שיקולים לגבי גורמים כמו מיקום הפריסה, שיתוף מצב, שכפול סינכרוני ואסינכרוני של מסדי נתונים מרובי-ענן רלוונטיים לתורים ולקבצים, הדיון הזה לא נכלל במסגרת המסמך הזה.
Networking
בארכיטקטורה של אפליקציה כללית עם שמירת מצב (שמוצגת שוב בתרשים הבא), כל חץ בין הרכיבים מייצג קשר תקשורת דרך חיבור לרשת – לדוגמה, לקוח של אפליקציה ניגש לשירות של אפליקציה.
החיבור יכול להיות בתוך אזור או בין אזורים, בין אזורים או בין עננים. יכולים להיות קשרים בין כל שילוב של מיקומי פריסה. בסביבות מרובות עננים, רשתות בין עננים הן שיקול חשוב, ויש כמה אפשרויות שבהן אפשר להשתמש. מידע נוסף על רשתות בענן זמין במאמרים רשתות חוצות ענן לאפליקציות מבוזרות וConnecting to Google Cloud: your networking options explained.
בתרחישי השימוש במסמך הזה, ההנחה היא:
- קיים חיבור מאובטח לרשת בין העננים.
- המסדי נתונים והרכיבים שלהם יכולים לתקשר ביניהם.
מבחינה לא פונקציונלית, גודל הרשת, כלומר התפוקה וזמן האחזור, עשוי להשפיע על זמן האחזור והתפוקה של מסד הנתונים. מבחינה פונקציונלית, בדרך כלל אין השפעה לרשת.
תרחישי שימוש במסדי נתונים מרובי-ענן
בקטע הזה מוצג מבחר של תרחישים לדוגמה נפוצים לניהול מסדי נתונים מרובי-ענן. בתרחישי השימוש האלה, ההנחה היא שיש קישוריות מאובטחת לרשת בין העננים וצמתי מסד הנתונים.
העברת אפליקציות
בהקשר של ניהול מסדי נתונים בענן מרובה, העברת אפליקציות מתייחסת להעברה של אפליקציה, כל שירותי האפליקציה ומסד הנתונים מהענן הנוכחי לענן היעד. יש הרבה סיבות לכך שארגון עשוי להחליט להעביר אפליקציה, למשל כדי להימנע ממצב תחרותי עם ספק שירותי הענן, כדי לחדש את הטכנולוגיה או כדי להפחית את עלות הבעלות הכוללת (TCO).
בהעברת אפליקציות, המטרה היא להפסיק את הייצור בענן הנוכחי ולהמשיך את הייצור בענן היעד אחרי שההעברה תושלם. שירותי האפליקציות צריכים לפעול בענן היעד. כדי להטמיע את השירותים, אפשר להשתמש בגישת העברה והפעלה. בגישה הזו, אותו קוד נפרס בענן היעד. כדי להטמיע מחדש את השירות, אפשר להשתמש בטכנולוגיות ענן מודרניות שזמינות בענן היעד.
מנקודת מבט של מסד נתונים, כדאי לשקול את האפשרויות החלופיות הבאות להעברת אפליקציות:
- השבתה, שכפול ומיגרציה של מסד נתונים לענן (lift and shift): אם מנוע מסד הנתונים זהה לזה שזמין בענן היעד, אפשר להשתמש בשיטה הזו כדי ליצור פריסה זהה בענן היעד.
- העברה של מסד נתונים לגרסה מקבילה מנוהלת: אפשר להעביר מסד נתונים שמנוהל באופן עצמי לגרסה מנוהלת של אותו מנוע מסד נתונים, אם ענן היעד מספק אותה.
- מודרניזציה של מסדי נתונים: עננים שונים מציעים טכנולוגיות שונות של מסדי נתונים. למסדי נתונים שמנוהלים על ידי ספק שירותי ענן יכולים להיות יתרונות כמו הסכמי רמת שירות (SLA) מחמירים יותר, מדרגיות ותוכנית התאוששות אוטומטית מאסון.
לא משנה מהי אסטרטגיית הפריסה, העברת מסד נתונים היא תהליך שלוקח זמן כי צריך להעביר נתונים מהענן הנוכחי לענן היעד. אפשר לייצא את הנתונים ואז לייבא אותם, אבל התהליך הזה כרוך בהשבתה. לכן, עדיף לבצע העברה עם זמן השבתה מינימלי או ללא זמן השבתה. הגישה הזו מצמצמת את זמן ההשבתה של האפליקציה ומשפיעה הכי פחות על הארגון ועל הלקוחות שלו. עם זאת, בדרך כלל נדרשת הגדרת העברה מורכבת יותר, כי היא כוללת טעינה ראשונית, שכפול מתמשך, מעקב, אימות גרנולרי וסנכרון בעת המעבר. כדי לתמוך בתרחישי חזרה למצב הקודם, צריך להטמיע מנגנון שכפול הפוך כדי לסנכרן את השינויים בחזרה למסד הנתונים של המקור אחרי המעבר למסד הנתונים של היעד.
תוכנית התאוששות מאסון (DR)
התאוששות מאסון היא היכולת של אפליקציה להמשיך לספק שירותים ללקוחות האפליקציה במהלך הפסקה זמנית בשירות באזור. כדי להבטיח התאוששות מאסון, צריך לפרוס אפליקציה לפחות בשני אזורים ולהיות מוכנים להפעלה בכל רגע. בסביבת הייצור, האפליקציה פועלת באזור הראשי. עם זאת, אם מתרחשת הפסקה זמנית בשירות, אזור משני הופך לאזור הראשי. אלה מודלים שונים של מוכנות להתאוששות מאסון:
- המתנה פעילה. האפליקציה נפרסת בשני אזורים או יותר (ראשי ומשני), והיא פועלת באופן מלא בכל אזור. אם האזור הראשי נכשל, האפליקציה באזור המשני יכולה לקבל תנועת לקוחות של האפליקציה באופן מיידי.
- המתנה קרה. האפליקציה פועלת באזור הראשי, אבל היא מוכנה להפעלה באזור משני (אבל לא פועלת). אם האזור הראשי נכשל, האפליקציה מופעלת באזור המשני. הפסקה זמנית בשירות של אפליקציה מתרחשת עד שהאפליקציה יכולה לפעול ולספק את כל שירותי האפליקציה ללקוחות האפליקציה.
- אין המתנה. במודל הזה, קוד האפליקציה מוכן לפריסה אבל עדיין לא נפרס באזור המשני (ולכן לא נעשה שימוש במשאבים שנפרסו). אם יש הפסקת חשמל באזור הראשי, הפריסה הראשונה של האפליקציה חייבת להיות באזור המשני. הפריסה הזו מעבירה את האפליקציה למצב זהה למצב המתנה לא פעילה (cold standby), כלומר צריך להפעיל אותה. בגישה הזו, משך ההשבתה של האפליקציה ארוך יותר בהשוואה לתרחיש של המתנה קרה, כי צריך קודם לפרוס את האפליקציה, כולל יצירת משאבי ענן.
מנקודת מבט של מסד נתונים, מודלים של מוכנות שמוזכרים ברשימה הקודמת תואמים לגישות הבאות למסד נתונים:
- מסד נתונים שמסונכרן ברמת העסקה. מסד הנתונים הזה תואם למודל של המתנה פעילה. כל טרנזקציה באזור הראשי מאושרת בתיאום סינכרוני באזור משני. כשמתרחשת הפסקה זמנית בשירות והאזור המשני הופך לאזור הראשי, מסד הנתונים עקבי וזמין באופן מיידי. במודל הזה, היעד להתאוששות מאסון (RPO) והיעד להתאוששות (RTO) הם אפס.
- מסד נתונים שמשוכפל באופן אסינכרוני. מסד הנתונים הזה תואם גם למודל של המתנה פעילה. הרפליקציה של מסד הנתונים מהאזור הראשי לאזור המשני היא אסינכרונית, ולכן יכול להיות שאם האזור הראשי ייכשל, חלק מהעסקאות ישוכפלו לאזור המשני. המסד נתונים באזור המשני מוכן לעומס ייצור, אבל יכול להיות שהנתונים בו לא יהיו עדכניים. לכן, האפליקציה עלולה לגרום לאובדן של טרנזקציות שלא ניתן לשחזר. בגלל הסיכון הזה, הגישה הזו כוללת זמן שחזור (RTO) של אפס, אבל נקודת השחזור (RPO) גדולה מאפס.
- מסד נתונים במצב סרק. מסד הנתונים הזה תואם למודל של המתנה קרה. מסד הנתונים נוצר ללא נתונים. אם האזור הראשי נכשל, צריך לטעון את הנתונים למסד הנתונים במצב המתנה. כדי לבצע את הפעולה הזו, צריך לבצע גיבוי רגיל באזור הראשי ולהעביר אותו לאזור המשני. הגיבוי יכול להיות מלא או מצטבר, בהתאם למה שהמנוע של מסד הנתונים תומך בו. בכל מקרה, מסד הנתונים חוזר לגיבוי האחרון, ומנקודת המבט של האפליקציה, יכול להיות שייאבדו הרבה טרנזקציות בהשוואה לאזור הראשי. הגישה הזו עשויה להיות חסכונית, אבל הערך שלה מוגבל בגלל הסיכון שכל העסקאות מאז הגיבוי האחרון יאבדו כי מצב מסד הנתונים לא עדכני.
- ללא מסד נתונים. המודל הזה שווה למקרה ללא המתנה. באזור המשני לא מותקן מסד נתונים, ואם האזור הראשי נכשל, צריך ליצור מסד נתונים. אחרי שיוצרים את מסד הנתונים, כמו במקרה של מסד נתונים במצב סרק, צריך לטעון אותו בנתונים לפני שהוא זמין לאפליקציה.
הגישות להתאוששות מאסון שמתוארות במסמך הזה רלוונטיות גם אם משתמשים בענן ראשי ובענן משני במקום באזור ראשי ובאזור משני. ההבדל העיקרי הוא שבגלל ההטרוגניות של הרשת בין העננים, זמן האחזור בין העננים עשוי להיות ארוך יותר בהשוואה למרחק ברשת בין אזורים בענן. פערים אחרים יכולים לנבוע מתכונות שונות ומברירות מחדל שונות של מסדי נתונים מנוהלים של ספקי ענן שונים.
הסבירות שכשל יתרחש בענן שלם נמוכה יותר מהסבירות שכשל יתרחש באזור. עם זאת, יכול להיות שעדיין יהיה שימוש לארגונים באפליקציה שנפרסה בשני עננים. הגישה הזו יכולה לעזור להגן על ארגון מפני כשל, או לעזור לו לעמוד בתקנות עסקיות או בתקנות של התעשייה.
גישה נוספת להתאוששות מאסון היא להגדיר אזור ראשי ואזור משני, וענן ראשי וענן משני. גישה זו מאפשרת לארגונים לבחור את תהליך ההתאוששות מאסון המתאים ביותר לטיפול במצב של כשל. כדי לאפשר לאפליקציה לפעול, אפשר להשתמש באזור משני או בענן משני, בהתאם לחומרת ההשבתה.
Cloud bursting
Cloud bursting הוא הגדרה שמאפשרת להגדיל את נפח התנועה של לקוחות האפליקציה במיקומי פריסה שונים. אפליקציה מתפרצת כשהביקוש לקיבולת גדל ומיקום בהמתנה מספק קיבולת נוספת. מיקום ראשי תומך בתנועה הרגילה, ואילו מיקום גיבוי יכול לספק קיבולת נוספת במקרה של עלייה בתנועת הלקוחות של האפליקציה מעבר למה שהמיקום הראשי יכול לתמוך בו. גם במיקום הראשי וגם במיקום הגיבוי פרוסים מופעים של שירותי אפליקציות.
התכונה cloud bursting מיושמת בעננים שונים, כאשר ענן אחד הוא הענן הראשי וענן שני הוא ענן ההמתנה. הוא משמש בהקשר של ענן היברידי כדי להגדיל מספר מוגבל של משאבי מחשוב במרכזי נתונים מקומיים באמצעות משאבי מחשוב גמישים בענן בענן ציבורי.
אלה האפשרויות הזמינות לתמיכה במסדי נתונים:
- פריסת המיקום הראשי. בפריסה הזו, מסד הנתונים נפרס רק במיקום הראשי ולא במיקום ההמתנה. כשמתרחש שימוש חריג באפליקציה, האפליקציה במיקום ההמתנה ניגשת למסד הנתונים במיקום הראשי.
- פריסה של מיקום ראשי ומיקום לגיבוי. הפריסה הזו תומכת במיקום הראשי ובמיקום הגיבוי. מופע של מסד נתונים נפרס בשני המיקומים, והגישה אליו מתבצעת על ידי מופעים של שירות האפליקציה באותו מיקום, במיוחד במקרה של שימוש בקיבולת נוספת. כמו במאמר בנושא תוכנית התאוששות מאסון (DR) בענן אחד או בכמה עננים, אפשר לסנכרן את שני מסדי הנתונים באופן טרנזקציונלי או באופן אסינכרוני. בסנכרון אסינכרוני, יכול להיות עיכוב. אם מתבצעים עדכונים במיקום ההמתנה, צריך להעביר את העדכונים האלה בחזרה למיקום הראשי. אם אפשר לבצע עדכונים בו-זמנית בשני המיקומים, צריך להטמיע פתרון לסתירות.
פריצת ענן היא תרחיש שימוש נפוץ בעננים היברידיים כדי להגדיל את הקיבולת במרכזי נתונים מקומיים. זו גם גישה שאפשר להשתמש בה בעננים ציבוריים כשצריך לשמור את הנתונים בתוך מדינה מסוימת. במצבים שבהם יש לענן ציבורי רק אזור אחד במדינה מסוימת, אפשר להשתמש באזור של ענן ציבורי אחר באותה מדינה. הגישה הזו מבטיחה שהנתונים יישארו בתוך המדינה, ועדיין תאפשר להתמודד עם מגבלות המשאבים באזור של אזורי הענן הציבורי.
שימוש בשירות ענן ברמה הגבוהה ביותר
באפליקציות מסוימות נדרשים מוצרים ושירותים מיוחדים בענן שלא זמינים בענן יחיד. לדוגמה, אפליקציה יכולה לבצע עיבוד של לוגיקה עסקית של נתונים עסקיים בענן אחד, וניתוח של הנתונים העסקיים בענן אחר. בתרחיש השימוש הזה, החלקים של עיבוד הלוגיקה העסקית והחלקים של הניתוח של האפליקציה נפרסים בעננים שונים.
מבחינת ניהול נתונים, אלה תרחישי השימוש:
- נתונים מחולקים. לכל חלק באפליקציה יש מסד נתונים משלו (מחיצה נפרדת), ואף אחד ממסדי הנתונים לא מחובר ישירות למסד נתונים אחר. האפליקציה שמנהלת את הנתונים כותבת כל נתון שצריך להיות זמין בשני מסדי הנתונים (המחיצות) פעמיים.
- מסד נתונים שמשוכפל באופן אסינכרוני. אם נתונים מענן אחד צריכים להיות זמינים בענן אחר, יכול להיות שמתאים להשתמש בקשר שכפול אסינכרוני. לדוגמה, אם אפליקציית ניתוח נתונים דורשת את אותו מערך נתונים או קבוצת משנה של מערך הנתונים עבור אפליקציה עסקית, אפשר לשכפל את מערך הנתונים בין העננים.
- מסד נתונים שמסונכרן ברמת העסקה. מסדי נתונים כאלה מאפשרים לכם להפוך את הנתונים לזמינים לשני חלקי האפליקציה. כל עדכון מכל אחת מהאפליקציות עקבי מבחינת טרנזקציות וזמין לשני מסדי הנתונים (המחיצות) באופן מיידי. מסדי נתונים שמסונכרנים בטרנזקציות פועלים למעשה כמסד נתונים מבוזר יחיד.
שירותים מבוזרים
שירות מבוזר נפרס ומופעל בשני מיקומי פריסה או יותר. אפשר לפרוס את כל מופעי השירות בכל מיקומי הפריסה. לחלופין, אפשר לפרוס חלק מהשירותים בכל המיקומים וחלק רק באחד מהמיקומים, בהתאם לגורמים כמו זמינות חומרה או עומס מוגבל צפוי.
הנתונים במסד נתונים שמסונכרן באופן טרנזקציוני עקביים בכל המיקומים. לכן, מסד נתונים כזה הוא האפשרות הטובה ביותר לפריסת מופעי שירות בכל מיקומי הפריסה.
כשמשתמשים במסד נתונים משוכפל אסינכרוני, יש סיכון שפריט נתונים זהה ישונה בשני מיקומי פריסה בו-זמנית. כדי לקבוע איזה מבין שני השינויים הסותרים הוא המצב העקבי הסופי, צריך להטמיע אסטרטגיה לפתרון קונפליקטים. אפשר ליישם אסטרטגיה לפתרון קונפליקטים, אבל זה לא תמיד פשוט, ויש מקרים שבהם נדרבת התערבות ידנית כדי לשחזר את הנתונים למצב עקבי.
העברה של שירות מבוזר וגיבוי במקרה של כשל
אם אזור שלם בענן נכשל, מתחילה תוכנית התאוששות מאסון (DR). אם שירות יחיד באפליקציית מסד נתונים עם שמירת מצב נכשל (לא האזור או האפליקציה כולה), צריך לשחזר את השירות ולהפעיל אותו מחדש.
גישה ראשונית להתאוששות מאסון היא הפעלה מחדש של השירות שנכשל במיקום הפריסה המקורי שלו (גישה של הפעלה מחדש במקום). טכנולוגיות כמו Kubernetes מפעילות מחדש שירות באופן אוטומטי על סמך ההגדרה שלו.
עם זאת, אם הגישה הזו של הפעלה מחדש במקום לא מצליחה, אפשרות חלופית היא להפעיל מחדש את השירות במיקום משני. השירות עובר ממיקום ראשי למיקום משני. אם האפליקציה נפרסת כקבוצה של שירותים מבוזרים, יתירות הכשל של שירות יחיד יכולה להתבצע באופן דינמי.
מנקודת מבט של מסד נתונים, הפעלה מחדש של השירות במיקום הפריסה המקורי שלו לא דורשת פריסה ספציפית של מסד נתונים. כשמעבירים שירות למיקום פריסה חלופי והשירות ניגש למסד הנתונים, חלים אותם מודלים של מוכנות שפורטו בקטע שירותים מבוזרים בהמשך המסמך.
אם שירות מסוים מועבר באופן זמני, ואם זמן האחזור הגבוה יותר מקובל על הארגון במהלך ההעברה, השירות יכול לגשת למסד הנתונים במיקומי הפריסה. למרות שהשירות מועבר, הוא ממשיך לגשת למסד הנתונים באותה דרך שבה הוא ניגש אליו ממיקום הפריסה המקורי שלו.
פריסה שתלויה בהקשר
באופן כללי, פריסה של אפליקציה אחת כדי לשרת את כל לקוחות האפליקציה כוללת את כל שירותי האפליקציה ומסדי הנתונים שלה. עם זאת, יש מקרים חריגים. פריסה של אפליקציה אחת יכולה לשרת רק קבוצת משנה של לקוחות (על סמך קריטריונים ספציפיים), ולכן נדרשת יותר מפריסה אחת של אפליקציה. כל פריסה משרתת קבוצת משנה שונה של לקוחות, וכל הפריסות יחד משרתות את כל הלקוחות.
הנה כמה תרחישים לדוגמה לפריסה שתלויה בהקשר:
- כשפורסים אפליקציה מרובת דיירים שבה אפליקציה אחת נפרסת לכל הדיירים הקטנים, אפליקציה אחרת נפרסת לכל 10 דיירים בינוניים ואפליקציה אחת נפרסת לכל דייר פרימיום.
- כשצריך להפריד בין לקוחות, למשל לקוחות עסקיים ולקוחות ממשלתיים.
- כשצריך להפריד בין סביבות פיתוח, Staging וייצור.
מנקודת המבט של מסד הנתונים, אפשר לפרוס מסד נתונים אחד לכל פריסת אפליקציה בשיטת פריסה של אחד לאחד. כפי שמוצג בתרשים הבא, האסטרטגיה הזו היא גישה פשוטה שבה נוצרים נתונים מחולקים כי לכל פריסה יש מערך נתונים משלה.
בתרשים שלמעלה מוצגים:
- הגדרה עם שלוש פריסות של אפליקציה.
- לכל מערך נתונים יש מסד נתונים משלו.
- לא מתבצע שיתוף נתונים בין הפריסות.
במקרים רבים, פריסה של מכשיר אחד לכל משתמש היא האסטרטגיה המתאימה ביותר, אבל יש גם חלופות.
במקרה של ריבוי דיירים, יכול להיות שהדיירים יועברו למיקום אחר. יכול להיות שדייר קטן יהפוך לדייר בינוני ויהיה צורך להעביר אותו לאפליקציה אחרת. במקרה כזה, פריסות נפרדות של מסדי נתונים מחייבות העברה של מסד הנתונים. אם מסד נתונים מבוזר נפרס ומשמש את כל הפריסות בו-זמנית, כל נתוני הדיירים נמצאים במערכת מסד נתונים אחת. לכן, כדי להעביר דייר ממסד נתונים אחד למסד נתונים אחר, לא צריך להעביר את מסד הנתונים. בתרשים הבא מוצגת דוגמה למסד נתונים מסוג כזה:
בתרשים שלמעלה מוצגים:
- שלוש פריסות של אפליקציה.
- כל הפריסות חולקות מסד נתונים מבוזר יחיד.
- לאפליקציות יש גישה לכל הנתונים בכל פריסה.
- לא מיושמת חלוקה למחיצות של נתונים.
אם ארגון מעביר לעיתים קרובות דיירים כחלק מפעולות מחזור החיים, שכפול מסד נתונים עשוי להיות חלופה שימושית. בגישה הזו, נתוני הדייר משוכפלים בין מסדי נתונים לפני העברת הדייר. במקרה הזה, נעשה שימוש במסדי נתונים עצמאיים לפריסות שונות של אפליקציות, והם מוגדרים לשכפול רק לפני העברת הדייר ובמהלכה. הדיאגרמה הבאה מציגה שכפול זמני בין שני פריסות של אפליקציות במהלך העברת דיירים.
בתרשים שלמעלה מוצגים שלושה פריסות של אפליקציה עם שלושה מסדי נתונים נפרדים שמכילים את הנתונים שמשויכים לכל פריסה. כדי להעביר נתונים ממסד נתונים אחד למסד נתונים אחר, אפשר להגדיר העברה זמנית של מסד נתונים.
היסב אפליקציות
ניידות של אפליקציות מבטיחה שאפשר לפרוס אפליקציה במיקומי פריסה שונים, במיוחד בעננים שונים. הניידות הזו מבטיחה שאפשר להעביר אפליקציה בכל שלב, בלי שיהיה צורך בהנדסה מחדש ספציפית להעברה או בפיתוח אפליקציה נוספת כדי להתכונן להעברת אפליקציה.
כדי להבטיח ניידות של האפליקציה, אפשר להשתמש באחת מהגישות הבאות, שמתוארות בהמשך הקטע הזה:
- ניידות מבוססת-מערכת
- תאימות ל-API
- ניידות מידע לפי פונקציונליות
ניידות מבוססת-מערכת משתמשת באותם רכיבים טכניים שמשמשים בכל הפריסות האפשריות. כדי להבטיח ניידות מבוססת-מערכת, כל טכנולוגיה צריכה להיות זמינה בכל המיקומים הפוטנציאליים לפריסה. לדוגמה, אם מסד נתונים כמו PostgreSQL הוא מועמד, צריך לוודא שהוא זמין בכל מיקומי הפריסה הפוטנציאליים בפרק הזמן הצפוי. הכלל הזה נכון גם לגבי כל הטכנולוגיות האחרות – לדוגמה, שפות תכנות וטכנולוגיות תשתית. כפי שמוצג בדיאגרמה הבאה, גישה זו יוצרת קבוצה של פונקציות משותפות בכל מיקומי הפריסה על בסיס טכנולוגיה.
הדיאגרמה שלמעלה מציגה פריסת אפליקציה ניידת שבה האפליקציה מצפה למערכת מסד נתונים זהה בדיוק בכל מיקום שבו היא נפרסת. מכיוון שמשתמשים באותה מערכת מסדי נתונים בכל מיקום, האפליקציה ניידת. האפליקציה יכולה לצפות שאותה מערכת מסד נתונים בדיוק תשמש בכל הפריסה. לכן, אפשר להניח שיהיה ממשק ומאפיינים זהים של מערכת מסד הנתונים.
בהקשר של מסדי נתונים, במערכת התאימות ל-API, הלקוח משתמש בספרייה ספציפית לגישה למסד נתונים (לדוגמה, ספריית לקוח של MySQL) כדי לוודא שהוא יכול להתחבר לכל הטמעה תואמת שעשויה להיות זמינה בסביבת ענן. התרשים הבא מדגים את התאימות של ה-API.
בתרשים שלמעלה מוצגת ניידות של אפליקציות שמבוססת על ה-API של מערכת מסד הנתונים במקום על מערכת מסד הנתונים. למרות שמערכות מסדי הנתונים יכולות להיות שונות בכל אחד מהמיקומים, ה-API זהה ומציג את אותה פונקציונליות. האפליקציה ניידת כי היא יכולה להניח שקיים אותו API בכל מיקום, גם אם מערכת מסד הנתונים הבסיסית היא טכנולוגיית מסד נתונים שונה.
ניידות מבוססת-פונקציונליות מאפשרת שימוש בטכנולוגיות שונות בעננים שונים, שמספקות את אותה פונקציונליות. לדוגמה, יכול להיות שאפשר להגביל את השימוש במסדי נתונים למודל יחסי. מכיוון שכל מערכת מסדי נתונים רלציוניים יכולה לתמוך באפליקציה, אפשר להשתמש במערכות מסדי נתונים שונות בגרסאות שונות בעננים שונים בלי להשפיע על הניידות של האפליקציה. חיסרון של ניידות מבוססת-פונקציונליות הוא שאפשר להשתמש רק בחלקים של מודל מסד הנתונים שכל מערכות מסדי הנתונים הרלציוניים תומכות בהם. במקום מערכת מסדי נתונים שתואמת לכל העננים, צריך להשתמש במודל מסד נתונים. התרשים הבא מציג ארכיטקטורה לדוגמה לניידות מבוססת-פונקציונליות.
כפי שאפשר לראות בתרשים שלמעלה, יכול להיות ש-API של מערכת מסד הנתונים ומערכת מסד הנתונים יהיו שונים בכל מיקום. כדי להבטיח ניידות, האפליקציה צריכה להשתמש רק בחלקים של כל מערכת מסד נתונים וכל API שזמינים בכל מיקום. מכיוון שבכל מיקום זמין בדרך כלל רק חלק ממערכת מסד הנתונים, האפליקציה צריכה להגביל את השימוש שלה לחלק הזה.
כדי להבטיח ניידות לכל האפשרויות שבקטע הזה, צריך לפרוס את הארכיטקטורה המלאה באופן רציף לכל מיקומי היעד. צריך להריץ את כל מקרי הבדיקה של היחידות והמערכות מול הפריסות האלה. אלה דרישות חיוניות לזיהוי מוקדם של שינויים בתשתיות ובטכנולוגיות ולטיפול בהם.
מניעת תלות בספקים
מניעת תלות בספק (נעילה) עוזרת לצמצם את הסיכון לתלות בטכנולוגיה או בספק ספציפיים. היא דומה באופן שטחי לניידות של אפליקציות. ההגנה מפני תלות בספק חלה על כל הטכנולוגיות שבהן נעשה שימוש, ולא רק על שירותי ענן. לדוגמה, אם משתמשים ב-MySQL כמערכת מסד נתונים והיא מותקנת במכונות וירטואליות בענן, אז אין תלות מנקודת מבט של הענן, אבל יש תלות ב-MySQL. אפליקציה ניידת בענן עדיין עשויה להיות תלויה בטכנולוגיות שמסופקות על ידי ספקים שונים מאלה של הענן.
כדי למנוע תלות בספק, צריך לוודא שאפשר להחליף את כל הטכנולוגיות. לכן, צריך לבצע הפשטה יסודית ומובנית של כל הפונקציונליות של האפליקציה, כדי שיהיה אפשר להטמיע מחדש כל שירות של האפליקציה על בסיס טכנולוגי שונה, בלי להשפיע על אופן ההטמעה של האפליקציה. מנקודת מבט של מסד נתונים, אפשר לבצע את ההפשטה הזו על ידי הפרדה בין השימוש במודל של מסד נתונים לבין מערכת מסוימת לניהול מסד נתונים.
מערכת קיימת לניהול מסדי נתונים של ייצור
אפליקציות רבות לשימוש בכמה עננים מפותחות עם מערכות מסדי נתונים כחלק מהעיצוב שלהן, אבל ארגונים רבים מפתחים אפליקציות לשימוש בכמה עננים כחלק מהמאמץ שלהם למודרניזציה של האפליקציות. האפליקציות האלה פותחו מתוך הנחה שהאפליקציה החדשה שתוכננה והוטמעה ניגשת למסדי הנתונים הקיימים.
יש הרבה סיבות לכך שלא כדאי לשלב מסדי נתונים קיימים בתהליך מודרניזציה. יכול להיות שאתם משתמשים בתכונות ספציפיות שלא זמינות במערכות אחרות של מסדי נתונים. יכול להיות שבארגון יש מסדי נתונים עם תהליכי ניהול מורכבים ומבוססים, ולכן מעבר למערכת אחרת לא יהיה מעשי או כלכלי. לחלופין, חברה יכולה לבחור לעדכן אפליקציה בשלב הראשון ולעדכן את מסד הנתונים בשלב השני.
כשארגון משתמש במערכת מסד נתונים קיימת, המעצב של האפליקציה מרובת העננים צריך להחליט אם זו תהיה מערכת מסד הנתונים היחידה שבה נעשה שימוש, או אם צריך להוסיף מערכת מסד נתונים אחרת למיקומי פריסה שונים. לדוגמה, אם מסד נתונים נמצא בשרת מקומי והאפליקציה צריכה לפעול גם ב- Google Cloud, צריך לבדוק אם שירותי האפליקציה שנפרסו ב- Google Cloud ניגשים למסד הנתונים בשרת המקומי. לחלופין, אם צריך לפרוס מסד נתונים שני גם ב-Google Cloud וגם בשירותי האפליקציות שפועלים באופן מקומי.
אם מסד נתונים שני נפרס ב- Google Cloud, יכול להיות שתרחיש השימוש יהיה זהה לתרחישי השימוש שמוסברים במאמרים בנושא Cloud bursting או שירותים מבוזרים. בכל מקרה, הדיון על מסד הנתונים רלוונטי כמו בקטעים האלה. עם זאת, היא מוגבלת לפונקציונליות של מיקומים שונים שהמסד הנתונים הקיים יכול לתמוך בהם – למשל, סנכרון ושכפול.
דפוסי פריסה
במסמך הזה נדון בתרחישי שימוש שמעלים שאלה נפוצה מנקודת מבט של מסד נתונים: אם מסדי נתונים נמצאים ביותר ממיקום פריסה אחד, מה הקשר ביניהם?
הסוגים העיקריים של קשרים (דפוסי פריסה) שמפורטים בקטע הבא הם:
- חלוקה למחיצות ללא תלות במסד נתונים
- שכפול אסינכרוני חד-כיווני
- שכפול דו-כיווני עם פתרון התנגשויות
- מערכת מבוזרת מסונכרנת באופן מלא במצב פעיל-פעיל
אפשר למפות כל תרחיש שימוש במסמך הזה לאחת או יותר מארבע תבניות הפריסה.
בדיון הבא, נניח שהלקוחות ניגשים לשירותי האפליקציה ישירות. בהתאם לתרחיש השימוש, יכול להיות שיהיה צורך במאזן עומסים כדי להפנות באופן דינמי את גישת הלקוח לאפליקציות, כמו שמוצג בתרשים הבא.
בתרשים שלמעלה, מאזן עומסים בענן מפנה קריאות של לקוחות לאחד מהמיקומים הזמינים. מאזן העומסים מוודא שמדיניות איזון העומסים נאכפת, ושהלקוחות מופנים למיקום הנכון של האפליקציה ומסד הנתונים שלה.
חלוקה למחיצות ללא תלות במסד נתונים
דפוס הפריסה הזה הוא הפשוט ביותר מבין כל הדפוסים שמוסברים במסמך הזה: לכל מיקום או ענן יש מסד נתונים, ומסדי הנתונים מכילים מערכי נתונים מחולקים שלא תלויים זה בזה. פריט נתונים מאוחסן רק במסד נתונים אחד. כל מחיצת נתונים ממוקמת במסד נתונים משלה. דוגמה לדפוס הזה היא אפליקציה מרובת דיירים שבה מערך נתונים נמצא במסד נתונים אחד או במסד נתונים אחר. התרשים הבא מציג שתי אפליקציות עם חלוקה מלאה למחיצות.
כפי שמוצג בדיאגרמה הקודמת, אפליקציה נפרסת בשני מיקומים, וכל אחד מהם אחראי למחיצה של קבוצת הנתונים כולה. כל פריט נתונים נמצא רק באחד מהמיקומים, וכך מתקבל מערך נתונים מחולק בלי שכפול בין שני המיקומים.
תבנית פריסה חלופית למסדי נתונים עם מחיצות היא כשהנתונים מחולקים למחיצות באופן מלא אבל עדיין מאוחסנים באותו מסד נתונים. יש רק מסד נתונים אחד שמכיל את כל מערכי הנתונים. למרות שמערכי הנתונים מאוחסנים באותו מסד נתונים, הם נפרדים לחלוטין (מחולקים למחיצות), ושינוי באחד מהם לא גורם לשינויים באחרים. בתרשים הבא מוצגות שתי אפליקציות שמשתפות מסד נתונים יחיד.
בתרשים שלמעלה מוצגים:
- שני פריסות של אפליקציות שחולקות מסד נתונים משותף, שנמצא במיקום הראשון.
- לכל אפליקציה יש גישה לכל הנתונים בפריסה כי מערך הנתונים לא מחולק למחיצות.
שכפול אסינכרוני חד-כיווני
בתבנית הפריסה הזו יש מסד נתונים ראשי שמשוכפל למסד נתונים משני אחד או יותר. אפשר להשתמש במסד הנתונים המשני לגישת קריאה, אבל האפליקציה צריכה לקחת בחשבון את השהיית השכפול הפוטנציאלית. דוגמה לתבנית הזו היא כשמשתמשים במסד הנתונים הטוב ביותר לתרחיש שימוש מסוים כבסיס הנתונים הראשי, ובמסד הנתונים המשני לצורכי ניתוח. בתרשים הבא מוצגות שתי אפליקציות שגשת למסדי נתונים משוכפלים באופן חד-כיווני.
כפי שאפשר לראות בתרשים הקודם, אחד משני מסדי הנתונים הוא העתק של השני. החץ בתרשים מציין את כיוון השכפול: הנתונים ממערכת מסד הנתונים במיקום 1 משוכפלים למערכת מסד הנתונים במיקום 2.
שכפול דו-כיווני עם פתרון התנגשויות
בתבנית הפריסה הזו יש שני מסדי נתונים ראשיים שמתבצעת ביניהם שכפול אסינכרוני. אם אותם נתונים נכתבים בו-זמנית לכל מסד נתונים (לדוגמה, אותו מפתח ראשי), יכולה להיווצר התנגשות בין פעולות כתיבה. בגלל הסיכון הזה, צריך להגדיר פתרון לסכסוכים כדי לקבוע מהו המצב האחרון במהלך השכפול. אפשר להשתמש בדפוס הזה במצבים שבהם הסיכוי לקונפליקט של כתיבה-כתיבה הוא נדיר. התרשים הבא מציג שתי אפליקציות שמתבצעת בהן גישה למסדי נתונים שמשוכפלים דו-כיוונית.
כמו שרואים בתרשים שלמעלה, כל מסד נתונים משוכפל למסד הנתונים השני. שני השכפולים הם בלתי תלויים זה בזה, כפי שמצוין בתרשים באמצעות שני חיצים כחולים נפרדים. מכיוון שהשכפול מתבצע בשני מקומות נפרדים, יכול להיווצר קונפליקט אם במקרה אותו פריט נתונים משתנה על ידי כל אחת מהאפליקציות ומשוכפל בו-זמנית. במקרה כזה, צריך לפתור את הקונפליקט.
מערכת מבוזרת מסונכרנת באופן מלא במצב פעיל-פעיל
בתבנית הפריסה הזו יש מסד נתונים יחיד עם הגדרה פעילה-פעילה (גם ראשונית-ראשונית). בהגדרה פעילה-פעילה, עדכון של נתונים בכל מסד נתונים ראשי הוא עקבי מבחינת עסקאות ומשוכפל באופן סינכרוני. דוגמה לתרחיש שימוש בתבנית הזו היא מחשוב מבוזר. בתרשים הבא מוצגות שתי אפליקציות שמאפשרות גישה למסד נתונים ראשי-ראשי מסונכרן לחלוטין.
כפי שאפשר לראות בתרשים שלמעלה, הסידור הזה מבטיח שלכל אפליקציה תהיה תמיד גישה למצב העקבי האחרון, בלי עיכוב או סיכון להתנגשות. שינוי שמתבצע במסד נתונים אחד זמין באופן מיידי במסד הנתונים השני. כל שינוי משתקף בשני מסדי הנתונים כשמתבצעת טרנזקציה של שינוי.
סיווג של מערכות מסדי נתונים
לא כל מערכות ניהול מסדי הנתונים מתאימות באותה מידה לדפוסי הפריסה שמוסברים במסמך הזה. בהתאם לתרחיש לדוגמה, יכול להיות שאפשר יהיה להטמיע רק דפוס פריסה אחד או שילוב של דפוסי פריסה עם קבוצת משנה בלבד של מערכות מסדי נתונים.
בקטע הבא, מערכות מסדי הנתונים השונות מסווגות וממופות לארבעת דפוסי הפריסה.
אפשר לסווג מסדי נתונים לפי מאפיינים שונים כמו מודל נתונים, ארכיטקטורה פנימית, מודל פריסה וסוגי טרנזקציות. בקטע הבא, לצורך ניהול מסד נתונים מרובה עננים, נעשה שימוש בשני מאפיינים:
- ארכיטקטורת הפריסה. הארכיטקטורה של פריסת מערכת לניהול מסדי נתונים במשאבים של עננים (לדוגמה, מנועי חישוב או ניהול בענן).
- מודל הפצה. מודל ההפצה שמערכת מסד נתונים תומכת בו (לדוגמה, מופע יחיד או מבוזר לחלוטין).
שני המאפיינים האלה הם הרלוונטיים ביותר בהקשר של תרחישי שימוש בריבוי עננים, והם יכולים לתמוך ב-4 דפוסי הפריסה שנגזרים מתרחישי השימוש במסדי נתונים בריבוי עננים. סיווג נפוץ מבוסס על מודלים של נתונים שנתמכים על ידי מערכת לניהול מסדי נתונים. מערכות מסוימות תומכות רק במודל אחד (למשל, מודל גרף). מערכות אחרות תומכות בכמה מודלים של נתונים בו-זמנית (לדוגמה, מודלים יחסיים ומודלים של מסמכים). עם זאת, בהקשר של ניהול מסדי נתונים מרובי-ענן, הסיווג הזה לא רלוונטי כי אפליקציות מרובות-ענן יכולות להשתמש בכל מודל נתונים לפריסה מרובת-ענן.
מערכת מסד נתונים לפי ארכיטקטורת פריסה
ניהול מסדי נתונים בענן מרובה כולל את ארבעת הסוגים העיקריים הבאים של ארכיטקטורת פריסה למערכות לניהול מסדי נתונים:
- מסדי נתונים מובנים בענן. מסדי נתונים מובנים בענן מתוכננים, בנויים ומותאמים לעבודה עם טכנולוגיית ענן. לדוגמה, מערכות מסוימות של מסדי נתונים משתמשות ב-Kubernetes כפלטפורמת ההטמעה שלהן ומשתמשות בפונקציונליות של Kubernetes. CockroachDB ו-YugaByte הן דוגמאות למסדי נתונים מסוג זה. אפשר לפרוס אותם בכל ענן שתומך ב-Kubernetes.
- מסדי נתונים שמנוהלים על ידי ספק ענן. מסדי נתונים מנוהלים של ספק שירותי ענן מבוססים על טכנולוגיה ספציפית של ספק שירותי ענן, והם שירות מסד נתונים שמנוהל על ידי ספק שירותי ענן ספציפי. Spanner, Bigtable, Firestore ו-AlloyDB ל-PostgreSQL הן דוגמאות למסדי נתונים מסוג זה. מסדי נתונים שמנוהלים על ידי ספק שירותי ענן זמינים רק בענן של ספק שירותי הענן, ואי אפשר להתקין אותם ולהפעיל אותם במקום אחר. עם זאת, AlloyDB ל-PostgreSQL תואם באופן מלא ל-PostgreSQL.
- מסדי נתונים לפני הענן. מסדי נתונים לפני הענן היו קיימים לפני הפיתוח של טכנולוגיית הענן (לפעמים במשך זמן רב), ובדרך כלל הם פועלים על חומרת Bare Metal ומכונות וירטואליות (VM). PostgreSQL, MySQL ו-SQL Server הם דוגמאות למסדי נתונים מסוג זה. המערכות האלה יכולות לפעול בכל ענן שתומך במכונות הווירטואליות הנדרשות או בחומרה מסוג Bare Metal.
- מסדי נתונים בענן שמנוהלים על ידי שותפים. יש עננים ציבוריים שכוללים שותפים למסדי נתונים שמתקינים ומנהלים את מסדי הנתונים של הלקוחות בענן הציבורי. לכן, הלקוחות לא צריכים לנהל את מסדי הנתונים האלה בעצמם. MongoDB Atlas, MariaDB, ו- ScyllaDB הן דוגמאות למסדי נתונים מסוג זה.
יש כמה וריאציות של הקטגוריות העיקריות האלה. לדוגמה, ספק מסד נתונים שמטמיע מסד נתונים שנוצר לענן יכול גם לספק התקנה בטכנולוגיה שנוצרה לענן והצעה מנוהלת ללקוחות בענן שסופק על ידי הספק. הגישה הזו מקבילה למצב שבו הספק מספק ענן ציבורי שתומך רק במסד הנתונים שלו כשירות יחיד.
יכול להיות שגם מסדי נתונים שאינם בענן נמצאים בקונטיינרים, ואפשר לפרוס אותם באשכול Kubernetes. עם זאת, מסדי הנתונים האלה לא משתמשים בפונקציונליות ספציפית ל-Kubernetes, כמו שינוי גודל, ריבוי שירותים או פריסה של כמה פודים.
יכול להיות שספקי מסדי נתונים ישתפו פעולה עם יותר מספק שירותי ענן אחד בו-זמנית, ויציעו את מסד הנתונים שלהם כמסד נתונים מנוהל על ידי שותף בענן ביותר מענן ציבורי אחד.
מערכת מסד נתונים לפי מודל הפצה
מערכות שונות לניהול מסדי נתונים מיושמות בהתאם למודלים של הפצה בארכיטקטורה של מסד נתונים. המודלים למסדי נתונים הם:
- מופע יחיד. מופע יחיד של מסד נתונים פועל במכונה וירטואלית אחת או בקונטיינר אחד, ומשמש כמערכת מרכזית. המערכת הזו מנהלת את כל הגישה למסד הנתונים. מכיוון שאי אפשר לחבר את המופע היחיד למופע אחר, מערכת מסד הנתונים לא תומכת בשכפול.
- מצב פעיל-סביל עם כמה מופעים במקביל. באדריכלות הנפוצה הזו, כמה מופעים של מסד נתונים מקושרים זה לזה. הקישור הנפוץ ביותר הוא יחס פעיל-סביל, שבו מופע אחד הוא מופע מסד הנתונים הפעיל שתומך בשני המופעים, וגם כותב וגם קורא. מערכת פסיבית אחת או יותר הן לקריאה בלבד, והן מקבלות את כל השינויים במסד הנתונים מהמערכת הראשית באופן סינכרוני או אסינכרוני. מערכות פסיביות יכולות לספק גישת קריאה. המונח 'פעיל-סביל' נקרא גם 'ראשי-משני' או 'מקור-עותק'.
- Multi-instance active-active (כמה מופעים במקביל פעיל-פעיל). באופן יחסי, בארכיטקטורה לא נפוצה, כל מופע הוא מופע פעיל. במקרה כזה, כל מופע יכול לבצע עסקאות קריאה וכתיבה ולספק עקביות נתונים. לכן, כדי למנוע חוסר עקביות בנתונים, כל המקרים מסונכרנים תמיד.
- פעיל-פעיל עם כמה מופעים במקביל ופתרון התנגשויות. זו גם מערכת יחסית לא נפוצה. כל מופע זמין לגישת קריאה וכתיבה, אבל מסדי הנתונים מסונכרנים במצב אסינכרוני. מותר לבצע עדכונים בו-זמניים של אותו פריט נתונים, מה שמוביל למצב לא עקבי. מדיניות לפתרון קונפליקטים צריכה להחליט איזו מהמדינות היא המדינה העקבית האחרונה.
- חלוקת נתונים (sharding) בכמה מופעים במקביל. החלוקה לשברים מבוססת על ניהול של מחיצות נתונים (לא חופפות). כל מחיצה מנוהלת על ידי מופע נפרד של מסד נתונים. החלוקה הזו ניתנת להרחבה כי אפשר להוסיף עוד שברים באופן דינמי לאורך זמן. עם זאת, יכול להיות שלא ניתן יהיה לבצע שאילתות חוצות-שארדים, כי לא כל המערכות תומכות בפונקציונליות הזו.
כל מודלי ההפצה שמוסברים בקטע הזה יכולים לתמוך בפיצול (sharding) ולהיות מערכת מפולחת. עם זאת, לא כל המערכות מתוכננות לספק אפשרות של חלוקה למקטעים. חלוקה למקטעים היא מושג שקשור למדרגיות, ובדרך כלל הוא לא רלוונטי לבחירת ארכיטקטורת מסד נתונים בסביבות מרובות עננים.
מודלים של הפצה שונים עבור מסדי נתונים ב-Cloud ומסדי נתונים שמנוהלים על ידי שותפים. מכיוון שמסדי הנתונים האלה קשורים לארכיטקטורה של ספק שירותי ענן, המערכות האלה מיישמות ארכיטקטורות שמבוססות על מיקומי הפריסה הבאים:
- מערכת אזורית. מערכת מסדי נתונים שמנוהלת לפי אזור קשורה לאזור מסוים. כשהאזור זמין, גם מערכת מסד הנתונים זמינה. עם זאת, אם האזור לא זמין, אי אפשר לגשת למסד הנתונים.
- מערכת אזורית. מסד נתונים אזורי מנוהל קשור לאזור וניתן לגשת אליו כשניתן לגשת לאזור אחד לפחות. יכול להיות שלא תהיה גישה לשילוב כלשהו של אזורים.
- מערכת חוצה אזורים. מערכת חוצת-אזורים קשורה לשני אזורים או יותר, והיא פועלת בצורה תקינה כשזמין לפחות אזור אחד.
מערכת חוצת-אזורים יכולה גם לתמוך במערכת חוצת-עננים אם אפשר להתקין את מסד הנתונים בכל העננים שהארגון מתכוון להשתמש בהם.
יש חלופות אפשריות אחרות לארכיטקטורות של מסדי נתונים מנוהלים שמוזכרות בקטע הזה. מערכת אזורית עשויה לשתף דיסק בין שני אזורים. אם לא תהיה גישה לאחד משני התחומים, מערכת מסד הנתונים תוכל להמשיך לפעול בתחום השני. עם זאת, אם הפסקה זמנית בשירות משפיעה על שני האזורים, מערכת מסד הנתונים לא זמינה, גם אם אזורים אחרים עדיין פועלים באופן מלא.
מיפוי של מערכות מסדי נתונים לדפוסי פריסה
בטבלה הבאה מתואר הקשר בין דפוסי הפריסה וארכיטקטורות הפריסה שמוסברים במסמך הזה. בשדות מפורטים התנאים שצריכים להתקיים כדי שהשילוב יהיה אפשרי, על סמך דפוס הפריסה וארכיטקטורת הפריסה.
| ארכיטקטורת פריסה | תבנית פריסה | ||||
|---|---|---|---|---|---|
| חלוקה למחיצות ללא תלות במסד נתונים | שכפול אסינכרוני חד-כיווני | שכפול דו-כיווני עם פתרון התנגשויות | מערכת מבוזרת מסונכרנת באופן מלא במצב פעיל-פעיל | ||
| מסדי נתונים מובנים בענן | אפשר להשתמש בטכנולוגיה הזו בכל העננים שמספקים טכנולוגיית ענן מובנית שמשמשת מערכות מסדי נתונים.
אם מסד הנתונים זהה לא זמין, אפשר להשתמש במערכות שונות של מסדי נתונים. |
מסד נתונים בענן שמספק שכפול. | מסד נתונים בענן שמספק שכפול דו-כיווני. | מסד נתונים בענן שמספק סנכרון ראשי-ראשי. | |
| מסדי נתונים שמנוהלים על ידי ספק ענן | מערכות מסדי נתונים יכולות להיות שונות בעננים שונים. | העותק לא חייב להיות מסד נתונים שמנוהל על ידי ספק הענן (ראו התפקיד של טכנולוגיית העברת מסדי נתונים בדפוסי פריסה). | רק בענן אחד, ולא בין עננים, אם מסד הנתונים מספק שכפול דו-כיווני. | רק בתוך ענן, לא בין עננים, אם מסד הנתונים מספק סנכרון ראשי-ראשי. | |
| מסדי נתונים לפני המעבר לענן | מערכות מסדי הנתונים יכולות להיות זהות או שונות בעננים שונים. | אפשר לבצע שכפול בכמה עננים. | מערכת מסד הנתונים מספקת שכפול דו-כיווני ופתרון של קונפליקטים. | מערכת מסד הנתונים מספקת סנכרון ראשי-ראשי. | |
| מסדי נתונים בענן בניהול שותף | מערכות מסדי נתונים יכולות להיות שונות בעננים שונים.
אם השותף מספק מערכת מסדי נתונים מנוהלת בכל העננים הנדרשים, אפשר להשתמש באותו מסד נתונים. |
רפליקה לא חייבת להיות מסד נתונים שמנוהל על ידי ספק שירותי הענן. אם השותף מספק מערכת מסדי נתונים מנוהלת בכל העננים הנדרשים, אפשר להשתמש באותו מסד נתונים. |
מערכת מסד הנתונים מספקת שכפול דו-כיווני ופתרון של קונפליקטים. | מערכת מסד הנתונים מספקת סנכרון ראשי-ראשי. | |
אם מערכת מסד נתונים לא מספקת שכפול מובנה, יכול להיות שאפשר להשתמש בטכנולוגיית שכפול של מסד נתונים במקום זאת. מידע נוסף זמין במאמר התפקיד של טכנולוגיית העברת נתונים ממסדי נתונים בדפוסי פריסה.
בטבלה הבאה מפורטים דפוסי הפריסה בהתאם למודלים של הפצה. בשדות מצוינים התנאים שבהם השילוב אפשרי בהינתן תבנית פריסה ומודל הפצה.
| מודל הפצה | תבנית פריסה | ||||
|---|---|---|---|---|---|
| חלוקה למחיצות ללא תלות במסד נתונים | שכפול אסינכרוני חד-כיווני | שכפול דו-כיווני עם פתרון התנגשויות | מערכת מבוזרת מסונכרנת באופן מלא במצב פעיל-פעיל | ||
| מכונה אחת | אפשר להשתמש באותה מערכת מסדי נתונים או במערכות שונות בעננים הרלוונטיים. | לא רלוונטי | לא רלוונטי | לא רלוונטי | |
| מצב פעיל-סביל עם כמה מופעים במקביל | אפשר להשתמש באותה מערכת מסדי נתונים או במערכות שונות בעננים הרלוונטיים. | אפשר לבצע שכפול בין עננים. | אפשר לבצע שכפול בין עננים. | לא רלוונטי | |
| מצב פעיל-פעיל עם כמה מופעים במקביל | אפשר להשתמש באותה מערכת מסדי נתונים או במערכות שונות בעננים הרלוונטיים. | לא רלוונטי | לא רלוונטי | אפשר לסנכרן בין עננים שונים. | |
| מצב פעיל-פעיל עם כמה מופעים במקביל ופתרון התנגשויות | אפשר להשתמש באותה מערכת מסדי נתונים או במערכות שונות בעננים הרלוונטיים. | לא רלוונטי | לא רלוונטי | רלוונטי אם אפשר לבצע רפליקציה דו-כיוונית בין עננים. | |
ביישומים מסוימים של מודלים להפצה שמוסיפים הפשטה נוספת על סמך טכנולוגיית מסד הנתונים הבסיסית, אין מודל הפצה כזה שמוטמע בהם – לדוגמה, Postgres-BDR, מערכת פעילה-פעילה. מערכות כאלה נכללות בטבלה שלמעלה בקטגוריה המתאימה. מנקודת מבט של סביבה מרובת עננים, לא משנה איך מודל ההפצה מיושם.
העברה ושכפול של מסדי נתונים
בהתאם לתרחיש השימוש, יכול להיות שארגון יצטרך להעביר מסד נתונים ממיקום פריסה אחד למיקום אחר. לחלופין, כדי לעבד נתונים בהמשך, יכול להיות שיהיה צורך לשכפל את הנתונים ממסד נתונים למיקום אחר. בקטע הבא מוסבר בפירוט על העברת מסד נתונים ועל שכפול מסד נתונים.
העברה של מסדי נתונים
העברת מסד נתונים משמשת להעברת מסד נתונים ממיקום פריסה אחד למיקום פריסה אחר. לדוגמה, מסד נתונים שפועל במרכז נתונים מקומי מועבר לפעולה בענן. אחרי שהמיגרציה מסתיימת, מסד הנתונים מושבת במרכז הנתונים המקומי.
אלה הגישות העיקריות להעברת מסד נתונים:
- חותכים ולוקחים. המכונה הווירטואלית והדיסקים שמריצים את מופעי מסד הנתונים מועתקים לסביבת היעד כמו שהם. אחרי שהם מועתקים, הם מופעלים והמיגרציה מסתיימת.
- ייצוא וייבוא, גיבוי ושחזור. שתי הגישות האלה משתמשות בפונקציונליות של מערכת מסד הנתונים כדי להעביר מסד נתונים למיקום חיצוני וליצור אותו מחדש במיקום היעד. ייצוא/ייבוא מתבצעים בדרך כלל בפורמט ASCII, ואילו גיבוי ושחזור מתבצעים בפורמט בינארי.
- העברה ללא השבתה. בגישה הזו, מסד נתונים מועבר בזמן שמערכות האפליקציות ניגשות למערכת המקור. אחרי טעינה ראשונית, השינויים מועברים ממסד הנתונים של המקור למסד הנתונים של היעד באמצעות טכנולוגיות של סימון נתונים שהשתנו (CDC). האפליקציה מושבתת מהרגע שהיא נעצרת במערכת מסד הנתונים של המקור, עד שהיא מופעלת מחדש במערכת מסד הנתונים של היעד אחרי שההעברה מסתיימת.
העברה של מסד נתונים רלוונטית בתרחישי שימוש בענן מרובה, כשמסד נתונים מועבר מענן אחד לענן אחר, או מסוג אחד של מנוע מסד נתונים לסוג אחר.
העברת מסד נתונים היא תהליך מורכב. מידע נוסף זמין במאמרים העברת נתונים של מסדי נתונים: מושגים ועקרונות (חלק 1) והעברת נתונים של מסדי נתונים: מושגים ועקרונות (חלק 2).
אפשר להשתמש בטכנולוגיות מובנות של מסדי נתונים כדי לבצע העברה של מסד נתונים – למשל ייצוא וייבוא, גיבוי ושחזור או פרוטוקולי שכפול מובנים. אם מערכת המקור ומערכת היעד הן מערכות מסדי נתונים שונות, טכנולוגיות העברה הן האפשרות הטובה ביותר להעברת מסד נתונים. Database Migration Service, Striim ו-Debezium הם דוגמאות לטכנולוגיות להעברת מסדי נתונים.
שכפול מסד נתונים
שכפול מסד נתונים דומה להעברת מסד נתונים. עם זאת, במהלך שכפול מסד הנתונים, מערכת מסד הנתונים של המקור נשארת במקומה, וכל שינוי מועבר למסד הנתונים של היעד.
שכפול מסד נתונים הוא תהליך רציף שבו שינויים ממסד הנתונים של המקור נשלחים למסד הנתונים של היעד. כשהתהליך הזה הוא אסינכרוני, השינויים מגיעים למסד הנתונים של היעד אחרי השהיה קצרה. אם התהליך הוא סינכרוני, השינויים במערכת המקור מתבצעים במערכת היעד באותו הזמן ובאותן עסקאות.
בנוסף לשכפול מקור למסד נתונים יעד, נהוג לשכפל נתונים ממסד נתונים מקור למערכת ניתוח יעד.
בדומה להעברת מסד נתונים, אם יש פרוטוקולים לשכפול, אפשר להשתמש בטכנולוגיית מסד נתונים מובנית לשכפול מסד נתונים. אם אין פרוטוקולים מובנים לשכפול, אפשר להשתמש בטכנולוגיית שכפול כמו Datastream, Striim או Debezium.
תפקיד הטכנולוגיה להעברת מסדי נתונים בדפוסי פריסה
טכנולוגיית מסד נתונים מובנית שמאפשרת שכפול בדרך כלל לא זמינה כשמשתמשים במערכות מסד נתונים שונות בדפוסי פריסה – לדוגמה, שכפול אסינכרוני (הטרוגני). במקום זאת, אפשר להשתמש בטכנולוגיה להעברת מסדי נתונים כדי להפעיל שכפול כזה. חלק ממערכות ההעברה האלה מיישמות גם שכפול דו-כיווני.
אם יש טכנולוגיה להעברה או לשכפול של מסדי נתונים במערכות מסדי הנתונים שמשמשות בשילובים שמסומנים כ'לא רלוונטי' בטבלה 1 או בטבלה 2 במאמר מיפוי מערכות מסדי נתונים לדפוסי פריסה, יכול להיות שאפשר להשתמש בה לשכפול מסד נתונים. התרשים הבא מציג גישה לשכפול מסד נתונים באמצעות טכנולוגיית העברה.
בתרשים הקודם, מסד הנתונים במיקום 1 משוכפל למסד הנתונים במיקום 2. במקום רפליקציה ישירה של מערכת מסד הנתונים, פורס שרת העברה כדי להטמיע את הרפליקציה. הגישה הזו משמשת למערכות מסדי נתונים שאין בהן פונקציונליות של שכפול מסד נתונים שמוטמעת בהן, ושצריכות להסתמך על מערכת נפרדת ממערכת מסד הנתונים כדי להטמיע שכפול.
בחירת מסד נתונים מרובה-עננים
תרחישי השימוש במסדי נתונים מרובי-עננים, בשילוב עם סיווג מערכות מסדי הנתונים, עוזרים לכם להחליט אילו מסדי נתונים מתאימים ביותר לתרחיש שימוש מסוים. לדוגמה, כדי להטמיע את תרחיש השימוש בניוד אפליקציות, יש שתי אפשרויות. האפשרות הראשונה היא לוודא שהמנוע של מסד הנתונים זהה זמין בכל העננים. הגישה הזו מבטיחה ניידות של המערכת. האפשרות השנייה היא לוודא שכל העננים יכולים לגשת לאותו מודל נתונים ולאותו ממשק שאילתות. למרות שמערכות מסדי הנתונים עשויות להיות שונות, הניוד מתבצע בממשק פונקציונלי.
בעצי ההחלטות שבקטעים הבאים מוצגים הקריטריונים לקבלת החלטות לגבי תרחישי השימוש במסד נתונים מרובה עננים שמתוארים במסמך הזה. עצי ההחלטות מציעים את מסד הנתונים הכי מתאים לכל תרחיש לדוגמה.
שיטות מומלצות למערכת מסדי נתונים קיימת
אם מערכת מסד נתונים נמצאת בייצור, צריך להחליט אם להשאיר אותה או להחליף אותה. התרשים הבא מציג את השאלות שצריך לשאול בתהליך קבלת ההחלטות:
אלה השאלות והתשובות בעץ ההחלטות:
- האם יש מערכת מסד נתונים בסביבת הייצור?
- אם אין מערכת מסדי נתונים בייצור, בוחרים מערכת מסדי נתונים (מדלגים אל ההחלטה לגבי ניהול מסדי נתונים מרובי-עננים).
- אם מערכת מסד נתונים נמצאת בייצור, צריך להעריך אם כדאי לשמור אותה.
- אם מערכת מסד נתונים נמצאת בייצור, צריך להעריך אם כדאי לשמור אותה.
- אם צריך לשמור את מערכת מסד הנתונים, ההחלטה מתקבלת ותהליך קבלת ההחלטה מסתיים.
- אם צריך לשנות את מערכת מסד הנתונים או אם עדיין לא התקבלה החלטה, בוחרים מערכת מסד נתונים (אפשר לדלג אל ההחלטה לגבי ניהול מסד נתונים מרובה עננים).
החלטה לגבי ניהול מסד נתונים מרובה עננים
עץ ההחלטות הבא מתאים לתרחיש שימוש שבו נדרש מסד נתונים עם כמה מיקומים (כולל פריסת מסד נתונים בכמה עננים). היא משתמשת בתבנית הפריסה כבסיס לקריטריונים לקבלת החלטות.
אלה השאלות והתשובות בעץ ההחלטות:
- האם הנתונים מחולקים למסדי נתונים שונים ללא תלות בין מסדי הנתונים?
- אם כן, אפשר לבחור את אותן מערכות מסדי נתונים או מערכות שונות לכל מיקום.
- אם לא, ממשיכים לשאלה הבאה.
- האם נדרש שכפול חד-כיווני אסינכרוני?
- אם כן, צריך להעריך אם מערכת שכפול מסד נתונים היא פתרון מקובל.
- אם כן, בוחרים את אותן מערכות מסדי נתונים או מערכות שונות שתואמות למערכת השכפול.
- אם לא, צריך לבחור מערכת מסד נתונים שאפשר להטמיע בה מודל הפצה פעיל-סביל.
- אם לא, ממשיכים לשאלה הבאה.
- אם כן, צריך להעריך אם מערכת שכפול מסד נתונים היא פתרון מקובל.
- בוחרים מערכת מסדי נתונים עם מופעים מסונכרנים.
- האם פתרון הסכסוך מקובל?
- אם כן, בוחרים במערכת מסד נתונים עם שכפול דו-כיווני או במערכת מסד נתונים פעילה-פעילה.
- אם לא, בוחרים במערכת פעילה-פעילה.
- האם פתרון הסכסוך מקובל?
אם מטמיעים יותר מתרחיש שימוש אחד של ריבוי עננים, הארגון צריך להחליט אם הוא רוצה להשתמש במערכת מסד נתונים אחת שתתמוך בכל תרחישי השימוש, או בכמה מערכות מסד נתונים.
אם ארגון רוצה להשתמש במערכת מסד נתונים אחת שתתמוך בכל תרחישי השימוש, הבחירה הטובה ביותר היא המערכת עם הסנכרון הטוב ביותר. לדוגמה, אם נדרש שכפול חד-כיווני וגם מופעים מסונכרנים, הבחירה הטובה ביותר היא המופעים המסונכרנים.
ההיררכיה של איכות הסנכרון היא (מהנמוכה לגבוהה): חלוקה למחיצות, שכפול חד-כיווני, שכפול דו-כיווני ושכפול מסונכרן לחלוטין.
שיטות מומלצות לפריסה
בקטע הזה מפורטות שיטות מומלצות לבחירת מסד נתונים להעברה או לפיתוח של אפליקציות מרובות עננים.
מערכת קיימת לניהול מסדי נתונים
מומלץ לשמור מסד נתונים ולא לבצע שינויים במערכת מסד הנתונים, אלא אם נדרש אחרת בתרחיש שימוש ספציפי. בארגון עם מערכת מבוססת לניהול מסדי נתונים, ותהליכי פיתוח, תפעול ותחזוקה יעילים, יכול להיות שעדיף להימנע משינויים.
תרחיש שימוש ב-Cloud Bursting שלא דורש מערכת מסד נתונים בענן, לא בהכרח ידרוש שינוי במסד הנתונים. תרחיש שימוש נוסף הוא שכפול אסינכרוני למיקום פריסה אחר באותו ענן או לענן אחר. במקרים כאלה, כדאי להטמיע מדד השוואה ולוודא שהתקשורת בין המיקומים וההשהיה עומדות בדרישות האפליקציה כשניגשים למסד הנתונים.
מערכת מסד נתונים כשירות Kubernetes
אם ארגון שוקל להפעיל מערכת מסדי נתונים ב-Kubernetes כשירות שמבוסס על StatefulSets, צריך לקחת בחשבון את הגורמים הבאים:
- אם מסד הנתונים מספק את מודל מסד הנתונים שנדרש על ידי האפליקציה.
- גורמים לא פונקציונליים שקובעים איך ההעברה לשימוש תפעולי מיושמת במערכת מסד נתונים כשירות Kubernetes – לדוגמה, איך מתבצעת ההרחבה (הגדלה והקטנה), איך מתבצע גיבוי ושחזור ואיך המערכת מספקת ניטור. כדי לעזור להם להבין את הדרישות של מערכת מסד נתונים מבוססת-Kubernetes, חברות צריכות להשתמש בניסיון שלהן עם מסדי נתונים כנקודת השוואה.
- זמינות גבוהה ותוכנית התאוששות מאסון (DR). כדי לספק זמינות גבוהה, המערכת צריכה להמשיך לפעול כשמתרחש כשל באזור בתוך אזור. מסד הנתונים צריך לאפשר מעבר מהיר מאיזור אחד לאיזור אחר במקרה של כשל. במקרה הטוב ביותר, במסד הנתונים פועל מופע בכל אזור, והוא מסונכרן באופן מלא עם RTO ו-RPO של אפס.
- תוכנית התאוששות מאסון (DR) לטיפול בכשל באזור (או בענן). בתרחיש אידיאלי, מסד הנתונים ממשיך לפעול באזור שני עם RPO ו-RTO של אפס. בתרחיש פחות אידיאלי, יכול להיות שהנתונים במסד הנתונים באזור המשני לא יהיו עדכניים לגבי כל העסקאות ממסד הנתונים הראשי.
כדי לקבוע את הדרך הטובה ביותר להריץ מסד נתונים ב-Kubernetes, מומלץ לבצע הערכה מלאה של מסד הנתונים, במיוחד אם המערכת צריכה להיות דומה למערכת בייצור מחוץ ל-Kubernetes.
מערכת מסדי נתונים עצמאית ל-Kubernetes
לא תמיד צריך שאפליקציה שמיושמת כשירותים ב-Kubernetes תפעיל את מסד הנתונים ב-Kubernetes בו-זמנית. יש הרבה סיבות להפעלת מערכת מסד נתונים מחוץ ל-Kubernetes, למשל תהליכים מבוססים, ידע על מוצרים בארגון או חוסר זמינות. גם ספקי שירותי ענן וגם מסדי נתונים שמנוהלים על ידי שותפי ענן נכללים בקטגוריה הזו.
אפשר להריץ מסד נתונים ב-Compute Engine. כשבוחרים מערכת מסד נתונים, מומלץ לבצע הערכה מלאה של מסד הנתונים כדי לוודא שכל הדרישות של האפליקציה מתקיימות.
מבחינת עיצוב האפליקציה, איגום חיבורים הוא שיקול חשוב. שירות אפליקציה שגש למסד נתונים עשוי להשתמש באופן פנימי במאגר חיבורים. שימוש במאגר חיבורים משפר את היעילות ומקטין את זמן האחזור. הבקשות נלקחות מהמאגר בלי צורך בהפעלתן, ואין המתנה ליצירת חיבורים. אם מגדילים את קנה המידה של האפליקציה על ידי הוספת מופעים של שירות האפליקציה, כל מופע יוצר מאגר חיבורים. אם פועלים לפי השיטות המומלצות, כל מאגר יוצר מראש קבוצה מינימלית של חיבורים. בכל פעם שנוצר מופע נוסף של שירות אפליקציה לצורך שינוי גודל האפליקציה, חיבורים מתווספים למסד הנתונים. מבחינת העיצוב, מכיוון שמסדי נתונים לא יכולים לתמוך במספר בלתי מוגבל של חיבורים, צריך לנהל את הוספת החיבורים כדי למנוע עומס יתר.
מערכת מסד נתונים מומלצת לעומת ניידות של מערכת מסד נתונים
כשבוחרים מערכות מסדי נתונים, נהוג בחברות לבחור את מערכת מסד הנתונים הטובה ביותר כדי לענות על הדרישות של אפליקציה. בסביבה מרובת עננים, אפשר לבחור את מסד הנתונים הכי טוב בכל ענן, ולחבר אותם זה לזה על סמך תרחיש השימוש. אם המערכות האלה שונות, כל שכפול – חד-כיווני או דו-כיווני – דורש מאמץ משמעותי. הגישה הזו יכולה להיות מוצדקת אם היתרון בשימוש במערכת הטובה ביותר עולה על המאמץ שנדרש כדי להטמיע אותה.
עם זאת, מומלץ לשקול ולבחון במקביל גישה למערכת מסד נתונים שזמינה בכל העננים הנדרשים. אומנם מסד נתונים כזה לא אידיאלי כמו האפשרות הכי טובה, אבל יכול להיות שהרבה יותר קל להטמיע, להפעיל ולתחזק מערכת כזו.
הערכה של מערכות מסדי נתונים בו-זמנית מדגימה את היתרונות והחסרונות של שתי מערכות מסדי הנתונים, ומספקת בסיס מוצק לבחירה.
רפליקציה של מערכת מסד נתונים מובנית לעומת רפליקציה של מערכת מסד נתונים חיצונית
בתרחישי שימוש שבהם נדרשת מערכת מסדי נתונים בכל מיקומי הפריסה (אזורים, אזורים או עננים), שכפול הוא תכונה חשובה. השכפול יכול להיות אסינכרוני, דו-כיווני או שכפול פעיל-פעיל מסונכרן לחלוטין. לא כל מערכות מסדי הנתונים תומכות בכל סוגי השכפול האלה.
במערכות שלא תומכות בשכפול כחלק מהטמעת השכפול במערכת, אפשר להשתמש במערכות כמו Striim כדי להשלים את הארכיטקטורה (כפי שמוסבר במאמר בנושא העברת מסדי נתונים).
מומלץ להעריך מערכות חלופיות לניהול מסדי נתונים כדי להבין את היתרונות והחסרונות של מערכת עם שכפול מובנה או של מערכת שנדרשת בה טכנולוגיית שכפול.
במקרה הזה, יש גם טכנולוגיה מסוג שלישי שמשחקת תפקיד. המחלקות האלה מספקות תוספים למערכות מסדי נתונים קיימות כדי לספק שכפול. דוגמה אחת היא MariaDB Galera Cluster. אם תהליך ההערכה מאפשר זאת, מומלץ להעריך את המערכות האלה.
מסדי נתונים מרובי-מודלים
מסדי נתונים מרובי-מודלים מספקים ניהול נתונים גמיש וניתן להרחבה בענן ובאפליקציות בזמן אמת. מסדי נתונים מרובי-מודלים תומכים בכמה מודלים של נתונים, כמו מסמך, גרף, זוגות של מפתח-ערך, משפחת עמודות ויחסי גומלין, בממשק שאילתות מאוחד ובמנוע אחסון מאוחד. היכולות האלה מציעות יתרונות כמו:
- ניהול פשוט יותר: מפתחים יכולים לנהל סוגים שונים של נתונים במערכת מסד נתונים אחת, מה שעוזר לצמצם את המורכבות התפעולית והתקורה.
- פיתוח מהיר יותר: מסדי נתונים מרובי-מודלים מספקים את הגמישות להשתמש במודל הנתונים האופטימלי לצרכים שונים. הגמישות הזו יכולה להאיץ את הפיתוח ולעזור לכם להסתגל מהר יותר לשינויים בדרישות.
- שילוב קל יותר: ממשק שאילתות ומנוע אחסון מאוחדים מצמצמים את המורכבות של חיבור מסדי נתונים שונים וסנכרון שלהם.
- שאילתות משופרות: מפתחים יכולים לשלוח שאילתות ולשלב נתונים ממודלים שונים, וכך לקבל תובנות עשירות יותר ולפתח תכונות מתוחכמות יותר לאפליקציות.
- חיסכון בעלויות: פחות מערכות מסדי נתונים מובילות לעלויות נמוכות יותר של רישוי, חומרה והוצאות תפעוליות.
- ביצועים אופטימליים: בחירה של מודל הנתונים המתאים ביותר למשימות ספציפיות יכולה לשפר את ביצועי האפליקציה.
לדוגמה, Spanner מציע תכונות של ריבוי מודלים עם תמיכה בניב PostgreSQL. היכולת הזו מאפשרת לכם ליצור אפליקציות חכמות מבוססות-AI באמצעות נתונים יחסיים ונתוני NoSQL, לשאול שאילתות לגבי קשרים מורכבים באמצעות Spanner Graph ולהשתמש בחיפוש וקטורי לחיפוש סמנטי.
המאמרים הבאים
- מידע נוסף על דפוסי ארכיטקטורה היברידיים ומרובי עננים
- מידע על דפוסים לחיבור ספקים אחרים של שירותי ענן ל-Google Cloud
- מידע על ארכיטקטורות של מעקב ורישום ביומן לפריסות היברידיות ומרובות עננים ב- Google Cloud
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
Author: Alex Cârciu | Solutions Architect