Mengukur performa OLTP di AlloyDB untuk PostgreSQL

Dokumen ini menjelaskan cara mengonfigurasi AlloyDB untuk PostgreSQL dan mesin klien untuk menjalankan benchmark performa AlloyDB menggunakan TPC-C, spesifikasi benchmark OLTP. Dokumen ini juga menjelaskan cara menjalankan skenario OLTP intensif baca dan tulis yang disesuaikan, seperti Index Insert Only dan Select Only.

Petunjuk dalam dokumen ini didasarkan pada konfigurasi AlloDB dan mesin klien tertentu. Gunakan nilai yang diberikan untuk setiap langkah dalam petunjuk benchmark.

Kemampuan workload AlloyDB

AlloyDB memberikan keandalan, skalabilitas, dan performa tingkat perusahaan yang cocok untuk semua bisnis dan workload penting. AlloyDB menyediakan komponen dan fitur berikut yang memungkinkan performa tinggi untuk workload transaksional (OLTP), analitis (OLAP), dan hybrid (HTAP):

  • Pengelolaan log dan transaksi
  • Pengelolaan memori dinamis
  • Integrasi kecerdasan buatan dan machine learning
  • Mesin kolom bawaan
  • Cache multi-tingkat
  • Penyimpanan terdistribusi dan skalabel

Sistem database relasional biasanya mengharuskan administrator database untuk mengoptimalkan database untuk benchmark, yang mencakup mengonfigurasi setelan log transaksi, menetapkan ukuran kumpulan buffering yang tepat, dan mengubah parameter database atau tanda dan karakteristik lainnya. Setelan ini bervariasi, bergantung pada ukuran dan jenis instance.

AlloyDB telah dikonfigurasi sebelumnya dengan setelan yang dioptimalkan untuk setiap jenis mesin. AlloyDB tidak mengharuskan Anda menyesuaikan flag di tingkat database untuk mencapai performa OLTP yang tinggi. Sebagai gantinya, AlloyDB memiliki performa OLTP bawaan yang tinggi.

Jenis benchmark yang didukung

Dokumen ini menunjukkan cara menjalankan benchmark OLTP menggunakan alat berikut:

Pembuat benchmark OLTP Kasus penggunaan
HammerDB HammerDB mengukur performa sistem dalam hal transaksi per menit (TPM) dan menghasilkan laporan yang menyertakan statistik mendetail dan metrik performa.

HammerDB mendukung penyesuaian parameter benchmark, yang memungkinkan Anda menyesuaikan ukuran database, jumlah warehouse, dan karakteristik beban kerja lainnya untuk menyimulasikan berbagai skenario.

HammerDB menyertakan implementasi benchmark TPC-C untuk mengevaluasi performa sistem OLTP. Implementasi TPC-C HammerDB memungkinkan Anda menyimulasikan beban kerja yang mirip dengan benchmark TPC-C, termasuk campuran transaksi yang meniru perilaku lingkungan pemasok grosir.
pgbench pgbench adalah alat benchmark yang disertakan bersama PostgreSQL. pgbench memungkinkan Anda menyimulasikan beban kerja transaksi seperti menyisipkan, memperbarui, memilih data, dan mengukur performa sistem database dalam Transaksi Per Detik (TPS).

Saat menggunakan pgbench, Anda dapat menyesuaikan ukuran database, jumlah klien, dan campuran transaksi untuk mengemulasi beban kerja produksi dan mendapatkan insight tentang perilaku sistem dalam berbagai skenario.
pgbench menyertakan implementasi TPC-B. Implementasi TPC-B pgbench mirip dengan benchmark TPC-B.

Sebelum memulai

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

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

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Aktifkan Cloud API yang diperlukan untuk membuat dan terhubung ke AlloyDB untuk PostgreSQL.

    Aktifkan API

    1. Pada langkah Konfirmasi project, klik Berikutnya untuk mengonfirmasi nama project yang akan Anda ubah.

    2. Pada langkah Aktifkan API, klik Aktifkan untuk mengaktifkan hal berikut:

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

      Service Networking API diperlukan jika Anda berencana mengonfigurasi konektivitas jaringan ke AlloyDB menggunakan jaringan VPC yang berada di project Google Cloud yang sama dengan AlloyDB.

      Compute Engine API dan Cloud Resource Manager API diperlukan jika Anda berencana untuk mengonfigurasi konektivitas jaringan ke AlloyDB menggunakan jaringan VPC yang berada di project Google Cloud yang berbeda.

Menyiapkan dan menyediakan database serta mesin klien

Mulai benchmark dengan membuat cluster dan instance AlloyDB. Kecuali jika ditentukan lain, informasi dalam dokumen ini didasarkan pada 16 vCPU dengan RAM 128 GB sebagai instance AlloyDB utama.

