סקירה כללית של 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.

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

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

מרישום ביומן ועד לניקוי (vacuuming) ומנוע מבוסס-עמודות, אפשר להגדיר את התנהגות מסד הנתונים של AlloyDB Omni באמצעות flags של מסד הנתונים.

היתרונות של הפעלת 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.

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

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

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

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

היתרונות של Adaptive autovacuum:

  • ניהול דינמי של משאבי vacuum: במקום להשתמש במגבלת עלות קבועה,‏ AlloyDB Omni משתמש בנתונים סטטיסטיים של משאבים בזמן אמת כדי להתאים את תהליכי ה-vacuum. כשהמערכת עמוסה, תהליך ה-vacuum וניצול המשאבים שקשור אליו מוגבלים. אם יש מספיק זיכרון, מוקצה זיכרון נוסף ל-maintenance_work_mem כדי לקצר את זמן הריקון מקצה לקצה.
  • הגבלת קצב דינמית של מזהי טרנזקציות (XID): המערכת עוקבת באופן אוטומטי ורציף אחרי התקדמות ה-vacuuming והמהירות של צריכת מזהי הטרנזקציות. אם מזוהה סיכון של גלישת מזהי טרנזקציות, 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.

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