AlloyDB Omni היא חבילת תוכנה של מסד נתונים שניתן להוריד, שמאפשרת לפרוס גרסה יעילה של AlloyDB ל-PostgreSQL בסביבות מחשוב שאתם מנהלים. AlloyDB Omni והשירות המנוהל במלואו של AlloyDB ב- Google Cloudחולקים את אותם רכיבי ליבה. ב-AlloyDB נעשה שימוש בשכבת אחסון מבוססת-ענן מפורקת, וב-AlloyDB Omni הפריסה מתבצעת באחסון לבחירתכם.
הניידות של AlloyDB Omni מאפשרת להריץ אותו בסביבות רבות, כולל:
- מרכזי הנתונים הפרטיים שלכם
- כל ענן ציבורי
- המחשב הנייד
- מכונות וירטואליות מבוססות-ענן
ב-AlloyDB Omni יש כמה שיפורים, בנוסף ל-PostgreSQL הרגיל, שתומכים במדרגיות, בזמינות, באמינות, בביצועים, ב-AI ובשפה טבעית. מידע נוסף מופיע במאמר תוספות של AlloyDB Omni ל-PostgreSQL רגיל.
תרחישים לדוגמה של AlloyDB Omni
AlloyDB Omni מתאים במיוחד לתרחישים הבאים:
- אתם צריכים גרסה של PostgreSQL עם יכולת התאמה לעומס וביצועים גבוהים, שצריך להריץ באופן מקומי בגלל דרישות רגולטוריות או דרישות של ריבונות הנתונים.
- אתם צריכים מסד נתונים שממשיך לפעול גם כשהוא מנותק מהאינטרנט.
- אתם רוצים לעבור ממסד נתונים מדור קודם בלי להתחייב לשירות ענן מנוהל כמו AlloyDB ל-PostgreSQL.
תכונות עיקריות
- שרת מסד נתונים שתואם ב-100% ל-PostgreSQL.
- תמיכה ב-AlloyDB AI, שעוזר לכם ליצור אפליקציות של AI גנרטיבי ברמה שמתאימה לארגונים באמצעות הנתונים התפעוליים שלכם.
- שילובים עם סביבת ה-AI של Google Cloud , כולל Vertex AI Model Garden וכלי AI גנרטיבי בקוד פתוח.
תמיכה בתכונות של טייס אוטומטי מ-AlloyDB ל-PostgreSQL ב-Google Cloud , שמאפשרות ל-AlloyDB Omni לנהל ולכוונן את עצמו.
לדוגמה, AlloyDB Omni תומך בניהול זיכרון אוטומטי וב-autovacuum אדפטיבי של נתונים לא עדכניים.
המנוע מבוסס-העמודות של AlloyDB Omni, ששומר נתונים רלוונטיים בפורמט מבוסס-עמודות בזיכרון, כדי להאיץ שאילתות של ניתוח נתונים, דיווח ועומסי עבודה של עיבוד טרנזקציות וניתוח נתונים היברידי (HTAP).
ממשק המשתמש באינטרנט של AlloyDB Omni, שמאפשר מעקב גרפי אחרי נתוני הטלמטריה וביקורת על ההגדרות של האשכולות בניהול עצמי.
בבדיקות ביצועים, עומסי עבודה (workloads) עם טרנזקציות ב-AlloyDB Omni מהירים יותר מפי 2, ושאילתות ניתוח נתונים מהירות יותר עד פי 100, בהשוואה ל-PostgreSQL רגיל.
אפשרויות הפריסה של AlloyDB Omni
במסוף Google Cloud , אתם יכולים לבדוק את אפשרויות הפריסה, לגשת למקורות מידע ולנהל רישיונות ישירות מדף הנחיתה של AlloyDB Omni:
דף הנחיתה של הקונסולה כולל שתי כרטיסיות עיקריות:
- אפשרויות פריסה: נתיבים ומדריכים מותאמים אישית להתקנת AlloyDB Omni בסביבות תשתית שונות, וגם גישה ל-Codelabs ולהדגמות של AI.
- מינויים: ניהול רישיונות מרוכז לפריסות בסביבת הייצור. אתם יכולים לחשב ולרכוש רישיונות על סמך המספר הכולל של מעבדי ה-vCPU, לשנות את מספר מעבדי ה-vCPU, לראות את העלויות ולנהל את ההנחות תמורת התחייבות.
אפשר להתקין את AlloyDB Omni באמצעות אחת מאפשרויות הפריסה הבאות:
AlloyDB Omni באמצעות קונטיינרים: קונטיינר של מסד נתונים עצמאי. מריצים את AlloyDB Omni במערכת Linux עם אחסון SSD וזיכרון בנפח של 8GB לפחות לכל מעבד (CPU).
AlloyDB Omni באמצעות כלי לתזמור קונטיינרים: חלק מקונטיינר בסביבת Kubernetes. האופרטור של AlloyDB Omni ב-Kubernetes הוא תוסף ל-Kubernetes API שמאפשר להריץ את AlloyDB Omni ברוב סביבות Kubernetes שתואמות ל-CNCF.
אופרטור AlloyDB Omni מפשט את פעולות מסד הנתונים הבסיסיות, ומאפשר לכם להגדיר פריסות אוטומטיות של זמינות גבוהה (HA) או פריסות בודדות, וגם פעולות ביום השני כמו גיבוי, שחזור, יתירות כשל והגדרת תוכנית התאוששות מאסון (DR) באזורים שונים.
AlloyDB Omni באמצעות RPM: חבילה עצמאית שפועלת ישירות במכונה וירטואלית או בשרת פיזי. AlloyDB Omni שמשתמש ב-RPM פועל כקבוצה של רכיבי תוכנה משולבים ישירות במערכת ההפעלה המארחת. הוא משתמש במערכת הקבצים הרגילה של Linux לאחסון, ומאפשר לכם להשתמש בתשתית האחסון ובשיטות הניהול הקיימות שלכם.
AlloyDB Omni באמצעות מתזמן RPM: פריסה של Red Hat Package Manager (RPM) למכונות וירטואליות או לשרתים פיזיים. האפשרות הזו כוללת פלטפורמת תזמור שמבצעת פריסה וניהול אוטומטיים בסביבות שאינן Kubernetes. הוא מרחיב את הגמישות של הענן לתשתית שתבחרו, בלי צורך בשכבות של קונטיינרים כמו Docker.
האפליקציות שלכם מתחברות למסד הנתונים של AlloyDB Omni ומתקשרות איתו, כמו שהן מתחברות לשרת מסד נתונים רגיל של PostgreSQL ומתקשרות איתו. גם בקרת הגישה של המשתמשים מבוססת על תקני PostgreSQL.
אתם יכולים להגדיר את ההתנהגות של מסד הנתונים AlloyDB Omni באמצעות דגלים לניהול מסד נתונים, כולל רישום ביומן, ניקוי ומנוע מבוסס-עמודות. מידע נוסף זמין במאמר אפשרויות זמינות להורדה ולהתקנה של AlloyDB Omni.
AlloyDB Omni כקונטיינר
Google מפיצה את AlloyDB Omni כקונטיינר שאפשר להריץ עם סביבות זמן ריצה של קונטיינרים כמו Docker ו-Podman. אפשר גם לפרוס קונטיינרים של AlloyDB Omni בסביבת Kubernetes, עם הרבה פעולות בסיסיות אוטומטיות.
מבחינה תפעולית, קונטיינרים מציעים את היתרונות הבאים:
- ניהול שקוף של יחסי תלות: כל יחסי התלות הנדרשים כלולים בקונטיינר ונבדקים על ידי Google כדי לוודא שהם תואמים באופן מלא ל-AlloyDB Omni.
- ניידות: AlloyDB Omni פועל באופן עקבי בסביבות שונות.
- בידוד אבטחה: אתם בוחרים לאילו דברים במכונה המארחת יש גישה לקונטיינר של AlloyDB Omni.
- ניהול משאבים: אתם יכולים להגדיר את כמות משאבי המחשוב שאתם רוצים שהקונטיינר של AlloyDB Omni ישתמש בהם.
- תיקונים ושדרוגים חלקים: כדי לתקן קונטיינר, מחליפים את קובץ האימג' הקיים בקובץ חדש.
AlloyDB Omni בסביבת RHEL
ב-AlloyDB Omni יש שתי אפשרויות פריסה לסביבת RHEL, בהתאם לדרישות האוטומציה וההתאמה לעומס.
AlloyDB Omni באמצעות RPM
אפשרות הפריסה של RPM היא התקנה עצמאית של Red Hat Package Manager (RPM) שמיועדת לסביבות שבהן רוצים מסד נתונים של AlloyDB Omni שלא נמצא בקונטיינר. האפשרות הזו תומכת ב-RHEL 9 וב-Rocky Linux 9.
- שילוב ישיר במערכת ההפעלה: פועל כקבוצה של רכיבי תוכנה משולבים ישירות במערכת ההפעלה המארחת.
- אחסון קיים: משתמש במערכת הקבצים הרגילה של Linux (ext4 ו-xfs), שתומכת בתשתית האחסון הקיימת ובשיטות הניהול הקיימות.
- פשטות: מתאים להגדרות של מכונה אחת שבהן נדרש שילוב עמוק עם מערכת ההפעלה המארחת, ללא שכבות תזמור נוספות.
הכלי לניהול סוכנים של RPM
אפשרות הפריסה של מתזמר RPM משתמשת באותן חבילות RPM כמו AlloyDB Omni באמצעות RPM, אבל מוסיפה פלטפורמת תזמור כדי להפוך את הניהול לאוטומטי בסביבות שהן לא Kubernetes.
- גמישות כמו בענן: הרחבת האוטומציה לתשתית מקומית, טיפול באתחול, יתירות כשל וניהול מחזור החיים.
- מסגרות אוטומציה: משתלב עם כלים פופולריים כמו Ansible, ומאפשר לצוותים להשתמש במיומנויות קיימות. אפשר גם להשתמש בכלים ייעודיים של שורת הפקודה.
- תכונות Enterprise: תכונות שתוכננו במיוחד כדי לתמוך בזמינות גבוהה (HA) ובתוכנית התאוששות מאסון (DR) באמצעות תוכנה מרכזית לניהול אשכולות.
גיבוי נתונים ותוכנית התאוששות מאסון (DR)
ב-AlloyDB Omni יש מערכת גיבוי ושחזור רציפה שמאפשרת ליצור אשכול חדש של מסדי נתונים על סמך כל נקודת זמן בתקופת שמירה שאפשר לשנות. כך תוכלו לשחזר נתונים שאבדו בטעות.
בנוסף, AlloyDB Omni יכול ליצור ולשמור גיבויים מלאים של הנתונים באשכול של מסד הנתונים, על פי דרישה או לפי לוח זמנים קבוע. בכל שלב אפשר לשחזר מגיבוי לאשכול מסדי נתונים של AlloyDB Omni, שמכיל את כל הנתונים מאשכול מסדי הנתונים המקורי בזמן שבו נוצר הגיבוי.
כדי לשפר את תוכנית ההתאוששות מאסון, אתם יכולים ליצור אשכולות משניים של מסדי נתונים במרכזי נתונים נפרדים, וכך לשכפל את הנתונים בין מרכזי הנתונים. AlloyDB Omni מעביר נתונים באופן אסינכרוני מאשכול מסד נתונים ראשי ייעודי לכל אחד מהאשכולות המשניים שלו. בכל פעם שצריך, אתם יכולים לקדם אשכול משני של מסדי נתונים לאשכול ראשי של מסדי נתונים ב-AlloyDB Omni.
רכיבי AlloyDB Omni
AlloyDB Omni מורכב משתי קבוצות של רכיבי ארכיטקטורה: רכיבי PostgreSQL עם שיפורים של AlloyDB Omni ורכיבים ספציפיים ל-AlloyDB Omni.
בתרשים הבא מוצגות שתי קבוצות הרכיבים, כולל שכבת התשתית שבה הרכיבים נמצאים והתכונות של כל רכיב.
אחסון הנתונים
ב-AlloyDB Omni הנתונים מאוחסנים בדפים בגודל קבוע שמאוחסנים במערכת הקבצים הבסיסית. כששאילתה צריכה לגשת לנתונים, AlloyDB Omni בודק קודם את מאגר המאגרים. אם הדפים שמכילים את הנתונים הנדרשים לא נמצאים במאגר המאגר, AlloyDB Omni קורא את הדפים הנדרשים ממערכת הקבצים.
הגישה לנתונים ממאגר הנתונים הזמני מהירה משמעותית מקריאה ממערכת הקבצים. חשוב להגדיל ככל האפשר את מאגר הנתונים הזמני של הנתונים שהאפליקציה ניגשת אליהם. אפשר להוסיף שכבת מטמון מהירה במיוחד כדי לשפר עוד יותר את ביצועי השאילתות.
ניהול המשאבים
ב-AlloyDB Omni נעשה שימוש בניהול זיכרון דינמי אוטומטי כדי לאפשר למאגר המאגרים לגדול ולהתכווץ באופן דינמי בתוך גבולות מוגדרים, בהתאם לדרישות הזיכרון של המערכת. לכן, אין צורך לשנות את הגודל של מאגר המאגרים. כשמנתחים בעיות בביצועים, קודם כל צריך לבדוק מדדים כמו שיעור ההתאמה של מאגר המאגרים ושיעור הקריאה, כדי לקבוע אם האפליקציה מפיקה תועלת ממאגר המאגרים. אם לא, סימן שקבוצת הנתונים של האפליקציה לא מתאימה למאגר המאגרים, וכדאי לשקול לשנות את הגודל למכונה גדולה יותר עם יותר זיכרון.
תהליך האחזור, הסינון, הצבירה, המיון וההקרנה של הנתונים דורש משאבי מעבד (CPU) בשרת מסד הנתונים. כדי להפחית את כמות משאבי המעבד (CPU) שנדרשים לתהליך הזה, צריך לצמצם את כמות הנתונים שצריך לעבד. עוקבים אחרי ניצול המעבד (CPU) בשרת מסד הנתונים כדי לוודא שניצול המצב היציב הוא בסביבות 70%. הכמות הזו משאירה מספיק מקום בשרת לעליות חדות בשימוש או לשינויים בדפוסי הגישה לאורך זמן. הפעלה בשיעור ניצול שקרוב ל-100% יוצרת תקורה בגלל תזמון תהליכים והחלפת הקשר, ועלולה ליצור צווארי בקבוק בחלקים אחרים של המערכת. ניצול גבוה של המעבד (CPU) הוא מדד חשוב נוסף שצריך להביא בחשבון כשמחליטים על מפרט המכונה.
פעולות קלט/פלט לשנייה (IOPS) הן גורם חשוב בביצועים של אפליקציות מסדי נתונים, והן מודדות כמה פעולות קלט או פלט לשנייה התקן האחסון הבסיסי יכול לספק למסד הנתונים. כדי לא לחרוג ממגבלות ה-IOPS של האחסון במסד הנתונים, כדאי לצמצם את פעולות הקריאה והכתיבה באחסון. מגדילים את כמות הנתונים שמתאימה למאגר המאגרים או לשכבת המטמון.
מנוע מבוסס-עמודות
המנוע המובנה מבוסס-העמודות מאיץ את העיבוד של שאילתות ניתוח נתונים, שבדרך כלל כוללות סריקות מלאות של טבלאות, איחודים מורכבים וצבירות.
מאגר עמודות בזיכרון: מכיל נתונים של טבלאות ותצוגות מהותיות של עמודות נבחרות בפורמט שמותאם לעמודות. כברירת מחדל, מאגר העמודות צורך 30% מהזיכרון הזמין. כדי לשנות את כמות הזיכרון שבה מאגר העמודות יכול להשתמש, מגדירים את הפרמטר
google_columnar_engine.memory_size_in_mbב-postgresql.confשבו משתמש המכונה של AlloyDB Omni.מתכנן תוכנית לביצוע שאילתה מבוסס-עמודות ומנוע הרצה: תומך בשימוש במאגר העמודות בשאילתות.
מידע נוסף זמין במאמר מידע על המנוע מבוסס-העמודות של AlloyDB ל-PostgreSQL.
ניהול זיכרון אוטומטי
מנהל הזיכרון האוטומטי עוקב אחרי צריכת הזיכרון בכל המכונה של AlloyDB Omni ומבצע אופטימיזציה שלה. כשמריצים את עומסי העבודה, המודול הזה מתאים את הגודל של מאגר הנתונים הזמני המשותף בהתאם ללחץ על הזיכרון.
כברירת מחדל, מנהל הזיכרון האוטומטי מגדיר את הגבול העליון ל-80% מזיכרון המערכת ומקצה 10% מזיכרון המערכת למטמון של מאגר הנתונים הזמני המשותף.
כדי לשנות את הגבול העליון של גודל המטמון של מאגר הנתונים הזמני המשותף, מגדירים את הפרמטר shared_buffers בקובץ postgresql.conf שמשמש את המכונה של AlloyDB Omni.
Adaptive autovacuum
התכונה "ניקוי אוטומטי מותאם" מנתחת את הפעולות על סמך עומס העבודה במסד הנתונים, ומתאימה באופן אוטומטי את תדירות הניקוי. הכוונון האוטומטי הזה עוזר למסד הנתונים לשמור על ביצועים אופטימליים, גם כשהעומס משתנה, בלי הפרעה מתהליך ה-vacuum.
כדי לקבוע את התדירות והעוצמה של פעולות ה-vacuum, המערכת משתמשת בגורמים הבאים:
- גודל מסד הנתונים
- מספר ה-tuples המתים במסד הנתונים
- גיל הנתונים במסד הנתונים
- מספר העסקאות לשנייה לעומת מהירות הוואקום המשוערת
- ניצול משאבים
עובד/ת בתחום ה-AI/ML
ב-AlloyDB Omni, ה-worker ברקע של AI/ML מספק את היכולות שנדרשות כדי להפעיל מודלים של Vertex AI ישירות ממסד הנתונים. ה-worker של AI או ML פועל כתהליך שנקרא omni ml worker.
ממשק המשתמש באינטרנט
ממשק המשתמש האופציונלי לאינטרנט הוא מסוף אינטרנט בניהול עצמי, שמאפשר לכם לצפות במכונות של מסד הנתונים.
הממשק הזה ממפה מרכזי בקרה גרפיים לתכונות בהתאמה אישית, כמו המנוע מבוסס-העמודות ושילובי נקודות הקצה של המודלים, שכלים חזותיים טיפוסיים בקוד פתוח של PostgreSQL לא יכולים לעקוב אחריהם.
כדי להתקין את ממשק המשתמש באינטרנט ולהתחבר אליו, מבצעים את ההגדרות האופציונליות הבאות:
- התקנה באמצעות קונטיינרים
- התקנה באמצעות כלי לניהול קונטיינרים
- התקנה באמצעות RPM
- התקנה באמצעות כלי התזמור של RPM
מישור הבקרה של כלי התזמור
באפשרות הפריסה של מנהל התזמור של RPM, משתמשים בתוכנה לניהול אשכולות מרכזית כדי להפוך פעולות ברמת האשכול לאוטומטיות, כולל אתחול ויתירות כשל.
ממשקי ניהול
אפשרות הפריסה של מתזמר RPM מספקת כלי שירות של שורת הפקודה (alloydbctl) ותפקידי Ansible, שמאפשרים לנהל אשכול אחד או יותר בקנה מידה נרחב.
אופטימיזציה של הביצועים
אפשרות הפריסה של RPM orchestrator כוללת תמיכה משולבת ב-PgBouncer למאגר חיבורים וב-HAProxy לאיזון עומסים בין נקודות קצה לקריאה וכתיבה ונקודות קצה לקריאה בלבד.
המאמרים הבאים
כדי להתחיל, אתם יכולים לבחור אחת מאפשרויות הפריסה הבאות של AlloyDB Omni:
כך מתקינים את ממשק המשתמש באינטרנט ומתחברים אליו: