השוואת ביצועים של OLTP ב-AlloyDB ל-PostgreSQL

כדי להעריך את התפוקה ואת זמן האחזור של עומסי העבודה של העסקאות ב-AlloyDB ל-PostgreSQL, אתם יכולים להגדיר את AlloyDB ואת מכונת הלקוח להשוואה בין ביצועי עיבוד העסקאות אונליין (OLTP) באמצעות TPC-C, מפרט להשוואה בין ביצועי OLTP שהוא הסטנדרט בתחום. אפשר גם להריץ תרחישי OLTP מותאמים אישית עם הרבה פעולות קריאה וכתיבה, כמו Index Insert Only ו-Select Only.

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

יכולות של עומסי עבודה ב-AlloyDB

‫AlloyDB מספק אמינות, יכולת התאמה וביצועים ברמה שמתאימה לארגונים, לכל העסקים ולעומסי עבודה קריטיים. ‫AlloyDB מספק את הרכיבים והתכונות הבאים, שמאפשרים ביצועים גבוהים לעומסי העבודה של הטרנזקציות (OLTP), הניתוח (OLAP) וההיברידיים (HTAP):

  • ניהול יומנים ועסקאות
  • ניהול זיכרון דינמי
  • שילוב של בינה מלאכותית (AI) ולמידת מכונה (ML)
  • מנוע מבוסס-עמודות מובנה
  • מטמון בכמה רמות
  • אחסון מבוזר וניתן להתאמה

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

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

סוגי נקודות ההשוואה הנתמכים

במאמר הזה נסביר איך להריץ בדיקות השוואה של OLTP באמצעות הכלים הבאים:

מנהלי התקנים להשוואת ביצועים של OLTP תרחישי שימוש
HammerDB ‫HammerDB מודד את ביצועי המערכת במונחים של טרנזקציות לדקה (TPM) ומפיק דוחות שכוללים נתונים סטטיסטיים מפורטים ומדדים לבדיקת ביצועים.

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

‫HammerDB כולל הטמעה של השוואה לשוק של TPC-C כדי להעריך את הביצועים של מערכות OLTP. ההטמעה של HammerDB TPC-C מאפשרת לדמות עומס עבודה שדומה ל-TPC-C, כולל שילוב של טרנזקציות שמדמות את ההתנהגות של סביבת ספק סיטונאי.
pgbench ‫pgbench הוא כלי להשוואה בין ביצועים שמגיע עם PostgreSQL. בעזרת pgbench אפשר לדמות עומסי עבודה של טרנזקציות כמו הוספה, עדכון ובחירת נתונים, ולמדוד את הביצועים של מערכת מסד הנתונים בטרנזקציות לשנייה (TPS).

כשמשתמשים ב-pgbench, אפשר להתאים אישית את גודל מסד הנתונים, את מספר הלקוחות ואת שילוב העסקאות כדי לדמות את עומס העבודה בסביבת הייצור, ולקבל תובנות לגבי התנהגות המערכת בתרחישים שונים.
‫pgbench כולל הטמעה של TPC-B. ההטמעה של pgbench TPC-B דומה לבדיקת ביצועים של TPC-B.

לפני שמתחילים

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  4. מפעילים את ממשקי ה-API של Cloud שנדרשים כדי ליצור מכונות של AlloyDB ל-PostgreSQL ולהתחבר אליהן.

    הפעלת ממשקי ה-API

    1. בשלב Confirm project, לוחצים על Next כדי לאשר את שם הפרויקט שבו רוצים לבצע שינויים.

    2. בשלב Enable APIs, לוחצים על Enable כדי להפעיל את ממשקי ה-API הבאים:

      • AlloyDB API
      • Compute Engine API
      • Cloud Resource Manager API
      • Service Networking API

      צריך את Service Networking API אם מתכננים להגדיר קישוריות רשת ל-AlloyDB באמצעות רשת VPC שנמצאת באותו פרויקט ב- Google Cloud כמו AlloyDB.

      אם אתם מתכננים להגדיר קישוריות רשת ל-AlloyDB באמצעות רשת VPC שנמצאת בפרויקט אחר ב- Google Cloud , אתם צריכים את Compute Engine API ואת Cloud Resource Manager API.

הגדרה והקצאה של מסד הנתונים ומכונת הלקוח

כדי להתחיל את הבדיקה, יוצרים אשכול ומכונה של AlloyDB. אלא אם צוין אחרת, המידע במסמך הזה מבוסס על מכונה ראשית של AlloyDB עם 16 vCPU ו-128GB RAM.

יצירת אשכול ומכונה של AlloyDB

  1. נכנסים לדף Clusters.

    כניסה לדף Clusters

  2. לוחצים על Create Cluster.

  3. בשדה Cluster ID, מזינים שם לאשכול.

  4. בקטע Zonal availability, בוחרים באפשרות Multiple zones (Highly Available) בתור סוג האשכול.

  5. בוחרים את רשת ברירת המחדל.

  6. בשדה Database version, בוחרים אחת מהאפשרויות הבאות:

    • ‫PostgreSQL בגרסה 17

    • PostgreSQL 18

  7. שימו לב למיקום של האזור הראשי ולכתובת ה-IP הפרטית. אל תיצרו מאגר קריאה.

  8. לוחצים על Create Cluster.

הקצאת מכונת הלקוח

כדי להריץ בדיקות השוואה של OLTP, צריך מכונה של לקוח עם כוח עיבוד מתאים. כלי השוואה כמו HammerDB ו-pgbench פועלים באופן מקבילי מאוד וצורכים הרבה משאבי מעבד (CPU). מכונת הלקוח לא יכולה להיות צוואר בקבוק כשמריצים בדיקת ביצועים של OLTP.

אלא אם צוין אחרת, ההוראות במסמך הזה משתמשות במכונה E2-standard-32 עם דיסק בנפח 128GB כלקוח לבדיקות השוואתיות של OLTP, כדי להפעיל מכונה של AlloyDB במכונה עם 16 vCPU ו-RAM בנפח 128GB. צריך ליצור את מכונת הלקוח באותו אזור שבו נמצא המכונה הראשית של AlloyDB.