Membuat cluster dan instance AlloyDB

  1. Buka halaman Cluster.

    Buka Cluster

  2. Klik Create Cluster.

  3. Di kolom Cluster ID, masukkan nama untuk cluster Anda.

  4. Di Zonal availability, pilih Multiple zones (Highly Available) untuk jenis cluster.

  5. Pilih jaringan default.

  6. Di kolom Database version, pilih PostgreSQL 15.

  7. Catat lokasi zona utama dan alamat IP pribadi. Jangan membuat kumpulan baca.

  8. Klik Create Cluster.

Menyediakan mesin klien

Untuk menjalankan benchmark OLTP, Anda memerlukan mesin klien dengan daya pemrosesan yang memadai. Alat benchmark seperti HammerDB dan pgbench berjalan dengan cara yang sangat paralel, dan menggunakan banyak CPU. Mesin klien tidak boleh menjadi bottleneck saat Anda menjalankan benchmark OLTP.

Kecuali jika ditentukan lain, petunjuk dalam dokumen ini menggunakan mesin E2-standard-32 dengan disk 128 GB sebagai klien untuk benchmark OLTP guna mendorong instance AlloyDB di mesin 16 vCPU dengan RAM 128 GB. Anda harus membuat mesin klien di zona yang sama dengan instance utama AlloyDB.

Untuk menjalankan benchmark TPC-C pada instance utama AlloyDB dengan 16 CPU virtual, ikuti langkah-langkah berikut untuk membuat VM Compute Engine dan menyediakan mesin klien:

  1. Di konsol Google Cloud, buka halaman Instance VM.

    Buka instance VM

  2. Pilih project yang berisi instance AlloyDB yang ingin Anda hubungkan.
  3. Klik Create instance.
  4. Klik bagian Konfigurasi mesin.
  5. Masukkan Nama untuk instance.
  6. Konfigurasikan zona tempat Anda ingin membuat instance. Zona harus sama dengan zona instance utama AlloyDB.
  7. Pilih jenis mesin e2-standard-32.
  8. Pertahankan nilai default di bagian OS and Storage.
  9. Klik bagian Networking, lalu tetapkan Network interfaces ke jaringan VPC yang dikonfigurasi untuk akses layanan pribadi ke AlloyDB.
    Jika Network interfaces tidak ditetapkan ke jaringan VPC yang dikonfigurasi untuk akses layanan pribadi, luaskan, lalu tetapkan Network ke jaringan VPC.
  10. Pertahankan nilai default di bagian Observabilitas.
  11. Klik bagian Keamanan.
  12. Di bagian Identity and API access, tetapkan Access scopes ke Allow full access to all Cloud APIs.
  13. Mempertahankan nilai default di bagian Advanced.
  14. Klik Buat.
  15. Setelah VM dibuat, hubungkan ke VM Compute Engine yang Anda buat menggunakan SSH.

Menyiapkan mesin driver benchmark

Setelah menginstal dan menyiapkan database dan komputer klien, Anda mengonfigurasi komputer klien yang berjalan di Google Cloud, tempat Anda menginstal alat benchmarking seperti HammerDB dan pgbench.

Untuk menyiapkan mesin driver benchmark, ikuti langkah-langkah berikut:

  1. Hubungkan ke mesin klien menggunakan perintah gcloud compute ssh berikut:

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

  2. Instal klien PostgreSQL.

    1. Gunakan perintah berikut untuk menginstal klien PostgreSQL yang menyertakan aplikasi psql, lalu pastikan Anda dapat terhubung.

      sudo apt-get update
sudo apt install postgresql-client

    2. Gunakan perintah berikut untuk memastikan klien berfungsi dan Anda dapat terhubung ke AlloyDB. Gunakan alamat IP pribadi instance AlloyDB utama Anda.

      psql -h PRIVATE_IP -U postgres

  3. Instal driver HammerDB-4.6 untuk benchmark TPC-C dengan menjalankan perintah berikut:

    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. Instal driver pgbench untuk TPC-B dan benchmark OLTP lainnya dengan menjalankan perintah berikut:

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

    Jika pgbench --version berjalan tanpa error, artinya pgbench telah diinstal.

Melakukan pembersihan benchmark

Jika berencana menjalankan beberapa benchmark secara berurutan, Anda harus melakukan pembersihan benchmark di antara setiap benchmark untuk memastikan hasil benchmark yang akurat dan andal.

Pembersihan benchmark memastikan bahwa efek residu dari benchmark sebelumnya tidak memengaruhi pengukuran performa benchmark baru. Pembersihan benchmark juga membantu memastikan konsistensi dan pengulangan hasil benchmark, yang penting untuk membuat perbandingan yang bermakna antara berbagai sistem atau mengidentifikasi area untuk pengoptimalan dalam hardware, software, atau konfigurasi.

