במסמך הזה מתוארות ארכיטקטורות פריסה, תרחישים לדוגמה ושיטות מומלצות לניהול מסדי נתונים מרובי-ענן. המאמר מיועד לאדריכלים ולמהנדסים שתפקידם לתכנן וליישם אפליקציות עם שמירת מצב בתוך כמה עננים ובניהם.
ארכיטקטורות של אפליקציות מרובות עננים עם גישה למסדי נתונים תלויות בתרחיש השימוש. אין ארכיטקטורה של אפליקציה עם שמירת מצב שיכולה לתמוך בכל תרחישי השימוש של סביבות מרובות עננים. לדוגמה, פתרון מסד הנתונים הטוב ביותר לתרחיש לדוגמה של cloud bursting שונה מפתרון מסד הנתונים הטוב ביותר לאפליקציה שפועלת בו-זמנית בסביבות ענן מרובות.
בעננים ציבוריים כמו Google Cloud, יש טכנולוגיות שונות של מסדי נתונים שמתאימות לתרחישים ספציפיים של שימוש בענן מרובה. כדי לפרוס אפליקציה בכמה אזורים בענן ציבורי יחיד, אפשר להשתמש במסד נתונים ציבורי שמנוהל על ידי ספק הענן וממוקם במספר אזורים, כמו Spanner. כדי לפרוס אפליקציה שתהיה ניידת בין עננים ציבוריים, יכול להיות שעדיף להשתמש במסד נתונים בלתי תלוי בפלטפורמה, כמו AlloyDB Omni או PostgreSQL.
במסמך הזה מוגדרת אפליקציית מסד נתונים עם שמירת מצב, ואחרי כן מופיע ניתוח של תרחיש שימוש במסד נתונים מרובה-עננים. לאחר מכן, הוא מציג סיווג מפורט של מערכות מסדי נתונים לארכיטקטורות של פריסות בענן מרובה, על סמך תרחישי השימוש.
במסמך מוצג גם עץ החלטות לבחירת מסדי נתונים, שמתאר נקודות חשובות לבחירה של טכנולוגיית מסד נתונים מתאימה. בסיום הקורס יש דיון על שיטות מומלצות לניהול מסדי נתונים בענן מרובה.
מונחים והגדרות חשובים
בקטע הזה מוסבר על המינוח ומוגדרת אפליקציית מסד הנתונים הגנרית עם שמירת מצב (stateful) שמשמשת במסמך הזה.
הסברים על המונחים
- ענן ציבורי. ענן ציבורי מספק תשתית (בדרך כלל גלובלית) ושירותים שמשותפים לכמה לקוחות, והלקוחות יכולים להשתמש בהם כדי להריץ את עומסי העבודה של הייצור שלהם. Google Cloud הוא ענן ציבורי שמספק שירותים מנוהלים רבים, כולל GKE ומסדי נתונים מנוהלים.
- ענן היברידי. ענן היברידי הוא שילוב של ענן ציבורי עם מרכז נתונים מקומי אחד או יותר. לקוחות של ענן היברידי יכולים לשלב בין השירותים המקומיים שלהם לבין שירותים נוספים שמסופקים על ידי ענן ציבורי.
- Multicloud. סביבה מרובת-עננים היא שילוב של כמה עננים ציבוריים ומרכזי נתונים מקומיים. ענן היברידי הוא תת-קבוצה של מרובה עננים.
- מיקום הפריסה. מיקום תשתית הוא מיקום פיזי שבו אפשר לפרוס ולהפעיל עומסי עבודה, כולל אפליקציות ומסדי נתונים. לדוגמה, ב- Google Cloud, מיקומי הפריסה הם אזורים ותחומים. ברמה המופשטת, אזור או תחום בענן ציבורי ומרכז נתונים מקומי הם מיקומי פריסה.
אפליקציות של מסדי נתונים עם שמירת מצב
כדי להגדיר תרחישי שימוש במערכות מרובות עננים, במסמך הזה נעשה שימוש בארכיטקטורה של אפליקציית מסד נתונים כללית עם שמירת מצב, כמו שמוצג בתרשים הבא.
בתרשים מוצגים הרכיבים הבאים:
- מסד נתונים. מסד נתונים יכול להיות מופע יחיד, מופע מרובה או מסד נתונים מבוזר, שנפרס בצמתי מחשוב או זמין כשירות מנוהל בענן.
- שירותי אפליקציות. השירותים האלה משולבים כאפליקציה שמיישמת את הלוגיקה העסקית. שירותי האפליקציה יכולים להיות כל אחת מהאפשרויות הבאות:
- מיקרו-שירותים ב-Kubernetes.
- תהליכים גסים שפועלים במכונה וירטואלית אחת או יותר.
- אפליקציה מונוליתית במכונה וירטואלית גדולה אחת.
- קוד Serverless ב-Cloud Run functions או ב-Cloud Run. חלק משירותי האפליקציות יכולים לגשת למסד הנתונים. אפשר לפרוס כל שירות אפליקציה כמה פעמים. כל פריסה של שירות אפליקציה היא מופע של שירות האפליקציה הזה.
- אפליקציות לקוח. לקוחות של אפליקציות ניגשים לפונקציונליות שמסופקת על ידי שירותי האפליקציה. לקוחות אפליקציות יכולים להיות אחד מהבאים:
- לקוחות שפריסתם בוצעה, שבהם הקוד מופעל במחשב, במחשב נייד או בטלפון נייד.
- לקוחות שלא נפרסו, שבהם קוד הלקוח פועל בדפדפן. מופעים של לקוחות אפליקציות תמיד ניגשים למופע אחד או יותר של שירותי אפליקציות.
בדיון על מסד נתונים מרובה עננים, ההפשטה הארכיטקטונית של אפליקציה עם מצב כוללת מסד נתונים, שירותי אפליקציה ולקוחות אפליקציה. בהטמעה של אפליקציה, יכולים להיות הבדלים בין גורמים כמו השימוש במערכות הפעלה או בשפות התכנות שבהן נעשה שימוש. עם זאת, הפרטים האלה לא משפיעים על ניהול מסדי נתונים בענן מרובה ספקים.
תורים וקבצים כשירותי אחסון נתונים
יש הרבה משאבי אחסון נתונים שזמינים לשירותי אפליקציות. המקורות האלה כוללים מסדי נתונים, תורים וקבצים. כל משאב של אחסון נתונים מספק מודלים של אחסון נתונים ודפוסי גישה שמותאמים במיוחד למודלים האלה. אף על פי שאפליקציות משתמשות בתורים, במערכות הודעות ובמערכות קבצים, בקטע הבא נתמקד במסדי נתונים.
למרות שאותם שיקולים לגבי גורמים כמו מיקום הפריסה, שיתוף המצב, שכפול סינכרוני ואסינכרוני של מסדי נתונים מרובי-ענן רלוונטיים לתורים ולקבצים, הדיון הזה לא נכלל במסגרת המסמך הזה.
Networking
בארכיטקטורה של אפליקציה כללית עם שמירת מצב (שמוצגת שוב בתרשים הבא), כל חץ בין הרכיבים מייצג קשר תקשורת דרך חיבור לרשת – לדוגמה, לקוח של אפליקציה ניגש לשירות של אפליקציה.
החיבור יכול להיות בתוך אזור או בין אזורים, בין אזורים או בין עננים. יכולים להיות קשרים בין כל שילוב של מיקומי פריסה. בסביבות מרובות עננים, רשתות בין עננים הן שיקול חשוב, ויש כמה אפשרויות שבהן אפשר להשתמש. מידע נוסף על רשתות בענן זמין במאמרים רשתות חוצות ענן לאפליקציות מבוזרות וחיבור אל Google Cloud: הסבר על האפשרויות שלכם לרשתות.
בתרחישי השימוש שבמסמך הזה, ההנחה היא:
- קיים חיבור רשת מאובטח בין העננים.
- מסדי הנתונים והרכיבים שלהם יכולים לתקשר ביניהם.
מבחינה לא פונקציונלית, גודל הרשת, כלומר התפוקה וזמן האחזור, עשוי להשפיע על זמן האחזור והתפוקה של מסד הנתונים. מבחינה פונקציונלית, בדרך כלל אין השפעה לרשת.
תרחישים לדוגמה לשימוש במסדי נתונים מרובי עננים
בקטע הזה מוצג מבחר של תרחישים לדוגמה נפוצים לניהול מסדי נתונים מרובי-ענן. בתרחישי השימוש האלה, ההנחה היא שיש קישוריות מאובטחת לרשת בין העננים וצמתי מסד הנתונים.
העברת אפליקציות
בהקשר של ניהול מסדי נתונים בענן מרובה, העברת אפליקציות מתייחסת להעברה של אפליקציה, כל שירותי האפליקציה ומסד הנתונים מהענן הנוכחי לענן היעד. יש הרבה סיבות לכך שארגון עשוי להחליט להעביר אפליקציה, למשל כדי להימנע ממצב תחרותי עם ספק שירותי הענן, כדי לחדש את הטכנולוגיה או כדי להפחית את העלות הכוללת של הבעלות (TCO).
בהעברת אפליקציות, המטרה היא להפסיק את הייצור בענן הנוכחי ולהמשיך את הייצור בענן היעד אחרי שההעברה תושלם. שירותי האפליקציות צריכים לפעול בענן היעד. כדי להטמיע את השירותים, אפשר להשתמש בגישת lift and shift. בגישה הזו, אותו קוד נפרס בענן היעד. כדי להטמיע מחדש את השירות, אפשר להשתמש בטכנולוגיות ענן מודרניות שזמינות בענן היעד.
מנקודת מבט של מסד נתונים, כדאי לשקול את האפשרויות החלופיות הבאות להעברת אפליקציות:
- העברה של מסד נתונים בשיטת lift-and-shift: אם מנוע מסד הנתונים זהה לזה שזמין בענן היעד, אפשר להעביר את מסד הנתונים בשיטת lift-and-shift כדי ליצור פריסה זהה בענן היעד.
- העברה של מסד נתונים והעברה לגרסה מקבילה מנוהלת: אפשר להעביר מסד נתונים בניהול עצמי לגרסה מנוהלת של אותו מנוע מסד נתונים, אם ענן היעד מספק אותה.
- מודרניזציה של מסדי נתונים: עננים שונים מציעים טכנולוגיות שונות של מסדי נתונים. למסדי נתונים שמנוהלים על ידי ספק שירותי ענן יכולים להיות יתרונות כמו הסכמי רמת שירות (SLA) מחמירים יותר, מדרגיות ותוכנית התאוששות אוטומטית מאסון.
לא משנה מהי אסטרטגיית הפריסה, העברת מסד נתונים היא תהליך שלוקח זמן כי צריך להעביר נתונים מהענן הנוכחי לענן היעד. אפשר לייצא את הנתונים ואז לייבא אותם, אבל בגישה הזו יהיה זמן השבתה. לכן, עדיף לבצע העברה עם זמן השבתה מינימלי או ללא זמן השבתה. הגישה הזו מצמצמת את זמן ההשבתה של האפליקציה ומשפיעה הכי פחות על הארגון ועל הלקוחות שלו. עם זאת, בדרך כלל נדרשת הגדרת העברה מורכבת יותר, כי היא כוללת טעינה ראשונית, שכפול מתמשך, מעקב, אימות גרנולרי וסנכרון בעת המעבר. כדי לתמוך בתרחישי חזרה למצב הקודם, צריך להטמיע מנגנון שכפול הפוך כדי לסנכרן את השינויים בחזרה למסד הנתונים של המקור אחרי המעבר למסד הנתונים של היעד.
תוכנית התאוששות מאסון (DR)
תוכנית התאוששות מאסון (DR) מתייחסת ליכולת של אפליקציה להמשיך לספק שירותים ללקוחות האפליקציה במהלך הפסקת חשמל באזור. כדי להבטיח התאוששות מאסון, צריך לפרוס אפליקציה לפחות בשני אזורים ולהיות מוכנים להפעיל אותה בכל רגע. בסביבת הייצור, האפליקציה פועלת באזור הראשי. עם זאת, אם מתרחש שיבוש בשירות, אזור משני הופך לאזור הראשי. אלה מודלים שונים של מוכנות להתאוששות מאסון:
- המתנה פעילה. האפליקציה נפרסת בשני אזורים או יותר (ראשי ומשני), והיא פועלת באופן מלא בכל אזור. אם האזור הראשי נכשל, האפליקציה באזור המשני יכולה לקבל תנועת לקוחות של האפליקציה באופן מיידי.
- מצב המתנה קר. האפליקציה פועלת באזור הראשי, אבל היא מוכנה להפעלה באזור משני (אבל לא פועלת). אם האזור הראשי נכשל, האפליקציה מופעלת באזור המשני. השבתה של אפליקציה מתרחשת עד שהאפליקציה יכולה לפעול ולספק את כל שירותי האפליקציה ללקוחות האפליקציה.
- אין המתנה. במודל הזה, קוד האפליקציה מוכן לפריסה אבל עדיין לא נפרס באזור המשני (ולכן לא נעשה שימוש במשאבים שנפרסו). אם יש הפסקת חשמל באזור הראשי, הפריסה הראשונה של האפליקציה חייבת להיות באזור המשני. הפריסה הזו מעבירה את האפליקציה למצב זהה למצב המתנה קרה, כלומר צריך להפעיל אותה. בגישה הזו, משך ההשבתה של האפליקציה ארוך יותר בהשוואה למקרה של המתנה קרה, כי צריך קודם לפרוס את האפליקציה, כולל יצירת משאבי ענן.
מנקודת מבט של מסד נתונים, מודלים של מוכנות שמוזכרים ברשימה הקודמת תואמים לגישות הבאות למסד נתונים:
- מסד נתונים שמסונכרן ברמת העסקה. מסד הנתונים הזה תואם למודל של המתנה פעילה. כל טרנזקציה באזור הראשי מאושרת בתיאום סינכרוני באזור משני. כשאזור המשנה הופך לאזור הראשי במהלך הפסקת שירות, מסד הנתונים עקבי וזמין באופן מיידי. במודל הזה, היעד להתאוששות מאסון (RPO) ומשך ההתאוששות (RTO) הם אפס.
- מסד נתונים שמשוכפל באופן אסינכרוני. מסד הנתונים הזה תואם גם למודל של המתנה פעילה. הרפליקציה של מסד הנתונים מהאזור הראשי לאזור המשני היא אסינכרונית, ולכן יכול להיות שאם האזור הראשי ייכשל, חלק מהעסקאות ישוכפלו לאזור המשני. המסד הנתונים באזור המשני מוכן לטעינת נתונים של סביבת ייצור, אבל יכול להיות שהנתונים שבו לא יהיו עדכניים. לכן, יכול להיות שהאפליקציה תאבד טרנזקציות שלא ניתן לשחזר. בגלל הסיכון הזה, ה-RTO של הגישה הזו הוא אפס, אבל ה-RPO גדול מאפס.
- מסד נתונים במצב המתנה. מסד הנתונים הזה תואם למודל של המתנה קרה. מסד הנתונים נוצר ללא נתונים. אם האזור הראשי נכשל, צריך לטעון את הנתונים למסד הנתונים במצב המתנה. כדי לבצע את הפעולה הזו, צריך לבצע גיבוי רגיל באזור הראשי ולהעביר אותו לאזור המשני. הגיבוי יכול להיות מלא או מצטבר, בהתאם לתמיכה של המנוע של מסד הנתונים. בכל מקרה, מסד הנתונים חוזר לגיבוי האחרון, ומנקודת המבט של האפליקציה, יכול להיות שיהיו הרבה טרנזקציות חסרות בהשוואה לאזור הראשי. הגישה הזו עשויה להיות חסכונית, אבל הערך שלה מוגבל בגלל הסיכון שכל העסקאות מאז הגיבוי האחרון יאבדו כי מצב מסד הנתונים לא עדכני.
- אין מסד נתונים. המודל הזה שווה למקרה ללא המתנה. לא מותקן מסד נתונים באזור המשני, ואם האזור הראשי נכשל, צריך ליצור מסד נתונים. אחרי שיוצרים את מסד הנתונים, כמו במקרה של מסד נתונים במצב המתנה, צריך לטעון בו נתונים לפני שהאפליקציה יכולה לגשת אליו.
הגישות להתאוששות מאסון שמתוארות במסמך הזה רלוונטיות גם אם משתמשים בענן ראשי ובענן משני במקום באזור ראשי ובאזור משני. ההבדל העיקרי הוא שבגלל ההטרוגניות של הרשת בין העננים, זמן האחזור בין העננים עשוי להיות ארוך יותר בהשוואה למרחק ברשת בין אזורים בענן. פערים אחרים יכולים לנבוע מתכונות שונות ומברירות מחדל שונות של מסדי נתונים מנוהלים של ספקי ענן שונים.
הסבירות לכשל בענן שלם נמוכה יותר מהסבירות לכשל באזור. עם זאת, יכול להיות שעדיין יהיה שימוש לארגונים בפריסת אפליקציה בשני עננים. הגישה הזו יכולה לעזור להגן על ארגון מפני כשלים, או לעזור לו לעמוד בתקנות עסקיות או בתקנות של הענף.
גישה נוספת להתאוששות מאסון היא להגדיר אזור ראשי ואזור משני, וענן ראשי וענן משני. הגישה הזו מאפשרת לארגונים לבחור את תהליך ההתאוששות מאסון המתאים ביותר לטיפול במצב של כשל. כדי לאפשר לאפליקציה לפעול, אפשר להשתמש באזור משני או בענן משני, בהתאם לחומרת ההשבתה.
Cloud bursting
Cloud bursting הוא מונח שמתייחס להגדרה שמאפשרת להגדיל את נפח התנועה של לקוחות האפליקציה במיקומי פריסה שונים. אפליקציה מתפרצת כשהביקוש לקיבולת גדל ומיקום בהמתנה מספק קיבולת נוספת. מיקום ראשי תומך בתנועה הרגילה, בעוד שמיקום המתנה יכול לספק קיבולת נוספת במקרה של עלייה בתנועת הלקוחות של האפליקציה מעבר למה שהמיקום הראשי יכול לתמוך בו. גם במיקום הראשי וגם במיקום המשני יש פריסה של מופעים של שירותי אפליקציות.
Cloud bursting מיושם בעננים שונים, כאשר ענן אחד הוא הענן הראשי וענן שני הוא ענן ההמתנה. הוא משמש בהקשר של ענן היברידי כדי להגדיל מספר מוגבל של משאבי מחשוב במרכזי נתונים מקומיים באמצעות משאבי מחשוב גמישים בענן בענן ציבורי.
אלה האפשרויות הזמינות לתמיכה במסדי נתונים:
- פריסת המיקום הראשי. בפריסה הזו, מסד הנתונים נפרס רק במיקום הראשי ולא במיקום ההמתנה. כשמתרחש שימוש חריג באפליקציה, האפליקציה במיקום ההמתנה ניגשת למסד הנתונים במיקום הראשי.
- פריסת מיקום ראשי ומיקום גיבוי. הפריסה הזו תומכת במיקום הראשי ובמיקום הגיבוי. מופע של מסד נתונים נפרס בשני המיקומים, והגישה אליו מתבצעת על ידי מופעים של שירות האפליקציה באותו מיקום, במיוחד במקרה של שימוש בקיבולת נוספת. כמו במאמר בנושא תוכנית התאוששות מאסון (DR) בענן אחד או בכמה עננים, אפשר לסנכרן את שני מסדי הנתונים באופן טרנזקציונלי או באופן אסינכרוני. בסנכרון אסינכרוני, יכול להיות עיכוב. אם מתבצעים עדכונים במיקום ההמתנה, צריך להעביר את העדכונים האלה בחזרה למיקום הראשי. אם אפשר לבצע עדכונים בו-זמנית בשני המיקומים, צריך להטמיע פתרון לסתירות.
פריצת ענן היא תרחיש נפוץ לשימוש בעננים היברידיים כדי להגדיל את הקיבולת במרכזי נתונים מקומיים. זו גם גישה שאפשר להשתמש בה בעננים ציבוריים כשצריך שהנתונים יישארו בתוך מדינה מסוימת. במצבים שבהם יש לענן ציבורי רק אזור אחד במדינה מסוימת, אפשר להשתמש ב-bursting לאזור בענן ציבורי אחר באותה מדינה. הגישה הזו מבטיחה שהנתונים יישארו בתוך המדינה, ועדיין תאפשר לטפל במגבלות המשאבים באזור של אזורי הענן הציבורי.
שימוש בשירותי ענן ברמה הגבוהה ביותר
באפליקציות מסוימות נדרשים מוצרים ושירותי ענן מיוחדים שלא זמינים בענן יחיד. לדוגמה, אפליקציה יכולה לבצע עיבוד של לוגיקה עסקית של נתונים עסקיים בענן אחד, וניתוח של הנתונים העסקיים בענן אחר. בתרחיש השימוש הזה, החלקים של עיבוד הלוגיקה העסקית והחלקים של הניתוח של האפליקציה נפרסים בעננים שונים.
מבחינת ניהול נתונים, אלה תרחישי השימוש:
- נתונים מחולקים. לכל חלק באפליקציה יש מסד נתונים משלו (מחיצה נפרדת), ואף אחד ממסדי הנתונים לא מחובר ישירות למסד נתונים אחר. האפליקציה שמנהלת את הנתונים כותבת כל נתון שצריך להיות זמין בשני מסדי הנתונים (המחיצות) פעמיים.
- מסד נתונים שמשוכפל באופן אסינכרוני. אם נתונים מענן אחד צריכים להיות זמינים בענן אחר, יכול להיות שיהיה מתאים להשתמש בקשר שכפול אסינכרוני. לדוגמה, אם אפליקציית ניתוח נתונים דורשת את אותו מערך נתונים או קבוצת משנה של מערך הנתונים עבור אפליקציה עסקית, אפשר לשכפל את מערך הנתונים בין העננים.
- מסד נתונים שמסונכרן ברמת העסקה. במסדי נתונים כאלה אפשר להפוך את הנתונים לזמינים לשני חלקי האפליקציה. כל עדכון מכל אחת מהאפליקציות עקבי מבחינת טרנזקציות וזמין לשני מסדי הנתונים (המחיצות) באופן מיידי. מסדי נתונים שמסונכרנים בטרנזקציות פועלים למעשה כמסד נתונים מבוזר יחיד.
שירותים מבוזרים
שירות מבוזר נפרס ומופעל בשני מיקומי פריסה או יותר. אפשר לפרוס את כל מופעי השירות בכל מיקומי הפריסה. לחלופין, אפשר לפרוס חלק מהשירותים בכל המיקומים וחלק רק באחד מהמיקומים, בהתאם לגורמים כמו זמינות חומרה או עומס מוגבל צפוי.
הנתונים במסד נתונים שמסונכרן באופן טרנזקציוני עקביים בכל המיקומים. לכן, מסד נתונים כזה הוא האפשרות הטובה ביותר לפריסת מופעי שירות בכל מיקומי הפריסה.
כשמשתמשים במסד נתונים משוכפל אסינכרוני, יש סיכון שפריט נתונים זהה ישונה בו-זמנית בשני מיקומי פריסה. כדי לקבוע איזה מבין שני השינויים המתנגשים הוא המצב העקבי הסופי, צריך להטמיע אסטרטגיה לפתרון קונפליקטים. אפשר ליישם אסטרטגיה לפתרון קונפליקטים, אבל זה לא תמיד פשוט, ויש מקרים שבהם נדרבת התערבות ידנית כדי לשחזר את הנתונים למצב עקבי.
העברה של שירות מבוזר וגיבוי במקרה של כשל
אם אזור שלם בענן נכשל, מתחיל תהליך של התאוששות מאסון. אם שירות יחיד באפליקציית מסד נתונים עם שמירת מצב נכשל (לא האזור או האפליקציה כולה), צריך לשחזר את השירות ולהפעיל אותו מחדש.
גישה ראשונית להתאוששות מאסון היא הפעלה מחדש של השירות שנכשל במיקום הפריסה המקורי שלו (גישה של הפעלה מחדש במקום). טכנולוגיות כמו Kubernetes מפעילות מחדש שירות באופן אוטומטי על סמך ההגדרה שלו.
עם זאת, אם הגישה הזו של הפעלה מחדש במקום לא מצליחה, אפשרות חלופית היא להפעיל מחדש את השירות במיקום משני. השירות עובר ממיקום ראשי למיקום משני. אם האפליקציה נפרסת כקבוצה של שירותים מבוזרים, המעבר לגיבוי (failover) של שירות יחיד יכול להתבצע באופן דינמי.
מנקודת מבט של מסד נתונים, הפעלה מחדש של השירות במיקום הפריסה המקורי שלו לא דורשת פריסה ספציפית של מסד נתונים. כשמעבירים שירות למיקום פריסה חלופי והשירות ניגש למסד הנתונים, חלים אותם מודלים של מוכנות שנדונו קודם במסמך בקטע שירותים מבוזרים.
אם שירות מסוים מועבר באופן זמני, ואם זמן האחזור הגבוה יותר מקובל על הארגון במהלך ההעברה, השירות יכול לגשת למסד הנתונים במיקומי הפריסה. למרות שהשירות מועבר, הוא ממשיך לגשת למסד הנתונים באותה דרך שבה הוא ניגש אליו ממיקום הפריסה המקורי שלו.
פריסה שתלויה בהקשר
בדרך כלל, פריסה של אפליקציה אחת שמיועדת לכל לקוחות האפליקציה כוללת את כל שירותי האפליקציה ומסדי הנתונים שלה. עם זאת, יש מקרים חריגים. פריסה של אפליקציה אחת יכולה לשרת רק קבוצת משנה של לקוחות (על סמך קריטריונים ספציפיים), ולכן נדרשת יותר מפריסה אחת של אפליקציה. כל פריסה משרתת קבוצת משנה שונה של לקוחות, וכל הפריסות יחד משרתות את כל הלקוחות.
הנה כמה תרחישים לדוגמה לפריסה שתלויה בהקשר:
- כשפורסים אפליקציה מרובת דיירים שבה אפליקציה אחת נפרסת לכל הדיירים הקטנים, אפליקציה אחרת נפרסת לכל 10 דיירים בינוניים ואפליקציה אחת נפרסת לכל דייר פרימיום.
- כשצריך להפריד בין לקוחות, למשל לקוחות עסקיים ולקוחות ממשלתיים.
- כשצריך להפריד בין סביבות פיתוח, Staging וייצור.
מנקודת המבט של מסד הנתונים, אפשר לפרוס מסד נתונים אחד לכל פריסת אפליקציה במסגרת אסטרטגיית פריסה של אחד לאחד. כפי שמוצג בדיאגרמה הבאה, אסטרטגיה זו היא גישה פשוטה שבה נוצרים נתונים מחולקים כי לכל Deployment (פריסה) יש קבוצת נתונים משלה.
בתרשים שלמעלה מוצגים:
- הגדרה עם שלוש פריסות של אפליקציה.
- לכל מערך נתונים יש מסד נתונים משלו.
- לא מתבצע שיתוף נתונים בין הפריסות.
במקרים רבים, פריסה של מכשיר אחד לכל משתמש היא האסטרטגיה המתאימה ביותר, אבל יש גם חלופות.
במקרה של ריבוי דיירים, יכול להיות שהדיירים יועברו למיקום אחר. יכול להיות שדייר קטן יהפוך לדייר בינוני ויהיה צורך להעביר אותו לאפליקציה אחרת. במקרה כזה, פריסות נפרדות של מסדי נתונים מחייבות העברה של מסד הנתונים. אם מסד נתונים מבוזר נפרס ומשמש את כל הפריסות בו-זמנית, כל נתוני הדיירים נמצאים במערכת מסד נתונים אחת. לכן, כדי להעביר דייר בין מסדי נתונים לא צריך להעביר את מסד הנתונים. התרשים הבא מציג דוגמה למסד נתונים מסוג כזה:
בתרשים שלמעלה מוצגים:
- שלוש פריסות של אפליקציה.
- כל הפריסות חולקות מסד נתונים מבוזר יחיד.
- לאפליקציות יש גישה לכל הנתונים בכל פריסה.
- לא מיושם חלוקת נתונים.
אם ארגון מעביר לעיתים קרובות דיירים כחלק מפעולות מחזור החיים, שכפול מסד נתונים עשוי להיות חלופה שימושית. בגישה הזו, נתוני הדייר משוכפלים בין מסדי נתונים לפני העברת הדייר. במקרה הזה, נעשה שימוש במסדי נתונים עצמאיים לפריסות שונות של אפליקציות, והם מוגדרים לשכפול רק לפני העברת הדייר ובמהלכה. הדיאגרמה הבאה מציגה שכפול זמני בין שני פריסות של אפליקציות במהלך העברת דייר.
בתרשים שלמעלה מוצגים שלושה פריסות של אפליקציה עם שלושה מסדי נתונים נפרדים שמכילים את הנתונים שמשויכים לכל פריסה. כדי להעביר נתונים ממסד נתונים אחד למסד נתונים אחר, אפשר להגדיר העברה זמנית של מסד נתונים.
ניידות של אפליקציות
ניידות של אפליקציות מבטיחה שאפשר לפרוס אפליקציה במיקומי פריסה שונים, במיוחד בעננים שונים. הניידות הזו מבטיחה שאפשר להעביר אפליקציה בכל שלב, בלי שיהיה צורך בהנדסה מחדש ספציפית להעברה או בפיתוח אפליקציה נוספת כדי להתכונן להעברת אפליקציה.
כדי להבטיח ניידות של האפליקציה, אפשר להשתמש באחת מהגישות הבאות, שמתוארות בהמשך הקטע הזה:
- ניידות מבוססת-מערכת
- תאימות ל-API
- ניידות מידע שמבוססת על פונקציונליות
ניידות מבוססת-מערכת משתמשת באותם רכיבים טכניים שמשמשים בכל הפריסות האפשריות. כדי להבטיח ניידות מבוססת-מערכת, כל טכנולוגיה צריכה להיות זמינה בכל המיקומים הפוטנציאליים לפריסה. לדוגמה, אם מסד נתונים כמו PostgreSQL הוא מועמד, צריך לוודא שהוא זמין בכל מיקומי הפריסה הפוטנציאליים בפרק הזמן הצפוי. הכלל הזה נכון גם לגבי כל הטכנולוגיות האחרות – לדוגמה, שפות תכנות וטכנולוגיות תשתית. כפי שמוצג בדיאגרמה הבאה, גישה זו יוצרת קבוצה של פונקציות משותפות בכל מיקומי ה-Deployment (פריסה) על בסיס טכנולוגיה.
בתרשים שלמעלה מוצג פריסת אפליקציה ניידת שבה האפליקציה מצפה לאותה מערכת מסד נתונים בדיוק בכל מיקום שבו היא נפרסת. מכיוון שמשתמשים באותה מערכת מסדי נתונים בכל מיקום, האפליקציה ניידת. האפליקציה יכולה לצפות שאותה מערכת מסד נתונים בדיוק תשמש בכל הפריסה. לכן, אפשר להניח שיהיו בדיוק אותו ממשק ואותה התנהגות של מערכת מסד הנתונים.
בהקשר של מסדי נתונים, במערכת התאימות ל-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, כמו שינוי גודל, ריבוי שירותים או פריסה של כמה pods.
יכול להיות שספקי מסדי נתונים ישתפו פעולה עם יותר מספק שירותי ענן אחד בו-זמנית, ויציעו את מסד הנתונים שלהם כמסד נתונים מנוהל על ידי שותף בענן ביותר מענן ציבורי אחד.
מערכת מסד נתונים לפי מודל הפצה
מערכות שונות לניהול מסדי נתונים מיושמות בהתאם למודלים של הפצה בארכיטקטורה של מסד נתונים. המודלים למסדי נתונים הם:
- מופע יחיד. מופע יחיד של מסד נתונים פועל במכונה וירטואלית אחת או בקונטיינר אחד, ומשמש כמערכת מרכזית. המערכת הזו מנהלת את כל הגישה למסד הנתונים. מכיוון שאי אפשר לחבר את המופע היחיד למופע אחר, מערכת מסד הנתונים לא תומכת בשכפול.
- פעיל-סביל עם כמה מופעים במקביל. בארכיטקטורה הנפוצה הזו, כמה מופעים של מסדי נתונים מקושרים זה לזה. הקישור הנפוץ ביותר הוא יחס פעיל-סביל, שבו מופע אחד הוא מופע מסד הנתונים הפעיל שתומך בשני המופעים, וגם כותב וגם קורא. מערכת פסיבית אחת או יותר הן לקריאה בלבד, והן מקבלות את כל השינויים במסד הנתונים מהמערכת הראשית באופן סינכרוני או אסינכרוני. מערכות פסיביות יכולות לספק גישת קריאה. המונח 'פעיל-סביל' נקרא גם 'ראשי-משני' או 'מקור-עותק'.
- פעיל-פעיל עם כמה מופעים במקביל. באופן יחסי, בארכיטקטורה לא נפוצה הזו, כל מופע הוא מופע פעיל. במקרה כזה, כל מופע יכול לבצע עסקאות קריאה וכתיבה ולספק עקביות נתונים. לכן, כדי למנוע חוסר עקביות בנתונים, כל המופעים מסונכרנים תמיד.
- פעיל-פעיל עם כמה מופעים במקביל ופתרון התנגשויות. זו גם מערכת יחסית לא נפוצה. כל מופע זמין לגישת קריאה וכתיבה, אבל מסדי הנתונים מסונכרנים במצב אסינכרוני. מותר לבצע עדכונים בו-זמניים של אותו פריט נתונים, מה שמוביל למצב לא עקבי. מדיניות לפתרון קונפליקטים צריכה לקבוע איזו מהמדינות היא המדינה העקבית האחרונה.
- חלוקת מסד נתונים לכמה מופעים במקביל. החלוקה לשברים מבוססת על ניהול של מחיצות (לא חופפות) של נתונים. כל מחיצה מנוהלת על ידי מופע נפרד של מסד נתונים. החלוקה הזו ניתנת להרחבה כי אפשר להוסיף עוד רסיסים באופן דינמי לאורך זמן. עם זאת, יכול להיות שלא ניתן יהיה לבצע שאילתות חוצות-שארדים, כי לא כל המערכות תומכות בפונקציונליות הזו.
כל מודלי ההפצה שמוסברים בקטע הזה יכולים לתמוך בפיצול (sharding) ולהיות מערכת מפולחת. עם זאת, לא כל המערכות מתוכננות לספק אפשרות של חלוקה למקטעים. חלוקה למקטעים היא מושג שקשור למדרגיות, ובדרך כלל הוא לא רלוונטי לבחירת ארכיטקטורת מסד נתונים בסביבות מרובות עננים.
מודלים של הפצה שונים במסדי נתונים בענן ובמסדי נתונים שמנוהלים על ידי שותפים. מכיוון שמסדי הנתונים האלה קשורים לארכיטקטורה של ספק שירותי ענן, המערכות האלה מיישמות ארכיטקטורות שמבוססות על מיקומי הפריסה הבאים:
- מערכת אזורית. מערכת מסדי נתונים שמנוהלת לפי אזור קשורה לאזור. כשהאזור זמין, גם מערכת מסד הנתונים זמינה. עם זאת, אם האזור לא זמין, אי אפשר לגשת למסד הנתונים.
- מערכת אזורית. מסד נתונים אזורי מנוהל קשור לאזור וניתן לגשת אליו כשניתן לגשת לאזור אחד לפחות. יכול להיות שלא תהיה גישה לשילוב כלשהו של אזורים.
- מערכת חוצה אזורים. מערכת חוצת-אזורים קשורה לשני אזורים או יותר, והיא פועלת בצורה תקינה כשזמין לפחות אזור אחד.
מערכת חוצת-אזורים יכולה לתמוך גם במערכת חוצת-עננים, אם אפשר להתקין את מסד הנתונים בכל העננים שהארגון מתכוון להשתמש בהם.
יש חלופות אפשריות אחרות לארכיטקטורות של מסדי נתונים מנוהלים שמוסברות בקטע הזה. מערכת אזורית עשויה לשתף דיסק בין שני אזורים. אם אחת משתי האזורים הופכת ללא נגישה, מערכת מסד הנתונים יכולה להמשיך לפעול באזור השני. עם זאת, אם הפסקה זמנית בשירות משפיעה על שני האזורים, מערכת מסד הנתונים לא זמינה, גם אם אזורים אחרים עדיין זמינים באופן מלא.
מיפוי של מערכות מסדי נתונים לדפוסי פריסה
בטבלה הבאה מתואר הקשר בין דפוסי הפריסה וארכיטקטורות הפריסה שמוסברים במסמך הזה. בשדות מפורטים התנאים שצריכים להתקיים כדי שהשילוב יהיה אפשרי, על סמך דפוס הפריסה וארכיטקטורת הפריסה.
| ארכיטקטורת פריסה | תבנית פריסה | ||||
|---|---|---|---|---|---|
| חלוקה למחיצות ללא תלות במסד נתונים | רפליקציה אסינכרונית חד-כיוונית | שכפול דו-כיווני עם יישוב מחלוקות | מערכת מבוזרת מסונכרנת באופן מלא במצב פעיל-פעיל | ||
| מסדי נתונים מובנים בענן | אפשר להשתמש בטכנולוגיה הזו בכל העננים שמספקים טכנולוגיית ענן מובנית שמשמשת מערכות מסדי נתונים.
אם אותו מסד נתונים לא זמין, אפשר להשתמש במערכות שונות של מסדי נתונים. |
מסד נתונים בענן שמספק שכפול. | מסד נתונים בענן שמספק שכפול דו-כיווני. | מסד נתונים בענן שמספק סנכרון ראשי-ראשי. | |
| מסדי נתונים שמנוהלים על ידי ספק הענן | מערכות מסדי נתונים יכולות להיות שונות בעננים שונים. | העותק לא חייב להיות מסד נתונים שמנוהל על ידי ספק הענן (ראו התפקיד של טכנולוגיית העברת מסדי נתונים בדפוסי פריסה). | רק בענן אחד, ולא בין עננים, אם מסד הנתונים מספק שכפול דו-כיווני. | רק בתוך ענן, לא בין עננים, אם מסד הנתונים מספק סנכרון ראשי-ראשי. | |
| מסדי נתונים לפני המעבר לענן | מערכות מסדי הנתונים יכולות להיות זהות או שונות בעננים שונים. | אפשר לבצע שכפול בכמה עננים. | מערכת מסד הנתונים מספקת שכפול דו-כיווני ופתרון של קונפליקטים. | מערכת מסד הנתונים מספקת סנכרון ראשי-ראשי. | |
| מסדי נתונים בענן בניהול שותף | מערכות מסדי נתונים יכולות להיות שונות בעננים שונים.
אם השותף מספק מערכת מסדי נתונים מנוהלת בכל העננים הנדרשים, אפשר להשתמש באותו מסד נתונים. |
השכפול לא חייב להיות מסד נתונים שמנוהל על ידי ספק הענן. אם השותף מספק מערכת מסדי נתונים מנוהלת בכל העננים הנדרשים, אפשר להשתמש באותו מסד נתונים. |
מערכת מסד הנתונים מספקת שכפול דו-כיווני ופתרון של קונפליקטים. | מערכת מסד הנתונים מספקת סנכרון ראשי-ראשי. | |
אם מערכת מסד נתונים לא מספקת שכפול מובנה, יכול להיות שאפשר להשתמש בטכנולוגיית שכפול של מסד נתונים במקום זאת. מידע נוסף זמין במאמר התפקיד של טכנולוגיית העברת מסדי נתונים בתבניות פריסה.
בטבלה הבאה מפורטים דפוסי הפריסה בהתאם למודלים של הפצה. בשדות מצוינים התנאים שבהם השילוב אפשרי בהתאם לדפוס הפריסה ולמודל ההפצה.
| מודל הפצה | תבנית פריסה | ||||
|---|---|---|---|---|---|
| חלוקה למחיצות ללא תלות במסד נתונים | רפליקציה אסינכרונית חד-כיוונית | שכפול דו-כיווני עם יישוב מחלוקות | מערכת מבוזרת מסונכרנת באופן מלא במצב פעיל-פעיל | ||
| מופע יחיד | אפשר להשתמש באותה מערכת מסדי נתונים או במערכות שונות בעננים הרלוונטיים. | לא רלוונטי | לא רלוונטי | לא רלוונטי | |
| מצב פעיל-סביל עם כמה מופעים במקביל | אפשר לעשות זאת עם אותה מערכת מסדי נתונים או עם מערכות שונות בעננים הרלוונטיים. | אפשר לבצע שכפול בין עננים. | אפשר לבצע שכפול בין עננים. | לא רלוונטי | |
| מצב פעיל-פעיל עם כמה מופעים במקביל | אפשר לעשות זאת עם אותה מערכת מסדי נתונים או עם מערכות שונות בעננים הרלוונטיים. | לא רלוונטי | לא רלוונטי | אפשר לבצע סנכרון בין עננים שונים. | |
| מצב פעיל-פעיל עם כמה מופעים במקביל ופתרון התנגשויות | אפשר לעשות זאת עם אותה מערכת מסדי נתונים או עם מערכות שונות בעננים הרלוונטיים. | לא רלוונטי | לא רלוונטי | רלוונטי אם אפשר לבצע רפליקציה דו-כיוונית בין עננים. | |
ביישומים מסוימים של מודלים להפצה שמוסיפים הפשטה נוספת על סמך טכנולוגיית מסד הנתונים הבסיסית, אין מודל הפצה כזה שמוטמע בהם – לדוגמה, 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). כדי לספק זמינות גבוהה, המערכת צריכה להמשיך לפעול כשמתרחש כשל באזור בתוך אזור. מסד הנתונים צריך להיות מסוגל לבצע מעבר מהיר לגיבוי (failover) מאזור אחד לאזור אחר. במקרה הטוב ביותר, במסד הנתונים פועל מופע בכל אזור, והוא מסונכרן באופן מלא עם 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