כדי להריץ את מבחן הביצועים TPC-C במכונה ראשית של AlloyDB עם 16 מעבדים וירטואליים, צריך ליצור מכונה וירטואלית של Compute Engine ולהקצות מכונת לקוח:

  1. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  2. בוחרים את הפרויקט שמכיל את המכונה של AlloyDB שאליה רוצים להתחבר.
  3. לוחצים על Create instance.
  4. לוחצים על הקטע Machine configuration.
  5. מזינים שם למכונה.
  6. מגדירים את האזור שבו רוצים ליצור את המכונה. האזור חייב להיות זהה לאזור של המכונה הראשית של AlloyDB.
  7. בוחרים את סוג המכונה e2-standard-32.
  8. משאירים את ערכי ברירת המחדל בקטע OS and Storage.
  9. לוחצים על הקטע Networking ומגדירים את Network interfaces לרשת ה-VPC שהוגדרה לגישה לשירותים פרטיים ב-AlloyDB.
    אם האפשרות Network interfaces לא מוגדרת לרשת ה-VPC שהוגדרה לגישה לשירותים פרטיים, מרחיבים אותה ומגדירים את Network לרשת ה-VPC.
  10. משאירים את ערכי ברירת המחדל בקטע Observability.
  11. לוחצים על הקטע אבטחה.
  12. בקטע Identity and API access, מגדירים את היקפי גישה ל-Allow full access to all Cloud APIs.
  13. משאירים את ערכי ברירת המחדל בקטע Advanced.
  14. לוחצים על יצירה.
  15. אחרי שיוצרים את המכונה הווירטואלית, מתחברים למכונה הווירטואלית של Compute Engine שיצרת באמצעות SSH.

הגדרת מכונת הדרייבר לבדיקת הביצועים

אחרי שמתקינים ומגדירים את מסד הנתונים ואת מכונת הלקוח, מגדירים את מכונת הלקוח שפועלת ב- Google Cloud, שבה מתקינים כלים להשוואה כמו HammerDB ו-pgbench.

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

  1. מתחברים למכונת הלקוח באמצעות הפקודה הבאה של gcloud compute ssh:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME"  --project "GOOGLE_PROJECT"

  2. מתקינים את הלקוח של PostgreSQL.

    1. משתמשים בפקודה הבאה כדי להתקין לקוח PostgreSQL שכולל אפליקציית psql, ואז מוודאים שאפשר להתחבר.

      sudo apt-get update
sudo apt install postgresql-client

    2. כדי לוודא שהלקוח פועל ושאפשר להתחבר ל-AlloyDB, משתמשים בפקודה הבאה: משתמשים בכתובת ה-IP הפרטית של המכונה הראשית ב-AlloyDB.

      psql -h PRIVATE_IP -U postgres

  3. מריצים את הפקודות הבאות כדי להתקין את מנהל ההתקן HammerDB-4.6 לבדיקת הביצועים של TPC-C:

    mkdir hammerdb
pushd hammerdb
curl -OL https://github.com/TPC-Council/HammerDB/releases/download/v4.6/HammerDB-4.6-Linux.tar.gz
tar zxvf HammerDB-4.6-Linux.tar.gz

  4. כדי להתקין את מנהל ההתקן של pgbench ל-TPC-B ולבדיקות ביצועים שונות של OLTP, מריצים את הפקודות הבאות:

    sudo apt-get update
sudo apt-get install postgresql-contrib
pgbench --version

    אם הפקודה pgbench --version פועלת בלי שגיאות, סימן ש-pgbench מותקן.

ביצוע ניקוי של הערכת הביצועים

אם אתם מתכננים להריץ כמה נקודות השוואה ברצף, אתם צריכים לבצע ניקוי בין כל נקודת השוואה כדי להבטיח תוצאות מדויקות ואמינות.

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

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

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

    psql -h PRIVATE_IP -U postgres -c "DROP DATABASE IF EXISTS <database_name>;"

    מידע נוסף על השימוש ב-psql זמין במאמר התחברות למסד נתונים.

  2. מפעילים מחדש את המכונה של AlloyDB. בשלב הזה מנקים את המטמון ברמת מסד הנתונים ומערכת ההפעלה.

הרצת בדיקת ביצועים של TPC-C

‫HammerDB הוא כלי להשוואה בין ביצועים שכולל הטמעה של השוואת ביצועים מסוג TPC-C, כדי להעריך את הביצועים של מערכות OLTP. ההטמעה של TPC-C ב-HammerDB מאפשרת לדמות עומס עבודה שדומה ל-TPC-C, כולל שילוב של טרנזקציות שמדמות את ההתנהגות של סביבת ספק סיטונאי.

‫HammerDB מודד את ביצועי המערכת במונחים של טרנזקציות לדקה (TPM) ומפיק דוחות שכוללים נתונים סטטיסטיים מפורטים ומדדים לבדיקת ביצועים. בנוסף, HammerDB תומך בהתאמה אישית של הפרמטרים של נקודת ההשוואה, כך שהמשתמשים יכולים לשנות את גודל מסד הנתונים, את מספר המחסנים ומאפיינים אחרים של עומס העבודה כדי לדמות תרחישים שונים.

תרחישים של הערכת ביצועים

הביצועים של בדיקת השוואה של TPC-C מוערכים בשיטות הבאות:

  • מצב שמירה חלקית במטמון (כ-30%): במצב הזה נוצר מסד נתונים גדול של TPC-C, שיכול להתאים רק באופן חלקי למטמון המאגר. הטרנזקציות במצב הזה לא תמיד מוגשות מהזיכרון, והן גורמות לקלט/פלט לתת-המערכות של האחסון הבסיסי. התרחיש הזה רלוונטי לצרכים של משתמשים רבים ב-OLTP.

  • מצב שמירה מלאה במטמון (100%): במצב הזה, מסד הנתונים של TPC-C מתאים באופן מלא למטמון המאגר. המכונה של AlloyDB משתמשת בכ-90% מ-128GB של זיכרון ה-RAM הזמין, כולל מטמון המאגר.

    מכיוון שטרנזקציות TPC-C מבצעות פעולות קלט/פלט מינימליות – כי הקריאות מוגשות בעיקר מהמטמון של מאגר הנתונים הזמני – במצב הזה צפוי TPM גבוה יותר בהשוואה להרצות ששמורות חלקית במטמון. התרחיש הזה רלוונטי לצורכי OLTP של משתמשים עם צורכי קלט/פלט נמוכים מאוד.