Ikuti langkah-langkah berikut untuk melakukan pembersihan benchmark sebelum menjalankan benchmark lain:

  1. Hapus data benchmark atau database benchmark sebelumnya. Untuk menghapus database benchmark sebelumnya, gunakan perintah psql berikut dari mesin klien:

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

    Untuk mengetahui informasi selengkapnya tentang penggunaan psql, lihat Menghubungkan ke database.

  2. Mulai ulang instance AlloyDB. Langkah ini akan menghapus cache di tingkat database dan sistem operasi.

Menjalankan Benchmark TPC-C

HammerDB adalah alat benchmark yang menyertakan implementasi benchmark TPC-C untuk mengevaluasi performa sistem OLTP. Implementasi TPC-C HammerDB memungkinkan Anda menyimulasikan beban kerja yang mirip dengan benchmark TPC-C, termasuk campuran transaksi yang meniru perilaku lingkungan pemasok grosir.

HammerDB mengukur performa sistem dalam hal transaksi per menit (TPM) dan membuat laporan yang menyertakan statistik dan metrik performa mendetail. Selain itu, HammerDB mendukung penyesuaian parameter benchmark, yang memungkinkan pengguna menyesuaikan ukuran database, jumlah warehouse, dan karakteristik beban kerja lainnya untuk menyimulasikan berbagai skenario.

Skenario evaluasi performa

Performa benchmark TPC-C dievaluasi menggunakan metode berikut:

  • Mode cache sebagian (~30%): Dalam mode ini, database TPC-C besar dibuat, yang hanya dapat muat sebagian dalam cache buffer. Transaksi dalam mode ini tidak selalu ditayangkan dari memori dan menimbulkan I/O ke subsistem penyimpanan yang mendasarinya. Skenario ini berlaku untuk kebutuhan OLTP banyak pengguna.

  • Mode cache penuh (100%): Dalam mode ini, database TPC-C sepenuhnya sesuai dengan cache buffer. Instance AlloyDB menggunakan sekitar 90% dari RAM 128 GB yang tersedia, termasuk cache buffer.

    Karena transaksi TPC-C melakukan I/O minimal —karena sebagian besar pembacaan dilayani dari cache buffer— dalam mode ini, TPM yang lebih tinggi diharapkan dibandingkan dengan operasi yang di-cache sebagian. Skenario ini berlaku untuk kebutuhan OLTP pengguna dengan kebutuhan I/O yang sangat rendah.

Menyiapkan mesin klien

  1. Siapkan mesin driver benchmark.

  2. Jika Anda menjalankan beberapa benchmark secara berurutan, lakukan pembersihan benchmark.

  3. Buka hammerdb/HammerDB-4.6 directory dengan menjalankan perintah berikut:

    cd hammerdb/HammerDB-4.6

    Anda menjalankan perintah dari direktori ini untuk menyiapkan mesin klien.

  4. Buat file setup.env menggunakan perintah berikut:

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

  5. Edit file setup.env yang dihasilkan dengan mengganti semua parameter value yang ditandai dengan parameter value yang paling sesuai dengan penyiapan lingkungan Anda.

  6. Opsional: Uji mode yang di-cache sebagian (~30%) dengan mengubah NUM_WAREHOUSE menjadi 3200 dalam file setup.env. Untuk informasi selengkapnya, lihat Skenario evaluasi performa.

  7. Opsional: Uji mode yang di-cache sepenuhnya (100%) dengan mengubah NUM_WAREHOUSE menjadi 576 di setup.env file. Untuk informasi selengkapnya, lihat Skenario evaluasi performa.

Memuat data TPC-C ke dalam database

Langkah pemuatan mengacu pada proses mengisi database benchmark dengan data awal sebelum menjalankan pengujian performa.

Selama langkah pemuatan, database diisi dengan sejumlah gudang, pelanggan, dan entitas lainnya sesuai dengan spesifikasi TPC-C. Tujuan langkah pemuatan adalah untuk membuat beban kerja yang realistis untuk pengujian performa, dan untuk memastikan bahwa hasil pengujian sebanding di berbagai sistem.

Setelah langkah pemuatan selesai, database berada dalam status yang konsisten dengan kumpulan data awal yang ditentukan, siap digunakan untuk pengujian benchmark TPC-C.

Untuk memuat database TPC-C, ikuti langkah-langkah berikut:

  1. Beralih ke direktori utama benchmark menggunakan perintah berikut:

    cd hammerdb/HammerDB-4.6

  2. Salin konten berikut, lalu tempelkan ke 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. Jalankan perintah pemuatan berikut dan tunggu hingga perintah selesai.

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

  4. Validasi pemuatan. Setelah skrip sebelumnya selesai, sebaiknya confirmasikan bahwa pemuatan database berhasil. Untuk memverifikasi ukuran database, jalankan perintah berikut:

    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)

Dalam konfigurasi TPC-C yang di-cache 30% (dengan 3.200 warehouse), ukuran database tpcc diperkirakan sekitar 300 GB.

