איך לשרוד מסד נתונים SQL במאה ה-21: עננים, Kubernetes ו-PostgreSQL multimaster

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

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

הוובינר נערך ולרי בזרוקוב, Google Cloud Practice Delivery Manager ב-EPAM Systems.

כשהעצים היו קטנים...

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

בסוף שנות ה-90 ותחילת שנות ה-2, בעצם לא הייתה ברירה בכל הנוגע לבסיסי נתונים תעשייתיים הניתנים להרחבה. כן, היו IBM DBXNUMX, Sybase ועוד כמה מסדי נתונים שהגיעו והלכו, אבל באופן כללי הם לא היו כל כך מורגשים על רקע אורקל. בהתאם לכך, הכישורים של המהנדסים של אותם זמנים היו קשורים איכשהו לבחירה היחידה שקיימת.

Oracle DBA היה צריך להיות מסוגל:

• התקן את Oracle Server מערך ההפצה;
• להגדיר את Oracle Server:

• init.ora;
• listener.ora;

- ליצור:

• מרחבי שולחן;
• תָכְנִית;
• משתמשים;

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

יחד עם זאת, לא הייתה דרישה מיוחדת מ-Oracle DBA:

• להיות מסוגל לבחור את ה-DBMS האופטימלי או טכנולוגיה אחרת לאחסון ועיבוד נתונים;
• לספק זמינות גבוהה ומדרגיות אופקית (זו לא תמיד הייתה בעיה של DBA);
• ידע טוב בתחום הנושא, תשתית, ארכיטקטורת יישומים, מערכת הפעלה;
• לטעון ולפרוק נתונים, להעביר נתונים בין DBMSs שונים.

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

הזמן שלנו

מאז, כמובן, העצים גדלו, העולם השתנה, וזה הפך למשהו כזה:

גם שוק ה-DBMS השתנה, כפי שניתן לראות בבירור מהדוח האחרון של גרטנר:

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

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

מה עכשיו?

היום כולנו בענן. והשאלות שעולות עבורנו הן שאלות של בחירה. וזה ענק, גם אם נדבר רק על הבחירה בטכנולוגיות DBMS בפורמט On-premises. יש לנו גם שירותים מנוהלים ו-SaaS. כך, הבחירה רק הופכת קשה יותר מדי שנה.

יחד עם שאלות של בחירה, יש גם גורמים מגבילים:

• מחיר. טכנולוגיות רבות עדיין עולות כסף;
• כישורים. אם אנחנו מדברים על תוכנה חופשית, אז עולה שאלת הכישורים, שכן תוכנה חופשית דורשת יכולת מספקת מהאנשים שפורסים ומתפעלים אותה;
• פוּנקצִיוֹנָלִי. לא לכל השירותים הזמינים בענן ובנויים, למשל, אפילו על אותו Postgres, יש את אותן תכונות כמו Postgres On-premises. זהו גורם חיוני שצריך לדעת ולהבין. יתר על כן, גורם זה הופך חשוב יותר מהידע על כמה יכולות נסתרות של DBMS יחיד.

מה צפוי מ-DA/DE כעת:

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

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

שימו לב ש-PostgreSQL אינו כלול בסכימה, וזאת משום שהוא מוסתר תחת המינוח ענן SQL. וכשנגיע ל-Cloud SQL, אנחנו צריכים לעשות בחירה שוב:

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

סך הכל:

1. ככל שמתקדמים יותר, כך שאלת הבחירה הופכת דחופה יותר. וגם אם מסתכלים רק על GCP, שירותים מנוהלים ו-SaaS, אז איזשהו אזכור של RDBMS מופיע רק בשלב הרביעי (ושם Spanner נמצא בקרבת מקום). בנוסף, הבחירה ב-PostgreSQL מופיעה בשלב ה-4, ולצידה יש ​​גם MySQL ו-SQL Server, כלומר יש הרבה מהכל, אבל צריך לבחור.
2. אסור לשכוח מגבלות על רקע פיתויים. בעצם כולם רוצים Spanner, אבל זה יקר. כתוצאה מכך, בקשה טיפוסית נראית בערך כך: "בבקשה תעשה לנו Spanner אבל במחיר של Cloud SQL, אתם מקצוענים!"

