心理的パフォーマンスについて

数日前に、PostgreSQL用の完全にオープンソースの論理レプリケーションソリューションであるpglogicalをリリースしました。これは、それほど遠くない将来にPostgreSQLツリーに含まれることを願っています。論理レプリケーションによって可能になるすべてのことについて説明するつもりはありません。pglogicalリリースの発表は非常に優れた概要を示し、Simonは数日前の別の投稿で論理レプリケーションの利点についても簡単に説明しました。

代わりに、発表で言及された1つの特定の側面、つまり既存のソリューションとのパフォーマンスの比較についてお話ししたいと思います。 pglogicalページの言及

ベンチマーク

この投稿では、各ソリューションが遅れることなく処理できる最大の「持続可能な」スループット（1秒あたりのトランザクション数）を見つけるために実行したベンチマークの詳細について説明します。これを行うために、さまざまな数のクライアントを使用してi2.4xlarge AWSインスタンスのペアでいくつかのpgbenchテストを実行し、マスターのスループットとスタンバイが追いつくまでにかかった時間を測定しました（遅れていた場合） 。次に、その結​​果を使用して、スタンバイノードの最大スループットの見積もりを計算しました。

たとえば、16のクライアントでpgbenchを30分間実行し、マスターで10000 tpsを測定したが、スタンバイが遅れており、追いつくのにさらに15分かかったとします。その場合、最大の持続可能なスループットの見積もりは

tps =（実行されたトランザクション）/（スタンバイが追いつくまでの合計実行時間）

つまり、

tps =（30 60 10.000）/（45 * 60）=18.000.000 / 2.700 =6.666

したがって、その場合、スタンバイでの最大の持続可能なスループットは6.666 tpsです。つまり、マスターで測定されたトランザクションレートの約66％にすぎません。

システム

ベンチマークは、同じプレースメントグループで構成されたi2.4xlarge AWSインスタンスのペア（つまり、それらの間に最大2Gbitのネットワーク接続がある）と、RAID-0で構成された4x SSDドライブ（I/Oがここで問題が発生します）。インスタンスには最大122GBのRAMがあるため、データセット（スケール5000のpgbench）はRAMに収まります。すべてのテストは、まったく同じ構成のPostgreSQL 9.5.0で実行されました：

checkpoint_timeout = 15min
effective_io_concurrency = 32
maintenance_work_mem = 1GB
max_wal_size = 8GB
min_wal_size = 2GB
shared_buffers = 16GB

すべてのレプリケーションシステムで、特に最新の利用可能なバージョンが使用されました

• slony1 2.2.4
• skytools 3.2

チュートリアルで説明されているように、単純なレプリケーションが設定されました（どちらもベンチマークに使用されたpgbenchの例を使用します）。

結果

次に示す結果には、論理レプリケーションに関連するオーバーヘッドをより正確に把握できるように、ストリーミングレプリケーション（非同期モード）も含まれています。トランザクションレートは、pgbenchで測定された「生の」数値ではなく、この投稿の冒頭に示した式を使用して計算された「持続可能な」レートです。