Dalam konfigurasi TPC-C yang di-cache 100% (dengan 576 warehouse), ukuran database tpcc diperkirakan sekitar 55 GB.

Menjalankan benchmark TPC-C

Sekarang Anda siap menjalankan pengujian performa TPC-C. Benchmark TPC-C dijalankan menggunakan database yang diisi dari langkah pemuatan. Benchmark menghasilkan serangkaian transaksi yang menyimulasikan lingkungan bisnis yang khas, termasuk entri pesanan, pemrosesan pembayaran, dan pengelolaan inventaris. Beban kerja diukur dalam transaksi per menit (TPM), yang mewakili jumlah transaksi bisnis lengkap yang dapat ditangani sistem dalam satu menit.

Langkah run dirancang untuk membebani sistem database dalam kondisi yang realistis dan untuk memberikan cara standar dalam mengukur performa yang dapat Anda bandingkan di berbagai sistem database. Vendor dan pengguna sering menggunakan hasil benchmark TPC-C untuk mengevaluasi performa berbagai sistem database dan konfigurasi hardware.

Untuk menjalankan benchmark TPC-C, ikuti langkah-langkah berikut:

  1. Beralih ke direktori utama benchmark:

    cd hammerdb/HammerDB-4.6

  2. Salin konten berikut, lalu tempelkan ke 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. Jalankan skrip menggunakan perintah berikut:

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

  4. Tunggu hingga skrip run-tpcc.sh selesai. Skrip ini memerlukan waktu sekitar 1 jam 10 menit untuk diselesaikan. Setelah skrip selesai, Anda dapat menganalisis hasilnya.

Menganalisis hasil benchmark

Dalam benchmark TPC-C, Pesanan Baru Per Menit (NOPM) dan Transaksi Per Menit (TPM) adalah metrik performa yang digunakan untuk mengukur performa sistem database.

  • NOPM: mengukur jumlah transaksi pesanan baru yang dapat ditangani sistem dalam satu menit. Transaksi pesanan baru adalah salah satu transaksi yang paling penting dalam benchmark TPC-C dan melibatkan pembuatan pesanan baru untuk pelanggan.

  • TPM: mengukur jumlah total transaksi bisnis yang diselesaikan yang dapat ditangani sistem dalam satu menit. Transaksi mencakup transaksi pesanan baru serta jenis transaksi lainnya yang ditentukan dalam benchmark TPC-C, seperti pembayaran, pengiriman, dan status pesanan.

    TPM adalah metrik performa utama untuk benchmark TPC-C karena memberikan pengukuran keseluruhan kemampuan sistem untuk menangani beban kerja yang realistis. NOPM dapat menjadi metrik yang berguna untuk sistem yang berfokus pada pemrosesan pesanan baru, seperti sistem e-commerce atau retail.

Melihat hasil dengan database TPC-C yang di-cache 30% di mesin dengan 16 vCPU

Untuk mengekstrak angka performa untuk skenario ini, gunakan perintah berikut:

grep NOPM results/run-tpcc.out

Berikut adalah output yang diharapkan:

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

Dengan database TPC-C yang di-cache 30% di mesin 16 vCPU (dengan NUM_WAREHOUSE=3200 dan NUM_USERS=256), Anda mengamati 252.970 tpm-C (Pesanan Baru Per Menit) dari TPM AlloyDB kumulatif 582.385.

Melihat hasil dengan database TPC-C yang di-cache 100% di mesin dengan 16 vCPU

Pada database TPC-C yang di-cache 100% di mesin 16 vCPU (dengan NUM_WAREHOUSE=576 dan NUM_USERS=256), Anda mengamati 428.316 tpm-C (Pesanan Baru Per Menit) dari TPM AlloyDB kumulatif 974.264.

Untuk mengekstrak angka performa untuk skenario ini, gunakan perintah berikut:

grep NOPM results/tpcc-run.out

Berikut adalah output yang diharapkan:

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

Ringkasan hasil performa pada mesin dengan 16 vCPU

Tabel berikut meringkas hasil performa benchmark untuk mesin dengan 16 vCPU:

Skenario TPC-C NUM_WAREHOUSE NUM_USERS NOPM TPM Kumulatif
30% di-cache 3200 256 252.970 582.385
100% di-cache 576 256 428.316 974.264

Mengamati metrik performa database

Untuk lebih memahami perilaku sistem database Anda, gunakan alat pemantauan AlloyDB untuk mengamati metrik sistem penting seperti penggunaan CPU, penggunaan memori, dan transaksi per detik. Untuk informasi selengkapnya, lihat Memantau performa instance.

Misalnya, setelah menjalankan benchmark ini, Anda dapat mengamati di halaman Ringkasan AlloyDB di konsol Google Cloud bahwa penggunaan CPU rata-rata untuk operasi TPC-C yang di-cache 100% hampir 90%.

Menjalankan benchmark TPC-C pada instance AlloyDB 64 vCPU

