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

בחירת גרסה של מאמר העזרה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך AlloyDB Omni פועל

אפשר להתקין את AlloyDB Omni כשרת עצמאי או כחלק מסביבת Kubernetes.

‫AlloyDB Omni פועל בקונטיינר Docker שמתקינים בסביבה שלכם. מומלץ להריץ את AlloyDB Omni במערכת Linux עם אחסון SSD ועם זיכרון של לפחות 8GB לכל CPU.

ה-operator של AlloyDB Omni Kubernetes הוא הרחבה של Kubernetes API שמאפשרת להריץ את AlloyDB Omni ברוב סביבות Kubernetes שתואמות ל-CNCF. מידע נוסף זמין במאמר בנושא התקנת AlloyDB Omni ב-Kubernetes.

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

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

היתרונות של הפעלת AlloyDB Omni כקונטיינר

‫Google מפיצה את AlloyDB Omni כקונטיינר שאפשר להריץ עם זמני ריצה של קונטיינרים כמו Docker ו-Podman. מבחינה תפעולית, קונטיינרים מציעים את היתרונות הבאים:

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

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

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

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

מידע נוסף זמין במאמר גיבוי ושחזור של AlloyDB Omni.

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

מידע נוסף זמין במאמר מידע על שכפול בין מרכזי נתונים

רכיבי מכונת וירטואלית של AlloyDB Omni

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

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

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

המנוע של מסד הנתונים

במסמך הזה מתוארת ארכיטקטורת מסד הנתונים ב-AlloyDB Omni בקונטיינר. במסמך הזה אנחנו יוצאים מנקודת הנחה שאתם מכירים את PostgreSQL.

המנוע של מסד הנתונים מבצע את המשימות הבאות:

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

כשיישום הלקוח שולח שאילתה ל-AlloyDB Omni, מתרחשות הפעולות הבאות:

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

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

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

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

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

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

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

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

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

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

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

מנוע מבוסס-עמודות מאיץ את העיבוד של שאילתות SQL של סריקות, שאילתות איחוד (join) וצבירות באמצעות הרכיבים הבאים:

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

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

  • מנוע ביצוע ותכנון שאילתות עמודתי: תומך בשימוש במאגר עמודות בשאילתות.

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

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

מידע נוסף זמין במאמר בנושא ניהול זיכרון אוטומטי.

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

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

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

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

היתרונות של תכונת הניקוי האוטומטי (autovacuum) הדינמי:

  • ניהול דינמי של משאבי vacuum: במקום להשתמש במגבלת עלות קבועה,‏ AlloyDB Omni משתמש בנתונים סטטיסטיים של משאבים בזמן אמת כדי להתאים את עובדי ה-vacuum. כשהמערכת עמוסה, תהליך ה-vacuum וניצול המשאבים שקשורים אליו מוגבלים. אם יש מספיק זיכרון פנוי, מוקצה זיכרון נוסף ל-maintenance_work_mem כדי לקצר את זמן הריקון מקצה לקצה.
  • הגבלת קצב דינמית של XID: מעקב אוטומטי ורציף אחרי התקדמות הניקוי ומהירות השימוש במזהה העסקה. אם מזוהה סיכון להחלפת מזהי עסקאות, AlloyDB Omni מאט את העסקאות כדי לווסת את צריכת המזהים. בנוסף,‏ AlloyDB Omni מקצה יותר משאבים לתהליכי ה-vacuum כדי לעבד את הטבלאות שחוסמות את ההתקדמות והשחרור של נפח מזהי העסקאות. במהלך התהליך הזה, מספר העסקאות הכולל לשנייה יורד עד שמזהי העסקאות מגיעים לאזור גלוי בוודאות (אפשר לראות את זה כשהביקורים ממתינים ב-AdaptiveVacuumNewXidDelay). ככל שהגיל של מזהה העסקה עולה, מספר העובדים של ה-vacuum גדל באופן דינמי.
  • שאיבת אבק יעילה יותר בטבלאות גדולות: הלוגיקה שמוגדרת כברירת מחדל ב-PostgreSQL, שמשמשת לקביעה מתי לבצע שאיבת אבק בטבלה, מבוססת על נתונים סטטיסטיים ספציפיים לטבלה שמאוחסנים ב-pg_stat_all_tables, שמכיל את היחס בין שורות מתות. הלוגיקה הזו מתאימה לטבלאות קטנות, אבל יכול להיות שהיא לא תפעל ביעילות בטבלאות גדולות שמתעדכנות לעיתים קרובות. ‫AlloyDB Omni מספק מנגנון סריקה מעודכן שעוזר להפעיל את התכונה autovacuum בתדירות גבוהה יותר. מנגנון הסריקה הזה סורק נתחים של טבלאות גדולות ומסיר טפלים מתים בצורה יעילה יותר מהלוגיקה של PostgreSQL שמוגדרת כברירת מחדל.
  • רישום הודעות אזהרה ביומן: ב-AlloyDB Omni, חסימות של פעולת ה-VACUUM, כמו טרנזקציות שפועלות במשך זמן רב, טרנזקציות מוכנות או משבצות שכפול שאיבדו את היעדים שלהן, מזוהות והאזהרות נרשמות ביומני PostgreSQL כדי שתוכלו לטפל בבעיות בזמן.

‫AI/ML worker

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

מידע נוסף זמין במאמר בנושא פיתוח אפליקציות AI גנרטיבי באמצעות AlloyDB AI.

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