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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

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

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

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

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

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

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

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

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

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

יצירת אשכול ומכונה של 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 ו-128GB RAM. צריך ליצור את מכונת הלקוח באותו אזור שבו נמצאת המופע הראשי של AlloyDB.

חשוב: כדי להריץ את מדד הביצועים של OLTP שמתואר במסמך הזה, צריך להקצות את לקוח Debian Linux באותו אזור, אזור זמינות ו-VPC כמו המופע הראשי של AlloyDB. הגישה לכלי ההשוואה לשוק מתבצעת דרך כתובת IP פרטית של מכונת 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. משאירים את ערכי ברירת המחדל בקטע מערכת הפעלה ואחסון.
9. לוחצים על הקטע Networking (רשת) ומגדירים את Network interfaces (ממשקי רשת) לרשת ה-VPC שהוגדרה לגישה לשירותים פרטיים ל-AlloyDB.
   אם Network interfaces לא מוגדר לרשת ה-VPC שהוגדרה לגישה לשירותים פרטיים, מרחיבים אותו ואז מגדירים את Network לרשת ה-VPC.
10. משאירים את ערכי ברירת המחדל בקטע Observability.
11. לוחצים על הקטע אבטחה.
12. בקטע Identity and API access (זהות וגישה ל-API), מגדירים את Access scopes (היקפי גישה) לערך Allow full access to all Cloud APIs (מתן גישה מלאה לכל ממשקי Cloud API).
13. משאירים את ערכי ברירת המחדל בקטע אפשרויות מתקדמות.
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% מזיכרון ה-RAM הזמין בנפח 128GB, כולל מטמון המאגר.

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

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

1. הגדרה של מכונת הנהג להשוואה

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

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

   cd hammerdb/HammerDB-4.6

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

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

   הערה: אם אתם משתמשים בניהול מאגר חיבורים, צריך לשנות את מספר היציאה מ-5432 ל-6432. בכל הדוגמאות שבדף הזה.

   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

   הערה: מספר המשתמשים (או הלקוחות) מוגדר ל-256. מספר המשתמשים הזה מותאם כדי לספק את התפוקה הטובה ביותר עם זמן אחזור מקובל בהגדרות של מטמון חלקי ומלא.

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.

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

הרצת מדד הביצועים TPC-C

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

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

הערה: הסקריפט הבא מריץ את מדד הביצועים TPC-C במשך כשעה אחרי כ-10 דקות של חימום.

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

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

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

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 AlloyDB TPM מצטבר.

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

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

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

grep NOPM results/tpcc-run.out

זה הפלט הצפוי:

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

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

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

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

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

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

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

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

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

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

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

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

3. הגדרה של מכונת הנהג להשוואה

הרצת ההשוואה לשוק

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

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

   • מגדירים את PGHOST לכתובת ה-IP הפרטית של מכונת AlloyDB החדשה עם 64 ליבות וירטואליות.
   • בתרחיש של 30% מטמון 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 ליבות וירטואליות:

מצב השוואה לשוק	NUM_WAREHOUSE	NUM_USERS	NOPM	עלות מצטברת לאלף חשיפות (TPM)
‫30% נשמרים במטמון	12800	1024	589,598	1,371,160
100% נשמר במטמון	2304	1024	716,138	1,665,438

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

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

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

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

הפלט של הפקודה האחרונה בקטע הרצת מדד הביצועים pgbench TPC-B אמור להיראות בערך כך, כאשר --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

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

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

הרצת השוואה לשוק של Index Insert Only

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

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

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

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

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

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

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

3. הגדרה של מכונת הנהג להשוואה

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

הרצת השוואה לשוק של Index Insert Only

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

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

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

   export PGHOST=<private_ip>
   

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

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)

הרצת השוואה לשוק של מכונה עם 64 ליבות וירטואליות

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

הפעלת השוואה לביצועים של קמפיין מסוג 'בחירה בלבד' עוזרת לכם:

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

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

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

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

הרצת מדד ההשוואה 'בחירה בלבד'

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

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

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

   export PGHOST=<private_ip>
   

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

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 אלף עסקאות בשנייה ושיעור ניצול CPU של כ-95%, כמו שמוצג בפלט לדוגמה הבא.

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 Machine Type	תרחיש של עומס עבודה (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 Machine Type	תרחיש של עומס עבודה ב-pgbench	גורם לקביעת קנה מידה	TPS	CPU %‎
‫16vCPU	TBC-B Like, Fully Cached	4000	20,359	96%
‫16vCPU	‫TPC-B Like, Partially Cached	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. בתרחיש הזה, צריך לבחור SKU עם 16 ליבות CPU וזמינות גבוהה (HA), ולהגדיר מראש את האחסון.

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

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

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

Install the Google Cloud CLI.

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

Install the Google Cloud CLI.

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

1. צריך לוודא שלחשבון המשתמש שלכם מוקצים התפקידים 'אדמין Cloud SQL' ו'צפייה ב-Compute'.

   כניסה לדף IAM

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

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

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

   • גרסת מסד הנתונים: PostgreSQL 14
   • בוחרים הגדרה כדי להתחיל: Production (ייצור)
   • בוחרים אזור וזמינות אזורית: בוחרים באפשרות 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. אם יצרתם מכונת לקוח חדשה, צריך להגדיר את המכונה של מנהל ההשוואה. אחרת, פועלים לפי ההוראות במדריך הזה לגבי בדיקת הביצועים שרוצים להריץ.

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

• מעקב אחרי הביצועים של מופע AlloyDB.