ベンチマーク Aurabase Postgres: pgbench、sysbench、TPC-C

この英語のテキストはフランス語のオリジナルから自動的に生成されたもので、まだレビューされていません。

このページは自動翻訳されました。英語版が正式です。

必需品

pgbench (公式 PostgreSQL ツール、TPC-B に近いワークロード) と sysbench-tpcc (実際のトランザクション負荷をより代表する TPC-C ワークロード) は両方とも、Aurabase プロジェクトの標準 Postgres 16 接続文字列に対して直接実行されます。バイパスする独自の API はありません。このチュートリアルでは、実際の注文と、GST 数値が正当に証明できる範囲を示します。

この 2 つのツールを使用する理由

簡素化のための pgbench、現実的なための sysbench-tpcc

pgbench は PostgreSQL 自体とともに配布されます。すでに Postgres クライアントツールをお持ちの場合、クライアントに個別にインストールする必要はありません。デフォルトのワークロードは、過去の TPC-B ベンチマークに近い負荷を再現します。シンプルで起動が早く、最初の信号に役立ちます。

sysbench は、より一般的なベンチマークツールであり、TPC-C ワークロードを複製する sysbench-tpcc プラグインを備えています。これは、実際の OLTP アプリケーション (注文、支払い、在庫) を表すトランザクションの組み合わせであり、汎用の pgbench ワークロードよりも本番環境で Aurabase バックエンドが処理するものに近いものです。

準備

接続文字列を取得し、専用のテストベースを作成します。

Aurabase ダッシュボードから接続文字列を取得します。

プロジェクトのデータベースセクション、標準の postgresql://user:password@host:5432/dbname形式。

本番ベースではなく、別のテストベースを作成してください

psql "$AURABASE_CONN" -c "CREATE DATABASE bench_test;"

実稼働ベースのベンチマークを決して行わないでください

pgbench と sysbench-tpcc はテーブルを作成、設定、変更します。常に専用のベースを使用し、実際のトラフィックを処理するスキームは決して使用しないでください。

pgベンチ

初期化して最初の実行を開始する

データセットを初期化する

pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = スケール係数 (pgbench_accounts の 10 × 100,000 行)

10 台の競合クライアントで 60 秒間実行します

pgbench -c 10 -j 2 -T 60 -P 5 "postgresql://user:pass@host:5432/bench_test" # -c = 同時クライアント · -j = スレッド · -T = 期間 (秒) · -P = 5 秒ごとのレポート

結果を読む

pgbench は、接続時間の有無にかかわらず、実行の終了時に tps (1 秒あたりのトランザクション数) を表示します。スケール係数、クライアント数、実行ごとの継続時間に注意してください。これら 3 つのパラメータがなければ、数値だけでは意味がありません。

sysbench-tpcc

より代表的なトランザクションワークロード

sysbench と tpcc プラグインをインストールする

git clone https://github.com/Percona-Lab/sysbench-tpcc.git # プラグインをコンパイルするにはリポジトリの README に従ってください

TPC-C データセットを準備する

./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 prepare

ランニングを開始する

./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 --time=300 --threads=16 --report-interval=10 run

PostgreSQL 専用の sysbench-tpcc チューニングガイドが 2026 年 5 月に Percona によって公開されました。これは、代表的な実行を実行する前に shared_buffers および work_mem をチューニングするのに役立ちます。

解釈

GST 数値だけでは証明できないこと

tps は、スケール係数、同時クライアントの数、基盤となるハードウェア、および実行時にアクティブな Postgres 設定によって異なります。異なるパラメータで取得された 2 つの時間の数値は、同じデータベース上であっても比較できません。

結果を再現可能な参照として機能させるには、Postgres のバージョン、スケールファクター、クライアント/スレッドの数、実行時間、効果的な postgresql.conf 構成を体系的に文書化します。図を公開する前に適用するプロトコルについては、完全なベンチマーク手法を参照してください。

さらに進んでください

実行を再開する前に Postgres をチューニングする

ベンチマークを実行すると、多くの場合、接続の飽和、自動バキュームの遅延、インデックスの欠落など、調整の前にボトルネックが明らかになります。実稼働環境での Postgres チューニングチェックリストと max_connections のサイジングに関する記事では、実行を再開する前に確認する必要がある設定について説明しています。

よくある質問

よくある質問

pgbench と sysbench の違いは何ですか?+

pgbench は PostgreSQL で提供される公式ツールです。インストールが簡単で、デフォルトのワークロードは TPC-B に近いです。 sysbench は、PostgreSQL 上で TPC-C ワークロードを再現する sysbench-tpcc プラグインを備えた、より一般的なベンチマークツールです。

pgbench を Aurabase データベース上で直接実行できますか?+

はい、プロジェクトダッシュボードで提供される標準の Postgres 接続文字列に対してです。本番ベースではなく、専用のテストベースを使用してください。

tps の数値は 2 つのバックエンドを比較するのに十分ですか?+

いいえ。TPS は、同時クライアントの数、データセットのサイズ、基盤となるハードウェア、Postgres の構成によって異なります。公開され、同一に再現された方法論がなければ、2 つの GST 数値を比較することはできません。