הגדרת מכונת הלקוח

  1. מגדירים את מכונת מנהל ההתקן של נקודת ההשוואה.

  2. אם אתם מריצים כמה בדיקות ברצף, בצעו ניקוי של הבדיקה.

  3. פותחים את hammerdb/HammerDB-4.6 directory באמצעות הפקודה הבאה:

    cd hammerdb/HammerDB-4.6

    מריצים פקודות מהספרייה הזו כדי להגדיר את מכונת הלקוח.

  4. יוצרים את הקובץ setup.env באמצעות הפקודות הבאות:

    cat << EOF > setup.env
# Private IP of the AlloyDB primary instance
export PGHOST=PRIVATE_IP
# Postgres default port address. You do not need to change it unless you use non-default port address.
export PGPORT=5432   # default port to connect with postgres
# Number of TPC-C warehouses to load. This determines the overall database size.
export NUM_WAREHOUSE=576
# Number of users for running the benchmark.
export NUM_USERS=256
EOF

  5. עורכים את הקובץ setup.env שנוצר ומחליפים את כל ערכי הפרמטרים המודגשים בערכי פרמטרים שמתאימים להגדרת הסביבה שלכם.

  6. אופציונלי: בודקים את מצב השמירה החלקית במטמון (כ-30%) על ידי שינוי של NUM_WAREHOUSE ל-3200 בקובץ setup.env. מידע נוסף זמין במאמר תרחישים להערכת ביצועים.

  7. אופציונלי: בודקים את מצב השמירה המלאה (100%) במטמון על ידי שינוי של NUM_WAREHOUSE ל-576 ב-setup.env file. מידע נוסף זמין במאמר תרחישים להערכת ביצועים.

טעינת נתוני TPC-C למסד הנתונים

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

בשלב הטעינה, מסד הנתונים מאוכלס במספר מסוים של מחסנים, לקוחות וישויות אחרות בהתאם למפרט של TPC-C. מטרת שלב הטעינה היא ליצור עומס עבודה מציאותי לבדיקת הביצועים, ולוודא שאפשר להשוות בין תוצאות הבדיקה במערכות שונות.

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

כדי לטעון את מסד הנתונים של TPC-C:

  1. עוברים לספריית הבית של הבדיקה באמצעות הפקודה הבאה:

    cd hammerdb/HammerDB-4.6

  2. מעתיקים את התוכן הבא ומדביקים אותו ב-build-tpcc.sh:

    #!/bin/bash -x

source ./setup.env

# create role tpcc with superuser login as 'postgres' and password as 'AlloyDB#123';
# -----------------------------------------------------

./hammerdbcli << EOF

# CONFIGURE PARAMETERS FOR TPCC BENCHMARK
# --------------------------------------
dbset db pg
dbset bm tpc-c

# CONFIGURE POSTGRES HOST AND PORT
# --------------------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC
# --------------------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user tpcc
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# SET NUMBER OF WAREHOUSES AND USERS TO MANAGE EACH WAREHOUSE
# THIS IMPORTANT METRIC ESTABLISHES THE DATABASE SCALE/SIZE
# --------------------------------------
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 10

# LOG OUTPUT AND CONFIGURATION DETAILS
# --------------------------------------
vuset logtotemp 1
print dict

# CREATE AND POPULATE DATABASE SCHEMA
# --------------------------------------
buildschema

waittocomplete
vudestroy
quit

EOF

  3. מריצים את פקודת הטעינה הבאה וממתינים עד שהיא תסתיים.

    chmod +x ./build-tpcc.sh
mkdir results
sudo nohup ./build-tpcc.sh > results/build-tpcc.out 2>&1

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

    psql -h $PGHOST -p 5432 -U postgres
postgres=> \l+ tpcc
                                                                          List of databases
     Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size   | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+---------+------------+--------------------------------------------
 tpcc         | tpcc             | UTF8     | C.UTF-8 | C.UTF-8 |                                       | --- GB  | pg_default |
           |                  |          |         |         |                                       | 160.000 |            |
 (1 row)

במערך TPC-C עם 30% מטמון (עם 3,200 מחסנים), הגודל של מסד הנתונים של tpcc צפוי להיות בערך 300GB.

בהגדרת TPC-C עם 100% מטמון (עם 576 מחסנים), גודל מסד הנתונים של tpcc צפוי להיות כ-55GB.

הרצת נקודת ההשוואה של TPC-C

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

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

כדי להריץ את בדיקת ההשוואה של TPC-C:

  1. עוברים לספריית הבית של נקודת ההשוואה:

    cd hammerdb/HammerDB-4.6

  2. מעתיקים את התוכן הבא ומדביקים אותו ב-run-tpcc.sh:

    #!/bin/bash -x

source ./setup.env

./hammerdbcli << EOF
dbset db pg
dbset bm tpc-c

# CONFIGURE PG HOST and PORT
# -------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC DB
# -------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user postgres
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# BENCHMARKING PARAMETERS
# -------------------------
diset tpcc pg_driver timed
diset tpcc pg_rampup 10
diset tpcc pg_duration 60
diset tpcc pg_vacuum false
diset tpcc pg_partition false
diset tpcc pg_allwarehouse true
diset tpcc pg_timeprofile true
diset tpcc pg_connect_pool false
diset tpcc pg_dritasnap false
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 1

loadscript
print dict
vuset logtotemp 1
vuset vu $NUM_USERS
vucreate
vurun
waittocomplete
quit
EOF

  3. מריצים את הסקריפט באמצעות הפקודות הבאות:

    chmod +x run-tpcc.sh
mkdir results
sudo nohup ./run-tpcc.sh > results/run-tpcc.out 2>&1

  4. מחכים שהסקריפט run-tpcc.sh יסתיים. הסקריפט פועל במשך כשעה ו-10 דקות. אחרי שהסקריפט מסתיים, אפשר לנתח את התוצאות.

ניתוח תוצאות ההערכה