אבל מה לעשות?

בלי לטעון שהם האמת האולטימטיבית, בואו נגיד את הדברים הבאים:

עלינו לשנות את הגישה שלנו ללמידה:

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

אתה צריך לדעת לא רק ולא כמה המוצר, אלא:

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

אתה גם צריך להיות מסוגל להעביר נתונים ולהבין את העקרונות הבסיסיים של אינטגרציה עם ETL.

מקרה אמיתי

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

• לבנות CI/CD;
• סקור את הארכיטקטורה;
• להכניס את הכל לפעולה.

האפליקציה עצמה הייתה microservices, וקוד Python/Django פותח מאפס וישיר ב-GCP. לגבי קהל היעד, ההנחה הייתה שיהיו שני אזורים - ארה"ב והאיחוד האירופי, והתנועה הופצה דרך מאזן העומס העולמי. כל עומסי העבודה ועומס העבודה המחשוב פעלו ב-Google Kubernetes Engine.

באשר לנתונים, היו 3 מבנים:

• אחסון בענן;
• חנות מידע;
• Cloud SQL (PostgreSQL).

אפשר לתהות מדוע נבחר Cloud SQL? אם לומר את האמת, שאלה כזו עוררה איזושהי הפסקה מביכה בשנים האחרונות - יש תחושה שאנשים התביישו במאגרי מידע יחסיים, אבל בכל זאת ממשיכים להשתמש בהם באופן פעיל ;-).

באשר למקרה שלנו, Cloud SQL נבחר מהסיבות הבאות:

1. כאמור, האפליקציה פותחה באמצעות Django, ויש לה מודל למיפוי נתונים מתמידים מבסיס נתונים SQL לאובייקטים של Python (Django ORM).
2. המסגרת עצמה תמכה ברשימה די סופית של DBMSs:

• PostgreSQL;
• MariaDB;
• MySQL;
• נבואה;
• SQLite.

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

מה היה חסר:

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

למרות העובדה ש-Django עצמה יכולה לעבוד עם מספר בסיסי נתונים במקביל ולחלק אותם לקריאה וכתיבה, לא הייתה כל כך הרבה כתיבה באפליקציה (יותר מ-90% היא קריאה). ובכלל, ובכלל, אם אפשר היה לעשות רפליקה של הבסיס הראשי באירופה ובאסיה, זה יהיה פתרון פשרה. נו, מה כל כך מסובך בזה?

הקושי היה שהלקוח לא רצה לוותר על שימוש בשירותים מנוהלים וב-Cloud SQL. והיכולות של Cloud SQL מוגבלות כרגע. Cloud SQL תומך בזמינות גבוהה (HA) ו-Replica (RR), אך אותו RR נתמך רק באזור אחד. לאחר שיצרת מסד נתונים באזור אמריקה, אינך יכול ליצור העתק קריאה באזור אירופה באמצעות Cloud SQL, למרות ש-Postgres עצמה לא מונעת ממך לעשות זאת. ההתכתבות עם עובדי גוגל לא הובילה לשום מקום והסתיימה בהבטחות בסגנון "אנחנו מכירים את הבעיה ועובדים עליה, מתישהו הנושא ייפתר".

אם נרשום בקצרה את היכולות של Cloud SQL, זה ייראה בערך כך:

1. זמינות גבוהה (HA):

• בתוך אזור אחד;
• באמצעות שכפול דיסק;
• לא נעשה שימוש במנועי PostgreSQL;
• שליטה אוטומטית וידנית אפשרית - failover/failback;
• בעת המעבר, ה-DBMS אינו זמין למשך מספר דקות.

2. קרא העתק (RR):

• בתוך אזור אחד;
• המתנה חמה;
• שכפול סטרימינג של PostgreSQL.

בנוסף, כמקובל, בבחירת טכנולוגיה תמיד מתמודדים עם כמה מגבלות:

