המלצות לגבי גודל ופריסה

במסמך הזה מפורטות המלצות לגבי עומסי עבודה ופריסות לצורך קביעת הגודל של מופעי AlloyDB ל-PostgreSQL לעומסי עבודה של עיבוד טרנזקציות אונליין (OLTP) ועיבוד אנליטי אונליין (OLAP).

סקירה כללית

כדי לעזור לכם לשפר את הביצועים של מסד הנתונים, AlloyDB ל-PostgreSQL מספק את התכונות המובנות הבאות:

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

כדי לשפר את הביצועים של מכונת AlloyDB ל-PostgreSQL, צריך לנהל את הדברים הבאים::

  • בחירת הגודל המתאים למכונות של הבריכה הראשית ולבריכת הקריאה
  • עדכון של דגלים שמשפיעים על הביצועים

שיקולים לגבי גודל

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

  • סוג עומס העבודה: OLTP,‏ OLAP או HTAP
  • דרישות ביצועים: דרישות לגבי זמן האחזור וקצב העברת הנתונים
  • גודל הנתונים הצפוי: הגודל של הנתונים שאתם מתכננים לאחסן ב-AlloyDB ל-PostgreSQL, וגודל מערך הנתונים הפעיל
  • היקף עומס העבודה: עלייה או גידול בגודל הנתונים לאורך זמן

עומסי עבודה של OLTP

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

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

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

עם זאת, שימוש בנתונים של עסקאות לשנייה (TPS) או עסקאות לדקה (TPM) יכול לספק השוואה משמעותית כדי להבין את כמות הנתונים שאפשר לטפל בהם ב-AlloyDB ל-PostgreSQL.

מדד הגודל העיקרי הוא TPS. כדי להעריך את הגודל הנדרש של AlloyDB ל-PostgreSQL, פועלים לפי השלבים הבאים:

  1. מזהים את עומס העבודה הקיים. אם אתם מבצעים העברה מ-PostgreSQL בניהול עצמי או ממסדי נתונים מסחריים אחרים, יכול להיות שכבר יש לכם את ערך ה-TPS של עומס העבודה הקיים.
  2. ניתוח השאילתות. זיהוי השאילתות הכי חשובות בעומס העבודה וקביעת דרישות הביצועים שלהן.
  3. משתמשים בכלי כמו HammerDB או pgbench. הכלים האלה עוזרים להשוות את הביצועים של AlloyDB ל-PostgreSQL ולקבוע אם גודל המכונה עונה על דרישות ה-TPS שלכם.
  4. משתמשים במדריך להשוואת ביצועים של OLTP ב-AlloyDB ל-PostgreSQL. במדריך הזה מפורטים נתוני ביצועים של תצורות שונות של AlloyDB ל-PostgreSQL, כדי שתוכלו למצוא תצורה שתעמוד בדרישות ה-TPS שלכם.
  5. בוחרים גודל מתאים של AlloyDB ל-PostgreSQL. כדאי לקחת בחשבון את גודל הנתונים הנוכחי ואת הצפי לצמיחה בעתיד.

הנחיות לגבי גודל המכונה

בטבלת הדוגמה הבאה מוצגות המלצות לנתונים עם השוואה בין ביצועים של TPC-C, עם יחס קריאה-כתיבה של כ-65% קריאות ו-35% כתיבות. כשקובעים את הגודל של מופע AlloyDB ל-PostgreSQL, צריך לשאוף לשימוש יציב ב-CPU של כ-60-70% כדי להימנע מתקורה של תזמון מערכת ההפעלה. כך יש מרווח ביטחון מסוים למקרים של עליות פתאומיות בניצול המשאבים על ידי אפליקציות לקוח.

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

vCPU/Mem טווח מומלץ של עסקאות לשנייה
(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
‫64 / 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.
  • כדי להבטיח זמינות גבוהה, מומלץ להוסיף יותר מצומת אחד לכל מופע של מאגר קריאה.
  • הפעלה סלקטיבית של מנוע עמודות במופעים ספציפיים של מאגר קריאה לשיפור הביצועים של שאילתות קריאה. במקרה הזה, לא צריך להפעיל את מנוע מבוסס-העמודות במופע הראשי.

כדאי להשתמש בתכונות מובנות כמו index advisor כדי להוסיף אינדקסים שיכולים לשפר את ביצועי השאילתות.

עומסי עבודה של OLAP

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

למידע נוסף על מדידת ביצועי OLAP באמצעות AlloyDB ל-PostgreSQL עם עומס עבודה של TPC-H, אפשר לעיין במדריך בנושא השוואת ביצועים של OLAP ב-PostgreSQL ל-PostgreSQL.

סוגי פריסות

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

רק ראשי

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

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

Primary with read pool

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

  • אם יש לכם פעולות כתיבה רבות וגם קריאות אנליטיות שרגישות לזמן אחזור עם דרישות נמוכות של השהיה, כדאי לפרוס את המכונה הראשית עם זמינות גבוהה (HA) מופעלת, ועם מכונות ממאגר הקריאה.
  • מפעילים את מנוע העמודות במופעים של מאגר קריאה שבהם מריצים את השאילתות האנליטיות.
  • אם יש לכם יותר ממסד נתונים אחד – למשל, CRM או Finance באותו מופע – אתם יכולים להגדיר כמה מופעים של מאגר קריאה. השימוש באסטרטגיה הזו עוזר לשמירה יעילה במטמון ולביצועי שאילתות.
  • אתם יכולים להגדיר גודל שונה למופעים של מאגר הקריאה ולמופע הראשי בהתאם לדרישות שלכם. מידע נוסף על שיטות מומלצות לשימוש במופעים של מאגר קריאה זמין במאמר שיטות מומלצות לשיפור הביצועים והזמינות של AlloyDB.
  • כדי להבטיח זמינות גבוהה, מומלץ להוסיף יותר מצומת אחד לכל מופע של מאגר קריאה.
  • הפעלה סלקטיבית של מנוע עמודות במופעים ספציפיים של מאגר קריאה לשיפור הביצועים של שאילתות קריאה. במקרה הזה, לא צריך להפעיל את מנוע מבוסס-העמודות במופע הראשי.

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