Untuk menjalankan benchmark TPC-C pada instance AlloyDB 64 vCPU, Anda harus mengikuti langkah-langkah penyiapan yang sama seperti dalam Menjalankan benchmark TPC-C, tetapi Anda menggunakan jenis mesin yang berbeda.

Menyiapkan AlloyDB dan mesin klien

  1. Buat cluster dan instance AlloyDB, ganti 64 vCPU, 512GB sebagai jenis mesin.

  2. Sediakan mesin klien, dengan mengganti n2-standard-64 sebagai jenis mesin.

  3. Siapkan mesin driver benchmark.

Menjalankan benchmark

  1. Jika Anda menjalankan beberapa benchmark secara berurutan, lakukan pembersihan benchmark.

  2. Siapkan mesin klien, dengan mengganti nilai berikut:

    • Tetapkan PGHOST ke IP Pribadi instance AlloyDB 64 vCPU baru Anda.
    • Untuk skenario TPC-C yang Di-cache 30%, tetapkan NUM_WAREHOUSE=12800 dan NUM_USERS=1024.
    • Untuk skenario TPC-C yang Disimpan dalam Cache 100%, tetapkan NUM_WAREHOUSE=2304 dan NUM_USERS=1024.

  3. Menyiapkan dan memuat database TPC-C. Untuk mempercepat pemuatan, ubah nilai pg_num_vu menjadi 64 di build-tpcc.sh sebagai diset tpcc pg_num_vu 64.

  4. Menjalankan benchmark TPC-C.

Menganalisis hasil benchmark

Tabel berikut meringkas hasil performa benchmark pada mesin dengan 64 vCPU:

Mode benchmark NUM_WAREHOUSE NUM_USERS NOPM TPM Kumulatif
30% di-cache 12800 1024 589.598 1.371.160
100% di-cache 2304 1024 716.138 1.665.438

Menjalankan benchmark TPC-B pgbench

TPC-B (Transaction Processing Performance Council Benchmark B) adalah salah satu mode benchmark yang tersedia di pgbench, alat benchmark untuk PostgreSQL. TPC-B menyimulasikan skenario perbankan dengan beberapa kasir yang menjalankan transaksi di akun pelanggan. Beban kerja terdiri dari jenis transaksi berikut:

  • Setoran
  • Penarikan
  • Pertanyaan saldo

Benchmark mengukur performa sistem database dengan menyimulasikan campuran transaksi ini dan mengukur jumlah transaksi per detik yang dapat ditangani sistem.

Mode TPC-B di pgbench menghasilkan database sintetis dan menyimulasikan gabungan transaksi yang menyerupai beban kerja TPC-B, tetapi tidak disertifikasi secara resmi oleh organisasi TPC. Oleh karena itu, meskipun mode TPC-B di pgbench memberikan perkiraan performa TPC-B yang berguna, jangan menggunakannya untuk mengklaim kepatuhan terhadap standar TPC-B.

Skenario untuk mengukur performa

Bagian ini menjelaskan cara mengukur performa TPC-B dalam mode kritis berikut. Satu-satunya parameter yang berbeda dalam mode ini adalah nilai parameter SCALE_FACTOR.

Skenario database yang di-cache sebagian

Dalam skenario ini, Anda akan menyiapkan dan melakukan inisialisasi database besar (ukuran sekitar 650 GB) menggunakan --scale= 50000. Memiliki database besar yang tidak muat dalam memori dan menyebabkan I/O disk yang signifikan memberikan representasi yang realistis dari banyak beban kerja produksi.

Database besar yang menyebabkan I/O disk yang signifikan dapat menekankan pentingnya desain database dan pengoptimalan kueri. Database besar juga dapat mengekspos masalah performa yang terkait dengan I/O disk, seperti akses disk yang lambat atau kueri yang tidak efisien, yang mungkin tidak terlihat dalam database kecil atau sepenuhnya berada di memori.

Skenario database yang di-cache sepenuhnya

Dalam skenario ini, Anda menyiapkan dan melakukan inisialisasi database dengan ukuran sekitar 60 GB menggunakan --scale=4000 sehingga berada di kumpulan buffer. Benchmarking database yang berada dalam memori penting karena memungkinkan Anda menilai performa maksimum sistem database dalam lingkungan yang terkontrol.

Database yang berada dalam memori menyimpan semua data dalam kumpulan buffer PostgreSQL, sehingga menghilangkan bottleneck I/O yang dapat terjadi saat mengakses data dari disk. Mode ini dapat membantu mengidentifikasi bottleneck performa yang tidak terkait dengan I/O, seperti penggunaan CPU atau masalah penguncian, yang mungkin tidak terlihat saat Anda menjalankan benchmark database yang mengandalkan I/O disk.

Menyiapkan server database dan mesin klien