בבדיקת ביצועים של TPC-C, המדדים "הזמנות חדשות לדקה" (NOPM) ו"טרנזקציות לדקה" (TPM) משמשים למדידת הביצועים של מערכת מסד נתונים.

  • ‫NOPM: מודד את מספר העסקאות של הזמנות חדשות שהמערכת יכולה לטפל בהן בדקה אחת. הטרנזקציה של הזמנה חדשה היא אחת מהטרנזקציות החשובות ביותר בבנצ'מרק TPC-C, והיא כוללת יצירת הזמנה חדשה ללקוח.

  • ‫TPM: מודד את המספר הכולל של עסקאות שהושלמו שהמערכת יכולה לטפל בהן בדקה אחת. הטרנזקציות כוללות טרנזקציות של הזמנות חדשות וגם סוגים אחרים של טרנזקציות שמוגדרים בבנצ'מרק TPC-C, כמו תשלום, משלוח וסטטוס הזמנה.

    המדד TPM הוא מדד לבדיקת ביצועים העיקרי של מבחן הביצועים TPC-C, כי הוא מספק מדד כולל ליכולת של המערכת להתמודד עם עומס עבודה מציאותי. המדד NOPM יכול להיות שימושי למערכות שמתמקדות בעיבוד הזמנות חדשות, כמו מערכות של מסחר אלקטרוני או קמעונאות.

הצגת התוצאות עם 30% מטמון של מסד נתונים TPC-C במכונה עם 16 מעבדי vCPU

כדי לחלץ את נתוני הביצועים בתרחיש הזה, משתמשים בפקודה הבאה:

grep NOPM results/run-tpcc.out

הפלט הצפוי:

Vuser 1:TEST RESULT : System achieved 252970 NOPM from 582385 PostgreSQL TPM

עם מסד נתונים של TPC-C ש-30% ממנו נשמר במטמון במכונה עם 16 מעבדי vCPU (עם NUM_WAREHOUSE=3200 ו-NUM_USERS=256), אתם רואים 252,970 tpm-C (הזמנות חדשות לדקה) מתוך 582,385 TPM מצטברים של AlloyDB.

הצגת התוצאות עם מסד נתונים TPC-C שכולו במטמון במכונה עם 16 מעבדי vCPU

במסד נתונים TPC-C ששמור ב-100% במטמון במכונה עם 16 מעבדי vCPU (עם NUM_WAREHOUSE=576 ו-NUM_USERS=256), מתקבלים 428,316 tpm-C (הזמנות חדשות לדקה) מתוך 974,264 TPM מצטברים ב-AlloyDB.

כדי לחלץ את נתוני הביצועים של התרחיש הזה, משתמשים בפקודה הבאה:

grep NOPM results/tpcc-run.out

הפלט הצפוי:

Vuser 1:TEST RESULT : System achieved 428316 NOPM from 974264 PostgreSQL TPM

סיכום של תוצאות הביצועים במכונה עם 16 מעבדי vCPU

בטבלה הבאה מוצג סיכום של תוצאות בדיקת הביצועים של מכונה עם 16 מעבדי vCPU:

תרחיש TPC-C NUM_WAREHOUSE NUM_USERS NOPM TPM מצטבר
30% נשמרו במטמון 3200 256 252,970 582,385
‫100% נשמר במטמון 576 256 428,316 974,264

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

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

לדוגמה, אחרי הרצת הבדיקה הזו, בדף Overview של AlloyDB במסוף Google Cloud אפשר לראות שניצול ה-CPU הממוצע להרצת TPC-C במטמון של 100% הוא כמעט 90%.

הרצת הערכת ביצועים של TPC-C במכונה של AlloyDB עם 64 מעבדי vCPU

כדי להריץ בדיקת השוואה של TPC-C במכונה של AlloyDB עם 64 מעבדי vCPU, מבצעים את אותם שלבי הגדרה כמו בהרצת בדיקת השוואה של TPC-C, אבל משתמשים בסוגי מכונות שונים.

הגדרת AlloyDB ומכונת הלקוח

  1. יוצרים אשכול ומכונה של AlloyDB, ומחליפים את סוג המכונה ב-64 vCPU, 512GB.

  2. מקצים את מכונת הלקוח, ומחליפים את n2-standard-64 בסוג המכונה.

  3. מגדירים את מכונת מנהל ההתקן של נקודת ההשוואה.

הרצת הערכת הביצועים

  1. אם אתם מריצים כמה בדיקות ברצף, בצעו ניקוי של הבדיקה.

  2. מגדירים את מכונת הלקוח, ומחליפים את הערכים הבאים:

    • מגדירים את PGHOST לכתובת ה-IP הפרטית של המכונה החדשה של AlloyDB עם 64 מעבדי vCPU.
    • בתרחיש של 30% Cached TPC-C, מגדירים את NUM_WAREHOUSE=12800 ו-NUM_USERS=1024.
    • בתרחיש של 100% Cached TPC-C, מגדירים את NUM_WAREHOUSE=2304 ו-NUM_USERS=1024.

  3. הגדרה וטעינה של מסד נתונים של TPC-C. כדי לטעון מהר יותר, משנים את הערך של pg_num_vu ל-64 ב-build-tpcc.sh בתור diset tpcc pg_num_vu 64.

  4. הרצת נקודת ההשוואה של TPC-C.

ניתוח תוצאות ההערכה

בטבלה הבאה מוצג סיכום של תוצאות הערכת הביצועים במכונה עם 64 מעבדי vCPU:

מצב הערכת ביצועים NUM_WAREHOUSE NUM_USERS NOPM TPM מצטבר
30% נשמרו במטמון 12800 1024 589,598 1,371,160
‫100% נשמר במטמון 2304 1024 716,138 1,665,438

הרצת הערכת ביצועים של pgbench TPC-B

‫TPC-B (Transaction Processing Performance Council Benchmark B) הוא אחד ממצבי ההשוואה שזמינים ב-pgbench, כלי להשוואה של PostgreSQL. ‫TPC-B מדמה תרחיש בנקאי שבו כמה כספרים מבצעים עסקאות בחשבונות של לקוחות. עומס העבודה מורכב מהסוגים הבאים של טרנזקציות:

  • הפקדות
  • משיכות
  • בירורי יתרה

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