• הלקוח לא רצה ליצור ישויות ולהשתמש ב-IaaS, אלא באמצעות GKE;
• הלקוח לא ירצה לפרוס שירות עצמי PostgreSQL/MySQL;
• ובכן, באופן כללי, Google Spanner היה מתאים למדי אלמלא המחיר שלו, עם זאת, Django ORM לא יכול לעבוד איתו, אבל זה דבר טוב.

בהתחשב במצב, הלקוח קיבל שאלת המשך: "האם אתה יכול לעשות משהו דומה כדי שזה יהיה כמו Google Spanner, אבל גם יעבוד עם Django ORM?"

אפשרות פתרון מס' 0

הדבר הראשון שעלה לי לראש:

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

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

אפשרות פתרון מס' 1

לאחר הרהור נוסף והתחשבות בנסיבות קודמות, השתנתה מסלול המחשבה במקצת:

• אנחנו עדיין מנסים להישאר בתוך CloudSQL, אבל אנחנו עוברים ל-MySQL, כי ל-Cloud SQL של ​​MySQL יש מאסטר חיצוני, אשר:

- הוא פרוקסי עבור MySQL חיצוני;
- נראה כמו מופע MySQL;
- הומצא להעברת נתונים מעננים אחרים או מקומיים.

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

למעשה, בשלב זה התברר ש-Cloud SQL אינו מתאים כלל. כמו שאומרים, עשינו כל מה שיכולנו.

אפשרות פתרון מס' 2

מכיוון שלא ניתן היה להישאר במסגרת Cloud SQL, ניסינו לגבש דרישות לפתרון פשרה. הדרישות התבררו כדלקמן:

• עבודה ב-Kubernetes, שימוש מרבי במשאבים וביכולות של Kubernetes (DCS, ...) ו- GCP (LB, ...);
• חוסר בנטל מחבורה של דברים מיותרים בענן כמו פרוקסי HA;
• היכולת להריץ PostgreSQL או MySQL באזור HA הראשי; באזורים אחרים - HA מה-RR של האזור הראשי בתוספת העותק שלו (למען מהימנות);
• מולטי מאסטר (לא רציתי ליצור איתו קשר, אבל זה לא היה מאוד חשוב)

.
כתוצאה מדרישות אלו, עמ'DBMS מתאים ואפשרויות כריכה:

• MySQL Galera;
• CockroachDB;
• כלי PostgreSQL

:
- pgpool-II;
- פטרוני.

MySQL Galera

טכנולוגיית MySQL Galera פותחה על ידי Codership והיא תוסף עבור InnoDB. מוזרויות:

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

ג'וק DB

לפי התיאור, הדבר הוא פצצה לחלוטין והוא פרויקט קוד פתוח שנכתב ב-Go. המשתתף העיקרי הוא Cockroach Labs (נוסדה על ידי אנשים מגוגל). DBMS יחסי זה תוכנן במקור להיות מופץ (עם קנה מידה אופקי מחוץ לקופסה) וסובלני לתקלות. מחבריה מהחברה תיארו את המטרה של "לשלב את העושר של פונקציונליות SQL עם הנגישות האופקית המוכרת לפתרונות NoSQL."

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

Pgpool

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

פטרוני

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

מה בחרת בסוף?

הבחירה לא הייתה קלה:

1. ג'וק DB - אש, אבל חשוך;
2. MySQL Galera - גם לא רע, משתמשים בו בהרבה מקומות, אבל MySQL;
3. Pgpool - הרבה ישויות מיותרות, כל כך אינטגרציה עם הענן ו-K8s;
4. פטרוני - אינטגרציה מעולה עם K8s, ללא ישויות מיותרות, משתלב היטב עם GCP LB.

לפיכך, הבחירה נפלה על פטרוני.

ממצאים

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

לגבי SQL, SQL יחיה. זה אומר שאתה צריך להכיר את PostgreSQL ו-MySQL ולהיות מסוגל לעבוד איתם, אבל עוד יותר חשוב זה להיות מסוגל להשתמש בהם בצורה נכונה.

מקור: www.habr.com