Untuk menyiapkan infrastruktur guna menjalankan benchmark pgbench TPC-B, ikuti langkah-langkah berikut:

  1. Buat cluster dan instance AlloyDB, ganti 16 vCPU, 128GB sebagai jenis mesin.

  2. Sediakan mesin klien, dengan mengganti E2-standard-16 (minimum) sebagai jenis mesin.

  3. Siapkan mesin driver benchmark.

  4. Lakukan pembersihan benchmark.

Menjalankan benchmark TPC-B pgbench

  1. Hubungkan ke komputer klien menggunakan perintah Google Cloud CLI berikut:

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

  2. Buat file 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. Edit file setup.env yang dihasilkan dan ganti parameter value berikut dengan nilai yang sesuai dengan penyiapan lingkungan Anda.

    • PRIVATE_IP: IP pribadi instance AlloyDB Anda.

    Gunakan tabel berikut untuk memilih nilai <scale_factor> dan <num_clients>. Nilai ini harus diskalakan dengan jenis mesin dan ukuran database (di-cache sepenuhnya atau di-cache sebagian). Contoh dalam panduan ini menggunakan nilai SCALE_FACTOR dan NUM_CLIENT yang sesuai dengan jenis mesin n2-highmem-16.

    Di-cache Sepenuhnya Di-cache Sebagian
    Machine Type 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 8.000 768 100000 512
    n2-highmem-64 16000 1536 200000 1024

  4. Membuat database pgbench.

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

  5. Lakukan inisialisasi dan muat database pgbench dengan menjalankan perintah berikut. Langkah ini memastikan bahwa set data benchmarking dibuat dan diisi dengan data yang realistis, yang memungkinkan Anda menyimulasikan beban kerja TPC-B secara akurat di database 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

    Perkiraan waktu pemuatan:

    • Database yang di-cache sebagian memerlukan waktu sekitar 6 jam untuk dimuat.
    • Database yang di-cache sepenuhnya memerlukan waktu sekitar 45 menit untuk dimuat.

  6. Opsional: Lakukan pemeriksaan akurasi pemuatan dengan memastikan bahwa konten file /tmp/pgbench-tpcb-partially-cached-db-init.out mirip dengan yang berikut ini:

    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. Opsional: Untuk memvalidasi akurasi pemuatan lebih lanjut, jalankan perintah PostgreSQL berikut yang mengukur ukuran semua tabel pgbench:

    1. Menghubungkan ke database pgbench:

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

    2. Jalankan perintah SQL berikut:

      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. Bandingkan output perintah sebelumnya dengan output yang Anda dapatkan untuk operasi database yang di-cache sebagian (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. Jalankan perintah berikut untuk menyimulasikan beban kerja sistem akuntansi keuangan dengan menjalankan serangkaian transaksi yang melibatkan setoran, transfer, dan pembayaran, yang memungkinkan Anda mengukur performa database dalam beban kerja yang berat.

    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

Menganalisis hasil benchmark

Periksa output perintah sebelumnya dalam file ~/results/alloydb/pgbench/pgbench.run.out. Jumlah TPS harus dekat dengan angka yang ditampilkan dalam database yang di-cache sepenuhnya dan dalam skenario database yang di-cache sebagian.

Hasil dengan database yang di-cache sepenuhnya

Output perintah terakhir di Menjalankan benchmark TPC-B pgbench akan mirip dengan berikut, dengan --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)

Untuk lebih memahami perilaku sistem database, Anda dapat memantau metrik sistem seperti penggunaan CPU, penggunaan memori, dan transaksi per detik menggunakan konsol Google Cloud. Untuk mengetahui informasi selengkapnya, lihat Memantau instance.

Hasil dengan database yang di-cache sebagian

Output perintah terakhir di Menjalankan benchmark TPC-B pgbench akan mirip dengan berikut, dengan --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)

Ringkasan hasil performa untuk benchmark pgbench TPC-B

Tabel berikut meringkas hasil performa untuk benchmark TPC-B pgbench:

Skenario TPC-B SCALE_FACTOR TPS Penggunaan CPU (%)
Di-cache sebagian 50000 17.460 96%
Di-cache Sepenuhnya 4000 21.750 94%

Menjalankan benchmark Khusus Penyisipan Indeks

Benchmark Index Insert Only adalah skenario yang sangat serentak dan intensif tulis yang disesuaikan di bagian ini untuk menunjukkan manfaat performa AlloyDB untuk sebagian besar aplikasi OLTP. Untuk menjalankan benchmark ini, Anda membuat beberapa indeks pada tabel pgbench_history, lalu melakukan operasi INSERT berulang kali pada tabel pgbench_history dari beberapa koneksi klien.

Benchmark Insert Khusus Indeks mengukur performa penyisipan data ke dalam tabel database yang secara khusus berfokus pada dampak indeks terhadap operasi tulis. Benchmark ini memungkinkan Anda memahami seberapa cepat baris baru dapat ditambahkan ke tabel dengan dan tanpa indeks, yang menyoroti potensi kelambatan yang disebabkan oleh pemeliharaan indeks selama penyisipan.

