השוואת ביצועים של 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	תרחישים לדוגמה
HammerDB	‫HammerDB מודד את ביצועי המערכת במונחים של עסקאות לדקה (TPM) ומפיק דוחות שכוללים נתונים סטטיסטיים מפורטים ומדדי ביצועים.‫ ‫HammerDB תומך בהתאמה אישית של פרמטרים להשוואה, שמאפשרת לכם לשנות את גודל מסד הנתונים, את מספר המחסנים ומאפיינים אחרים של עומס העבודה כדי לדמות תרחישים שונים.‫ ‫HammerDB כולל הטמעה של השוואה מסוג TPC-C להערכת הביצועים של מערכות OLTP. ההטמעה של TPC-C ב-HammerDB מאפשרת לכם לדמות עומס עבודה שדומה להשוואה מסוג TPC-C, כולל שילוב של עסקאות שמדמות את ההתנהגות של סביבת ספק סיטונאי.
pgbench	‫pgbench הוא כלי להשוואת ביצועים שמגיע עם PostgreSQL.‫pgbench מאפשר לדמות עומסי עבודה של עסקאות, כמו הוספה, עדכון ובחירה של נתונים, ולמדוד את הביצועים של מערכת מסד הנתונים בעסקאות לשנייה (TPS). כשמשתמשים ב-pgbench, אפשר להתאים אישית את גודל מסד הנתונים, את מספר הלקוחות ואת שילוב העסקאות כדי לחקות את עומס העבודה של הייצור ולקבל תובנות לגבי התנהגות המערכת בתרחישים שונים. ‫pgbench כולל הטמעה של TPC-B. ההטמעה של TPC-B ב-pgbench דומה למדד השוואת הביצועים 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.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. 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.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

1. מפעילים את Cloud APIs שנדרשים כדי ליצור מכונת 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. לוחצים על יצירת אשכול.

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

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

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

6. בשדה Database version (גרסת מסד הנתונים), בוחרים באחת מהאפשרויות הבאות:

   • PostgreSQL 17

   • ‫PostgreSQL 18

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

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

8. לוחצים על יצירת אשכול.

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

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

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

חשוב: כדי להריץ את בדיקת הביצועים של OLTP שמתוארת במסמך הזה, צריך להקצות את לקוח Debian Linux באותו אזור, באותו אזור זמינות ובאותו VPC כמו המופע הראשי של AlloyDB. הגישה לכלים להשוואת ביצועים (benchmarking) מתבצעת למכונת AlloyDB באמצעות כתובת IP פרטית.

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

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

הצגת תוצאות עם מסד נתונים של TPC-C בזיכרון מטמון של 30% במכונה עם 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 (New Order Per Minute) מתוך 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

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

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

הפלט של הפקודה האחרונה בקטע הרצת מדד הביצועים 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	ניצול יחידת העיבוד המרכזית (CPU) (%)
מאוחסן במטמון באופן חלקי	50000	17,460	96%
במטמון	4000	21,750	94%

הפעלת השוואה לשוק של הוספת אינדקס בלבד

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

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

‫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)

הפעלת מדד השוואה מסוג Select Only במופע עם 64 ליבות וירטואליות

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

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

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

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

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

התקינו את ה-CLI של Google Cloud.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

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.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

התקינו את ה-CLI של Google Cloud.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

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.