מצב TPC-B ב-pgbench יוצר מסד נתונים סינתטי ומדמה שילוב של טרנזקציות שדומה לעומס העבודה של TPC-B, אבל הוא לא מאושר באופן רשמי על ידי ארגון TPC. לכן, למרות שמצב TPC-B ב-pgbench מספק הערכה שימושית של ביצועי TPC-B, אל תשתמשו בו כדי לטעון לתאימות לתקני TPC-B.

תרחישים למדידת ביצועים

בקטע הזה מוסבר איך למדוד את הביצועים של TPC-B במצבים הקריטיים הבאים. הפרמטר היחיד ששונה במצבים האלה הוא הערך של הפרמטר SCALE_FACTOR.

תרחיש של מסד נתונים שנשמר חלקית במטמון

בתרחיש הזה, אתם מגדירים ומפעילים מסד נתונים גדול (בגודל של כ-650GB) באמצעות --scale= 50000. מסד נתונים גדול שלא מתאים לזיכרון וגורם לקלט/פלט משמעותי בדיסק, מספק ייצוג מציאותי של עומסי עבודה רבים בסביבת הייצור.

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

תרחיש של מסד נתונים שכולו במטמון

בתרחיש הזה, אתם מגדירים ומפעילים מסד נתונים בגודל של כ-60GB באמצעות --scale=4000, כך שהוא נמצא במאגר המאגרים הזמניים. חשוב לבצע השוואה של מסד נתונים שמאוחסן בזיכרון, כי כך אפשר להעריך את הביצועים המקסימליים של מערכת מסד הנתונים בסביבה מבוקרת.

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

הגדרת שרת מסד הנתונים ומכונת הלקוח

כדי להגדיר את התשתית להרצת בדיקת השוואה של pgbench TPC-B, מבצעים את השלבים הבאים:

  1. יוצרים אשכול ומכונה של AlloyDB, ומחליפים את סוג המכונה ב-16 vCPU, 128GB.

  2. מקצים את מכונת הלקוח, ומחליפים את סוג המכונה ב-E2-standard-16 (minimum).

  3. מגדירים את מכונת מנהל ההתקן של נקודת ההשוואה.

  4. מבצעים ניקוי של נקודת ההשוואה.

הרצת הערכת הביצועים של pgbench TPC-B

  1. מתחברים למכונת הלקוח באמצעות הפקודה הבאה של Google Cloud CLI:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. יוצרים את הקובץ pgbench-setup.env:

    $ cat << EOF > pgbench-setup.env

# Private IP of the AlloyDB primary instance
export PGHOST=<private_ip>

# Set PGUSER to postgres as a default user.
export PGUSER=postgres

# Password set for PGUSER
export PGPASSWORD=<your pg password>

# In pgbench, the scale factor represents the size of the test database.
# and is defined as the number of 1 MB-sized data pages to be generated per client.
export SCALE_FACTOR=<scale_factor>

# Number of clients to drive the benchmark in throughput mode
export NUM_CLIENTS=<num_clients>

EOF

  3. עורכים את קובץ setup.env שנוצר ומחליפים את ערך הפרמטר הבא בערכים שמתאימים להגדרת הסביבה שלכם.

    • ‫PRIVATE_IP: כתובת ה-IP הפרטית של המכונה ב-AlloyDB.

    אתם יכולים להיעזר בטבלה הבאה כדי לבחור את הערכים של <scale_factor> ו-<num_clients>. הערכים האלה צריכים להיות מותאמים לסוג המכונה ולגודל מסד הנתונים (שמירה מלאה או חלקית במטמון). בדוגמאות שבמדריך הזה נעשה שימוש בערכים של SCALE_FACTOR ו-NUM_CLIENT שתואמים לסוג המכונה n2-highmem-16.

    Fully Cached נשמר חלקית במטמון
    סוג מכונה SCALE_FACTOR NUM_CLIENTS SCALE_FACTOR NUM_CLIENTS
    n2-highmem-2 500 48 6250 32
    n2-highmem-4 1000 96 12500 64
    n2-highmem-8 2000 192 25000 128
    n2-highmem-16 4000 384 50000 256
    n2-highmem-32 8000 768 100000 512
    n2-highmem-64 16000 1536 200000 1024

  4. יוצרים מסד נתונים ב-pgbench.

    source ./pgbench-setup.env
psql -h $PGHOST -p 5432
postgres=> create database pgbench;
CREATE DATABASE

  5. מאתחלים וטוענים את מסד הנתונים של pgbench באמצעות הפקודות הבאות: השלב הזה מבטיח שקבוצת הנתונים להשוואה נוצרת ומאוכלסת בנתונים מציאותיים, שמאפשרים לדמות במדויק עומס עבודה של TPC-B במסד הנתונים של pgbench.

    source ./pgbench-setup.env
sudo nohup pgbench -i --host=$PGHOST --scale=$SCALE_FACTOR pgbench > /tmp/pgbench-tpcb-partially-cached-db-init.out 2>&1

    זמני טעינה צפויים:

    • טעינת מסד הנתונים שנשמר חלקית במטמון נמשכת כ-6 שעות.
    • טעינת מסד הנתונים ששמור במלואו במטמון נמשכת כ-45 דקות.

  6. אופציונלי: כדי לבדוק את דיוק הטעינה, מוודאים שהתוכן של הקובץ /tmp/pgbench-tpcb-partially-cached-db-init.out דומה לתוכן הבא:

    generating data (client-side)...