AlloyDB meningkatkan performa tulis PostgreSQL, yang juga meningkatkan workload OLTP. Untuk meningkatkan performa skenario OLTP yang intens menulis, AlloyDB menawarkan inovasi arsitektur termasuk lapisan cache bertingkat untuk membantu operasi baca, dan teknologi mesin penyimpanan terdistribusi dan sangat skalabel untuk operasi tulis.

Menyiapkan AlloyDB dan mesin klien

Untuk menyiapkan infrastruktur guna menjalankan benchmark Penyisipan Khusus Indeks, ikuti langkah-langkah berikut:

  1. Buat cluster dan instance AlloyDB, ganti 16 vCPU and 128 GB RAM sebagai jenis mesin.

  2. Sediakan mesin klien, dengan mengganti E2-standard-16 (minimum) sebagai jenis mesin.

  3. Siapkan mesin driver benchmark.

  4. Lakukan pembersihan benchmark.

Menjalankan benchmark Index Insert Only

  1. Hubungkan ke komputer klien menggunakan contoh perintah berikut:

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

  2. Siapkan lingkungan dengan menjalankan perintah berikut:

    export PGHOST=<private_ip>

  3. Buat database pgbench menggunakan contoh berikut. Jika database sudah ada, hapus database dan buat ulang.

    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. Lakukan inisialisasi dan muat database pgbench untuk memastikan bahwa set data benchmarking dibuat dan diisi dengan data yang realistis. Edit parameter yang ditandai, lalu jalankan perintah berikut:

    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. Pastikan output perintah sebelumnya mirip dengan berikut ini:

    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. Buat skrip index-init.sql menggunakan perintah berikut:

    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. Jalankan skrip index-init.sql:

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

  8. Opsional: Validasi skema database dan pemuatan awal:

    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)

    Setelah pemuatan, ukuran database diperkirakan sekitar 365 GB:

    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. Buat skrip index-inserts-only.sql menggunakan perintah berikut:

    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. Jalankan benchmark pgbench menggunakan perintah berikut:

    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

Menganalisis hasil benchmark

Verifikasi output perintah sebelumnya dalam file /tmp/pgbench-index-insert-only-run.out. Anda akan melihat sekitar 52 ribu transaksi per detik dan tingkat penggunaan CPU ~88% selama pengujian benchmark ini, seperti yang ditunjukkan dalam contoh output berikut.

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)

Menjalankan benchmark Select Only di Instance 64 vCPU

pgbench mendukung skenario bawaan khusus pilih yang berulang kali menjalankan kueri SELECT dari beberapa koneksi klien terhadap database yang ditentukan. Benchmark ini digunakan untuk mengukur performa baca database, tanpa menimbulkan overhead operasi modifikasi data seperti INSERT, UPDATE, atau DELETE. Kueri SELECT ini adalah kueri pencarian titik yang merupakan jenis kueri pilih yang paling cepat dan efisien karena hanya melibatkan akses ke satu baris data langsung dari struktur indeks.

Menjalankan benchmark Select Only membantu Anda mencapai hal berikut:

  • Mencapai throughput maksimum: Karena pencarian titik pada indeks adalah bentuk kueri yang paling efisien dalam sistem database, Anda dapat mengukur throughput maksimum yang dapat dicapai AlloyDB.

  • Skalabilitas: Hanya pilih benchmark yang membantu Anda menguji skalabilitas AlloyDB dari 2 vCPU hingga konfigurasi vCPU maksimum yang ditawarkan oleh AlloyDB.

Menyiapkan AlloyDB dan mesin klien

Siapkan AlloyDB dan mesin klien pada jenis mesin 64 vCPU.

Menjalankan benchmark Select Only

  1. Hubungkan ke komputer klien menggunakan contoh perintah berikut:

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

  2. Siapkan lingkungan menggunakan perintah berikut:

    export PGHOST=<private_ip>

  3. Buat database pgbench menggunakan contoh berikut:

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. Lakukan inisialisasi database pgbench. Perintah berikut menginisialisasi database pgbench dengan data realistis sekitar 220 GB. Anda menggunakan --scale=15000 untuk benchmark Select Only yang di-cache sepenuhnya.

    Jalankan perintah berikut:

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

  5. Pastikan output perintah sebelumnya mirip dengan berikut ini:

    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. Jalankan pgbench. Langkah benchmark terakhir ini memerlukan waktu lebih dari satu jam untuk diselesaikan.

    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. Setelah benchmark selesai, periksa file /tmp/pgbench-select-only-run.out untuk mengetahui hasil akhir.

Menganalisis hasil benchmark

Anda akan mengamati sekitar 467 ribu transaksi per detik dan rasio penggunaan CPU ~95% selama pengujian benchmark ini, seperti yang ditunjukkan dalam contoh output berikut.

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)

