סקירה כללית על AlloyDB Omni

‫AlloyDB Omni הוא חבילת תוכנה של מסד נתונים שאפשר להוריד, שמאפשרת לפרוס גרסה יעילה של AlloyDB ל-PostgreSQL בסביבות מחשוב שאתם מנהלים. ‫AlloyDB Omni ושירות AlloyDB המנוהל במלואו ב- Google Cloudחולקים את אותם רכיבי ליבה. ‫AlloyDB משתמש בשכבת אחסון מפוצלת שמותאמת לענן, ואילו AlloyDB Omni נפרס באחסון לפי בחירתכם.

הניידות של AlloyDB Omni מאפשרת להריץ אותו בסביבות רבות, כולל:

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

‫AlloyDB Omni מציע שיפורים רבים – בנוסף ל-PostgreSQL הרגיל – שתומכים במדרגיות, בזמינות, במהימנות, בביצועים, ב-AI ובשפה טבעית. מידע נוסף זמין במאמר תוספות ל-PostgreSQL הסטנדרטי ב-AlloyDB Omni.

תרחישים לדוגמה לשימוש ב-AlloyDB Omni

‫AlloyDB Omni מתאים במיוחד לתרחישים הבאים:

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

תכונות עיקריות

  • שרת מסד נתונים שתואם ל-PostgreSQL ב-100%.
  • תמיכה ב-AlloyDB AI, שעוזרת לכם ליצור אפליקציות AI גנרטיביות ברמה ארגונית באמצעות הנתונים התפעוליים שלכם.
  • שילובים עם Google Cloud סביבת ה-AI, כולל Vertex AI Model Garden וכלים של AI גנרטיבי בקוד פתוח.

  • תמיכה בתכונות של טייס אוטומטי מ-AlloyDB ל-PostgreSQL ב-Google Cloud , שמאפשרת ל-AlloyDB Omni לנהל את עצמו ולבצע אופטימיזציה בעצמו.

    לדוגמה, AlloyDB Omni תומך בניהול זיכרון אוטומטי ובניקוי אוטומטי אדפטיבי של נתונים ישנים.

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

בבדיקות ביצועים, עומסי עבודה (workloads) עם טרנזקציות ב-AlloyDB Omni מהירים יותר מפי 2, ושאילתות ניתוח נתונים מהירות יותר עד פי 100, מאשר ב-PostgreSQL רגיל.

איך AlloyDB Omni פועל

יש כמה דרכים להתקין את AlloyDB Omni:

  • ‫AlloyDB Omni for containers: מאגר נתונים עצמאי. הפעלת AlloyDB Omni במערכת Linux עם אחסון SSD וזיכרון של 8GB לפחות לכל מעבד.

  • ‫AlloyDB Omni for Kubernetes: חלק מקונטיינר בסביבת Kubernetes. ‫AlloyDB Omni Kubernetes operator הוא תוסף ל-Kubernetes API שמאפשר להריץ את AlloyDB Omni ברוב סביבות Kubernetes שתואמות ל-CNCF.

    האופרטור AlloyDB Omni מפשט פעולות בסיסיות במסד הנתונים, ומאפשר לכם לבצע אוטומציה של פריסות יחידות או פריסות עם זמינות גבוהה (HA), ושל פעולות שמתבצעות אחרי הפריסה, כמו גיבוי, שחזור, מעבר לגיבוי כשל והגדרה של תוכנית התאוששות מאסון (DR) בין אזורים.

  • ‫AlloyDB Omni ל-Linux (תצוגה מקדימה): ‫Red Hat Package Manager‏ (RPM) שפועל ישירות במכונה וירטואלית או במתכת חשופה. ‫AlloyDB Omni for Linux פועל כקבוצה של רכיבי תוכנה משולבים ישירות במערכת ההפעלה של המארח. הוא משתמש במערכת הקבצים הרגילה של Linux לאחסון, כך שתוכלו להשתמש בתשתית האחסון הקיימת ובשיטות הניהול שלכם.

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

אפשר להגדיר את אופן הפעולה של מסד הנתונים 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 for Linux (תצוגה מקדימה) מיועד לסביבות שבהן עדיף לפרוס מסד נתונים שלא מבוסס על קונטיינר. מודל הפריסה הזה תומך בשרתי מתכת חשופה ובמכונות וירטואליות.

אפשר להתקין את AlloyDB Omni for Linux ישירות בסביבה של Red Hat Enterprise Linux ‏ (RHEL) או בסביבה שתואמת ל-Red Hat באמצעות מנהלי חבילות סטנדרטיים של מערכת ההפעלה.

‫AlloyDB Omni ל-Linux תומך ב-RHEL 9 וב-Rocky Linux 9.

גיבוי נתונים ותוכנית התאוששות מאסון (DR)

‫AlloyDB Omni כולל מערכת גיבוי ושחזור רציפה שמאפשרת ליצור אשכול מסד נתונים חדש על סמך כל נקודת זמן במהלך תקופת שמירת נתונים שניתנת להתאמה. כך תוכלו לשחזר נתונים במקרה של אובדן נתונים.

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

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

רכיבים של AlloyDB Omni

‫AlloyDB Omni מורכב משתי קבוצות של רכיבי ארכיטקטורה: רכיבי PostgreSQL עם שיפורים של AlloyDB ורכיבים ספציפיים ל-AlloyDB.

בתרשים הבא מוצגים שני סוגי הרכיבים, כולל שכבת התשתית שבה הרכיבים נמצאים, ותכונות של כל רכיב.

ארכיטקטורת רכיבים של AlloyDB Omni שכוללת רכיבים ספציפיים ל-AlloyDB ל-PostgreSQL ורכיבי PostgreSQL.

איור 1. ארכיטקטורה של AlloyDB Omni

אחסון הנתונים

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

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

ניהול המשאבים

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

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

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

מנוע מבוסס-עמודות

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

  • מאגר עמודות בזיכרון: מכיל נתונים של טבלאות ותצוגות חומריות של עמודות נבחרות בפורמט מבוסס-עמודות. כברירת מחדל, מאגר העמודות צורך 30% מהזיכרון הזמין. כדי לשנות את כמות הזיכרון שניתן להשתמש בה בחנות העמודות, צריך להגדיר את הפרמטר google_columnar_engine.memory_size_in_mb ב-postgresql.conf שבו נעשה שימוש במופע AlloyDB Omni.

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

ניהול זיכרון אוטומטי

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

כברירת מחדל, מנהל הזיכרון האוטומטי מגדיר את המגבלה העליונה ל-80% מזיכרון המערכת ומקצה 10% מזיכרון המערכת למטמון המאגר המשותף. כדי לשנות את המגבלה העליונה של גודל המטמון של המאגר המשותף, מגדירים את הפרמטר shared_buffers ב-postgresql.conf שבו משתמשים במופע AlloyDB Omni.

ניקוי אוטומטי דינמי

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

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

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

‫AI/ML worker

ב-AlloyDB Omni, עובד הרקע של AI/ML מספק את היכולות הנדרשות לקריאה למודלים של Vertex AI ישירות ממסד הנתונים. תהליך ה-AI/ML פועל כ-omni ml worker.

המאמרים הבאים