כדי לשפר את התפוקה, זמן האחזור והזמינות הגבוהה של עומסי העבודה ב-AlloyDB ל-PostgreSQL, אתם יכולים להגדיר את הגודל של המכונות הראשיות ושל מאגרי הקריאה ולפרוס אותן לעומסי עבודה של עיבוד טרנזקציות אונליין (OLTP), עיבוד אנליטי אונליין (OLAP) ועיבוד היברידי של טרנזקציות וניתוח נתונים (HTAP).
סקירה כללית
כדי לשפר את הביצועים של מסד הנתונים, AlloyDB ל-PostgreSQL כולל את התכונות המובנות הבאות:
- ניהול זיכרון אוטומטי
- Adaptive autovacuum
- הגדרות ביצועים מובנות שעברו אופטימיזציה
- השהיית רפליקציה קצרה
- תחזוקה ללא שיבושים, עם זמן השבתה של פחות משנייה למכונה הראשית ואפס זמן השבתה לצומתי מאגר הקריאה במהלך פעולות התאמה לעומס (scaling)
כדי לשפר את הביצועים של מכונת AlloyDB ל-PostgreSQL, צריך לנהל את הדברים הבאים:
- התאמת הגודל של המכונות במאגר הראשי ובמאגר לקריאה בלבד
- עדכון דגלים שמשפיעים על הביצועים
שיקולים שקשורים לגודל
לפני שקובעים את הגודל של מכונת AlloyDB ל-PostgreSQL, צריך להחליט לגבי הדברים הבאים:
- סוג עומס העבודה: OLTP, OLAP או HTAP
- דרישות ביצועים: דרישות לגבי זמן אחזור וקצב העברת נתונים
- גודל הנתונים הצפוי: גודל הנתונים שאתם מתכננים לאחסן ב-AlloyDB ל-PostgreSQL, וגודל מערך הנתונים הפעיל.
- היקף עומס העבודה: עלייה או גידול בגודל הנתונים לאורך זמן
עומסי עבודה של OLTP
אתם יכולים לפרוס את מסד הנתונים של AlloyDB ל-PostgreSQL כמכונה אזורית (צומת אחד) או כמכונה בזמינות גבוהה (שני צמתים בכל אזור). אפשר גם להוסיף מכונות של מאגר קריאה ואשכול משני באזור אחר לעומסי עבודה שמופצים גיאוגרפית או לתוכנית התאוששות מאסון (DR).
AlloyDB ל-PostgreSQL נפרס באמצעות ארכיטקטורה מבוזרת בקנה מידה של ענן, עם הפרדה בין המחשוב לאחסון. הכתיבות מאושרות ברגע שקובצי יומני הכתיבה מראש (WAL) נשמרים ב-Regional Storage, והמטריאליזציה של הבלוקים מועברת לאחסון.
באופן דומה, בארכיטקטורת מטמון בכמה רמות, הנתונים ממוקמים באופן אוטומטי בין מטמון המאגר, מטמון מהיר במיוחד ומנוע האחסון החכם. בגלל ארכיטקטורת המטמון הרב-שכבתית הזו שמשמשת ב-AlloyDB ל-PostgreSQL, פעולות קלט ופלט לשנייה (IOPs) לא רלוונטיות בהקשר של AlloyDB ל-PostgreSQL בהשוואה למערכות אחרות של מסדי נתונים.
עם זאת, שימוש בטרנזקציות לשנייה (TPS) או בטרנזקציות לדקה (TPM) יכול לספק השוואה משמעותית כדי להבין את כמות הנתונים ש-AlloyDB ל-PostgreSQL יכול לטפל בהם.
מדד הגודל העיקרי הוא TPS. כדי להעריך את הגודל הנדרש של AlloyDB ל-PostgreSQL:
- זיהוי עומס העבודה הקיים אם אתם עוברים מ-PostgreSQL בניהול עצמי או ממסדי נתונים מסחריים אחרים, יכול להיות שכבר יש לכם את ערך ה-TPS של עומס העבודה הקיים.
- ניתוח השאילתות. מזהים את השאילתות הכי קריטיות בעומס העבודה וקובעים את דרישות הביצועים שלהן.
- אפשר להשתמש בכלי כמו
HammerDBאוpgbench. הכלים האלה עוזרים להשוות את AlloyDB ל-PostgreSQL ולקבוע אם גודל המכונה עומד בדרישות ה-TPS שלכם. - משתמשים במדריך להשוואה לשוק של AlloyDB ל-PostgreSQL OLTP. במדריך הזה מוצגים נתוני ביצועים של הגדרות שונות של AlloyDB ל-PostgreSQL, כדי שתוכלו למצוא הגדרה שעומדת בדרישות ה-TPS שלכם.
- בחירת גודל מתאים של AlloyDB ל-PostgreSQL חשוב להביא בחשבון את גודל הנתונים הנוכחי ואת הציפיות לצמיחה בעתיד.
הנחיות לגבי גודל המכונה
בטבלה הבאה מוצגות המלצות לנתונים עם השוואה לשוק של TPC-C, עם יחס קריאה-כתיבה של כ-65% קריאות ו-35% כתיבות. כשמגדירים את הגודל של מכונה ב-AlloyDB ל-PostgreSQL, צריך לשאוף לשימוש קבוע של כ-60-70% ב-CPU כדי להימנע מתקורה בתזמון של מערכת ההפעלה. כך נשאר מרווח מסוים לעליות חדות בשימוש במשאבים על ידי אפליקציות לקוח.
ההמלצות לגבי הגודל בטבלה הבאה הן הנחיות כלליות.
כדי לדעת מהו המספר המקסימלי המומלץ של max_connections לכל גודל מכונה, קראו את המאמר מספר מקסימלי של חיבורים בו-זמניים.
| vCPU/זיכרון | טווח מומלץ של עסקאות לשנייה (30% במטמון) |
גודל מומלץ של נתוני עבודה (עד 128TB בסך הכול) |
|---|---|---|
| 2 / 16GB | עד 1,000 | עד 100GB |
| 4 / 32GB | עד 2,500 | עד 250GB |
| 8/ 64GB | עד 4,000 | עד 500GB |
| 16 / 128GB | עד 8,000 | עד 1TB |
| 32GB או 256GB | עד 14,000 | עד 3TB |
| 64GB / 512GB | עד 20,000 | עד 8TB |
| 96 / 768GB | עד 25,000 | עד 16TB |
| 128GB או 864GB | יותר מ-20,000 | עד 32TB |
סוגי פריסה
בהתאם לעומס העבודה, אתם יכולים לפרוס את AlloyDB ל-PostgreSQL כמכונה ראשית בלבד או כמכונה ראשית עם מאגר קריאה.
רק הראשי
בחרו בפריסה ראשית בלבד לעומסי העבודה הבאים:
- הרבה כתיבה ומעט עד בינוני קריאה
- שאילתות עם הרבה פעולות קריאה ומעט פעולות כתיבה
- קריאה וכתיבה אופייניות של OLTP (60-70% קריאות, 30-40% כתיבות).
מידע נוסף על סוגי מכונות זמין במאמר הנחיות כלליות לגבי גודל המכונה.
מופע ראשי עם מאגר קריאה
אם אתם בוחרים לפרוס מכונה ראשית עם מאגר לקריאה בלבד, כדאי להביא בחשבון את הדברים הבאים:
- אם יש לכם קריאות שרגישות לזמן אחזור, כדאי להעביר את שאילתות הקריאה למכונות של מאגר קריאה. אפשר להגדיר עד 20 צמתים בכל המכונות של מאגר הקריאה. מידע נוסף זמין במאמר יצירת מכונה של מאגר קריאה.
- אם יש לכם יותר ממסד נתונים אחד, למשל CRM או Finance באותו מופע, אתם יכולים להגדיר כמה מופעים של מאגר קריאה. האסטרטגיה הזו עוזרת לשמור במטמון ביעילות ולשפר את ביצועי השאילתות.
- אתם יכולים להגדיר את הגודל של המכונות במאגר הראשי ובמאגר לקריאה בלבד בהתאם לדרישות שלכם. מידע נוסף על שיטות מומלצות למכונות של מאגר קריאה זמין במאמר שיטות מומלצות לשיפור הביצועים והזמינות של AlloyDB.
- כדי להבטיח זמינות גבוהה, כדאי להוסיף יותר מצומת אחד לכל מכונה של מאגר קריאה.
- להפעיל את המנוע מבוסס-העמודות באופן סלקטיבי במכונות ספציפיות של מאגר קריאה, כדי לשפר את הביצועים של שאילתות קריאה. לא צריך להפעיל את המנוע מבוסס-העמודות במכונה הראשית.
עומסי עבודה של OLAP
בעומסי עבודה של OLAP, המדד העיקרי לקביעת הגודל הוא ביצועי השאילתות, במיוחד שאילתות שדורשות סריקות מלאות של טבלאות או צבירות. AlloyDB ל-PostgreSQL כולל מנוע מבוסס-עמודות מובנה שעוזר להאיץ שאילתות של ניתוח נתונים. כשמפעילים את המנוע מבוסס-העמודות כברירת מחדל, הוא צורך 30% מהזיכרון ומשתמש באופן אוטומטי בנתוני מטמון מהירים במיוחד.
מידע נוסף על מדידת הביצועים של OLAP באמצעות AlloyDB ל-PostgreSQL עם עומס עבודה של TPC-H זמין במדריך להשוואה בין ביצועי OLAP ב-AlloyDB ל-PostgreSQL.
סוגי פריסה
בהתאם לעומס העבודה, אתם יכולים לפרוס את AlloyDB ל-PostgreSQL כמכונה ראשית בלבד או כמכונה ראשית עם מאגר קריאה.
רק הראשי
אם אתם פורסים מכונה ראשית בלבד, כדאי להביא בחשבון את הדברים הבאים:
- הפריסה הזו מתאימה גם לעסקאות עם שאילתות אנליטיות (HTAP).
- הפעלת מנוע מבוסס-עמודות כדי לעזור בשאילתות OLAP.
- כדאי לפרוס עם מכונה של 16 vCPU או יותר, שמספקת יותר זיכרון לאחסון נתונים בעמודות.
ראשי עם מאגר קריאה
אם אתם פורסים מכונה ראשית עם מאגר לקריאה בלבד, כדאי להביא בחשבון את הדברים הבאים:
- אם יש לכם הרבה פעולות כתיבה וגם פעולות קריאה אנליטיות שרגישות לזמן אחזור עם דרישות השהיה נמוכות, כדאי לפרוס את המכונה הראשית עם זמינות גבוהה (HA) ועם מכונות של מאגר קריאה.
- מפעילים את המנוע מבוסס-העמודות במכונות של מאגר הקריאה שבהן מריצים את שאילתות הניתוח.
- אם יש לכם יותר ממסד נתונים אחד, למשל CRM או Finance באותו מופע, אתם יכולים להגדיר כמה מופעים של מאגר קריאה. האסטרטגיה הזו עוזרת לשמור במטמון ביעילות ולשפר את ביצועי השאילתות.
- אתם יכולים להגדיר את הגודל של המכונות במאגר הראשי ובמאגר לקריאה בלבד בהתאם לדרישות שלכם. מידע נוסף על שיטות מומלצות למכונות של מאגר קריאה זמין במאמר שיטות מומלצות לשיפור הביצועים והזמינות של AlloyDB.
- כדי להבטיח זמינות גבוהה, כדאי להוסיף יותר מצומת אחד לכל מכונה של מאגר קריאה.
- להפעיל את המנוע מבוסס-העמודות באופן סלקטיבי במכונות ספציפיות של מאגר קריאה, כדי לשפר את הביצועים של שאילתות קריאה. לא צריך להפעיל את המנוע מבוסס-העמודות במכונה הראשית.