Ringkasan hasil benchmark AlloyDB

Tabel berikut merangkum hasil benchmark AlloyDB berdasarkan pengujian yang dilakukan dalam dokumen ini.

Ringkasan performa HammerDB TPC-C

Jenis Mesin AlloyDB Skenario Workload TPC-C NUM_WAREHOUSE NUM_USERS Pesanan Baru Per Menit (NOPM) TPM Kumulatif Dikonversi ke TPS
16vCPU 30% di-cache 3200 256 252.970 582.385 9.706
16vCPU 100% di-cache 576 256 428.316 974.264 16.238
64vCPU 30% di-cache 12800 1024 589.598 1.371.160 22.853
64vCPU 100% di-cache 2304 1024 716.138 1.665.438 27.757

Ringkasan performa pgbench

Jenis Mesin AlloyDB Skenario Workload pgbench Faktor Skala TPS CPU %
16vCPU Seperti TPC-B, Di-cache Sepenuhnya 4000 20.359 96%
16vCPU Seperti TPC-B, Di-cache Sebagian 50000 14.060 94%
16vCPU Hanya sisipan indeks 25000 51.742 88%
64vCPU Throughput Maks. (Khusus Pilihan) 15000 467.583 95%

Menjalankan benchmark OLTP di Cloud SQL untuk PostgreSQL

Anda dapat menguji performa OLTP yang setara di PostgreSQL di Cloud SQL untuk PostgreSQL pada jenis mesin 16 vCPU untuk analisis komparatif. Bagian ini menjelaskan cara menyiapkan Cloud SQL untuk PostgreSQL (atau server PostgreSQL apa pun yang di-deploy di infrastruktur pilihan Anda) yang sebanding dengan penyiapan AlloyDB yang digunakan dalam panduan ini untuk menjalankan benchmark performa OLTP. Dalam skenario ini, termasuk memilih SKU 16vCPU, mengaktifkan ketersediaan tinggi (HA), dan pra-mengonfigurasi dengan penyimpanan.

Sebelum memulai

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Install the Google Cloud CLI.

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

    gcloud init

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

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. Install the Google Cloud CLI.

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

    gcloud init
  10. Pastikan Anda memiliki peran Admin Cloud SQL dan Compute Viewer di akun pengguna.

    Buka halaman IAM

    Pelajari lebih lanjut tentang peran dan perizinan

Menyediakan instance Cloud SQL untuk PostgreSQL

  1. Buat instance PostgreSQL, ganti nilai berikut:

    • Versi database: PostgreSQL 14
    • Pilih konfigurasi untuk memulai: Produksi
    • Pilih ketersediaan region dan zona: Pilih us-central1 sebagai region.
    • Ketersediaan zona: Beberapa zona (Ketersediaan Tinggi)
      • Zona utama: us-central1-c
      • Zona sekunder: us-central-1-f
    • Jenis mesin: Mesin High Memory 16 vCPU, 104 GB. Ini adalah mesin terdekat yang ditawarkan Cloud SQL untuk PostgreSQL ke instance AlloyDB yang cocok yang Anda buat di bagian benchmark AlloyDB dalam dokumen ini.
    • Kapasitas penyimpanan: Kustom, 1.500 GB
      • Aktifkan peningkatan penyimpanan otomatis
    • Enkripsi: Google-owned and Google-managed encryption key
    • Koneksi: IP Pribadi
      • Jaringan: default
      • IP Publik: Diaktifkan

  2. Klik Create instance.

  3. Setelah instance PostgreSQL dibuat, catat alamat IP Pribadi. Anda menggunakan IP sebagai PGHOST untuk membuat koneksi dengan benchmark.

Menyediakan mesin klien

  1. Menyediakan instance Cloud SQL untuk PostgreSQL. Untuk menjalankan benchmark OLTP pilihan Anda, Anda memerlukan mesin klien dengan kemampuan CPU yang signifikan di zona yang sama dengan instance Cloud SQL untuk PostgreSQL utama di Cloud SQL.

  2. Opsional: Sebagai alternatif untuk langkah sebelumnya, Anda dapat menggunakan mesin klien yang sama dengan yang Anda siapkan untuk benchmark AlloyDB, asalkan hal berikut berlaku:

    • Komputer klien berada di zona yang sama dengan instance utama PostgreSQL (Cloud SQL untuk PostgreSQL) baru.
    • Komputer klien memenuhi persyaratan CPU, RAM, dan ukuran disk minimum.

    Dalam panduan benchmark ini, Anda menggunakan kembali mesin klien saat berada di zona yang sama dengan instance utama, dan saat cukup besar untuk membawa server ke kapasitas penuhnya.

  3. Jika Anda membuat mesin klien baru, siapkan mesin driver benchmark. Jika tidak, ikuti petunjuk dalam panduan ini untuk benchmark yang ingin Anda jalankan.

Langkah berikutnya