100000 of 400000000 tuples (0%) done (elapsed 0.02 s, remaining 99.82 s)
.. .. ..
.. .. ..
399800000 of 400000000 tuples (99%) done (elapsed 534.60 s, remaining 0.27 s)
399900000 of 400000000 tuples (99%) done (elapsed 534.72 s, remaining 0.13 s)
400000000 of 400000000 tuples (100%) done (elapsed 534.85 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 1481.92 s (drop tables 0.01 s, create tables 0.04 s, client-side generate 540.93 s, vacuum 615.11 s, primary keys 325.84 s).

  7. אופציונלי: כדי לוודא שהעומס תקין, מריצים את הפקודה הבאה ב-PostgreSQL, שמודדת את הגודל של כל הטבלאות ב-pgbench:

    1. מתחברים למסד הנתונים של pgbench:

      source ./pgbench-setup.env
psql -h $PGHOST -p 5432 -U postgres -d pgbench

    2. מריצים את פקודת ה-SQL הבאה:

      pgbench=> SELECT nspname AS schema_name, relname AS table_name, pg_size_pretty(pg_total_relation_size(C.oid)) AS size FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema'
ORDER BY pg_total_relation_size(C.oid) DESC;

    3. משווים בין הפלט של הפקודה הקודמת לבין הפלט שקיבלתם מהרצת מסד הנתונים שנשמר חלקית במטמון (SCALE_FACTOR=50000).

       schema_name |                table_name                 |  size
 -------------+-------------------------------------------+---------
 public      | pgbench_accounts                          | 731 GB
 public      | pgbench_accounts_pkey                     | 105 GB
 public      | pgbench_tellers                           | 32 MB
 public      | pgbench_tellers_pkey                      | 11 MB
 public      | pgbench_branches                          | 2952 kB
 public      | pgbench_branches_pkey                     | 1112 kB
 .. .. ..
 public      | pgbench_history                           | 0 bytes
 .. .. ..
 (29 rows)

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

    source ./pgbench-setup.env
mkdir -p ~/results/alloydb/pgbench
sudo nohup pgbench --host=$PGHOST --builtin=tpcb-like --time=3900 --jobs=$NUM_CLIENTS --client=$NUM_CLIENTS --scale=$SCALE_FACTOR --protocol=prepared --progress=1 pgbench > ~/results/alloydb/pgbench/pgbench.run.out 2>&1

ניתוח תוצאות ההערכה

בודקים את הפלט של הפקודה הקודמת בקובץ ~/results/alloydb/pgbench/pgbench.run.out. מספר ה-TPS צריך להיות קרוב למספרים שמוצגים בתרחישים של מסד נתונים ששמור במטמון באופן מלא ושל מסד נתונים ששמור במטמון באופן חלקי.

תוצאות עם מסד נתונים שנשמר במלואו במטמון

הפלט של הפקודה האחרונה בהרצת מבחן הביצועים TPC-B של pgbench אמור להיות דומה לזה, כאשר --scale=4000:

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 4000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 84819501
latency average = 17.654 ms
latency stddev = 6.963 ms
tps = 21747.831164 (including connections establishing)
tps = 21750.579718 (excluding connections establishing)

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

תוצאות עם מסד נתונים שנשמר חלקית במטמון

הפלט של הפקודה האחרונה בהרצת מבחן הביצועים TPC-B של pgbench אמור להיות דומה לזה, כאשר --scale=50000:

pgbench: warning: scale option ignored, using count from pgbench_branches table (50000)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>

scaling factor: 50000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 68073405
latency average = 21.992 ms
latency stddev = 29.272 ms
tps = 17453.913041 (including connections establishing)
tps = 17460.373303 (excluding connections establishing)

סיכום של תוצאות הביצועים של בדיקת ביצועים של pgbench TPC-B

בטבלה הבאה מוצג סיכום של תוצאות הביצועים של נקודת השוואה (benchmark) מסוג pgbench TPC-B:

תרחיש TPC-B SCALE_FACTOR TPS ניצול המעבד (CPU) (%)
נשמר במטמון באופן חלקי 50000 17,460 96%
שמירה מלאה במטמון 4000 21,750 94%

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

בדיקת ההשוואה Index Insert Only היא תרחיש של כתיבה אינטנסיבית עם בו-זמניות גבוהה, שמותאם אישית בקטע הזה כדי להראות את יתרונות הביצועים של AlloyDB ברוב האפליקציות של OLTP. כדי להריץ את הבדיקה הזו, יוצרים כמה אינדקסים בטבלה pgbench_history ואז מבצעים פעולות INSERT חוזרות בטבלה pgbench_history מכמה חיבורי לקוח.

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

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

הגדרת AlloyDB ומכונת הלקוח

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

  1. יוצרים אשכול ומכונה של AlloyDB, ומחליפים את סוג המכונה ב-16 vCPU and 128 GB RAM.

  2. מקצים את מכונת הלקוח, ומחליפים את סוג המכונה ב-E2-standard-16 (minimum).

  3. מגדירים את מכונת מנהל ההתקן של נקודת ההשוואה.

  4. מבצעים ניקוי של נקודת ההשוואה.

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

  1. מתחברים למכונת הלקוח באמצעות פקודת הדוגמה הבאה:

    gcloud compute ssh --zone "<primary zone>" "<client machine name>" --project "<google-project>"

  2. מגדירים את הסביבה באמצעות הפקודה הבאה:

    export PGHOST=<private_ip>

  3. יוצרים מסד נתונים ב-pgbench לפי הדוגמה הבאה. אם מסד הנתונים כבר קיים, צריך למחוק אותו וליצור אותו מחדש.

    psql -h $PGHOST -p 5432 -U postgres -c "DROP DATABASE IF EXISTS pgbench"
psql -h $PGHOST -p 5432 -U postgres -c "CREATE DATABASE pgbench"

  4. מאתחלים וטוענים את מסד הנתונים של pgbench כדי לוודא שקבוצת הנתונים של ההשוואה נוצרה ומאוכלסת בנתונים מציאותיים. עורכים את הפרמטרים המודגשים ומריצים את הפקודה הבאה:

    sudo nohup pgbench -i  --host=$PGHOST --user=postgres --scale=25000 pgbench > /tmp/pgbench-index-insert-only-init.out 2>&1
...

postgres=> create database pgbench;
CREATE DATABASE pgbench

  5. מוודאים שהפלט של הפקודה הקודמת דומה לזה:

    dropping old tables...
creating tables...
generating data (client-side)...
100000 of 2500000000 tuples (0%) done (elapsed 0.03 s, remaining 636.43 s)
200000 of 2500000000 tuples (0%) done (elapsed 0.05 s, remaining 649.12 s)
.. .. ..
.. .. ..
2499900000 of 2500000000 tuples (99%) done (elapsed 3425.42 s, remaining 0.14 s)
2500000000 of 2500000000 tuples (100%) done (elapsed 3425.57 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 12851.19 s (drop tables 998.62 s, create tables 0.02 s, client-side generate 3460.33 s, vacuum 5299.93 s, primary keys 3092.29 s).

  6. יוצרים את הסקריפט index-init.sql באמצעות הפקודות הבאות:

    cat > index-init.sql << EOF
CREATE INDEX tid ON pgbench_history(tid);
CREATE INDEX bid ON pgbench_history(bid);
CREATE INDEX aid ON pgbench_history(aid);
CREATE INDEX delta ON pgbench_history(delta);
CREATE INDEX mtime ON pgbench_history(mtime);
EOF

  7. מריצים את הסקריפט index-init.sql:

    psql -h $PGHOST -U postgres -d pgbench -f ./index-init.sql
Password for user postgres:
CREATE INDEX

  8. אופציונלי: מאמתים את סכימת מסד הנתונים ואת הטעינה הראשונית:

    psql -h $PGHOST -U postgres -d pgbench

pgbench=> \dt
           List of relations
Schema |       Name       | Type  |  Owner
--------+------------------+-------+----------
 public | pgbench_accounts | table | postgres
 public | pgbench_branches | table | postgres
 public | pgbench_history  | table | postgres
 public | pgbench_tellers  | table | postgres
(4 rows)

pgbench=> \di
                       List of relations
 Schema |         Name          | Type  |  Owner   |      Table
--------+-----------------------+-------+----------+------------------
 public | aid                   | index | postgres | pgbench_history
 public | bid                   | index | postgres | pgbench_history
 public | delta                 | index | postgres | pgbench_history
 public | mtime                 | index | postgres | pgbench_history
 public | pgbench_accounts_pkey | index | postgres | pgbench_accounts
 public | pgbench_branches_pkey | index | postgres | pgbench_branches
 public | pgbench_tellers_pkey  | index | postgres | pgbench_tellers
 public | tid                   | index | postgres | pgbench_history
(8 rows)

    אחרי הטעינה, גודל מסד הנתונים צפוי להיות בערך 365GB:

    pgbench=> \l+ pgbench
                         List of databases
Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size  | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+--------+------------+--------------------------------------------
...
 pgbench      | postgres         | UTF8     | C.UTF-8 | C.UTF-8 |                                       | 365 GB | pg_default |
...

  9. יוצרים את הסקריפט index-inserts-only.sql באמצעות הפקודות הבאות:

    cat > index-inserts-only.sql << EOF
\set aid random(1, 1000000000)
\set bid random(1, 1000000000)
\set tid random(1, 1000000000)
\set delta random(-500000000, 500000000)
BEGIN;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
EOF

  10. מריצים את בדיקת הביצועים של pgbench באמצעות הפקודה הבאה:

    sudo nohup pgbench --host=$PGHOST --user=postgres --time=3900 --client=256 --jobs=256 --scale=25000 --progress=1 --file=./index-inserts-only.sql pgbench > /tmp/pgbench-index-insert-only-run.out 2>&1

ניתוח תוצאות ההערכה

מאמתים את הפלט של הפקודה הקודמת בקובץ /tmp/pgbench-index-insert-only-run.out. בבדיקת ההשוואה הזו אמורים להופיע כ-52,000 טרנזקציות לשנייה ושיעור ניצול של כ-88% מהמעבד, כמו שמוצג בפלט לדוגמה הבא.

scaling factor: 25000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 201785196
latency average = 4.947 ms
latency stddev = 3.488 ms
tps = 51738.604613 (including connections establishing)
tps = 51742.459757 (excluding connections establishing)

הרצת הערכת ביצועים של Select Only במכונה עם 64 מעבדי vCPU

‫pgbench תומך בתרחיש מובנה של בחירה בלבד, שמריץ שוב ושוב שאילתות SELECT מכמה חיבורי לקוח מול מסד נתונים מסוים. הבדיקה הזו משמשת למדידת ביצועי הקריאה של מסד הנתונים, בלי להוסיף את התקורה של פעולות לשינוי נתונים כמו INSERT,‏ UPDATE או DELETE. שאילתות ה-SELECT האלה הן שאילתות חיפוש נקודתיות, והן הסוג המהיר והיעיל ביותר של שאילתות בחירה כי הן כוללות גישה לשורת נתונים אחת בלבד ישירות ממבני האינדקס.

הרצת בדיקה של "בחירה בלבד" עוזרת לכם:

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

  • יכולת התאמה לעומס (scalability): בחרו רק בבדיקות ביצועים שעוזרות לבדוק את יכולת ההתאמה לעומס של AlloyDB, החל מ-2 מעבדי vCPU ועד להגדרת המקסימום של מעבדי vCPU ש-AlloyDB מציע.

הגדרת AlloyDB ומכונת הלקוח

הגדרת AlloyDB ומכונת הלקוח במכונה מסוג 64vCPU.

הרצת הערכת הביצועים "בחירה בלבד"

  1. מתחברים למכונת הלקוח באמצעות פקודת הדוגמה הבאה:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. מגדירים את הסביבה באמצעות הפקודה הבאה:

    export PGHOST=<private_ip>

  3. יוצרים את מסד הנתונים pgbench באמצעות הדוגמה הבאה:

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. מאתחלים את מסד הנתונים של pgbench. הפקודה הבאה מאתחלת את מסד הנתונים של pgbench עם כ-220GB של נתונים מציאותיים. אתם משתמשים ב---scale=15000 לבדיקת הביצועים של Select Only ששמורה במלואה במטמון.

    מריצים את הפקודה הבאה:

    sudo nohup pgbench -i --host=$PGHOST --user=postgres --scale=15000 pgbench > /tmp/pgbench-select-only-init.out 2>&1

  5. מוודאים שהפלט של הפקודה הקודמת דומה לזה:

    cat /tmp/pgbench-select-only-init.out
nohup: ignoring input
dropping old tables...
creating tables...
generating data (client-side)...
100000 of 1500000000 tuples (0%) done (elapsed 0.01 s, remaining 161.60 s)
200000 of 1500000000 tuples (0%) done (elapsed 0.03 s, remaining 224.35 s)
300000 of 1500000000 tuples (0%) done (elapsed 0.09 s, remaining 448.97 s)
.. .. ..
.. .. ..
1499900000 of 1500000000 tuples (99%) done (elapsed 1251.03 s, remaining 0.08 s)
1500000000 of 1500000000 tuples (100%) done (elapsed 1251.10 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 2204.62 s (drop tables 2.29 s, create tables 0.01 s, client-side generate 1271.82 s, vacuum 427.83 s, primary keys 502.66 s).

  6. מריצים את pgbench. השלב האחרון של בדיקת הביצועים נמשך יותר משעה.

    sudo nohup pgbench --host=$PGHOST --user=postgres  --builtin=select-only --time=3900 --jobs=256 --client=256 --scale=15000 --protocol=simple --progress=1 pgbench > /tmp/pgbench-select-only-run.out  2>&1

  7. אחרי שהבדיקה מסתיימת, בודקים את הקובץ /tmp/pgbench-select-only-run.out כדי לראות את התוצאות הסופיות.

ניתוח תוצאות ההערכה

במהלך בדיקת ההשוואה הזו, אתם אמורים לראות כ-467,000 טרנזקציות לשנייה ושיעור ניצול של כ-95% מהמעבד (CPU), כמו שמוצג בפלט לדוגמה הבא.

cat /tmp/pgbench-select-only-run.out
transaction type: <builtin: select only>
scaling factor: 15000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 1823506174
latency average = 0.547 ms
latency stddev = 0.267 ms
tps = 467563.144333 (including connections establishing)
tps = 467583.398400 (excluding connections establishing)

סיכום התוצאות של הערכת הביצועים ב-AlloyDB

בטבלאות הבאות מסוכמות תוצאות הבדיקה של AlloyDB, על סמך הבדיקה שבוצעה במסמך הזה.

סיכום הביצועים של HammerDB TPC-C

סוג המכונה של AlloyDB תרחיש של עומס עבודה (workload) ב-TPC-C NUM_WAREHOUSE NUM_USERS הזמנות חדשות לדקה (NOPM) TPM מצטבר הומרו ל-TPS
16vCPU 30% נשמרו במטמון 3200 256 252,970 582,385 9,706
16vCPU ‫100% נשמר במטמון 576 256 428,316 974,264 16,238
64vCPU 30% נשמרו במטמון 12800 1024 589,598 1,371,160 22,853
64vCPU ‫100% נשמר במטמון 2304 1024 716,138 1,665,438 27,757

סיכום הביצועים של pgbench

סוג המכונה של AlloyDB תרחיש של עומס עבודה ב-pgbench גורם לקביעת קנה מידה TPS אחוז ה-CPU
16vCPU דמוי TPC-B, במטמון מלא 4000 20,359 96%
16vCPU ‫TPC-B Like, מטמון חלקי 50000 14,060 94%
16vCPU הוספת אינדקסים בלבד 25000 51,742 88%
64vCPU תפוקה מקסימלית (בחירה בלבד) 15000 467,583 ‪95%

הרצת השוואה של OLTP ב-Cloud SQL ל-PostgreSQL

כדי לבצע ניתוח השוואתי, אתם יכולים לבדוק ביצועי OLTP מקבילים ב-PostgreSQL ב-Cloud SQL ל-PostgreSQL במכונה עם 16 מעבדי vCPU. בקטע הזה מוסבר איך להגדיר Cloud SQL ל-PostgreSQL (או כל שרת PostgreSQL שפרוס בתשתית שבחרתם) שדומה להגדרה של AlloyDB שמשמשת במדריך הזה להשוואה של ביצועי OLTP. בתרחיש הזה, כולל בחירת מק"ט של 16vCPU, הפעלת זמינות גבוהה (HA) והגדרה מראש עם אחסון.

לפני שמתחילים

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  4. Install the Google Cloud CLI.

  5. Configure the gcloud CLI to use your federated identity.

    For more information, see Sign in to the gcloud CLI with your federated identity.

  6. To initialize the gcloud CLI, run the following command: 

    gcloud init
  7. מוודאים שבחשבון המשתמש שלכם יש את התפקידים "אדמין ב-Cloud SQL" ו"צפייה ב-Compute".

    כניסה לדף IAM

    מידע נוסף על תפקידים והרשאות

הקצאת מכונה של Cloud SQL ל-PostgreSQL

  1. יוצרים מכונה של PostgreSQL, ומחליפים את הערכים הבאים:

    • גרסת מסד הנתונים: PostgreSQL 14
    • בוחרים הגדרה כדי להתחיל: ייצור
    • בוחרים את האזור והזמינות לפי אזור: בוחרים באפשרות us-central1 כאזור.
    • זמינות אזורית: מספר אזורים (זמינות גבוהה)
      • האזור הראשי: us-central1-c
      • אזור משני: us-central-1-f
    • סוג המכונה: מכונה עם זיכרון גבוה, 16 vCPU, ‏104GB. זו המכונה הכי קרובה ש-Cloud SQL ל-PostgreSQL מציע למכונת AlloyDB התואמת שיצרתם בקטע "השוואה לשוק של AlloyDB" במסמך הזה.
    • נפח אחסון: בהתאמה אישית, 1,500GB
      • הפעלת הגדלה אוטומטית של נפח האחסון
    • הצפנה: Google-owned and Google-managed encryption key
    • חיבורים: כתובת IP פרטית
      • רשת: default
      • כתובת IP ציבורית: מופעלת

  2. לוחצים על Create instance.

  3. אחרי שיוצרים את מכונת PostgreSQL, רושמים את כתובת ה-IP הפרטית. אתם משתמשים בכתובת ה-IP בתור PGHOST כדי ליצור חיבורים עם נקודת ההשוואה.

הקצאת מכונת הלקוח

  1. הקצאת מכונה של Cloud SQL ל-PostgreSQL. כדי להריץ את נקודת ההשוואה של OLTP לבחירתכם, אתם צריכים מכונת לקוח עם כוח משמעותי של מעבד (CPU) באותו אזור של המכונה הראשית של Cloud SQL ל-PostgreSQL ב-Cloud SQL.

  2. אופציונלי: במקום השלב הקודם, אתם יכולים להשתמש באותו מחשב לקוח שהגדרתם לבדיקת ביצועים של AlloyDB, בתנאי שמתקיימים התנאים הבאים:

    • מכונת הלקוח נמצאת באותו אזור שבו נמצא המכונה הראשית החדשה של PostgreSQL‏ (Cloud SQL ל-PostgreSQL).
    • המחשב של הלקוח עומד בדרישות המינימליות של המעבד, ה-RAM וגודל הדיסק.

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

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

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