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

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

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

פעולות קלט/פלט לשנייה (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.

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